VemsFrontier/NetWorkHardWare

Developer corner: find a good way for networking the ARM and AVR boards

This is hardware related. VemsFrontier/Networking is about software/logical issues.

Physical layer overview: why we like CAN transceivers everywhere

Many devices only support FBUS because of space constraints:
  • round small display
  • mobile phones
  • Nintendo Gameboy

For the above reasons, CAN was chosen as our primary network solution on physical layer.

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 ?

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 would need same software as the CAN-UART implementation (which needs only 1 CAN-transceiver).


LIN protocol - an alternative TODO: reevaluate it

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


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:

Fortunately the Texas transceiver works with both buses, but it's better to decide about the voltage now.

Any decision on this?


Conclusion

It's very important to understand: having the displays (GBA, IPAQ, round see note below) that only support UART, we really have no other options: we must make CAN-UART work.

Notes:


See also