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: 1. they worked over distances of up to 200 m at bit rates of 250kb/s 2. were real-time compliant 3. robust & reliable 4. kernel modules implementation took about 2 weeks (for one chip, an SJA1000) 5. 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' ;-) HTH .M -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
