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 work nice with CAN
- a CAN transceiver might be added to v3.x so at90can128 can be used
- CAN is also possible with ATMEGA88/atmega168 with the help of http://caraca.sourceforge.net but speed is limited and CPU overhead is significant
Physical layer overview: why we like CAN
- 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).
- 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. ARM processors with CAN controllers and onboard CAN transceivers are preferred except the most minimal designs. FBUS is freely available with any uC we use, and bigger boards will also feature connectivity solutions 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]
- symmetric drive for twisted pair preferred
- [SN65176B] makes symmetric (shielded pair) serial bus possible apparently same as ST485A
- ST490A or other driver
- you can experiment with v3 midOPA if you have no other choice
- physical ring
- physical bus:
- with collision detection
- or sg. like a token-ring
- 1 master + N slave (good enough)
- physical star: a board with many serial connections
The RS-485 is basically an update of the RS-422 specified for multipoint buses to be constructed. This standard meets and improves all the requirements of the RS-422 allowing, in addition, up to 32 drivers and 32 receivers can be connected to a single bus. [ST] site. TI has many cost efficient transceivers.
[modbus] goes hand in hand (as a practical upper layer) with RS485, although RS485 is just the physical layer and modbus is not a requirement.
RS485 on VemsFrontier/ArmEfi
- 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
LIN protocol - an alternative
- 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 seems to be the most widely used interconnection standard in the industry for low cost controllers and sensors.
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. authtication button). Between boards it's suboptimal, IMHO.
- RS485 is a low cost version of CAN. Definitely a nice direction. Both are nice, depending on speed requirements and application cost (used uC: atmega88 or ARM).
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.
See also