SPI vs I2C

Status
Not open for further replies.

KrisKasprzak

Well-known member
All,

I've built a data logger for a small electric race car using an Arduino Nano. The data is logged to and SD card and displayed on some OLED displays across a 6 foot wire. I've had TONs of problems where my Arduino would lockup and I'm pretty sure it's due to the I2C bus. After installing some pullups, current limiting resistors and shielded cable, i think i've solved my lock up problem. However there's not enough RAM for larger fonts. Hence I'm moving everything to a Teensy.

I would like to change my display to a 2.4" TFT SPI to get bigger fonts, the display is SPI and i've got a working prototype (all mounted on a breadboard). It works like a dream, but I'm not sure how reliable it will be if i have a 6 foot wire to the display. Anyone have any insight as to if the SPI is more reliable in this configuration?

Thanks in advance.

Kris
 
Various ways to improve signal integrity:
  • Slow down the clock
  • Use a different electrical standard and wire protocol, such as rs485 or Ethernet
  • Convert the signals to differential
  • Add a processor near the display to perform error correction
 
FWIW, on the 128x128 OLED SPI displays I've used, if I use a program that uses full DMA support to update the displays (uncanny eyes from Adafruit), I have to reduce the clock speed (wire length is about 6") so that the display doesn't glitch. On the Adafruit displays, I have to reduce the clock speed to 24Mhz, while on the New Haven displays, I have to reduce the clock speed to 48Mhz. The TFT LCD displays that I've tried (Adafruit and random ebay) can be run at the fastest clock speed that the 3.6 can run at.

I have heard about people using RS-485 send SPI signals over a distance: http://www.deathbylogic.com/2014/10/spi-over-long-distances/
 
Having been playing with this recently can confirm the unsurprising fact that the basic SPI displays are very sensitive to clock speed vs cable structure.

Do you have access to a osciliscope? Since that'll make a big difference in trying to tweak the maximum performance in your wiring, at your cable length with your display. In my case with three displays along 20cm of wiring harness 8mhz was fine but the higher speed options didn't work until I improved wire spacing and added termination resistors. Still can't get the highest speed the Teensy 3.6 is capable of but got it good enough given this is on a bread board.

One problem with SPI displays is that the number of signal lines can cross talk in interesting ways, so I could see the DC and CS signals mixing into the Data lines, which also impacts high speed operation (bit bashing libraries normally have these switched and settled by the time data and clock are active).

So yes you can probably make it work, but it'll involve some careful design work and some worst case testing before you lock things in, and may be easier to put a micro behind the display to push lots of pixels, and have your controller talking slowly to it with just the variable values (if possible on a balanced line). With any testing you do make sure your motor is online and running across the full range of speeds/loads, especially any where a frequency matchs your chosen clock rate.

Remember both SPI and I2C are designed for signals across a single PCB, so this is well off the envelope for what they are designed to do.
 
Another idea, if you need to show some data, like speed, etc, not a video from camera, may be it would make sense to replace the cable to BlueTooth/WiFi and remote screen to something like Android phone, or another Teensy with its local screen?
 
but I'm not sure how reliable it will be if i have a 6 foot wire to the display. Anyone have any insight as to if the SPI is more reliable in this configuration?

The 24 MHz SPI for those displays is very unlikely to be reliable, or perhaps even work at all, over 6 feet of wire.
 
Status
Not open for further replies.
Back
Top