Reply To: Suggested refinements

[Michael P. Flaga]

 
Thanks for the feedback your observations are very astute.
 
The call to SPI.setClockDivider(spiRate) was implemented as a safeguard. As libraries (aka Drivers) are implemented for different external resources there are often overlap. This is the case with the SPI. Where initially Bill implemented SPI settings in MP3player.resumeDataStream(), as to allow the use of other devices on the SPI, such as Temp Sensors. Where the resumeDataStream() restored the config away from whatever deviations the other SPI devices implemented. That said the SdCard is a SPI device and does not necessarily (or even typically) have the same clock speed as the Vdsp. It is faster and lead to un-reliability in reading back data. Though, miraculously it worked in sending. I re-discovered this in attempts to expand the library and then later found this stated on VSLI’s forum.
 
So yes it is more overhead to reconfigure the SPI with each block of transfer, but insignificant. It is a necessary requirement for robust and interoperable library/driver. I actually see that the SdFat does this. Never assume shared resources are what you expect.
 
As you have noted the Vdsp has a 2K buffer, where the driver transfers 32 at a time. Yes, it would appear that it would be a good idea to transfer larger chunks. Whereas there are more subtle issues at hand. First the Vdsp has a 32 byte pre buffer that does not require over fill checking. Hence this driver as recommended by VLSI is to send 32 at a time and then check. While the DREQ check is not required after each byte within the 32bytes, it is still required to allow proper time for the 32B to be transferred. Sending without waiting may cause skips.
 
It is very insightful watching a logic analyzer scope of the transfers. It reveals that Software or Timer Polling appears more efficient. Note that the library supports several methods of refilling the buffer. Please review http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/_s_f_e_m_p3_shield_config_8h.html#a4c60fb7c286789d19f9ed13a19891653 .  Where Timer method initially appears to transfers blocks and interrupt continuously feeds the buffer as it needs it. Either way it is cosmetic in that it takes the same amount of time to transfer the data. Looking closer reveals, the overhead of doing smaller blocks versus larger blocks, is mitigated by the need to check and wait for the DREQ internal transfer every 32.
 
The Due’s Extended SPI is attractive. In that it manages the interchanging of SPI configurations between assigned Chip Selects (aka channels), to avoid above mentioned conflicts. Where in reading the Due’s SPI.cpp it really is only software. The SPI_CONTINUE option is simply for the CS management, as each transfer is still individually done. Where I don’t see it transferring frames, Rather I read the spi.cpp of the SAM as transferring ONE byte at a time, not using the SAM’s internal DMA. Please point me to an example of it sending frames, Versus channels.
 
I would recommend reading the following thread: http://www.billporter.info/forum/topic/sfemp3shield-works-with-arduino-due/ as I came to the above conclusion in attempting to implement such improvements and found them not actually providing the expected benefits.
 

 

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;}