PiTFT + XBee like RF module = SPI conflict !

[younitty]

Hello !

We just installed our newly acquired PiTFT 2.8 Capacitive touch screens on a Raspberry Pi B+ on which we already had an Arduino Connection Bridge we had to use to connect a radio module only available under XBee socket. (See links )

The screen works perfectly in every aspect when installed directly on the Pi or when using separated wires when the Arduino Connection Bridge is installed.

Everything changes when we activate the small program we made to send radio packets using the RF chip. Both use the SPI bus so there's got to be a clock related synchronization issue here. The screen becomes all fussy and our little program itself freezes.

Any idea where we could look at to fix this ?
We will ask the same question of the support forum of the company that sells the connection bridge and RF chip we use.

[adafruit_support_mike]

I don't think there's any way to work around that.

The PiTFT display is controlled by a kernel module, and your own SPI code will run as a userland process. Sooner or later the process will get swapped out while it's trying to communicate via SPI, and the kernel will update the screen without knowing or caring what the userland code is trying to do.

The fact that the two pieces of code operate at different levels of abstraction makes it impossible to synchronize them without adding new system-level functions.

It would probably be easier to move the second SPI bus off to a microcontroller and communicate with that through a Serial connection.

[younitty]

No way to assign the display to SPI_CE1 instead of CE0 ?

[adafruit_support_mike]

Changing the CS pin would work if both devices were being called from the same program.

It won't stop the OS from suspending the userland code halfway through a transaction with the RF module, changing the CS pins (aborting the transaction as far as the RF module is concerned), updating the display, then swapping the userland code back in with a dead connection.. possibly within a loop that thinks it's just tested the connection to make sure it's good.

[younitty]

This is starting to get out of my sphere of expertise.

I have two devices on my Raspberry Pi that should be able to act as SPI slaves... i mean this is the whole point of having a "BUS" communication circuit... To allow multiple entities access to the same circuit.

What can i try to make this work ?

If nothing could be done then i think your product page should clearly mention that the display cannot work on a Raspberry Pi assembly already using some other device on the SPI bus.

[adafruit_support_mike]

Ah.. your definition of 'bus' is a bit too broad.

Calling something a bus protocol doesn't imply transparent expansion to multiple devices. It just means the protocol doesn't make multi-device communication fundamentally impossible. Any time you put multiple devices on a bus, synchronization, bandwidth allocation, and collision prevention/detection/recovery become the designer's responsibility.

In this case, it isn't strictly impossible to use the RasPi's SPI bus to communicate with both the PiTFT display and another SPI device, but you'd have to handle both at the same level so you could synchronize them. That would mean writing a kernel module for the other device. With proper OS scheduling, you could guarantee that the two devices never interrupt each other.

That would be a serious challenge though.

Your most practical option would be to use software SPI on a different set of pins to handle communication with the non-PiTFT device. It wouldn't be as fast as hardware SPI, but would sidestep all the problems of trying to share a bus with a device that needs 320x240x24==1.8 megabits of data per frame update.

[younitty]

My RF module is physically using SPI_CE0...
Your PiTFT displays are connected using a bunch of separated wires and everything is working fine as long as i do not use the software we made that uses the RF module... i could connect the display so that it talks on SPI_CE1...
...Would it solve the issue ?

For now making this particular connection doesn't work because the software expects SPI_CE0... But is there anything i could do to change this ?

We purchase more than $200 worth of Adafruit displays and we just cannot use them... It is as frustrating as saying that we purchased PC monitors but we cannot use them because our PCs contain Ethernet PCI cards !!!...

[adafruit_support_mike]

PCI is a plug-and-play backplane. Each device basically has its own microcontroller to manage the resource allocation and collision detection/prevention protocol.

SPI is far less complicated. This situation is more like an old-fashioned IRQ conflict, where it wasn't at all unusual to find that a new graphics card would disable your Ethernet card, or vice versa. The PCI comparison would be something like, "trying to wire two cards together so you can plug them into the same slot."

The capacitive PiTFT uses CE0, and that's coded into the kernel driver. You can change it to CE1 if you're willing to edit the code and compile your own kernel. Even if you do, you'll still have the inherent timing problems of trying to control an SPI bus from the kernel and userland code without having the two of them trip over each other.

It would be much less difficult to use a software SPI connection for your other device, using pins that the PiTFT doesn't. That would make the devices independent of each other.