Reply To: SFEMP3Shield works with Arduino Due

[Michael P. Flaga]

It may have worked. But it was not working for some of the right reasons.
I thought I had sent a follow up this morning, about some items I subsequently learned and some I was perplexed about.

The main purpose of the F() and PROGMEM was to avoid the tendency of C++ to place const variables, strings or arrays into and consuming RAM. A dangerous waist, when the AVR is limited to 2K and easily consumed. I don’t recall if the ARM tool chain does this, regardless the SAM3X8E 100K of SRAM is plenty.

Thanks for the links about digital read back problems. In reading the tool chains code and how the ARM’s helper functions are significantly different than the AVR’s, I see how the arduino core wiring_digital.c definition of digitalRead has problems reading back an assigned out. Yuck. This is possible on the ARM, but was skipped in the Arduino Due core library implementation, likely due to its complexity. And I see future room for improvement. (some day, I don’t even have a Due).
This read back is common on most all Micro’s I have worked with. It is common to use it, as it is an actual Register just like RAM, should be just as fast as other RAM. Keeping a copy of it only doubles the work and overhead. And in 8bitters every byte or bit counts, it is too easy to pile up. I have done it. The SFEMP3 library is very efficient on memory. As libraries should be, using as little of a footprint as possible leaving as much as possible for the main objective. You will notice this library does not store copies of parameters internal to the VDSP. But rather gets them.
Regardless the Due as is makes this convoluted. So a copy is simplest, as it has plenty of space.

About the DueExtendedSPI, I may be repeating an apparently lost posting from this morning. I read the spi.c for the Due and see the functions are overloaded with original and new enhanced. The later having the channelized Chip Selects. Where I see that only pins D4, D10 and D52 can function as automatic chip selects. Where original commands are still available, without CS and CONTINUE (defaulting to assert D52, anyways). Note the MP3_XCS and MP3_DXCS are correspondingly mapped to D6 and D7, and therefore should not work when placed into ExtendedSPI methods, they actually fall through not matching any of the allowed Chip Selects and assert SS3 (aka D78 not available) by default. I notice your forks dcs_low() uses SPI.setDataMode( MP3_XCS, SPI_MODE0 ) but note that both dcs_low() and cs_low() still have the original digitalWrite(MP3_?XCS, LOW) in them. Hence I believe the d/cs_low()’s are still asserting the correct chip selects D6/D7, making it work.

Note that while the SPI_CONTINUE is nice and sounds more efficient, the SPI.transfer with CS still while() loops and BLOCKING until the transfer is done, to be read back. No real speed increase. So the important reason for including the SPI_CONTINUE, in conjunction with including the CS, is not speed or ease, but to remove the glitch of the CS bouncing between transfers, when using the Extended method. Where it is not truly applicable in the case of MP3_XCS(D6) and MP3_DXCS(D7). As an FYI, I would mention that SdFat’s SPI for the ARM does not use the Arduino Due Core SPI functions but appears to use is own to take advantage of the SAM3X8E DMA features.

That all said I see errors or miss-conceptions in my suggested branch and need to clean them up. I don’t want to be propagating false code.