On 2010-10-16, Ulf Samuelsson <ulf@notvalid.atmel.com> wrote:
> 2010-10-16 06:50, Grant Edwards skrev:
>> On 2010-10-15, Ulf Samuelsson<ulf@notvalid.atmel.com>  wrote:
>>
>>> Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller?
>>
>> Mixed mode IC designs that include both a microcontroller and
>> something like robust differential analog transceivers like RS-485,
>> RS-422, RS-232, CAN, etc. tend to be pretty tricky (and expensive).
>>
>> I've never seen an off-the-shelf microcontroller with RS-485, RS-422,
>> or RS-485 tranceivers, and I've never met anybody with enough cash to
>> design one and have it fabbed.
>
> Maybe I wasn't too clear. Instead of adding a board with RS-232
> bridge to RS-485/422, he should consider adding an RS-485/422
> transceiver to the Microcontroller board.

I thought maybe you were hinting about a new AVR part soon to be
announced. :)

-- 
Grant

2010-10-16 06:50, Grant Edwards skrev:
> On 2010-10-15, Ulf Samuelsson<ulf@notvalid.atmel.com>  wrote:
>
>> Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller?
>
> Mixed mode IC designs that include both a microcontroller and
> something like robust differential analog transceivers like RS-485,
> RS-422, RS-232, CAN, etc. tend to be pretty tricky (and expensive).
>
> I've never seen an off-the-shelf microcontroller with RS-485, RS-422,
> or RS-485 tranceivers, and I've never met anybody with enough cash to
> design one and have it fabbed.
>

Maybe I wasn't too clear.
Instead of adding a board with RS-232 bridge to RS-485/422,
he should consider adding an RS-485/422 transceiver to the 
Microcontroller board.

Best Regards
Ulf Samuelsson

On Sat, 16 Oct 2010 04:50:31 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2010-10-15, Ulf Samuelsson <ulf@notvalid.atmel.com> wrote:
>
>> Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller?
>
>Mixed mode IC designs that include both a microcontroller and
>something like robust differential analog transceivers like RS-485,
>RS-422, RS-232, CAN, etc. tend to be pretty tricky (and expensive).
>
>I've never seen an off-the-shelf microcontroller with RS-485, RS-422,
>or RS-485 tranceivers, and I've never met anybody with enough cash to
>design one and have it fabbed.

While I can understand that there are no standard compliant RS-232
integrated controllers due to the large +/-6 V voltage swing and the
large power dissipation in the fault cases, RS-422/485/CAN will
operate from +5 V.

However, the OP was talking about distances up to 1 km and speeds up
to 250 kbit/s, which is twice what the standard suggest (in distance
or speed). At such distances the lame +12/-7 V RS-485 common mode
voltage range is not enough, so anyway, you would have to use
optoisolators for galvanic isolation.

On 2010-10-15, Ulf Samuelsson <ulf@notvalid.atmel.com> wrote:

> Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller?

Mixed mode IC designs that include both a microcontroller and
something like robust differential analog transceivers like RS-485,
RS-422, RS-232, CAN, etc. tend to be pretty tricky (and expensive).

I've never seen an off-the-shelf microcontroller with RS-485, RS-422,
or RS-485 tranceivers, and I've never met anybody with enough cash to
design one and have it fabbed.

-- 
Grant

