Developer corner: find a good way for networking the AVR (mega88) boards
This is rather hardware related. VemsFrontier/Networking is about software/logical issues.
While the big ARM guys ( VemsFrontier/ArmEfi and IonSense ) will work nice with CAN, CAN is not feasible for ATMEGA88.
ATMEGA88 has an UART (ATMEGA128 also, except it has 2):
- FBUS point-2-point for very short distance
- RS232 point-2-point for short distance
- RS485 bus for upto 32 nodes network. The only cost efficient solution that allows several small boards (displays, dongles, ECMs) to communicate without a central HUB.
While FBUS requires no transceivers, the RS232 and RS485 transceivers are the same cost (very cheap) and availability.
Neither of the above can be used to talk to most notebooks directly: since majority of notebooks have neither of these ports, only USB.
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.
- 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. Johan, where did you upload the sch?
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).