Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 2 of 2

Thread: Problem displaying RFM95 data (Teensy 3.2)

  1. #1
    Junior Member
    Join Date
    May 2018
    Posts
    2

    Problem displaying RFM95 data (Teensy 3.2)

    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?

  2. #2
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,954
    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:

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •