PDA

View Full Version : About to start serial communication project



Branmuffin Industries
05-11-2008, 01:07 AM
I've visited the propeller object exchange and found numerous I2C drivers and objects by Mike Green, James Burrows and CAPT DAVE.

I'm designing a system where one master propeller will talk to six slave propellers, and I'm thinking of using I2C for the job. This will be in an automotive environment and near high voltage (+150 VDC)

Is I2C the best protocol for this job? I think it will let me assign serial IDs to each of the slaves so the master can know who it is talking with.

What do you guys think? Is there an easier way to get started?

-Ryan Brandys
Branmuffin Industries

Rayman
05-11-2008, 01:23 AM
If low pin count is the main priority, then I2C is the way to go...

Mike Green
05-11-2008, 01:30 AM
In any discussion of communications between devices, particularly in an electrically noisy environment, you're leaving out several facts: How far are these devices from each other? What speed do you want to transfer data at?

You're also putting way too little priority on the noisy environment.

I2C is a logic level protocol and there's nothing in the protocol for error detection and recovery other than a signal (ACK/NAK) that indicates that the slave did or did not understand part of the data (not all of it).

Full voltage (+12V/-12V) RS232 is better and RS485 with shielded twisted pair wiring is better, but you need some kind of error detecting / correcting protocol on top of that. You could easily use Kermit, which is very well documented, and add an address byte in the message header.

Rayman
05-11-2008, 02:48 AM
I think I would go RS232 if you can spare the pins/cogs on the master...

Chuck Rice
05-11-2008, 07:34 AM
I have 4 propboards communicating with each other using a modified FullDuplexSerial.spin and an fifth serial connection via XBee to a XBee on my laptop. I am using a packet system with a 8 byte header, and any number of string and numeric data chunks, up to a max of 255 bytes per packet. I am using TTL level connections between the 4 boards, but RS485 would be better in your environment (my 4 boards are inches apart). All packets are sent asynchronously with a main receive loop that will redirect packets between slave boards. The receive loop on each board drives function methods for each type of packet and these methods can respond with a response packet, also async. I have seen some error packets, but I am still debugging. Based on what I have done, what you are looking to do appears doable.

Propability
05-11-2008, 08:37 AM
When you mentioned automobile I thought of the CAN BUS system http://en.wikipedia.org/wiki/Controller_Area_Network. Never have used it but the chips for interface should be rather numerous and maybe inexpensive. Here is one that is in a 8 pin dip package. http://www.modtronix.com/product_info.php?products_id=112

Pete

Peter Jakacki
05-11-2008, 09:50 AM
Without a doubt I would say RS-485, or even a slightly modified version for the automotive industry called J1708 which uses RS-485 chips in a collision detection mode.

If you use straight RS-485 you can communicate at high speeds over a common twisted pair. Addressing can be done in a number of ways, there is the MODBUS method with the first character after a gap being the address character or else you could use 9-bit mode for data or command bytes (kick me, I have a number of serial routines to clean up and release).

Being near 150V is not a problem, it's what is happening with the 150V that might be a problem, but RS-485 does a good job of rejecting common-mode noise. Remmber you need to terminate the twisted pair properly to reduce reflections especially at high baud rates. J1708 is only spec'd for 9600 baud but it is an automotive standard.
www.kvaser.com/can/misc/j1708/j1708.htm (http://www.kvaser.com/can/misc/j1708/j1708.htm)

One thing that anybody needs to think about when connecting multiple micros in a network and especially during development is how the heck do you load new firmware into them and debug them? Whereas RS-485 is fine for the runtime environment you need something more akin to the full duplex serial coms that is used to load each prop. To get around this you might just have a header for initial programming and then load some network boot software that allows you to reprogram the eeprom over the network.

Propability: Those MCP2551 are only the drivers, you still need the controllers as well.

*Peter*

Branmuffin Industries
05-13-2008, 10:18 PM
I see they make RS-485 transceivers, but I wasn't able to find an RS-485 object in the Propeller Object Exchange.

So, I took a look at CAN Bus transceivers, and found this available from digikey:
http://parts.digikey.com/1/parts/497540-ic-transceiver-can-hi-spd-8-soic-mcp2551-i-sn.html

Here is the datasheet for this chip:
http://ww1.microchip.com/downloads/en/DeviceDoc/21667E.pdf

And here is an object in the object exchange that says it is compatible with this chip.
http://obex.parallax.com/objects/227/

I hope I am on the right track.

I will let you know how it progresses.

-Ryan

Mike Green
05-13-2008, 10:38 PM
There's no RS485 object because RS485 is an electrical (signal) specification, not a protocol. You would use something like FullDuplexSerial or Simple_Serial to drive it.

Ken Peterson
05-13-2008, 11:02 PM
Mike: Exactly what I was going to say, but FDS and SS don't handle networks by themselves. For this one would need a new object, perhaps incorporating one of the simpler serial protocols - especially if it is a master-slave configuration.

Media access with collision detection would require something entirely different for an object.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Ken Peterson) : 5/13/2008 4:08:44 PM GMT

