[Jacob Geigle] had a problem. A GPS unit and a Bluetooth-to-serial were tying up all the hardware UARTs on an AVR Arduino project. “Software serial”, I hear you say. But what if I told you [Jacob] already had the board in question sending out data over CAN bus?
[Jacob]’s sweet hack creates an arbitrary number of CAN “devices” inside the Arduino code, and can treat each one of them as its own serial data channel. The “N” in CAN stands for network, after all. The trick is to create a device ID for each desired CANSerial interface, which is done in his library using the usual Arduino setup step. A buffer takes care of storing all the different channels until they can be pushed out over the hardware CAN peripheral. On the big-computer side of things, some software listens for the different “device” enumeration IDs and assigns each a virtual serial port.
While this was a hack born of necessity, we can see it as a clever opportunity to segregate information coming from the microcontroller into different streams. Maybe a debug channel, a command channel, and a data channel? They’re virtual devices, so go nuts!
While we usually see CANbus in its native habitat – inside your car – it’s also cool to think of the uses we could put it to. For instance, controlling a 3D printer. Need a CAN refresher? We’ve got just the ticket.
[Bus photo: Malta Bus; The terminus, Valletta by John Haslam. Can photo: Paint Cans by Daniel R. Blume. Horrible visual pun: I’m afraid that’s on us. You try finding images for CANbus code!]
One of the big advantages of using a mictrocontroller with a hardware CAN controller instead of emulating it in software is that required retransmissions, buffering, error corrections, filtering unwanted messages, etc… are already done in hardware and you don’t need to spend CPU cycles on it. As most of the CAN transissions are time sensitive, I wonder if the software only works in the best cases or really in all real-life circumstances.
After all, CAN is a multi master protocol, meaning multiple devices can take the initiative to start talking. You will have collisions on the bus which need to be handled.
The library depends on a Microchip 2518 or 1515 to handle the CAN portion.
I’m disappointed by the article after seeing the into picture. I expected someone to have implemented serial-over-two-cans-and-a-string within a vehicle.
I did read in the picture “can” “bus” ….
Did someone mention torrenting over CAN?
I suppose you could, but the MTU (8 bytes!) would be horrible.
https://asa.scitation.org/doi/pdf/10.1121/1.3551678
^ On characterising the frequency response of an number of cup/tin and string telephones.
Makes me wonder what the effective baud would by using and FPGA to do Inverse FFT Synthesis for transmission when harmonics are taken into account.
I realise this has very little to do with the article, and a lot to do with the picture and other people’s comments so far…
The internet does not disappoint!
What? I don’t understand even what was the result, are you trying to tell us that he used a communication protocol to send different messages?
it should be a good combination with microcom which can act as a terminal over CAN bus! https://manpages.ubuntu.com/manpages/bionic/man1/microcom.1.html
DroneCAN and Cyphal are being used more and more.