[En-Nut-Discussion] CVS Commits

[Ralph Mason]

Harald Kipp wrote:

>> The possibility of reentrant/nested interrupt handlers is an 
>> interesting idea, and clearly complicates an interrupt stack. 
>> Solutions are not hard to imagine but you need to consider (IMHO) 
>> that if you are doing something that takes that long you should be 
>> doing it in user mode anyway.  Interrupt handlers should be fast in 
>> quick work and out of there.
>
>
> In general, I agree. But MP3 feeding is a bit different.
> The latency between NutEventPostAsync and releasing
> NutEventWait may cause an out of data in the MP3 decoder
> on very high bitrates. That's the disadvantage of
> cooperate multithreading. Feeding the decoder in the
> interrupt routine avoids this problem. But I must admit,
> that my first MP3 decoder driver was for a 3.6864 MHz
> ATmega103, the 14.7456 MHz ATmega128 may significantly
> reduce the problem.


The amount of data required is totally deterministic and regular.  So 
you could have a  timer interrupt that refills it at regular intervals 
(when it's about half empty).  Then the main thread can just keep a 
buffer fill for the timer to send out to the decoder. Seems like it 
decouples it well.

I did a mp3 player with a mega103 and a STA019 a few years back.  My 
conclusion was that if I was to do it again (with an AVR) I would just 
use a  cheap sram and a CPLD to  feed the decoder, so I could write to 
it parallel and have a big deep fifo.  $3 worth of hardware makes the 
whole job simple.  Of course I was running slower and the max SPI speed 
was less in terms of clock cycles than it is with the 128.

Ralph