Compatibility issue for Teensy 3.2 SPI bus with 4.2' epaper display and RFID module

[iqasi096]

Hello,

I was looking to use a Teensy 3.2 MCU to communicate between an E paper display and RFID module to provide an interactive scale payment system for my project. I do intend to use I2C protocols to communicate with an ESP32 to retrieve and send different variables but that is not the root of my issue at the moment.

I have set up the E paper display to only switch to my sale screen when the RFID module receives a card ID. I was also able to get these devices to work individually, I do however think that there may be some compatibility issues in the hardware when putting them all together. My hardware connections are as follows:

-RFID Module
SDA -> 18
SCK -> 13
MOSI -> 11
MISO -> 12
RST -> 6
3.3V -> 3.3V
GND -> GND

-E-Paper Display
BUSY -> 7
RST -> 9
DC -> 8
CS -> 10
CLK -> 13
DIN -> 11
GND -> GND
VCC -> 3.3V

My code does consist of classes so I went ahead and attached it at the bottom

When checking the serial monitor while running the code this is what I receive:

Dispenser Initialization - Started

Starting SPI

Starting SPI, Complete

Configuring Push Button

Configuring LED

Configuring Buzzer

Starting RFID

Starting RFID - Complete

Configuring Motor Shield

Configuring Load Cell

Configuring Display

Dispenser Initialization - Complete

_PowerOn : 35058

_Update_Full : 16779111

_PowerOff : 20038

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

_PowerOn : 35061

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

displayProductInfo L1: Fictional Product

displayProductInfo L2: $0.01

displayProductInfo L3:  / 100 g

displayProductInfo L4: Tap card to activate

_Update_Part : 16779142

If i remove the if condition in the main code here:

if (dp.isCardPresent()) {...}

my device remains in this loop so having the RFID working as a key and be able to read the card ID is essential to the entirety of the project and at the moment it is doing neither. Running any other RFID code, separate from E paper display, to retrieve card IDs work very well with the current setup so I am not sure if the EPD is interrupting the communication with the RFID module.

Any insight on this would be very helpful and greatly appreciated!
Thank you

[KurtE]

Sorry, Maybe it is just me, but it is unclear from your description what your issue is?

For example is it that your code is not working or, you are having issues getting both devices to work with each other or???

Might help others to help out if you would describe your hardware:

In particular which RFID Reader and which E Paper display.

At times you may run into issues where for example a device like a display does not work well with other devices with its MISO pin. In particular they try to drive the signal HIGH or Low even when they are not the currently active (CS signal LOW), which will cause other devices to have problems.

But again not sure if this is the type of issue you are running into?

[MichaelMeissner]

Paul has this paper on better SPI bus design that covers issues that you see when you have more than one device on the SPI bus.

• https://www.pjrc.com/better-spi-bus-design-in-3-steps/

Putting in pull-up resistors is fairly easy. I had various Teensy 3.x's running Uncanny Eyes, which uses two 128x128 bit displays on the same SPI bus as fast as possible drawing creepy eyeballs. Before I added pull-up resistors to the two CS pins, I had to slow down the Teensy speed and/or play with SPI bus timings.

The second issue of verifying tri-state behavior I haven't had to deal with, but I think others may have (KurtE?).

The third issue (using SPI.beginTransaction) involves looking in the driver source for both RFID and the display. Hopefully this has been done.

In addition to providing SPI bus locking, the SPI.beginTransaction code allows you to use a different bus speed for each device. Some devices can work with faster SPI buses, some cannot.

<edit>
Another issue with many e-ink displays is that you have to keep the entire contents of the screen in memory. It could be that each of your two apps have enough memory to run, but together they run out of memory. I went through a phase experimenting with e-ink displays, and I found sometimes I would need to step up to a Teensy 3.5/3.6 to get more memory if I wanted to use a larger display (I was doing these experiments before the Teensy 4.0/4.1 came out).

Adafruit now has a series of mono and tri-colored e-ink displays that have a flash memory chip soldered to the display, and the Adafruit library keeps the screen image on this flash memory. So when it needs to display the screen, it reads from the flash memory the portion that it is displaying on the screen, and sends that out:

• https://www.adafruit.com/product/4197

Obviously since the flash memory and SD cards also have CS pins, it would be wise to add pull-up resistors for these pins.

