Specifications

button was pressed. The tests showed that de-bounce and the interrupts worked but the
buffer for the MP3 data kept emptying. This was surprising, because there was very
little extra that appeared to be happening then before when it worked. Even without
pressing the buttons the buffer kept emptying, but if the de-bounce thread was removed
the player now played without a problem. It was discovered that when a thread is
created, it is given a default priority of 64. What was happening was that the main
thread and the de-bounce thread had the same priority and hence were sharing a similar
CPU time. By giving the main thread a higher priority (60), the player started to operate
successfully with the de-bounce thread operating.
5.3.7.1 Play/Pause Button.
Next the Play/Pause button was given a function. Using the global variable to turn
access on and off for the decoders interface it was possible to either stop the MP3
decoder from reading any more data. The first stage was to see if it was possible to
pause the audio stream, essentially stopping the decoder from being able to read data
and also sending a command to the server to stop sending data. If the server was not
stopped, eventually the buffer would become full and the send command would
continue attempting to send but the Ethernut will not be receiving. Eventually the send
will fail and exit. Therefore, a method of passing commands from the MP3 player to the
server program was required. The design for this was to open a separate TCP
connection just for passing commands to the server. On the server a new thread was
created that simply waited for commands to be received and then responded to them. To
test the pause function the design in figure 21 was implemented.
45