Comm Matrix - VEMS wiki www.vems.hu

CommMatrix

This page is for developers to decide on communication options

Most microcontrollers have these native communication protocols:

UART (eg. for standard RS232 comm: GenBoard/CommToPC)
BUS (eg. for LCD)
SPI (eg. for knockchip, MCP3208)
I2C

All 4 types are used on VEMS GenBoard/VerThree, plus

1-wire (used for I-Button security)
CAN (used for BMW S65 electronic "DBW" CAN-throttles and idle valve)

There are other protocols used in the industry for several reasons:

high speed and target selection with a few wires (Ethernet, CAN chips are often driven from a BUS)
wireless: guess what it is for
different signal levels: in the past several standards were based on high signal levels (which sounds stupid today: think -/+8V RS232, originally -/+12V) instead of eg. symmetrically driven twisted-pair wires.
optimized for profit: USB comes to mind: instead of improving existing Ethernet with power supply, priority and user-friendly negotiation protocol (for autodetecting devices - user friendlyness makes sense), long-term intel profit dictated that a low speed (12 Mbit/s that was known to be useless for many tasks) short cablelength (prevents longer than a few m connection without switches or other intel-licensed active devices) standard had to be created that is incompatible with existing switching technology and interfaces, and has to be outdated soon with reasonable bitrate (the way to ensure even more devices can be sold). Note: this is not the place for detailed USB discussion. Anyway, fact is USB is now deep in the throats, only way forward is living with it.

TODO: links

RS232 widespread
[USB] (intel) widespread
Ethernet (Xerox) very high-speed, widespread
Bluetooth wireless (motorola)
- bluetooth-RS232 adapters now popular. Make sure to apply 100m range devices
[Zigbee] wireless (Berkeley Mica Mote)
1-wire (dallas) many small devices
firewire (texas) high-speed
CAN (Philips?) widespread in industry
RS422
RS485 and profibus
- RS485 (with auto-dir RS232-RS485 adapter) is [sometimes] used on 2nd serial port to query data (modbus or triggerframe protocol) eg. by PLC (mostly in powerplants; modbus slave; and sometimes modbus master to control frequency inverter for biomass-feed augers and section-flaps)
Raw (eg. FSK) Radio without MAC (Media Access Control): collision => data loss
[IEEE1394] firewire (twisted-pair cable impedance is 110 Ohm, similar to CAN or RS485)
ARINC mainly aviation cockpit instrumentation

ST232 / MAX232 onboard or in cable

Connectivity to existing systems (certainly including RS232) must be maintained at a reasonable cost. After that, decision is mainly statistics (of tendencies out of our control) and costs.

Reasons for max232 in the cable

max232 steals footprint from useful production functions
if the onboard max232 breaks, detecting the exact problem is needed (very tough), SMD unsoldering is needed (tough) and a new max232 (easy to ship, easy to solder). If the max232 in the cable breaks, just get another cable (it is very cheap and easy to locate the problem - swap in another). Anyone can stock a few RS232-FBUS or USB-FBUS cable the same way as he stocks DB9 connector or DSUB9 extension cables ) Note: what if the AVR breaks in the field? Should we build from NPN transistors because they are more likely to be available in the drawer :-)
when the computer side is USB, the USB-RS232 costs more than 2 USB-FBUS cables. (and FBUS-RS232 costs even less). USB is the case more and more often, number of "sold" USB ports is currently appr 6..8x of sold RS232 ports (my 2 desktops and 1 notebook has 16 USB and 2 RS232 altogether, although it might not be representative) and this number is increasing fast - there's nothing you can do, no, there's nothing you can do about it (Headlong - Queen) at all.

Reasons for onboard max232

voltage levels might be more tolerant to noise
maybe more protection of IO pins
tradition. Old-hat users already have much RS232 stuff in the drawer, but not FBUS (although they face USB-only PCs and notebooks more and more often as time passes, like any of us). They might also break cables more often, or even forget to order or lose them.

For these reasons, onboard RS232 is not a bad solution at all. Max232 will surely show up on many boards for quite some time.

Far future

CAN is mostly for communication between boards. While we want developer PCs to be part of the CAN network for testing and debugging, CAN is not likely to be the primary interface for general communication to the PC (for users) anytime soon.

Maybe in a few years when we want to move huge amounts of data for some reason, we want Ethernet onboard as well (the only cheap option today to move much data into a PC), but not for now.

Find the missing link - play this game: help to fill out the matrix. Links, products, notes...

Don't worry: 5..6 adapters cover everything we want, and 3 cover 95% of the needs.

The major communication matrix: native protocols to other protocols:

	RS232	USB	Ethernet	Bluetooth	Zigbee	1-wire	Firewire1	CAN	RS422	RS485	Radio
UART	MAX232	FTDI, Prolific	Ethernet	?????	Zigbee	DS2480B	Firewire	CAN	RS422	RS485	RadioBoard, [modules for 50..80 Euro]
BUS	16550A, all uC	FTDI, Prolific	RTL8019,CS8900	many chipsets	Mica Mote	Dallas?	Firewire	inside LPC2119, XC166	RS422	RS485	CC1000
SPI	RS232	USB	Ethernet	Bluetooth	Zigbee	1-wire	Firewire	MCP2551?	RS422	RS485	RadioBoard ?
I2C	RS232	USB	Ethernet	Bluetooth	Zigbee	1-wire	Firewire	Philips?	RS422	RS485	RadioBoard ?

The secondary communication matrix: other protocols to other protocols not needed too much but they might come handy sometime. The matrix below will be scarce.

	RS232	USB	Ethernet	Bluetooth	Zigbee	1-wire	Firewire1	CAN	RS422	RS485	Radio
RS232	X	USB-RS232 cable	Rs2Net box, ser2net on PC	BluetoothRs232	Zigbee	1-wire	Firewire	[can232]	RS422	RS485	RadioBoard
USB	x	X	Ethernet	offtheshelf devices	Zigbee	1-wire	Firewire	[can232]	RS422	RS485	Radio
Ethernet	x	x	X	Bluetooth	Zigbee	1-wire	Firewire	CAN	RS422	RS485	-
Bluetooth	x	x	x	X	Zigbee	1-wire	Firewire	CAN	RS422	RS485	Radio
Zigbee	x	x	x	x	X	1-wire	Firewire	CAN	RS422	RS485	Radio
1-wire	x	x	x	x	x	X	Firewire	CAN	RS422	RS485	Radio
Firewire	x	x	x	x	x	x	X	CAN	RS422	RS485	Radio
CAN	x	x	x	x	x	x	x	X	RS422	RS485	Radio
RS422	x	x	x	x	x	x	x	x	X	RS485	Radio
RS485	x	x	x	x	x	x	x	x	x	X	Radio

notations:

- unlikely that there is any reasonable solution
Notable solution in bold
X simple wire (diagonal)
x the other direction is the same.

Note that native protocols to native protocols is NOT needed (no 3d matrix).

TODO: translate both matrices (so the first is rather tall than wide, and the 2nd has most info on left side)

Note that the above is not all protocols ever used. Many other in-car and in-plane plane protocols exist. See CanBus for others like flexray and [OBDII standard] used for emission and diagnostic equipment.

RS232 to USB or RS232 to CAN is not too hard, since many controllers (ARMs, Atmel AVR, Philips SJA1000 even microchip PIC) has either USB or CAN and all has FBUS (from which RS232 is just a max232 away).

However USB and CAN in one uC is not common, but will be available in the IonSense generation VEMS controllers.