Problem displaying RFM95 data (Teensy 3.2)

Status
Not open for further replies.
K

KaDubb

New member
I am trying to display data from an RFM95 module onto a 1.8 tft display.

I have no problem operating either device using SPI.h.

However, when trying to operate them together, the display quits after the first instance the RFM95 is encountered. The RFM transmits and receives, the program just won't display the data. If I simply comment out the RFM statements, the display works flawlessly.

From a hardware perspective, my only thought is I am using pin 10 as CS for the display and 7 for the RFM. Is there an issue using that combination of pins?

Any other thoughts?
 
There are some devices that can't share a SPI bus. I've seen posts that for problematical devices you need an external tri-state buffer for the devices.

Next step is to look at the drivers for both the RFM and your display. See if they have #ifdef SPI_HAS_TRANSACTION in the source. If both device drivers have the code, it means the driver has been ported to use SPI.beginTransaction and SPI.endTransaction to properly announce they want control of the SPI bus. If one or both drivers don't have this, then you may need to modify the drivers to add it (and then try to convince the driver authors that they need to add the support).

It could be that the devices need to run the SPI bus at different speeds or with different bit orders. For example, I've found with certain OLED displays, I often have to choose a slower SPI bus speed particularly if I'm using a Teensy 3.5 or 3.6. You can change the bus speed with the argument to SPI.beginTransaction that uses SPISettings to set the bit order and SPI bus speed.

I see the Adafruit RFM95 board does not have a DC (data/command) pin that many SPI displays have. It may be that the RFM95 sets things up to use SPI 3 wire mode instead of SPI 4 wire mode, but the device might be in 4 wire mode.

Some Teensy SPI devices (mostly displays) have special speed ups if you choose the CS and DC pins to be in a set of special hardware pins and the device uses DMA in the background (and hence might be transmitting after the SPI calls, which is why you need to coordinate the SPI bus). However, some of these special pins overlap, and if you use one for a fast SPI driver, you can't use the other. The special pins for Teensy 3.2/3.5/3.6 are:
 
Status
Not open for further replies.
Back
Top