Looking to build a multi-drop sensing array where each node will contain its own low cost processor. With this, I need to come up with a robust way to get data from each of these sensors back to a master unit.

Data throughput need be minimal (thanks to the nodal processing), but it may need to operate in an electrically noisy environment.

I2C is very attractive due to suitability to the communication between master/slaves, and the availability on low cost/low pin# mcu's. However, I'm concerned with its integrity when used over cabling in noisy environments.

This pushes me toward CAN, but with seemingly additional expense.

Anyone tried remote I2C in such an environment?

 

problem 1. i2c is designed for short distances. there are tricks that can extend the range.

there are chips to extend range of i2c. i think you can use such chips to also be your "signal amplifiers". this way you don't really use their range extending feature, but simply "reinforce" the signal so that noise has less effect on the signal.

and of course there is always the use of shielded cable to protect the signal from the noise. you might also want to use metal enclosures instead of plastic to protect the signal from the noise at the microcontrollers.

 

Anyone tried remote I2C in such an environment?

Yep. Lots. A large client of mine uses I2C as its sensor backbone - each sensor array is controlled by a PIC I2C slave that gathers data, buffers it for transmission, takes commands, does local control etc. It works fine BUT, it was not trivial to develop. Noise wasn't a big deal but the protocol necessary to ensure ZERO error (and it is ZERO error) operation was not trivial. Within the instrument, we use a star topology - external we use an intrinsically safe bus that can go 30m. Again, not trivial. The protocol does dynamic address assignment of I2C slaves, keeps track of messages and retries lost ones, CRC errors etc. and accommodates multi-masters (bit-banged for a reason I2C 18F PICs). Nice, but keep in mind that while basic I2C provides flow control, arbitration etc. it does NOT by itself guarantee that correct data has been received (ACK just means that a byte has been received, not that its correct - that's the job of the protocol).

I like CAN a lot for control oriented stuff. The only drawback to CAN for my money is that its best suited for small data packets i.e. 1-8 bytes. Of something like 100+ bits of transmission, you get 64 bits of useful information. What you DO get with CAN is simplicity. Load the CAN buffer, set 'send' and if you don't get any error counts, your data got to where it was going - the protocol is a level or two above I2C and is designed for accuracy and reliability. Unlike I2C, CAN can run over different physical layers - usually its a differential pair for noise immunity. Messages have inherent priorities. The best thing is that all of the protocol is done for you in hardware. As I said, load up the transmit buffer and its done.

So, I2C is great for small, bussed networks like its intended for - EEPROMS, displays etc. Properly implemented, its pretty good. It will run rings around CAN for data throughput if you want it to. While multiple-mastering is fully specified, its not as nice IMHO as CAN and will take some effort to get it right.

For lots of short messages flying around from many sources, CAN is hard to beat. It was originally designed for automobiles to cut down on wiring. Robustness and message priority are paramount - ABS right now, glove box light later.

From what you have described, I'd use CAN.

Good luck!

 

Thank you for your excellent feedback. You have both confirmed my suspicions on two fronts.

So I'm back to to the inability to find a low pin count PIC with onboard CAN.... Microchip, are you listening?

 

How about the 18F25K80? ECAN 2.0, 28 pins, $1.90/5K
But yeah, a LPC / CAN for simple nodes would be a treat. Maybe another mfr?

 

How about the 18F25K80? ECAN 2.0, 28 pins, $1.90/5K
But yeah, a LPC / CAN for simple nodes would be a treat. Maybe another mfr?

The 18F25K80 you mention is the smallest option I can find. Definitely beats a micro and discrete driver for space and $$. Seems to me a low cost 8-bit mcu in a 16pin QFN, with a capable onboard oscillator, respectable 4 channel ADC, and CAN would be a staple for automotive guys.

 

The 18F25K80 you mention is the smallest option I can find. Definitely beats a micro and discrete driver for space and $$. Seems to me a low cost 8-bit mcu in a 16pin QFN, with a capable onboard oscillator, respectable 4 channel ADC, and CAN would be a staple for automotive guys.

Maybe take a look at LIN? Its a cheaper alternative maybe. Microchip used to (still does?) sell a CAN/LIN eval board - the idea being a CAN node hosted a lower end LIN node(s).

EDIT: I took a look at TI, NXP and ST - they are actually moving to bigger CAN parts..

Good luck!