Serial Bus Choices

On 16/11/2006 the venerable Joel etched in runes:

. . .

If there's any doubt about which station may be bus master you have to stick to two-wire and take the hit in the bus turn-around times.

If you want to contact me off-list, I have lots of ASCII protocol documentation and code for AVR written for Imagecraft C compiler.

The last thing I'd want to do is present a customer a list of choices like this. They'll probably select some "known, reliable, industry-standard" protocol that's a pain to implement, and that becomes a project in itself.

Customers should tell you what they want done, not how to do it.

John

I agree that their choice should not be a driver, but we have to at least listen to their concerns. You're right about their initial choice - it was ethernet - which I think would be horribly complicated to implement in our small modules, for very little gain over what 485 can do.

-- Joel

My recollection is the old Apple Talk was a 485 based system with transformer coupling to get around ground issues. In any event, 485 is a good idea. USB would require a hub.

One idea, and probably not a good one, is to use SMB, intel's system management bus. It is similar to I2C. There is a reasonable amount of programming skill out there with this bus since it is used in smart batteries.

I would present them with

'The best choice in this situation is RS485, for a number of compelling technical reasons. Should you wish to use another interconnect, it will cost more [insert estimate here] and take more time [insert extra time here]. It may also impact reliability (more components -> lower reliability).'

Use your spreadsheet to back you up.

Cheers

PeteS

Thanks for the link. I looked at it and have looked at I2C as well. It this application we think that differential lines will be very important for EMR/EMI issues. We will be operating in aircraft environments, sometime coexisting with as yet, undefined payloads.

-- Joel

That should be reflected in the costing of the design. If it is a project in itself, then it will be more expensive which probably wont appeal to the customer anyway.

Now here is a good question: how many 485 have true differential drivers? To get low EMI from a differential circuit, the signal source has to be truely differential as in switching at the same time.

If you use a chip with on-board power supplies, one thing to look at is receiver jitter. It is hard to keep the DC/DC from interfering with the receiver circuit.

We've done several products using the Lantronix Xport ethernet thing, not much bigger than an RJ45 connector. That erases most of the pain from ethernet, if you can stand the $40 or so.

John

That is one of the ones I am considering. I am also considering the MAX1487 and the TI SN65HVD3082.

I'll have to think about this last part some. Do you mean that my board would be generating a minus power for the driver? If so, I think we will be powering with a single supply voltage derived from a linear regulator. Or did you mean that the transceiver chip develops a voltage with an internal regulator? It doesn't look like the LTC part does that. Or did the clue bird fly way over my head? 8)

-- Joel

I will look at this, just to be complete, but an extra $40 on top of a board that we expect to cost $10-$20 ea will probably be a killer.

-- Joel

It is the on-chip DC/DC that can create jitter. When you test interface chips, the ATE needs to know when to look for the output to change, i.e. the ATE needs a window. The jitter can effect this, so in-house the jitter is well documented. What ends up on the datasheet is another story. I've only designed 232 chips, so this never was much of an issue since the jitter wasn't significant relative to the speed. It may not matter in your situation either, but it is something to be aware of. I would get a storage scope (digital, though analog would work too), trigger off the input, and look at the "ensemble" of the output. The fatness relates to the jitter.

The EMI is another story. Unless the circuit is doing some sort of current steering, it is unlikely that the differential output will match well, so the EMI may not be reduced due to the differential nature of the signal, or more correctly lack thereof. Again, just something to look at. In fact, you should always view usenet as just pointers on what to investigate, since often the advice is worth what you are paying for it. ;-)

need

me

ethernet,

OK. I will keep this in mind. We have plans for a fair amount of testing and this sounds like a good way to justify a new Tek scope with built-in jitter analysis 8).

Gotcha. My main interest in asking on this NG was to get some opinions. I am extremely skeptical and take everything I find here with 64.7989mg of salt.

-- Joel

I think CAN is a good choice. A CAN controller solves all the addressing, error detection and transport issues for you. Designing your own protocol is prone to errors and usually takes more time than you would expect. Besides, CAN is very rugged and there are many CAN analyzers for a fair price which can help you with debugging / sniffing packets.

And then try to make it bullet-proof. For most programmers this is not a trivial task. Even the people at ITU screw up badly every now and then.

I am still somewhat interested in CAN, but I do have a few issues with it.

I would like to maximize my bandwidth. I don't currently have a minimum value for this, but CAN is limited to 1 Mb/s while 485 will do

I'm also not sure how to use a message based protocol when I might have two identical modules with identical code. This seems more difficult than using an address based protocol.

For all of the CAN controllers that I have found the power consumption, even in standby mode, is a little bit higher than what I could get with a 485 transceiver.

Lastly, for now, is the low-cost analyzer that you mentioned. If I go with a 485 system, I can use a PC serial port to sniff packets, or to inject commands. I'm sure that a custom analyzer can do some cool stuff, but I am trying to minimize the development cost, as well.

-- Joel

I had the same decision some years ago:

- Ethernet: too expensive, too bulky (magnetics, connectors), big Ethernet switch required for many nodes (>50 here)

- USB: cable length restriction, Master-Slave design

- Firewire: too expensive, length restriction, node restriction (63 nodes)

We went for CAN because the controllers do many things in hardware we would have had to do in software with 485: collision detection and handling, crc checking, filtering out the messages for each node.

We use the AT90CAN128 which has CAN built-in (only needs a small transceiver ic) and our own protocol on top of it in order to keep things simple.

Mit freundlichen Grüßen

Frank-Christian Krügel

No problem: Use a part of the message id (you have 29 bits with CAN 2.0B) as device address.

... if you choose an external CAN controller. Atmel has AT90CAN32/64/128 with integrated controllers.

Mit freundlichen Grüßen

Frank-Christian Krügel

ld

ver

These are my top two choices, as well. I am hesitant to change controllers soley for the comm, and it seems that everything else that I used to weigh the choices pointed towards 485.

-- Joel