Michael, here some thoughts from my side.
You should look into using RS485 instead of CAN. The programming model is easier since it is just a UART. You can develop using RS232 and just switch transreceivers to use RS485 if noise is too much.
First of all, RS485 requires BUS arbitration in firm/software, and that’s why such networks nearly always conform to a master-slave-architecture. Years ago, I developed a collision-detection framework for RS485 using PIC’s and HC11’s, and it was pain in the end. Second, programming a CAN controller chip is as simple as doing the UART; nowadays you have code samples lying around for a mass of chips. (BTW: switching from RS232 to RS485 will lead you into troubles: RS485 is uni-, whereas RS232 is bi-directional)
I read that CANBUS is a preferred method for multiple sensors on a long wire. Would you agree?
It is preferred when there are multiple masters on bus and you want good collision resolution.
Right. CAN is a collision-avoidance system. This means, the chip cares about the right moment to put data onto the BUS WITHOUT destroying other frames, it re-tries, and in the end it gives you a ‘Sorry, not possible’ flag/interrupt to handle the problem from application level.
Years ago at some conveying company, we developed a distributed control system with Geode-SBC’s/Linux 2.4 at the front end and Motorola HC12’s at the field side. They were connected by CAN cables, and:
- they worked over distances of up to 200 m at bit rates of 250kb/s
- were real-time compliant
- robust & reliable
- kernel modules implementation took about 2 weeks (for one chip, an SJA1000)
- HC12 CAN firmware stack was done in 1 month
Sure, you have to invest some brain energy in a BUS and protocol design:
- what speed, what BUS length? See http://www.can-wiki.info/doku.php?id=can_cabling
- paket priorization and thus frame header usage
- if in a stochastic, event driven network - which is what CAN is made for - what’s the worst case load, and
- what is the real-time parameter one want’s to have guaranteed
Currently, I’m working on a home-automation system with devices connected per CAN 2.0. The BUS speed is about 100kb/s, I’m having 4 devices that random-cyclically produce paket streams of up to 150 bytes of user data and one device that sucks those bits, does its PID - or what-ever - calculation and puts out the control values to the BUS. Besides that there are button boxes producing broadcast events and actor prints turning on/off lights from these broadcasts.
Once a day, the host computer (which will soon be a BBB, I hope polls the devices for communication statistics and keeps them on disk. Within the last two years, these statistics show about one average problem per 2 months, where most of them where one-time, corrected by the chip. A few others were based on surveillance and plugging in the right device at the wrong place - BUS physics are critical, but simple.
So, my ‘Yes to CAN’