Combining SPI OLED Screen with constant i2C feedback

Projects Networking, Protocols, and Devices
1

Hi in there !

I'm currently working on a project involving multiple communication protocol (as far as i figured out the way to achieve my goal).

  • About the project :*

There are 3 machines. 1 Computer, 1 Teensy 3.2 I2C Master and 1 I2C Teensy 4 Slave with 3 encoders and 1 SPI Oled Screen (Adafruit 1331).

On the slave there are 3 encoders that sends the Master through i2C their values when changed (using EncoderTool library) as well as updating the Screen (with SPI). The master finally sends those received values to the computer with Serial communication to update a parameter.

Everything is fine so far. But, the idea is now to get the feedback from the computer when the parameter is moved in the software to update the encoder position (and therefore the screen). The datas then flow back from the computer to the slave following the same protocol pattern.
The application is for controlling a music software parameter which supposes the ability to feedback and update with the minimum latency and minimum drops.

The code seems to be working fine but the Screen update slows down a lot the data analysis so I cannot use it as the latency when moving the encoder increases. Whenever I remove this screen update, everything flows like a charm.

Is it linked to interferences in between SPI and the large amount of I2C incoming datas ?
I know OLED screens use a lot of ressources to run but is there a way to prioritize i2C data treatment compared to SPI update ?

I wonder if it's a matter of code being slow (due to bad coding) compared to what is capable the teensy 4 board or if the communication strategy is bad (communicating with i2C (which is not an option for me) and updating with SPI).

Hope it's clear ! Thanks in advance !

2

Generally speaking I2C and SPI are slow compared to processors used in the Teensy. A Teensy should be able to handle many serial interfaces without too many issue when the software is written well and the overall application processing requirements are within the budget.

Without seeing your code we can only give you some general patterns we see from beginners that stop them from using the processor to the full potential.

  • Killer number one is the use of delay()

Have a look at the following example to learn how to avoid that.

File -> Examples -> 02.Digital -> BlinkWithoutDelay

Generally it is a good idea to ensure your loop() runs as often as possible and code should not wait for anything. Try to avoid while loops, long loops of any kind and break up code that uses external interfaces with large amounts of data e.g. displays.

If you post your code we can give you some more specific advice.