Connect with us

Serial Bus Choices

Discussion in 'Electronic Design' started by Joel, Nov 15, 2006.

Scroll to continue with content
  1. Joel

    Joel Guest

    My company is designing the electronics for some UAV payloads and we
    are trying to decide on an inter-module serial comm scheme.
    Internally, we had chosen 485, but our customer asked why 485 and not
    ethernet, firewire, 1553, CAN, or USB. I am working on an answer for
    them and would like some input from this group.

    We have some constraints on size, weight and shape because we will need
    to fit into leftover space inside unspecified packages. This makes me
    tend away from COTS plug-in-board solutions, which would make ethernet,
    USB, or 1553 simple to implement.

    Our controllers for these modules will likely be from the AVR family -
    this is not set in stone but we already have experience with them and
    the tools. We don't expect to have huge amounts of data on this bus
    (it's mostly for command and status to a few sensors and motor
    controllers) and we don't currently know how many nodes we will need.
    The reason for having separate modules at all is to make it easier to
    adjust for feature creep and add new functionality without respinning
    every board when this happens.

    I know there are some holes in this info and I will answer any
    questions that I can.

  2. Joel Kolstad

    Joel Kolstad Guest


    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
    1553, CAN-BUS: I don't know enough about these to comment, although it would
    appear that at least with CAN-BUS you'd need an extra controller IC since I
    don't believe it can be bit-banged?

    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.
  3. Joerg

    Joerg Guest

    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.
  4. J.A. Legris

    J.A. Legris Guest

    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
  5. Joel

    Joel Guest

    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.

  6. Joel

    Joel Guest

    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.
  7. Joel

    Joel Guest

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

    PeteS Guest

    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.


  9. Joel

    Joel Guest

    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)
  10. Joel

    Joel Guest

    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)
  11. Joel

    Joel Guest

    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)
  12. 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.


    Adrian Jansen adrianjansen at internode dot on dot net
    Design Engineer J & K Micro Systems
    Microcomputer solutions for industrial control
    Note reply address is invalid, convert address above to machine form.
  13. Joel

    Joel Guest

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

    PeteS Guest


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

    No problem


  15. John  Larkin

    John Larkin Guest

    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


  16. 8 bytes to start with, not maximum

  17. 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
  18. Joel

    Joel Guest

    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.
  19. Joel

    Joel Guest

    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
  20. John B

    John B Guest

    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.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day