We don't want to duplicate their docs, but evaluate how it competes with HW implemented CAN (in LPC ARM) or modbus over serial (or profibus or similar).

Investigation revealed that caraca sw and hw is useless for us, because

* networking consumes virtually 100% of CPU time

* and still cannot talk any reasonable CAN speed (max baudrate is about 20 kbit/s)

Main questions:

* how easy it is to integrate to our firmware?

** impossible

* interrupt latency it introduces (important if the main task of uC is ignition control)

** unacceptable. It makes any useful realtime stuff impossible in our dimensions (it works for switching lights at your home, though)

CPU overhead

* Using HW uart for comm to the PC.

** For CAN it uses CPU controlled IO (with bit stuffing)

* CRC calculation?

** the flash-lookup trick (found in modbus over serial docs) can be used for any CRC calc (frees up CPU clocks on the cost of some flash usage). This wouldn't be a problem

----

Conclusion

ATmega88/168 or similar uC (or PC) with HW UART but without HW CAN can talk to the ARM efficiently at 115200 baud, but not via 100% compatible CAN protocol. The solution is to

* hook CAN transceiver on the UART of the small board and alos on an UART of VemsFrontier/ArmEfi (besides CAN transceivers on HW CAN controllers). This allows a simpler firmware implementation than with RS485 transceiver, and upto appr. 100m cable is possible in buildings with max 115200baud anyway.

* use a message format identical to CAN (11 or 29 bit ID-s and 8 byte messages and CRC)

* use a framing that is bitwise different from CAN, but efficient for UART HW (modbus over serial). This makes it incompatible with the high speed CAN, but compatibility is impossible anyway because of the different speed.