Reply To: Suggested refinements

[Michael P. Flaga]

YES, what you want to do is actually already built in to this library as a configurable option. As mentioned above the SFEMP3ShieldConfig.h can be configured to implement the refilling method as either a timer or soft poll. This works out well with other implementations that I have done that require non interfering interrupts. Simply setting the USE_MP3_REFILL_MEANS to USE_MP3_Polled allows the use of the MP3player.available(); command in the main loop to fill the buffers, outside of interrupts (aka real-time). And further specifying it to USE_MP3_SimpleTimer along with having the prescribed optional library installed cause the refill only to fill on a scheduled period. The only draw back is the pause and resume commands have issues, in these modes. But will do exactly what you described.

Note that this library depends on SdFAT, not developed here. Where SdFAT caches 500 bytes. This is good and bad. Cache is good until you need to fill it. It is this filling that if done in while in an interrupt causes the lack of real time. So by using not using the USE_MP3_INTx refill realtime is spared.

If you are real concerned about the precision of the Step Motor pulses I would recommend using the OutputCompare functions to pre-program the cycle time of the next transactions and then update it latent before the next toggle. It similar to the Timer, but it toggles the pin at that hard time regardless of any other code and or interrupt, then creates an interrupt for servicing.

As for the efficiency of the ExtendedSPI features, it is purely software no hardware. If you read into the code of the Due’s (aka SAM for ARM) SPI.CPP it is simply keeping track of the CS for you, in code, no hardware DMA. It still has the same overhead. One’s application still has to send the data one byte at a time and still check the DREQ status every 32 bytes. The real potential benefit here would be to make the SPI transfer non-blocking for a FRAME, either soft are DMA. But then one needs to add FINISH interrupts and more complexity. Especially on receiving, as each receive is linked to a specific transmit in the case of the SPI. Unlike the case of Serial UART, where rx and tx are a-coupled. As a result their are trade offs. In this case it becomes more confusing to have the library do the same thing two different ways and no real benefit.