If you don't know what a pull-up resistor is, it is a resistor that is connected to the data pin in parallel to the normal data connection, and the other end of the resistor connects to 3.3v. This means that tpins won't float, but are pulled high if the microprocessor doesn't explicitly pull them low.

[iqasi096]

Sorry, Maybe it is just me, but it is unclear from your description what your issue is?

For example is it that your code is not working or, you are having issues getting both devices to work with each other or???

Might help others to help out if you would describe your hardware:

In particular which RFID Reader and which E Paper display.

At times you may run into issues where for example a device like a display does not work well with other devices with its MISO pin. In particular they try to drive the signal HIGH or Low even when they are not the currently active (CS signal LOW), which will cause other devices to have problems.

But again not sure if this is the type of issue you are running into?

My apologies if I was not thorough enough with my problem statement, my issue is with having the waveshare 4.2' BWR e paper display to work with the MFRC522 RFID module. I did notice the CS suggestions posted here https://www.pjrc.com/better-spi-bus-design-in-3-steps/, there is no chip select for the MFRC522 however and I am connecting both modules to the same CLK and DOUT pins designated on the Teensy 3.2. Could an issue be arising from there?? As I mentioned previously, I was able to get both my devices working individually with the connections stated above, the problem arises when I present a card to my RFID module to switch the Epaper display from one screen to another where the Teensy 3.2 would require to read information from the RFID. It is however not reading it or returning anything to the serial monitor since the if statement is not fulfilled.

[MichaelMeissner]

If the RFID reader does not have a CS pin, you likely are hosed using hardware SPI. I could imagine having a transistor that controls whether the SCLK pin goes to the RFID unit. I.e. when you are reading from the RFID, enable the clock pin so the RFID reader sees it. When you are doing the display turn off access to the pin.

An icky proposal would be to use software SPI support (usually called bit-banging) where you do the SPI work by turning on/off the CS, SCLK, MISO, and MOSI pins and doing delays, etc.

As I write this it occurs to me another way to do this is to use the SPI alternate pins. Hook the display to the standard pins (SCLK = 13, MISO = 12, MOSI = 11), and hook the RFID reader to the alternate pins (SCLK = 14, MISO = 8, MOSI = 7). When you want to read from the RFID reader. make sure the display is finished and then switch all 3 pins to the alternate value, do the operation, wait for the RFID reader to finish, and then switch the SPI pins back to the standard values.

If you go up to other Teensies, they have more than one SPI bus, and you could migrate one device to that bus. You would have to clone the library and change SPI -> SPI1 if the library doesn't have support for multiple SPI buses.

[iqasi096]

If the RFID reader does not have a CS pin, you likely are hosed using hardware SPI. I could imagine having a transistor that controls whether the SCLK pin goes to the RFID unit. I.e. when you are reading from the RFID, enable the clock pin so the RFID reader sees it. When you are doing the display turn off access to the pin.

An icky proposal would be to use software SPI support (usually called bit-banging) where you do the SPI work by turning on/off the CS, SCLK, MISO, and MOSI pins and doing delays, etc.

As I write this it occurs to me another way to do this is to use the SPI alternate pins. Hook the display to the standard pins (SCLK = 13, MISO = 12, MOSI = 11), and hook the RFID reader to the alternate pins (SCLK = 14, MISO = 8, MOSI = 7). When you want to read from the RFID reader. make sure the display is finished and then switch all 3 pins to the alternate value, do the operation, wait for the RFID reader to finish, and then switch the SPI pins back to the standard values.

If you go up to other Teensies, they have more than one SPI bus, and you could migrate one device to that bus. You would have to clone the library and change SPI -> SPI1 if the library doesn't have support for multiple SPI buses.

Hello Michael, I cant help but be confused by the complexity of wiring these two devices together on the Teensy 3.2s. I did not encounter any such drawbacks when using the ESP32, what is the reason &/or significance for connecting the clock and MISOs to separate pins for each device ?? I apologize if this is a trivial question, I am however new to this kind of implementation.

Thank you

[KurtE]

My apologies if I was not thorough enough with my problem statement, my issue is with having the waveshare 4.2' BWR e paper display to work with the MFRC522 RFID module. I did notice the CS suggestions posted here https://www.pjrc.com/better-spi-bus-design-in-3-steps/, there is no chip select for the MFRC522 however and I am connecting both modules to the same CLK and DOUT pins designated on the Teensy 3.2. Could an issue be arising from there?? As I mentioned previously, I was able to get both my devices working individually with the connections stated above, the problem arises when I present a card to my RFID module to switch the Epaper display from one screen to another where the Teensy 3.2 would require to read information from the RFID. It is however not reading it or returning anything to the serial monitor since the if statement is not fulfilled.