Branmuffin Industries
05-14-2008, 04:27 AM
Here's an excerpt I found on the CAN bus on another website:

"CAN actually needs 3 lines, CAN_L, CAN_H and ground. It is a differential line,
where the the signal is represented by a differencs between CAN_L and CAN_H. If
the difference is positive and larger than a certain minimum voltage it is a
"1" and if the difference is negative it is a "0" (or the other way around, but
you get the picture). You can read more about differential signalling here
.

It is done in this way because then you can have very long cable lengths with a
twisted pair type of cable. If a disturbance is affecting the cable, it is
affecting both wires in the same way, which then effectiviely is canceled out
since it isn't differential. Also the line is said to be balanced which means
that each node (or perhaps only the end nodes in a large network) are
terminated with the same impedance as the cable (normally around 120 ohms)
which cancels out reflections that would otherwise be a big problem for higher
communication speeds.

The ground is needed since it isn't a current loop type of circuit but a
voltage level (difference) circuit. The voltage with respect to ground has to
be within certain maximum limits. To be sure that the ground levels at both end
are at the same (or almost the same) level, the grounds have to be connected."

Source:
http://www.embeddedrelated.com/groups/68hc12/show/15101.php

I have some old shielded twisted pair four-wire phone cable, so I'm thinking of using that to run between the nodes. I also have cat5e, but that isn't shielded. This will be running mere inches from a battery pack pulling 150 VDC at up to 300 amps DC.

-Ryan

Branmuffin Industries
05-14-2008, 07:35 AM
Even though the CAN bus itself only uses two wires, it turns out the CAN Bus object in the object exchange requires five I/O pins to control the MCP 2515 CAN bus controller.
I only have 2-3 pins free at this time, and real estate on the PCB is really tight. Trying to fit an 18 pin DIP would be tough.

I'm going to look into the MCP2551, which only uses 2-3 pins and has only an 8-Pin DIP footprint.

-Ryan Brandys

Peter Jakacki
05-14-2008, 09:37 AM
Ryan,

As I said, RS-485 is straightforward. I have some routines which I will post up this week which can be set to RS-485 mode, that is, it uses one I/O for RX/TX and one I/O for TxEnable. It also has support for packets, detecting gaps, addressing, checksums etc. Because RS-485 is half-duplex the cog runs at a higher baud rate then you normally could with full-duplex. I have used these routines to interface to actual commercial control systems so they definitely work.

So 2 I/O and an 8-pin driver and that's all you need.

BTW, I have read all the spiel on websites about 2-wire balanced networks especially RS-485 "needing" a ground, that they are not current loops etc etc and other spurious reasonings. This is not the case as all these techies have done is pass on their experience, not hard science. Because of the differences in the ground potentials between nodes they tie all the grounds together in a network to keep the common-mode signals within the range of the driver chips. In some installations this can be done, in others it is not practical. Twisted pair balanced lines do not need a ground at all to operate. If you place a 3V battery across the A and B inputs of a receiver it will detect a low or a high depending upon the polarity, all without a ground. The receivers do create their own virtual ground anyway as the load they present across the lines is referenced to the receivers common, it's a bit like two resistors in series across the lines with the center-tap tied to common. The best way to operate an RS-485 network is to have the drivers optically isolated so that they operate in true two wire mode without a ground and yet still able to handle thousands of volts of common-mode potential (think that's enough). In an automotive environment it is easy enough to keep the grounds at roughly the same potential so I wouldn't bother with a signal ground or optical isolation.