2010-10-13 03:13, Shane williams skrev:
> On Oct 13, 6:02 am, D Yuniskis<not.going.to...@seen.com>  wrote:
>> Hi Shane,
>>
>> Shane williams wrote:
>>> We have systems where a bunch of microcontrollers (up to 250) need to
>>> communicate with each other in a circular ring.
>>
>> Your wording implies a *physical* set of point-to-point links.
>> This can be accomplished "literally" in that same sense.  E.g.,
>> much like FDDI.
>>
>> Does a powered down/defective node count as a "break"?
>> I.e., can you count on all nodes being "up" at any given time
>> (two or more being OFF would be an irrecoverable failure)
>>
>> For example, a pair of RS232 links -- one clockwise and one
>> counterclockwise -- from each node to its two adjacent neighbors
>> gives you the physical capabilities you seek (though it forces
>> each node to participate actively in every message exchange).
>>
>> You can also implement a Token Ring network (e.g., ArcNet)
>> in which a "communications device" handles much of the
>> overhead of moving messages around (years ago, there were
>> 8051-ish solutions with ArcNet controllers).
>>
>> If you have any need for synchronization between nodes
>> (e.g., shared timebase), then the easier implementation is
>> a bus-oriented one.  (Note that the physical topology can
>> *force* a ring's "problems" onto a bus topology)  This
>> allows all nodes to see the same data/event COINCIDENTLY.
>>
>>> All controllers need
>>> to see all messages and if there is a single break in the ring, it
>>> needs to continue working and report the fault.  It doesn't need to be
>>
>> If you need the ring to bretain some integrity in the face
>> of a break, then you need at least two physical connections
>> per node.  Note that you need not have both connections *active*
>> at all times.  Rather, you just need to be able to sense your
>> "current" connection is defective and "recover" by switching
>> to your "backup" connection.  (of course, your protocol must
>> be smart enough that the controls don't start oscillating)
>> The relative cost of the hardware to do so must be weighed
>> against recovery time, protocol complexity, etc.
>>
>>> high speed, 200 kbps would probably do.  Are there any RS485 network
>>> cards that can do this and how much do they cost.
>>
>> Have you considered a wireless solution?  (you've not explained
>> the physical size of the ring but ~250 would probably NOT all
>> be colocated in a 1 meter segment!  :>  )  ZigBee is an
>> attractive, low power solution in your stated bandwidth.
>> (you can chose to implement a ring protocol, bus protocol,
>> mesh, etc.)
>
> Sorry, I guess I didn't ask my question very well.  The distance
> between nodes can be several kilometers or just one or two meters.  We
> can use fibre for the larger distances.  The network cards need to be
> standalone with a connection to the host preferably RS232 but maybe
> whatever's available.  The topology is not a bus but more of a daisy
> chain.  We were thinking of a scheme where messages propagate in both
> directions around the ring, to get the redundancy.  All nodes are
> powered up all of the time except when there's a fault/ power fail.
>
>

Why don't you implement RS-485 (or maybe RS-422) IN the microcontroller?
If you are using point to point, you do not have to even control the
enable signal.

If you are running for long distance, then you might consider
using a more advanced bit encoding like Manchester coding.

BR
Ulf Samuelsson

On 10/12/2010 7:13 PM, Shane williams wrote:
> On Oct 13, 6:02 am, D Yuniskis<not.going.to...@seen.com>  wrote:
>> Hi Shane,
>>
>> Shane williams wrote:
>>> We have systems where a bunch of microcontrollers (up to 250) need to
>>> communicate with each other in a circular ring.
>>
>> Your wording implies a *physical* set of point-to-point links.
>> This can be accomplished "literally" in that same sense.  E.g.,
>> much like FDDI.
>>
>> Does a powered down/defective node count as a "break"?
>> I.e., can you count on all nodes being "up" at any given time
>> (two or more being OFF would be an irrecoverable failure)
>>
>> For example, a pair of RS232 links -- one clockwise and one
>> counterclockwise -- from each node to its two adjacent neighbors
>> gives you the physical capabilities you seek (though it forces
>> each node to participate actively in every message exchange).
>>
>> You can also implement a Token Ring network (e.g., ArcNet)
>> in which a "communications device" handles much of the
>> overhead of moving messages around (years ago, there were
>> 8051-ish solutions with ArcNet controllers).
>>
>> If you have any need for synchronization between nodes
>> (e.g., shared timebase), then the easier implementation is
>> a bus-oriented one.  (Note that the physical topology can
>> *force* a ring's "problems" onto a bus topology)  This
>> allows all nodes to see the same data/event COINCIDENTLY.
>>
>>> All controllers need
>>> to see all messages and if there is a single break in the ring, it
>>> needs to continue working and report the fault.  It doesn't need to be
>>
>> If you need the ring to bretain some integrity in the face
>> of a break, then you need at least two physical connections
>> per node.  Note that you need not have both connections *active*
>> at all times.  Rather, you just need to be able to sense your
>> "current" connection is defective and "recover" by switching
>> to your "backup" connection.  (of course, your protocol must
>> be smart enough that the controls don't start oscillating)
>> The relative cost of the hardware to do so must be weighed
>> against recovery time, protocol complexity, etc.
>>
>>> high speed, 200 kbps would probably do.  Are there any RS485 network
>>> cards that can do this and how much do they cost.
>>
>> Have you considered a wireless solution?  (you've not explained
>> the physical size of the ring but ~250 would probably NOT all
>> be colocated in a 1 meter segment!  :>  )  ZigBee is an
>> attractive, low power solution in your stated bandwidth.
>> (you can chose to implement a ring protocol, bus protocol,
>> mesh, etc.)
>
> Sorry, I guess I didn't ask my question very well.  The distance
> between nodes can be several kilometers or just one or two meters.  We
> can use fibre for the larger distances.  The network cards need to be
> standalone with a connection to the host preferably RS232 but maybe
> whatever's available.  The topology is not a bus but more of a daisy
> chain.  We were thinking of a scheme where messages propagate in both
> directions around the ring, to get the redundancy.  All nodes are
> powered up all of the time except when there's a fault/ power fail.
>
>
Google "Rs-485 HUB"

Hi Shane,

Shane williams wrote:
> Sorry, I guess I didn't ask my question very well.  The distance
> between nodes can be several kilometers or just one or two meters.  We

Ouch!  "Important detail", that.  :-/

You've indicated performance criteria. What about cost, size
and reliability?

> can use fibre for the larger distances.  The network cards need to be
> standalone with a connection to the host preferably RS232 but maybe
> whatever's available.  The topology is not a bus but more of a daisy
> chain.  We were thinking of a scheme where messages propagate in both
> directions around the ring, to get the redundancy.  All nodes are
> powered up all of the time except when there's a fault/ power fail.

Without really knowing your application, I would look into
a pair of RS232 interfaces -- one counterclockwise, the other
clockwise -- with an external "media adapter module" that
you "select at deployment".

E.g., if B's clockwise neighbor (C) is a meter away, then B's
"clockwise media adapter module" is populated with something
like an EIA232 translator (perhaps even less depending on
other electrical characteristics).  The same applies to *C's*
"COUNTERclockwise media adapter module".  Similarly, if B's
counterclockwise neighbor (A) is a *mile* away, you could
populate B's "counterclockwise media adapter module" with
something like an RS232-fiber module (long haul modem)
as well as A's "CLOCKwise media adapter module".

[hopefully I've been consistent in my clockwise and counterclockwise
terms in that example  :>  if not, hopefully you can figure out
what I mean with the help of a little sketch with two interfaces
on each node]

This puts each node *in* the message loop physically and
procedurally.  I.e., the message has to pass *through*
each node and be handled by the processor, there.

If you have the budget, add a small MCU for each node that
simply does all of the communications protocol.  E.g.,
something with two UARTs and an SPI interface (which talks
to the "main CPU").  Since you can "nail down" your
protocol, you can test and debug that code and "fix" it
into that "communications processor".

Hint: since you are going to *process* packets (messages)
circulating around the ring, you can modify your protocol
so that you *tag* each packet with the "ring sequential"
ID of its sender (which might be different from it's
*logical* ID).  In that way, a node can "know" that it
is "node X" and, if it can't talk to "node Y" on it's
clockwise link but *can* talk to Y-1, it can deduce that
there is a break between Y and Y-1 (since Y and Y-1 "must"
be "ring adjacent").

[look at the RUPI for some historical context]

You can still look at wireless options but long distance
radio modems get pricey (OTOH, stringing a km of fiber isn't
cheap!)

Also, the synchronization issue gets trickier given this mix
of different interconnect technologies (assuming synchronous
operation *might* be required above syntonous requirements)

On Oct 13, 6:02=A0am, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).
>
> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).
>
> If you have any need for synchronization between nodes
> (e.g., shared timebase), then the easier implementation is
> a bus-oriented one. =A0(Note that the physical topology can
> *force* a ring's "problems" onto a bus topology) =A0This
> allows all nodes to see the same data/event COINCIDENTLY.
>
> > All controllers need
> > to see all messages and if there is a single break in the ring, it
> > needs to continue working and report the fault. =A0It doesn't need to b=
e
>
> If you need the ring to bretain some integrity in the face
> of a break, then you need at least two physical connections
> per node. =A0Note that you need not have both connections *active*
> at all times. =A0Rather, you just need to be able to sense your
> "current" connection is defective and "recover" by switching
> to your "backup" connection. =A0(of course, your protocol must
> be smart enough that the controls don't start oscillating)
> The relative cost of the hardware to do so must be weighed
> against recovery time, protocol complexity, etc.
>
> > high speed, 200 kbps would probably do. =A0Are there any RS485 network
> > cards that can do this and how much do they cost.
>
> Have you considered a wireless solution? =A0(you've not explained
> the physical size of the ring but ~250 would probably NOT all
> be colocated in a 1 meter segment! =A0:> ) =A0ZigBee is an
> attractive, low power solution in your stated bandwidth.
> (you can chose to implement a ring protocol, bus protocol,
> mesh, etc.)

Sorry, I guess I didn't ask my question very well.  The distance
between nodes can be several kilometers or just one or two meters.  We
can use fibre for the larger distances.  The network cards need to be
standalone with a connection to the host preferably RS232 but maybe
whatever's available.  The topology is not a bus but more of a daisy
chain.  We were thinking of a scheme where messages propagate in both
directions around the ring, to get the redundancy.  All nodes are
powered up all of the time except when there's a fault/ power fail.

On Oct 12, 12:02=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).


We did that a long time ago and put a relay on one of the RS-232 modem
control outputs.  If that wasn't powered, the relay bypassed the node
(can't really take credit for the idea, we were inspired by Token-
Ring, which does something very similar).  Also, you don't really need
pairs of RS-232 links, just a funky cable to connect TX from one node
to the RX of the next node.  A second ring would present opportunities
for redundancy.


> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).


ARCNet is actually token bus, not token ring.  It uses a broadcast
medium with repeaters/hubs.  It manages *access* by bouncing a token
around the network to all the nodes in sequence, only the holder of
the token can transmit, but those transmissions are broadcasts.
Contrast that to a token ring (like 802.5 Token Ring, or FDDI), which
physically transmits messages around a ring of point-to-point links,
with one of those messages being the token that allows transmission.
A token ring actually allows several messages to be circulating on the
ring at once (presuming the bandwidth-delay product of the physical
ring is high enough, of course), which is not possible with a token
bus.  A token ring also has certain electrical advantages from being
composed of point-to-point links.

On Oct 12, 12:02=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).
>
> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).
>
> If you have any need for synchronization between nodes
> (e.g., shared timebase), then the easier implementation is
> a bus-oriented one. =A0(Note that the physical topology can
> *force* a ring's "problems" onto a bus topology) =A0This
> allows all nodes to see the same data/event COINCIDENTLY.
>
> > All controllers need
> > to see all messages and if there is a single break in the ring, it
> > needs to continue working and report the fault. =A0It doesn't need to b=
e
>
> If you need the ring to bretain some integrity in the face
> of a break, then you need at least two physical connections
> per node. =A0Note that you need not have both connections *active*
> at all times. =A0Rather, you just need to be able to sense your
> "current" connection is defective and "recover" by switching
> to your "backup" connection. =A0(of course, your protocol must
> be smart enough that the controls don't start oscillating)
> The relative cost of the hardware to do so must be weighed
> against recovery time, protocol complexity, etc.
>
> > high speed, 200 kbps would probably do. =A0Are there any RS485 network
> > cards that can do this and how much do they cost.
>
> Have you considered a wireless solution? =A0(you've not explained
> the physical size of the ring but ~250 would probably NOT all
> be colocated in a 1 meter segment! =A0:> ) =A0ZigBee is an
> attractive, low power solution in your stated bandwidth.
> (you can chose to implement a ring protocol, bus protocol,
> mesh, etc.)



I think the winsystems Zigbee bd. uses the Xbee-pro. It has indoor/
urban range listed as 100m.

What interface/connection does the OP's controllers have (usb or PCI
or PC104 or ??)  or is he building an SBC?