Again maybe it would help to see link to which one you actually have.

For example: I see this one: https://www.hobbytronics.co.uk/mfrc522-reader
And I see it for sale in a few other places.

From the description of this one it appears like it has a CS Pin which in this case is the SS/SDA pin?

From the Readme file from the library they point to:

Arduino RFID Library for MFRC522 (13.56 Mhz)
--------------------------------------------

Pin order, starting from the bottom left hand pin (in case your
MFRC522 doesn't have pin markings like the B2CQSHOP one):

| Pins | SPI      | UNO  | Mega2560 | Leonardo/Due |
| ---- |:--------:|:----:|:--------:|:------------:|
| 1    | SDA (SS) |  10  |  53      | 10           |
| 2    | SCK      |  13  |  52      | SCK`1`       |
| 3    | MOSI     |  11  |  51      | MOSI`1`      |
| 4    | MISO     |  12  |  50      | MISO`1`      |
| 5    | IRQ      |  `*` |  `*`     | `*`          |
| 6    | GND      |  GND |  GND     | GND          |
| 7    | RST      |  5   |  ?       | Reset        |
| 8    | +3.3V    |  3V3 |  3V3     | 3.3V         |
`*` Not needed  
`1` on ICPS header

Using MFRC522 with other SPI components
---------------------------------------

If you are planning to use other SPI components you just have to make
sure each have an exclusive SS (Slave Select) line.  MISO, MOSI and
SCK lines may be shared. More reference regarding SPI may be found
[here](http://arduino.cc/en/Reference/SPI).

[iqasi096]

Again maybe it would help to see link to which one you actually have.

For example: I see this one: https://www.hobbytronics.co.uk/mfrc522-reader
And I see it for sale in a few other places.

From the description of this one it appears like it has a CS Pin which in this case is the SS/SDA pin?

From the Readme file from the library they point to:

Arduino RFID Library for MFRC522 (13.56 Mhz)
--------------------------------------------

Pin order, starting from the bottom left hand pin (in case your
MFRC522 doesn't have pin markings like the B2CQSHOP one):

| Pins | SPI      | UNO  | Mega2560 | Leonardo/Due |
| ---- |:--------:|:----:|:--------:|:------------:|
| 1    | SDA (SS) |  10  |  53      | 10           |
| 2    | SCK      |  13  |  52      | SCK`1`       |
| 3    | MOSI     |  11  |  51      | MOSI`1`      |
| 4    | MISO     |  12  |  50      | MISO`1`      |
| 5    | IRQ      |  `*` |  `*`     | `*`          |
| 6    | GND      |  GND |  GND     | GND          |
| 7    | RST      |  5   |  ?       | Reset        |
| 8    | +3.3V    |  3V3 |  3V3     | 3.3V         |
`*` Not needed  
`1` on ICPS header

Using MFRC522 with other SPI components
---------------------------------------

If you are planning to use other SPI components you just have to make
sure each have an exclusive SS (Slave Select) line.  MISO, MOSI and
SCK lines may be shared. More reference regarding SPI may be found
[here](http://arduino.cc/en/Reference/SPI).

That seems to be the same one I am using. Here is the epaper display: https://www.waveshare.com/wiki/4.2inch_e-Paper_Module It seems that I have connected my RFIDs SS to pin 18 (i.e: SDA0) which is the same pin I am using for I2C communication between my ESP32 master MCU and Teensy 3.2 slave MCU. I would send values from my ESP32 to Teensy 3.2 with the help of the SCL0 and SDA0 pins. If that is distorting the RFID's ability to read and send data to my Teensy 3.2, can I just swap my RFID's SDA pin to pin 15??

Thanks

[MichaelMeissner]

Hello Michael, I cant help but be confused by the complexity of wiring these two devices together on the Teensy 3.2s. I did not encounter any such drawbacks when using the ESP32, what is the reason &/or significance for connecting the clock and MISOs to separate pins for each device ?? I apologize if this is a trivial question, I am however new to this kind of implementation.

Thank you

Bear in mind I know nothing of the RFID reader, only what you posted.

There are some SPI devices that do not have a CS pin. In this case, you need to do something so that the device does not see the traffic for other devices. This 'something' could be:

• Use a second SPI bus (not possible on 3.2);
• Use alternate pins for at least the clock (SCLK). But if the device doesn't tri-state, then you likely will need to separate MISO/MOSI as well; (or)
• Prevent the device from seeing the clock pin when you are talking to the other device.

However, as KurtE says, it likely does have a CS pin, but they named it something else. In that case, try adding pull-up resistors.

There are devices such as some of the clone 240x240 displays out there that truly do not have a CS line. For the Uncanny Eyes program that runs 2 displays, in the Teensy 4.x, we wound up putting displays on the two main SPI buses, so they wouldn't interfere with each other. Typically, we don't have enough memory to use 2 240x240 displays on the Teensy 3.2, so it is less of an issue.

Usually the problem is often the Teensy runs the SPI bus faster than other processors, so it shows up more of these hardware issues as the SPI bus speed increases. Alternatively, you can play with reducing the processor speed and/or SPI bus speed to slow down things to get things to work.

[iqasi096]

Bear in mind I know nothing of the RFID reader, only what you posted.

There are some SPI devices that do not have a CS pin. In this case, you need to do something so that the device does not see the traffic for other devices. This 'something' could be:

• Use a second SPI bus (not possible on 3.2);
• Use alternate pins for at least the clock (SCLK). But if the device doesn't tri-state, then you likely will need to separate MISO/MOSI as well; (or)
• Prevent the device from seeing the clock pin when you are talking to the other device.

However, as KurtE says, it likely does have a CS pin, but they named it something else. In that case, try adding pull-up resistors.

There are devices such as some of the clone 240x240 displays out there that truly do not have a CS line. For the Uncanny Eyes program that runs 2 displays, in the Teensy 4.x, we wound up putting displays on the two main SPI buses, so they wouldn't interfere with each other. Typically, we don't have enough memory to use 2 240x240 displays on the Teensy 3.2, so it is less of an issue.

Usually the problem is often the Teensy runs the SPI bus faster than other processors, so it shows up more of these hardware issues as the SPI bus speed increases. Alternatively, you can play with reducing the processor speed and/or SPI bus speed to slow down things to get things to work.

I have found the issue! The RFID would use the SDA pin on my Teensy 3.2 which is the same pin I use to connect my Teensy 3.2 to an I2C bus to communicate with the ESP32. I initialized the I2C bus before checking for the card ID, thus my I2C readings were blocking my RFID from sending the card ID after it receives the clock data from my Teensy.

Thanks for your help!

[iqasi096]

So it seems that I was able to run my project appropriately. I slightly altered my main slave code by moving my wire.begin(8) from setup to inside the dp.isCardPresent() if else statement found here:

void loop()
{
      // Continuosly check for rfid cards
      if (dp.isCardPresent()) {
        Serial.print("CardID: ");
        Serial.println(dp.getCardID());
        // If one is detected, toggle LED
        // and display sale screen
        dp.ledOn();
        dp.buzz();
        dp.clearScreen();
        dp.showSaleScreen(0);

        // Keep filling container until timout is reached
         unsigned long startTime = millis();
         while (millis() - startTime < dispensingTimout) {
             
          // Toggle motor depending on whether
          // button is pressed
          if (dp.isButtonPressed()) {
            startTime = millis();
            Serial.println("Dispensing.");
            dp.motorOn(255);
            Wire.begin(8);               // join i2c bus with address #8
            Wire.onReceive(receiveEvent);
           
          } else {
            dp.motorOff();
          }
          delay(500);
       }

        // Debug echo
//        Serial.println("Exiting dispensing mode.");
//        Serial.print("CardID: ");
//        Serial.println(cardID);
//        Serial.print("machineID: ");
//        Serial.println(machineID);
//        Serial.print("weightGrams: ");
//        Serial.println(weightGrams);

        // After timout, "stop dispensing",
        // and return to product screen
        dp.motorOff();
        //dp.showSaleScreen(weight);
        dp.ledOff();
        //dp.resetWeight(); //reset


        delay(2500);
        dp.clearScreen();
        dp.showProductScreen();
      }

My issue now is that I cannot get it to loop back to the beginning of the code and detect my RFID scanner after one run unless I restart my Teensy. I suppose this is due to the I2C communication overwriting the SDA pin of my RFID (both connected to pin 18/A4). Is there a way to bypass this with my Teensy 3.2??

Thanks