Sharing QSPI

[v8dave]

Hi All,

I have a touch screen connected to the SPI (MOSI, MISO and SCK) port on a MOD5234. I now have this working with an ADS7846 touch screen controller and I can read touch etc.

Now when I add SD/MMC card handling the touchscreen stops working.

I have used multiple SPI devices together on the same bus before without any issues but I can't find any information about the configuration of the SC/MMC card for the SPI to see what mode etc it uses.

Has anyone else managed to get SD/MMC working with anything else on SPI? I could move the touchscreen to other free pins and do bit banging but it would mean a re-string of the PCB design. Not something I really want to do.

Dave...

[Ridgeglider]

The QSPI driver for the SD card only supported the SD card for quite a while. Recently, support was added to allo it to "share" the WiFi interface, although w/ reduced file IO throughput. If you are on the 5234, consider using the eTPU-based SPI /pinsdrivers for a 2nd interface. There used to be a description of how to share SPI for SD and WiFi on the NB WiFi pages, but I don't see it anymore.

[v8dave]

Thank RG.

I think I might have it working. As I don't read the touch screen until the user touches iy, I have used a Semiphore between that and any calls to the File System. My file access is only periodical anyway so this should suffice for this system.

At least the SPI for both are configured the same so in this instance it will work. Not so sure about devices with different CLOCK phases.

I have no spare eTPU functions left on this design. All are used up. I will consider it for the next generation but for now it seems to work quite well.

Dave...

[v8dave]

Yes. It works. As long as I init the SPI for the touch screen after the file system is initialised, they both work. If I do it the other way around, the touch screen controller does not respond.

I am using a Semiphore to hand the access to the SPI and this seems to be working well.!! I wrap any file system commands with a Pend and Post.

Nice. I like this Netburner system. The speed of the graphics display with it running, even in debug is pretty amazing. Even faster in Release mode.

Dave...

[v8dave]

After receiving a request to post how this done from Jonp I thought I would post for anyone else interested in how I got it working. By the way, the same principle applies if you are using I2C etc in different tasks.

First of all I created a semaphore for the taks that will use SPI. Then I simply pend for the semiphore prior to making the SPI based calls.

OSSemInit(&SPISemaphore, 0);
OSSemPost(&SPISemaphore); // Have to do this or the first pend call would pend forever.!!

Not sure why I had to do the post after creating as this same code work with UCOS II on the Rabbit system without the initial call to post.

This is the touch screen controller SPI calls. Each call is wrapped with the pend and post calls to the semiphore.

OSSemPend(&SPISemaphore, 0);
ts_spi_cs_lo();
QSPIStart(TouchSend, TouchReceive, 3, &QSPI_SEM);
OSSemPend(&QSPI_SEM, 0);
ts_spi_cs_hi();
OSSemPost(&SPISemaphore);

Then where I used the calls to the FFS I simply put a pend before and after each call. This does mean that there is a possibly longer pause between these but it avoids me modifying the main libraries. For me this works as I don't need touch screen control whilst accessing the filing system. In most cases other than the init call, these return quickly.

This is the init call to the flile system.

OSSemPend(&SPISemaphore, 0);
InitExtFlash(); // Initialize the SD/MMC external flash drive
OSSemPost(&SPISemaphore);

Sample of a call to read a file

OSSemPend(&SPISemaphore, 0);
Status = ReadFile(BufPtr, "USB.ROM", NumBytes);
OSSemPost(&SPISemaphore);

Hope this helps. Beware, that for me this worked because both the SD card settings for the SPI where the same as the touch screen controller. If your devices are different, you will have additional code to save and change the SPI settings before you make calls to you own SPI hardware.

Dave...