*Peter*

MCP2551 is only the driver part of the CAN controller. You need more than the driver.

Branmuffin Industries
05-15-2008, 11:28 PM
Thanks Peter. This is starting to make sense.

DigiKey has dozens of RS-485 Transceivers in 8-Pin DIP packages, made by National Semiconductor, Texas Instruments, and others.

I've been reading up on these datasheets, and they are very similar. There's A and B, which are the twisted pair lines for the actual serial bus, then there are four other pins (RO, RE, DE, DI) which communicate with the propeller.

RE and DE are Receiver Enable and Driver Enable. It looks like these can be tied together and use one propeller I/O pin to switch high when driving and low when receiving.

DI and RO are Data In and Receiver Out, and these can also be tied together to become our TX/RX line.

So I guess the question is, has someone written a "protocol" or other spin software component to work over this "RS-485 electrical specification" ???

I see there are full duplex serial objects in the object exchange, but RS-485 is half duplex.

Where do I go from here?

-Ryan

Ken Peterson
05-15-2008, 11:51 PM
Either Simple Serial or Full Duplex Serial can both be operated in a half-duplex mode (in this case FDS for speed), but you would need to arbitrate the bus at a higher protocol level, i.e., slaves don't transmit until told to by the master, and the master knows when the slave is done transmitting.

What protocol you try to use over RS-485 may depend on what your expected data rates and transmission distances are.

You can also go full duplex by transmitting and receiving over separate pairs·of A/B lines.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Ken Peterson) : 5/15/2008 5:01:54 PM GMT

hinv
05-16-2008, 11:08 AM
Hi Ryan,

It sound's like a fun electric car project you have there. I would think though, with the possibility of pulling 300Amps at 150Volts, you are going to have some major EMI to shield. Otherwise, I would guess you have to be very careful about inductors/transformers in your circuits.

Doug

4Alex
05-16-2008, 08:56 PM
Hi Ryan,

Definitely RS485. I've done some automotive implementation before and this is the simplest way to go. Excellent book from Jan Axelson "Serial Port Complete" if you need a better in-depth understanding. I currently use DS75176BN (Digikey # DS75176BN-ND in DIP-08) and Intersil ISL3172EIBZ (Newark # 50M3952 in SOIC-08): my favorite because 3v3, more node count, and higher speed. Also lots of other goodies as well for an automotive implementation.

