-----Urspr|ngliche Nachricht----- Von: "Katinka Mills" An: Gesendet: Montag, 26. August 2002 15:19 Betreff: Re: [PIC]: CAN or RS-485 ? > > -----Original Message----- > > From: pic microcontroller discussion list > > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Nelson Hochberg > > Sent: Monday, 26 August 2002 8:59 PM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: [PIC]: CAN or RS-485 ? > > > > > > My thanks to everyone who has given me advice on this question -- really > > good info. > > > > > > > I don't see any advantage of I2C over CAN w/18F448. > > Nor do I ! > > The cost of RS-485 using the 75176 is certainly attractive. Using one > > master to poll all the others every second to determine a once in 5-15 > > minute event has occurred then the master telling each of the slaves the > > event occurred does not make sense to me. The suggestions from > > Douglas Wood > > and Dwayne Reid of having a node check the net for activity twice before > > transmitting is intriguingly simple. snip > I prefer polling, as it guarantes (as long as a node does not crash on the > netwrok and pull it down or up) that collisions do not occur. snip Forget all this. CAN hardware will do it for you. Let's talk about worst-case. Hundreds of nodes start transmitting at the same time. Makes no difference to the dominant (low) line. All, but the highest priority node, drop off, once they notice, that their identifiers do not meet the priority requirements. This is done by a "Finite State Machine". Dropping off is no-fault condition, it only blocks the bitstream from being latched. Errors, which may occur, are detected by a cyclic redundancy check and taking care of an Error Management Logic. Multiple errors are counted, up to 128, plus or minus. After that, the device goes into a bus-off condition and into a recovery sequence. You should read that in the CAN protocol, which any CAN chip must satisfy. Anyway, the device tries again before it goes off-bus for good. CAN has a sophisticated adjustment to bit timing. Tolerance will increase within the decreasing bus speed. I don't remember all this in detail, mainly because we never had any problem except for the 80 C 150s, which are a pain in the -errr- neck. > snip That CAN specs guarantee 1 or 1.2 km at low bus speed. As bit-shift is less of an issue at really low transmission rates, I am sure you can go much farther. Regarding cost. I'm surprised that no one mentioned the MCP 250xx CAN interface tips, which were out even before the The 18 F 452. If you need no intelligence in the nodes, these should beat everything. Cost +/- 2 $ in quantity full CAN one and CAN 2 protocol, plus more intelligent reactions. 8 I/O pins, two of which can be configured as A/D, two as PWM if I'm right, the I/O have interrupt on change. Once initiated, the chips can be reconfigured via CAN bus. And some more goodies. I'm planning interface modules with these chips plus necessary buffers and reasonable lengths of cables sealed in the back part of a DIL connector. Ten of these should cost no more than one otherwise necessary, dustproof casing alone. We can build it in numbers, configure it in situ and in case of damage or fault, replace it and throw the bad one away. No service needed. We did not test that yet, but the 250xxs cannot possibly be worse than the 80P150 SLIO. By the way, two of the 250s even offer one wire transmission. I don't go for that, as long as no one has convinced me from thorough experience. You would not believe our CAN experience, when our hardware guys test new installations in the workshop. Hardware is real hardware in this case, from 3 mm sheet iron upwards. They connect the interface with one or two feet of bare wire to the sensors and magnetic valves. When they called me in for the testing the first time, I said "You're crazy, do it all over right away". They wanted to have their way and a won. In spite of a 30 kW motor with thyristor soft starter and welding machines nearby, no problems ever. For me, these facts are sufficient to switch from the 80 / 82 family to the Pic system. Regards Gerd Vieregge-Heyng gvh.ferroxon@t-online.de -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body