I would like to have the option to map all USB communication to just one virtual COM port.
The idea is to plug a RS485 stick to the PC and connect all modules via RS485. Same communication priciple as with UDP, but with a much lower HW efford. Should work quite out of the box, if one thing is considered: RS485 is half-duplex, so AgIO would have to care for time slots, e.g.:
RS485 is very robust! Further advantage: Direct use of relay modules is possible (example; there are I/O modules as well)
Thinking abaout something similar, but i want to use CAN-Bus as communication between the components and AgIO connected via USB (or UDP).
CAN is multi-master network, working very good to connect single sensors and actors like in a vehicle. Had that in mind when designing my board, too, but it has two disadvantages: a data packet is limited to 8 bytes (fix) and it’s quite difficult/expensive to connect it to Windows.
Unlike CAN, RS485 has direct support from Windows/AOG, because AgIO not even notices, whether the Nano is couples by USB or by RS485. I just made a smoke test, works out of the box for my autosteer module with an $0.99 USB-RS485-Stick:
RS485 can build a network very similar to UDP, but with minimal hardware efford and no need to config anything. As mentioned, AgIO as master would have to support time slots or (much easier) to concatenate packets to all modules to one, when talking to more than one module.
Modules need to have a cheap RS485 driver and to support half-duplex. Three options: hardware patch, clever driver or simply with some extra lines of software to control the direction of the driver like that (search for “&&&&”): Autosteer_USB_20_CMPS14_twistable.ino.txt (26,1 KB)
On my board, I needed to add the following connections:
I think most CAN systems, including the ones on our tractors, employ protocols on top of CAN that allow messages longer than 8 bytes by splitting them up, much like how networks break messages up packets. Could be something as simple as a byte that indicates a multi-part message, a byte to indicate which part this is, etc. Of course one would have to figure out how to deal with lost messages.
Check out Eterlogic - VSPE: tool for serial ports emulation
Not free but you can do all kinds of fancy things with virtual serial ports.
let’s keep it simple and free! If I got it correctly, everything starts with the reception of the GNSS string, which gives a perfect 100msec grid. So AOG takes it, does the calculations and sends the concatenated data to the virtual serial port. Autosteer has to answer 0…20msec after that packet, machinery 20…40ms. That would be all we need.
But I think for imu data more than 10hz is useful.
