Maker Pro
Maker Pro

Serial Bus Choices

J

Joel

Jan 1, 1970
0
John said:
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.

One of our primary reasons for using 485 is the ease of debugging HW
and SW using a PC terminal. I also agree with the ASCII comment.
Several of our past projects did this, and the customers were impressed
with the ability to do real-time debugging just by connecting up to the
bus.
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.

The fixed master thing is not cast in stone yet, but we are also
considering that any two of the modules may need to communicate with
each other for some reason. So far we can't see any benefit to using
422.
 
J

John B

Jan 1, 1970
0
John B wrote: ..
..
..

One of our primary reasons for using 485 is the ease of debugging HW
and SW using a PC terminal. I also agree with the ASCII comment.
Several of our past projects did this, and the customers were
impressed with the ability to do real-time debugging just by
connecting up to the bus.


The fixed master thing is not cast in stone yet, but we are also
considering that any two of the modules may need to communicate with
each other for some reason. So far we can't see any benefit to using
422.

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

John Larkin

Jan 1, 1970
0
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.

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
 
J

Joel

Jan 1, 1970
0
John said:
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 said:
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.

Thanks,

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.
http://www.smbus.org/
 
P

PeteS

Jan 1, 1970
0
Joel said:
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.

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
 
J

Joel

Jan 1, 1970
0
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.
http://www.smbus.org/

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

The Real Andy

Jan 1, 1970
0
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.

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.
 
Joel said:
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.
485 sounds like the way to go. LT make one with isolation
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1007,C1017,P1746,D2570

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

John Larkin

Jan 1, 1970
0
The last thing I'd want to do is present a customer a list of choices

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.


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
 
J

Joel

Jan 1, 1970
0
485 sounds like the way to go. LT make one with isolation
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1007,C1017,P1746,D2570

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.

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)
 
J

Joel

Jan 1, 1970
0
John said:
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

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 said:
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)

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. ;-)
 
J

Joel

Jan 1, 1970
0
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.

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

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

Nico Coesel

Jan 1, 1970
0
Joel said:
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 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.
 
N

Nico Coesel

Jan 1, 1970
0
John Larkin said:
We just had a meeting at which we re-affirmed the truism that the
easiest protocol to implement is one that you design yourself.

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

Joel

Jan 1, 1970
0
Nico said:
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.

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
10 Mb/s baseline with 50 Mb/s a theoretical possibility.

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

Frank-Christian Kruegel

Jan 1, 1970
0
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 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)

485 and CAN were the possible alternatives.

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
 
F

Frank-Christian Kruegel

Jan 1, 1970
0
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
10 Mb/s baseline with 50 Mb/s a theoretical possibility.

485 might do 10Mb/s, but you AVR won't do more than 1MB/s reliably.
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.

No problem: Use a part of the message id (you have 29 bits with CAN 2.0B) as
device address.
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.

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


Mit freundlichen Grüßen

Frank-Christian Krügel
 
J

Joel

Jan 1, 1970
0
Frank-Christian Kruegel said:
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)

485 and CAN were the possible alternatives.

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

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