Audio Library, SPI Peripherals, and T3.6

Status
Not open for further replies.

gfvalvo

Well-known member
Hi all.

So, working on a project using T3.2 that uses both the AudioPlaySdWav class from the Audio library and an nRF24L01+ module. I’m having problems with the code hanging and my conjecture is that’s it’s due to contention for the (single T3.2) SPI bus needed to access both the MicroSD card (on Audio board) and the nRF24L01+. This is probably exacerbated by the fact that the MicroSD is accessed over the SPI during interrupts, meaning it could clobber an ongoing nRF24L01+ transaction.

Anyway, I figured I’d switch to a T3.6 first to hopefully solve this problem but also because I’ve never used one before. So, if I play Audio from the T3.6’s built-in MicroSD, does that leave all 3 of it’s SPI ports available for other uses? Also, what’s the significance that only 1 of these 3 SPIs has a FIFO?

Finally, it looks like T3.6 pins GND-throught-12 (one edge of board) and Vin-thourgh-13 (other edge) are identical to the same pins on T3.2. So, that’s where the Audio board connects, correct?

Thanks.
 
SPI on T3.6 - All three SPI busses have a logical FIFO, just SPI1 and SPI2 the size is 1 where SPI0 is 4...

For the most part you don't care, except that if have code that is stuffing stuff out, that gets interrupted, on SPI0, you have a longer time when your are receiving stuff, that you have to read (POPR) from the queue before you lose data and likewise longer on output before your queue will go empty and you have a gap in your output...

Also it at times can change how your code works for certain cases. Example with the ILI9341_t3 library, when you were going to read a pixel, the code:
Code:
	// Push 4 bytes over SPI
	KINETISK_SPI0.PUSHR = 0 | (pcs_data << 16) | SPI_PUSHR_CTAS(0)| SPI_PUSHR_CONT;
	waitFifoEmpty();    // wait for both queues to be empty.

	KINETISK_SPI0.PUSHR = 0 | (pcs_data << 16) | SPI_PUSHR_CTAS(0)| SPI_PUSHR_CONT;
	KINETISK_SPI0.PUSHR = 0 | (pcs_data << 16) | SPI_PUSHR_CTAS(0)| SPI_PUSHR_CONT;
	KINETISK_SPI0.PUSHR = 0 | (pcs_data << 16) | SPI_PUSHR_CTAS(0)| SPI_PUSHR_EOQ;

	// Wait for End of Queue
	while ((KINETISK_SPI0.SR & SPI_SR_EOQF) == 0) ;
	KINETISK_SPI0.SR = SPI_SR_EOQF;  // make sure it is clear

	// Read Pixel Data
	dummy = KINETISK_SPI0.POPR;	// Read a DUMMY byte of GRAM
	r = KINETISK_SPI0.POPR;		// Read a RED byte of GRAM
	g = KINETISK_SPI0.POPR;		// Read a GREEN byte of GRAM
	b = KINETISK_SPI0.POPR;		// Read a BLUE byte of GRAM
Won't work on SPI1 and SPI2 as this one assumes it can have 4 entries on the POPR queue, where they only have 1...

But since ILI9341_t3 library was never updated to work with SPI1 and SPI2 it did not mater. However my ILI9341_t3n library is setup to work on all three SPI queues, so the code needed to be different.

Again another issue of using SPI1 and SPI2 is a lot of libraries are not setup to allow you to use other SPI objects. Some are, like RadioHead ...

Yes I am pretty sure Audio board can connect the same on T36 as T32...
 
Thanks @KurtE. So, looking at the T3.6 schematic (but not yet the code), it seems that using its built-in SD card with the Audio Library will use the chip’s HDSC controller rather than SPI. And, I see that SPI0 and SPI1 are both available via top-side pins (SPI2 pins are all on backside).

So, I’m guessing this will work well for my application. I can have 2 SPI peripherals each with their own bus (keeping SPI1 FIFO size in mind) and Audio will play via the HDSC.

I don’t mind customizing libraries to allow choice of SPI interface. If it works well, I’ll even do a PR with the additions to the library’s GitHub.
 
Note if you are using I2S output on the Teensy 3.2, 3.5, or 3.6, two of the I2S pins are the default SPI0 pins, so you would need to use the alternate pins for these. Look at the audio shield product page for more details.
 
Note if you are using I2S output on the Teensy 3.2, 3.5, or 3.6, two of the I2S pins are the default SPI0 pins, so you would need to use the alternate pins for these. Look at the audio shield product page for more details.
Yes, I am familiar. Thank you.
 
Status
Not open for further replies.
Back
Top