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 GenBoard/VerThree.
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
- 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
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 normally, not so easy to solder on unsoldered pads). 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.
See also: