Serial Bus Choices

Joel,

I like your reasoning. Here's my thoughts on the other options:

Ethernet, FireWire: Adds considerable complexity & power consumption USB: Not really a "networking" protocol; requires a single master and many slaves, so not directly applicable to systems with many boards that are "peers"

You might want to look at I2C which would probably also meet your needs and perhaps obviate the need for RS-485 line drivers/receivers, but otherwise -- given your low data-rate and the need to keep an eye on power consumption -- I think RS-485 is a very solid choice. About the only downside I can think of it that you'll end up having to come up with your own protocol (not at all difficult), whereas something like Ethernet/FireWire/USB already have the lowest-level "frame" packets defined.

Hello Joel,

I happen to work on something similar right now and I am looking into a similar bus architecture. But I'll exceed the usual 32 receiver limit just by a smidgen :-(

If this is for a defense project you might want to think about these reasons for adopting a simple serial bus:

• Has been around for a very long time (IOW, it works).
• Look at RS232: Often dissed but still around, for decades.
• Lots of people are familiar with it.
• Simplicity, meaning less can go wrong.
• Possibly less reliance on single-source parts.
• Not much overhead.
• Can be diagnosed with just about any old scope or analyzer.
• Lots of simple and cheap terminal software.
• Probably lots of other defense gear that has it.

Plug-in boards on anything that goes airborne, or anything else for that matter, reduce the reliability because you have more connectors.

Using something that you are already familiar with is a smart thing to do.

I would recommend CAN or one of its subsets such as J1939. It's everywhere now and you won't have to worry about convincing your customer.

-- Joe Legris

I generally agree with this as well, except for the USB, because we were already considering that one module would be a master for the system. My problem with USB is the expectation that you could just plug it into a port on a PC. My understanding is that there would be considerable firmware overhead to do this.

CAN does require a seperate controller, but you get some failsafing along with it.

We like the fact that we would develop our own protocol. Many of the other choices enforce a particular protocol that would waste a lot of bandwidth to send 1 byte of status.

Joel

With the newer 485 transceivers you can have upto 256 nodes. CAN does not use addressing, so you can have lots of nodes so long as you terminate proporly.

We have some problems with 232: Single ended means less noise immunity compared to differential Point-to-point limits the number of modules to the number of uarts on the main module 1 Mb/s might eventually be too low a bandwidth (485 can go to 50 Mb/s over short runs)

I agree with this but 1553 boards are in most subsystems on most military aircraft. My problem with 1553 is the complexity to implement in an embedded system.

-- Joel

I think that CAN is my second choice. My main problem with it is 8 bytes of data per packet.

-- Joel

I use CAN with J1939 as transport in one product, and it has some advantages (it's designed to be bulletproof), and lots of parts available.

To implement properly, you'll need a CAN controller either standalone or as part of a microcontroller, and a CAN transceiver - lots of these available from the usual suspects.

The issue is it may be overkill, and it has limited bandwidth. 1Mb/s over relatively short runs, which from a different post may not be suitable.

As to the original post; my take is to use the simplest possible interconnect that will meet the task. In this case, RS485 seems to be an excellent choice.

Keep in mind that all the others (be it CAN, ethernet, firewire, USB, whatever) will have *significant* software/firmware overhead. That adds a complexity layer that is actually worse than the hardware complexities. No - keep it simple.

Cheers

PeteS

I agree with everything you said. My customer is used to buying COTS boards for whatever function he needs. I don't think he understands how much more difficult it is to implement some of these things in an embedded system. Although, maybe this is just a test to see if I can really justify my choice.8)

-- Joel

I agree with everything you said. My customer is used to buying COTS boards for whatever function he needs. I don't think he understands how much more difficult it is to implement some of these things in an embedded system. Although, maybe this is just a test to see if I can really justify my choice.8)

-- Joel

I agree with everything you said. My customer is used to buying COTS boards for whatever function he needs. I don't think he understands how much more difficult it is to implement some of these things in an embedded system. Although, maybe this is just a test to see if I can really justify my choice.8)

-- Joel

I use RS485 in a similar situation, with SNAP protocol. But even with a very simple protocol, by the time you do addressing and error detection, you will end up with around 8 byte packets to do anything useful.

Damn Google Groups. This was obviously only supposed to go out once.

-- Joel

LOL

That happened to me when I posted from my cousin's computer using google groups last week.

No problem

Cheers

PeteS

We just had a meeting at which we re-affirmed the truism that the easiest protocol to implement is one that you design yourself.

I'd go for RS-485 with a simple, home-brew binary packet protocol. A single tri-statable RS485 transceiver chip will be an SO-8 at most, hardly any space or power, and your CPU probably has a suitable UART on-board.

John

Rene

Nice replies from all. But when you go to your customer and say, RS485 (or alternate solution) is the best value for money when it comes to cost v reliablility i think your customer will be happy. Weigh up the cost, then make a decision.

Tell them CAN will cost more, but is more robust or ethernet requires more hardware (and subsequently $$) but is more scaleable etc. Do yourself a favour and write down approximate costs of each solution and next to that write down pro's v con's. Take several options to your customer and let them choose which way they want to go based on your educated opinion.

Someone is paying you, give them what they want and you will get more work.

This was our thoughts as well.

I definitely agree with all of this. We have done a couple of projects recently where we rolled our own protocol, and it worked fine.

-- Joel

I still think that this was something of a test, to see how much thought we had put into the decision.

I am keeping a spreadsheet with as many comparative metrics on each protocol as I can find. I plan on coming up with a weighting scheme for each metric and willhave a relative merit value for each at the end.

-- Joel

On 16/11/2006 the venerable John Larkin etched in runes:

Having designed many industrial machines with internal RS485 networks, I agree with all that has gone before with one minor exception. I would suggest that you design your protocol in readable ASCII. That way you can make a debugging tool with a laptop running TeraTerm/HyperTerminal/Whatever and an RS485->RS232 converter.

If you are sure your system will always have one fixed master, then also look at four-wire RS422. That way there is no possibility of running into bus contention problems.