Developer corner: find a good way for networking the ARM and AVR boards
This is hardware related. VemsFrontier/Networking is about software/logical issues.
- the ARM ( eg. VemsFrontier/ArmEfi and IonSense ) will communicate with the HW CAN controller, upto 1 MBit/s
- a CAN transceiver might be added to v3.x so at90can128 can be used for 1Mbit/s with the HW CAN controller
- VemsFrontier/Networking/Caraca does not allow small uC with UART but without CAN controller HW (most notably atmega88/168) to talk CAN at any reasonable bitrate, especially with executing useful functions at the same time.
Physical layer overview: why we like CAN transceivers everywhere
- FBUS point-2-point for very short distance. This is the most cost efficient to connect to most recent notebooks, that only have USB, not RS232.
- round small display
- mobile phones
- Nintendo Gameboy
- RS232 point-2-point for short distance. This is the traditional connection, so connectivity solution required for psychological reasons. Cost to connect to most notebooks (USB) is higher than FBUS, but still relatively low.
- [[RS485] differential push-pull driven bus for networks upto 32 nodes (and beyond) on a segment. The most cost efficient high performance network solution. The only cost efficient automation network solution in buildings, where >40m segment lengths are required. Because of the push-pull drive, a "transmit enable" signal is needed between uC and the [transceiver] besides the GND/RX/TX. A (possibly elected) master controls bus arbitration. Most designs of professional networks are based on this (eg. profibus).
- CAN is a differential bus, that is not push-pull, but open collector driven, and pullup/down applied to maintain the "inactive state". So smaller line lengths are allowed (than RS485) for the same baudrate, but 40m segment is usually enough in a car. Bus arbitration takes place based on priority word at the beginning of each frame (using the open-collector bus, the "lower" priority wins). Because the drive is not push-pull, "transmit enable" signal is not needed between uC and transceiver just GND/RX/TX (TX=high will disable any transmitting)
- LIN and 1-wire are connectivity solutions. Worse spec than CAN or RS485, and higher cost than RS485. 1-wire is even higher cost than CAN, but the only way to talk to the nice ButtonImmobilizer authentication devices.
For the above reasons, CAN was chosen as our primary network solution on physical layer.
- ARM processors with CAN controllers and onboard CAN transceivers are preferred (because they are real CAN, upto 1Mbit/s ). On ARM uCs, we add CAN transceiver also on an UART (besides the CAN controller ports).
- on small uCs, without CAN controller, but with HW UART (most notably atmega88/168) CAN transceiver is added to the UART TX/RX. This allows a 115200 bit/s networking (naturally not compatible with the 1Mbit/s CAN buses), that is identical to CAN from the application's point of view (but firmware driver layer is different). Datalink layer is similar to modbus over serial so UARTs are used efficiently.
- most minimal designs: FBUS is freely available with any uC we use
- bigger boards will also feature connectivity solutions (max232 or similar on a HW UART) like RS232 for some time
Fortunately, [bridging ]either of these to USB is simple and cheap. It is normally just a "cable" with some circuitry inside.
RS232 and FBUS not only needs bridging to notebook, but also needs a HUB when more than 2 nodes are used. [converters]
[modbus] goes hand in hand (as a practical upper layer) with RS485 (see modbus over serial), although RS485 is just the physical layer and modbus is not a requirement. Modbus over serial would work with CAN transceivers also (not just RS485); advantage would be less overhead on small uC-s but possibly incompatibility with real CAN segments (the same way as different speed CAN segments are incompatible as well).
RS485 on VemsFrontier/ArmEfi - dropped
We have CAN anyway. Would we want to use RS485 or CAN transceiver on one of the UARTs ?
- 2 UARTs with LPC... is costlier than we thought, because every UART robs 2 PWM channels, so 2 UARTS means 4 out of 8 PWM is lost. We are sortof short of PWM on VemsFrontier/ArmEfi (although 4 should be enough), but not on other boards: mostly softpwm is good, HW PWM is nice for:
- WBO2 pump (for each WBO2 channel)
- injector PWMing (2 preferred for 8 injectors)
- SMPS (switching supply, eg. for CDI)
- misc analog output (softpwm is usually OK, but soft+HW pwm can do 12+ bits with high freq). This is available everywhere, since VemsFrontier/ArmEfi has only 1 WBO2 and no SMPS and IonSense has no injector PWMing.
- CAN to anything (RS485; or RS232 that is only used for PC; or parallel bus like LBUS that is only good onboard) is cheaper than we thought: http://caraca.sourceforge.net/candongle/index.html but software implemented CAN is very limited in baudrate and costs many CPU clocks.
Conclusion
We probably want CAN on as many boards as possible, including the 9343 display.
I'm afraid that 2 networks both CAN and RS485) would be costly to support originally. When we sell 10000 boards, we can maybe rethink this and invest in some development and use 2 networks from than on. The only difference this makes is that smaller sensor-controller boards (made from LPC2129) will have more IO than if they were atmega88 based. But the connector (and supply-connection!) costs dictate the same anyway.
Also, CAN is a sales pitch
I2C and I2C-CAN
- I2C I guess I2C would work the same way (between boards) as 1-wire. Very well with good grounds. Trash with ground-problems. If someone makes proper GND and GND5 network, I2C would work. But there is high risk people would tend to power big boards (unintentionally) through the SDL/SDC lines (like they not-so-rarely forget GND5 and power from GND5 despite all bold warnings)
- I2C over CAN phy to remote MAX7313 or 6956 seems good first, but 2xCAN transceivers needed, MAX GPIO is expensive (compared to say atmega168, or even AT91SAM7A3) and trash logistics.
I2C would need same software as the CAN-UART implementation (which needs only 1 CAN-transceiver).
LIN protocol - an alternative TODO: reevaluate it
- Transceiver like [Microchip LIN transceiver] connects to UART with no other components needed (like RS485)
- more expensive than RS485 - but still on the cheap side (unlike CAN)
- lower bitrate than RS485
- shorter distance than RS485 (would not be showstopper)
- similar, but even lower cost solution is a resistor for RX and an NPN (with internal base resistor) and slight pullup for TX.
For above reasons, RS485 woule be the 2nd after CAN (the chosen primary network). LIN will only be supported if it comes "free" for some reason.
I'd (sloppily) say that
- LIN is a low cost version of Dallas 1-wire. But we only use 1-wire when we have no other choice (eg. authentication button). Between boards it's suboptimal, IMHO.
CAN transceiver and CAN voltage
MCP2551 and Texas CAN transceivers are competing, but they are both SOIC8 and pin and function compatible.
Both support 3.3 or 5V IO to the uC (eg. MCP2551 thresholds are guaranteed ViH above 2V, and ViL below 0.8v)
power:
- 5V CAN might be more tolerant to noise ?
- 3.3V CAN. Since onboard IO will be 3.3V in the future, this eliminates an extra supply.
Fortunately the Texas transceiver works with both buses, but it's better to decide about the voltage now.
Any decision on this?
Conclusion
- It would be nice to forget CAN-UART, and go with real-CAN for everything
- in real life we DO HAVE CAN-UART because our round uses atmega168 (it cannot tolerate real-CAN anyway because of footprint and supply requirements of ARM)
- in the network, we'll require to have an ARM device on the CAN-UART bus. The CAN-UART bus will not be operable without this master. This relieves us from the extreme stress to roll the bus-master-code (or even worse, a token-ring like arbitration protocol) in 3..4 kbyte flash on AVR core. This is not a serious requirement, we can use a powerful ARM-based boostcontrol dongle or VemsFrontier/ArmUfo to be master.
- we'll need to be smart with the pricing (of course): price of network install of 4 ECM-s shouldn't cost more than 2.5 x price of 1. The only way this can be handled technologically is relatively cheap HW and suitable software licencing.
See also