In a Master-Slave configuration, I pinout as follow: A/B on twisted pair (I've used as small as gauge 30AWG!), on PPL side: RO to receive, DI to transmit, and RE tied to DE and both connected to PPL for direction. Depending on length, I sometime add 120ohms resistor between A and B at each ends. Not necessary for short links. Axelson gives the calculation to determine what is a "short" link. So it's a 3 pins configuration, really. As firmware, Serial_Mirror and FullSerial objects works well, communication protocol can be simplified to the extreme without much problems if your slave nodes behave well (i.e., transmit only when told to by master). For networking, pretty much any topology is acceptable, daisy-chained (drop-out nodes from main link) being the most common and derivatives work well too.

BTW, Intersil's IC gives you up to 4000 feet between nodes, up to 256 nodes. It's not just the car you can wire but the whole parking lot... http://forums.parallax.com/images/smilies/wink.gif

Cheers,

Alex

Branmuffin Industries
05-17-2008, 03:03 AM
Alex,

Thanks. This is exactly the information I needed. I went ahead and ordered some DS75176BN (Digikey # DS75176BN-ND in DIP-08). The datasheet says it will support up to 32 transceivers on the bus, which is great, because I may eventually expand from 1 master and 6 slaves to 1 master and 18 slaves. Next, I will set this chip up on a breadboard and download the serial objects you've specified.

Will let you know. Thanks again

-Ryan

Peter Jakacki
05-17-2008, 06:32 AM
The ancient 75176 chips are bipolar and haven't been used in commercial in designs for decades. They draw up to 40ma in standby vs <1ma for the CMOS devices. The best devices to get are the Intersil ISL3155 as in among other things they feature true fail-safe (not the gimmick fail-safe) operation. When the bus is undriven it is possible for RS-485 receivers to generate a false output so many popular chips feature a fail-safe mode that biases the inputs a little bit to keep the receiver in the inactive state. Great! at least on the sales blurb and on the bench but when you actually use them on a real bus that is undriven AND terminated they will actually work in reverse and the receiver output will generate a break signal. If you can tolerate that then the other brands are ok.

I have a modified serial object that uses only 2 I/O for RS-485. I'll try and post it today.

*Peter*

4Alex
05-17-2008, 11:45 PM
Hi Ryan,

You're most welcome. Hope your project will go well. The 75176 is really a bench workhorse IC (very forgiving, almost indestructible). I referenced to it simply because it is DIP-08 (easy to breadboard), very well documented, reliable, and still easily available. I must also admit that I've been using them for more than a decade. You should consider deploying a more suitable IC like the Intersil ISL3172, especially because of the 3v3 / PPL combo (this is a Propeller forum after all).

I am by no mean expert on RS485 and communication networks in noisy environments are always subject to troubles. So the most common rule of thumb in any design should be to make absolutely certain that a failure of any sort would not result in a catastrophic event. This is especially true in an automotive (and robotic) environment. Just be careful of what you link together.

No IC will absolutely protect you from a misfiring (or mis-'breaking' for that matter) but I like the ISL3172 and similars for (as per datasheet) their Full Fail-safe (Open, Short, Terminated/Floating) receivers, Hot Plug features (Tx and Rx outputs remain three-state during power-up), True 1/8 Unit Load (allows up to 256 nodes on the bus), Single 3.3V Supply (Propeller direct compatibility), and very high data rates (up to 20Mbps). More importantly for a 'dirty and leaky' automotive environment, it sports a current limiting and thermal shutdown for driver overload protection: a great feature when facing bad shorts due to water infiltration or chafed wires. I've designed around airbag deployment ICs (speaking of catastrophic event!) and the Intersil RS485 IC performed flawlessly when used in conjunction. We use their products in a lot of other designs without problem. It is based on this hand-on experience that I recommended it to you. Other ICs could be more suitable to you. Like they say: ask your doctor if Intersil is right for you http://forums.parallax.com/images/smilies/wink.gif

Automotive projects are always fun and challenging. I'm working on the robotics side at this time so I envy you a bit. Enjoy!

Cheers,

Alex

Paul Baker
05-21-2008, 05:54 AM
I'm with Peter, I would recommend a differential drive communication protocol. The differential lines help eliminate noise because what happens to one line happens to the other line so they can be used together to cancel out a great deal of the noise. RS-485 is one of the leading standards for this.

For highly transient spikes, a current drive differential helps even more. This is where its current flowing in a loop, and the direction it flows determines the logic state. Since current has·more "momentum" than voltage, it's somewhat more impervious to transient spikes and the steep gradient in electromagnetic energy they cause (steep EM gradients can counteract the differential voltage drive when the gradient·is on the order of the spacing between the wires).

But try the RS-485 first, you very well may find it·sufficient.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 5/20/2008 11:05:19 PM GMT

Ken Peterson
05-21-2008, 09:00 AM
I didn't know current had momentum! I guess electrons are heavier than I thought. http://forums.parallax.com/images/smilies/smilewinkgrin.gif

Another way of explaining the advantages of a current loop is that you can induce a voltage on a wire without making a connection to it (i.e., interference). This is what happens inside a transformer. But you can't change the current in a wire without making an electrical connection to it. If you have 100mA flowing in a wire, it's 100mA for the entire length of that wire, no exceptions. But it can have different voltages along the length of the wire depending on what electrical fields are present.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Ken Peterson) : 5/21/2008 2:07:58 AM GMT

Sleazy - G
08-21-2008, 05:39 AM
Ken Peterson said...
I didn't know current had momentum! I guess electrons are heavier than I thought. http://forums.parallax.com/images/smilies/smilewinkgrin.gif

Another way of explaining the advantages of a current loop is that you can induce a voltage on a wire without making a connection to it (i.e., interference). This is what happens inside a transformer. But you can't change the current in a wire without making an electrical connection to it. If you have 100mA flowing in a wire, it's 100mA for the entire length of that wire, no exceptions. But it can have different voltages along the length of the wire depending on what electrical fields are present.


····· Thats not entirely true.· KCL "mass balance" is a good·"Classical" way to look at linear circuit analysis, but semiconductors can hold an amount of charge carriers, they "saturate" or "deplete", where the valence band electrons of the group III or group·V doping elements in the semiconductor are not obligated to satisfy KCL INSTANTANEOUSLY, A.K.A. the sum of the currents going into a node are USUALLY·equal to the sum of the currents leaving the node, over a selected interval. ·You could argue that the charge carriers, when going from conduction band to valence band, are no longer current anymore , because those carriers are not "flux".

If you take conducton band electrons and jump them to the valence band, in a semiconductor, you have "stopped" those charge carrying·electrons, or the lack thereof in the case of positive charge carriers.
This would be a group·III·doping element "absorbing" free electrons,··in the reverse case·'depletion' or "donation"·of a group V·doping element where the valence·band jumps to the conduction band, you could argue youve·"started" them into conduction.

Think of a·PN junction,·the surplus valence band·electrons in the·N·phase··"plug" the charge carrier "holes" when driven.· If analyzed as a loop (circuit) , you could argue·some of the volumetric·electron flux only move from a "Bump" to a·"Hole", and do not actually make it around the circuit.·Technically ,·the electrons· initially responsible for the band jump could go around the circuit, but the total·electrical flux across the device does not satisfy KCL, integrally.· This means·for an·electron which was a victim of the band jump can find its way to the conduction band again, but must have another charge carrier take its place without net work being put into the system.

Think of it like a sponge, kindof.· You shoot water into a sponge and it holds onto the water until you wring out the sponge.
The sponge transfers water across its bounds better when it's wet, or saturated.·· It holds onto an amount of water when saturated, which makes it conduct flow better (or worse, dependent on the junction).·The water in the sponge doesnt necessairly have to be the first lot of water that initially saturated the sponge.· This is just a loose description, dont take this to literally.· The mechanisims in semiconduction have to do mostly with phonons, vibrational energy, so its kind of a "virtual" photon, or a virtual electron band jump.· ugh.

There is also the case of the Magneto Optical Trap / Holographic Optical Trap, where the electrons are stopped dead by lasers, then compressed to the 6th form of matter, the Bose-Einstein Condensate.· This is absolute zero, or so it is claimed, and the electrons are actually not electrons at all anymore.· KCL does not apply here either.· You can take relativistic particles and slow them down.· Another example of this is·Cherenkov radiation, where the speed of an electron (or any other wave-particle)·in a dielectric is faster than the speed of light in that dielectric, the electron emits photon energy in the dielectric until it slows to a speed which is less than the speed of light in that dielectric.· You can argue that the electrons are "slowing down" from an "ultrarelativistic" state and would not balance in a boundary flux calculation.· Remember this is INSTANTANEOUS KCL violation.

Theres also·devices called·... DEBUNCHER / Wiggler , Accumulator , which will also violate KCL by changing the density of a bunch of any particle youd like, with charge, and releasing the excess energy as·synchrotron·radiation.

Then theres weak force interactions, ever heard of someone focusing a beam of neutrally charged particles? Without the use of gravity?·Sounds impossible eh?·Theres the NuMI horn at Fermilab , it focuses neutrinos, which are electrons stripped of their charge, using weak force interactions. · Then theres Antimatter, which is described as going backwards in time, and anhillates matter (making some other nasty stuff and alot of energy).· High energy particle physics can do some crazy things.

So you see, there can be quite a few exceptions.· But for us , we can just forget all that crazyness.

Post Edited (Sleazy - G) : 8/20/2008 11:11:26 PM GMT