I have 1 Arduino Nano which is using CANBUS to communicate with the Car ECU and one OLED display that outputs the data. However, I am running out of flash and I would like to use this Nano for the data processing and another to handle the display only.
The problem is that I need the sketch to be very fast otherwise the busy CAN BUS bus gets saturated and my Arduino can't cope with.
Right now the sketch runs at 2.5ms which is great and sufficient. Most of the time usage is beacuse of the I2C for the OLED which I will get rid of by using the second Arduino.
In order to avoid extra costs and physical space usage I thought that the best idea is to communicate with the 2nd Arduino by using serial (Softserial as I already use the hw serial port).
Doing some tests I discovered that the 2 Arduinos cannot communicate reliably at 115200 using the software seria port as it reads garbage but on 57600 they are ok. Still, it takes around 8ms to send a 40byte message from the "master" to the "display" arduino.
So what happens is it makes the CAN BUS "crashing" as it cannot read fast enough.
At first, is there a way that I can do Serial.write without delaying the rest of the code? Also, is there a Softserial library that uses interrupts?
OR, what would be the best fastest choice for robust communication between the 2 of them EXCEPT I2C?
I though of CANBUS but it is a bit pricey plus it will add more messages to my network and I would not like that.
Maybe SPI? Any examples around? I already have 2 SPI devices on my "master" and don't know if there would be a problem with adding the 2nd arduino..
Why not have a separate 1 Mbit/s can bus link between the two Arduinos that only carries display messages. If you are using a dedicated chip like the MCP2515 then all the buffering, encoding, decoding and acknowledgement is done for you in hardware so there is no burden on either Arduino processor.
Because then I will need another 2 can bus modules, right?
I currently have one, I will need another one for the master and another one for the slave, correct me if I am wrong.. Then I will also run out of interrupt pins on the master, correct? But I have not rejected this way yet, I am still investigating..
Regarding the SPI, will it run reliably if the 2 arduinos are 2meters away from each other?
Data transfer speed is limited by the cable length. Reduce the speed (baudrate...) until the communication works over your cable.
AFAIR AltSoftSerial uses interrupts, but even then the baudrate can not be much higher than 38400.
Yeah so if you need code run speed then Serial is no solution..
I was wondering, in Due for example or even Teensy 3++ which has Ultra fast clock speed, does the Serial.write takes that long too?
If yes, then it totally cancels the capability of the processors!
SPI can be made much faster than Serial.
A Due may solve all your problems at once, so that no controller communication is required. Else a Mega has 4 hardware UARTs, in addition to SPI.
What's the minimum speed you could work with? 1Mbps?
Shouldn't be a problem as long as you can free up one hardware serial port (may need to use the Mega or Due as suggested by DrDiettrich). Note that the USART can be configured for MSPIM mode. Using an LTC6820 could provide an isolated interface at up to 1Mbps and cable length can be up to 100M.
I love the Nano at first because it is tiny and also because it is ultra cheap!
I could easily do my job with 115200 to 500000bps..
For the master I need the hardware serial to read data from a sensor (and the Serial event does this job perfectly without ANY delay to my code).. Can this part work using a softserial?
Yesterday I came up with another idea.. I don't mind if data on the display refreshes every lets say 50 or even 80 ms as the human eye can see 25fps (aka every 40ms) and even at 40ms the display is annoying (your brain cannot process what it is seeing well)..
So the idea is: Instead of broadcasting the 40byte array on each loop (which at the reliable speed of 57600 add 8ms=can bus death), why not send 8 bytes (around 2 ms) on every loop so it will take 5 loops to send the whole message. Plus CRC32 check so you know that everything arrived correctly! At first I thought ok let's send 3 bytes plus 4 CRC bytes=7*13ish= total of 91 bytes per whole message but then I thought I could first calculate the CRC32 and then send 8 message bytes and the last message will contain message bytes plus the CRC32.. Then the display Nano concludes the message, checks the CRC32 and shows the data on the display..
What do you think of that?