Mochuelo wrote:
> On Thu, 01 Jun 2006 07:56:08 +1200, Jim Granville
> <no.spam@designtools.co.nz> wrote:
> 
> 
>>Because every node runs its own baud, we found that having some small
>>gaps between bytes ( extra stop bits ), gives the system more tolerance
>>to baud rate creepages.  ( ie your average baud must be less than the
>>slowest actual baud of any node )
>>IIRC, this was good to appx 1 MBaud
> 
> 
> I forgot to ask.
> 
> If the baud rates were intentionally different, why did you do that?
> 
> If the baud rates were UNintentionally different, you noticed problems
> using one stop bit and crystals or ceramic resonators at the nodes?

  Neither, we avoided a potential problem :)

  If you stream continually, then you put a lot of pressure on the 
single stop bit ( actually half a stop bit, as it is mid-tested for 
STOP, before the uart flips to start edge sampling.. ) as that is the 
total time-elasticity.
  Also, RX must complete, before the RI sets, and it needs to test 9th 
bit, to decide what to TX, so you can see a SW aperture also creeps
into the budget. Often TX waits for the next whole BIT time,
before send - so whilst RX should be fractional bit tolerant, TX is not.

  You can easily test this, in a full system :)

-jg

On Thu, 01 Jun 2006 07:56:08 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Because every node runs its own baud, we found that having some small
>gaps between bytes ( extra stop bits ), gives the system more tolerance
>to baud rate creepages.  ( ie your average baud must be less than the
>slowest actual baud of any node )
>IIRC, this was good to appx 1 MBaud

I forgot to ask.

If the baud rates were intentionally different, why did you do that?

If the baud rates were UNintentionally different, you noticed problems
using one stop bit and crystals or ceramic resonators at the nodes?

Thanks,

On Thu, 01 Jun 2006 07:56:08 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Read my eariler post - with the ripple loop scheme, you have very simple 
>slaves.
>Signal with the 9th bit in uart.
>When a slave sees a rising edge on the 9th bit chain, it removes the
>following N bytes (info TO slave), and replaces them with it's messages
>(info FROM slave), and on these reply bytes it sets the 9th bit LOW.
>the next bytes simply pass thru, and now the next slave sees these
>clean bytes, as the first rising edge, so it removes/replaces them.
>and so on, right around the loop.
>eg, Slaves have 4 byte packets, master sends 40 bytes.
>Master sends > 40 bytes with 9th bit low.
>Starts message, 40 bytes with 9th bit high
>1st slave 9th Bit IN = 40_Hi,         OUT = 4_Low + 36_Hi
>2st slave 9th Bit IN = 4_Low + 36_Hi, OUT = 4_Low + 4_Low + 32_Hi
>etc
>Master counts slaves, but inspection of the 9th bit stretch, so
>the frame size is usually > slaves.
>
>The slave needs to be ready with a small buffer, so what it sends could
>be from the previous frame (not this one ) if you need a lot of time.
>
>Because every node runs its own baud, we found that having some small
>gaps between bytes ( extra stop bits ), gives the system more tolerance
>to baud rate creepages.  ( ie your average baud must be less than the
>slowest actual baud of any node )
>IIRC, this was good to appx 1 MBaud
>
>There is no message-address info, or overhead, as the slaves position in 
>the loop sets the 'address', adding /removing slaves can be automatic.
>Info is fully deteministic, and set by the frame rate.

Ok, now I understand. Thanks for the clear explanation. The idea is
quite nice.

Several comments:
- I would prefer not to use polled communications, and that's why I
didn't mention masters and slaves. The reason is that I know that more
than one company has had problems with similar systems (actually using
power line communications (PLC) instead of a ring of point-to-point
segments), using polling. I would like each sensor not to generate new
data until something has changed in its state. With your scheme, N
bytes are devoted to (sent to and received from) each sensor, each
"round," regardless of whether they have changed the state or not, and
whether there's something in its configuration that needs to be
changed or not. Some numbers: with {115200 bauds, 9 data_bits/word, 1
stop_bit/word, 4 bytes/frame, 200 nodes/ring (100 on each side of the
aisle), and the nodes always have ready the data to be sent} the total
time across the ring would be around 77 ms. That would not be bad at
all. I'll think about this (and especially about the frame size that I
would actually need).
- The fact that there is no address information does not worry me.

>I think Interbus has a similar scheme.
>
>Suitable uC: The Atmel new AT89LPC213/4/6 series, Philips LPC9xx, or if
>you need serious analog operation as well, Silabs C8051F41x series....

If I end up going for the 1-UART/sensor solution, I might even go down
to an ATmega48, which I've used a lot. The sensors need to be very
cheap.

Thanks again,

Mochuelo wrote:
> On Tue, 30 May 2006 03:28:10 -0500, hmurray@suespammers.org (Hal
> Murray) wrote:
> 
> 
>>I'm not sure you need a second UART.  Think "ring".  Everybody
>>sends to the left and listens to the station on the right.
>>To send right, you go left all the way around the ring.
>>
>>I'm not saying that's a good way to do it, just another idea
>>for the collection.
> 
> 
> 
> I've been thinking more about this. It is a pitty that using one UART
> per node makes more complex the flow control. By flow control I mean
> how a transmitter knows that the receiver to which it has sent some
> data has already processed it and is ready to accept more. I don't
> want to use extra wires in the cables to implement hardware flow
> control, because that means more connectors and less reliability. With
> two UARTs per node, I was thinking of using some kind of
> acknowledgement data to immediately signal the transmitter that the
> receiver is ready to accept more data. However, with one UART per
> node, the acknowledgement should travel around the entire ring, to
> reach the original transmitter, and that can be a hell of a protocol
> :-)
> 
> Some options that I see:
> 1) Not to implement flow control, and assume, from the point of view
> of each transmitter, that the corresponding receiver is infinitely
> fast. I'm a little bit worried, because the MCU needs to be cheap, and
> the amount of RAM will be very limited.
> 2) If 1) gives problems at peak times, I could insert forced wait
> times until problems disappear.
> 3) The system could start with zero wait times, and slowly and
> dynamically adjust them, in case problems are detected. For this, the
> UARTs need to signal that a new word has been received before having
> read the previous one, which I think is a standard feature. Sounds
> vague and complex, but might work, though maybe not efficiently
> enough.

Read my eariler post - with the ripple loop scheme, you have very simple 
slaves.
Signal with the 9th bit in uart.
When a slave sees a rising edge on the 9th bit chain, it removes the
following N bytes (info TO slave), and replaces them with it's messages
(info FROM slave), and on these reply bytes it sets the 9th bit LOW.
the next bytes simply pass thru, and now the next slave sees these
clean bytes, as the first rising edge, so it removes/replaces them.
and so on, right around the loop.
eg, Slaves have 4 byte packets, master sends 40 bytes.
Master sends > 40 bytes with 9th bit low.
Starts message, 40 bytes with 9th bit high
1st slave 9th Bit IN = 40_Hi,         OUT = 4_Low + 36_Hi
2st slave 9th Bit IN = 4_Low + 36_Hi, OUT = 4_Low + 4_Low + 32_Hi
etc
Master counts slaves, but inspection of the 9th bit stretch, so
the frame size is usually > slaves.

The slave needs to be ready with a small buffer, so what it sends could
be from the previous frame (not this one ) if you need a lot of time.

Because every node runs its own baud, we found that having some small
gaps between bytes ( extra stop bits ), gives the system more tolerance
to baud rate creepages.  ( ie your average baud must be less than the
slowest actual baud of any node )
IIRC, this was good to appx 1 MBaud

There is no message-address info, or overhead, as the slaves position in 
the loop sets the 'address', adding /removing slaves can be automatic.
Info is fully deteministic, and set by the frame rate.

I think Interbus has a similar scheme.

Suitable uC: The Atmel new AT89LPC213/4/6 series, Philips LPC9xx, or if
you need serious analog operation as well, Silabs C8051F41x series....

-jg

On Tue, 30 May 2006 03:28:10 -0500, hmurray@suespammers.org (Hal
Murray) wrote:

>I'm not sure you need a second UART.  Think "ring".  Everybody
>sends to the left and listens to the station on the right.
>To send right, you go left all the way around the ring.
>
>I'm not saying that's a good way to do it, just another idea
>for the collection.


I've been thinking more about this. It is a pitty that using one UART
per node makes more complex the flow control. By flow control I mean
how a transmitter knows that the receiver to which it has sent some
data has already processed it and is ready to accept more. I don't
want to use extra wires in the cables to implement hardware flow
control, because that means more connectors and less reliability. With
two UARTs per node, I was thinking of using some kind of
acknowledgement data to immediately signal the transmitter that the
receiver is ready to accept more data. However, with one UART per
node, the acknowledgement should travel around the entire ring, to
reach the original transmitter, and that can be a hell of a protocol
:-)

Some options that I see:
1) Not to implement flow control, and assume, from the point of view
of each transmitter, that the corresponding receiver is infinitely
fast. I'm a little bit worried, because the MCU needs to be cheap, and
the amount of RAM will be very limited.
2) If 1) gives problems at peak times, I could insert forced wait
times until problems disappear.
3) The system could start with zero wait times, and slowly and
dynamically adjust them, in case problems are detected. For this, the
UARTs need to signal that a new word has been received before having
read the previous one, which I think is a standard feature. Sounds
vague and complex, but might work, though maybe not efficiently
enough.

Any ideas?

Best,

In comp.arch.embedded,
Mochuelo <cucafera@RE_MO_VE_THIStelefonica.net> wrote:
>
> You are right, I don't need two UARTs :-)
> For one single array of sensors I would prefer using MCUs with two
> UARTs than having to run a second 300 m cable (to connect the control
> station to the furthest node, and so close the ring), but it turns out

You don't need a separate 300 m cable for that. Just leave one conductor
in the cable free for the return. Let each node just pass that conductor
through and on the last node place a 'terminator' connector that loops
the serial channel back to that free conductor.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

On Tue, 30 May 2006 10:33:20 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:
>You do not need 2 uarts for the link - is the 2nd uart used locally ?
>[...]
>We have done similar systems using what I call a 'twisted ring' loop.

You also mentioned rings. Sorry, I don't know why I did not realize at
the time of answering you that they could be another option for me. I
started involuntarily discarding rings because I had in mind only one
long line of sensors. When you said I needed only one UART I thought
it was because I hadn't explained that the control station would also
need to send data. Thanks, too.

On Tue, 30 May 2006 03:28:10 -0500, hmurray@suespammers.org (Hal
Murray) wrote:

>
>>I forgot to say that the sensors also receive data from the control
>>station, so each sensor needs to be able to transmit to its left and
>>to its right, and to receive from both sides too. That's why I
>>mentioned "packets going to and from the sensors 'to its right.'" So I
>>need two UARTs.
>
>I'm not sure you need a second UART.  Think "ring".  Everybody
>sends to the left and listens to the station on the right.
>To send right, you go left all the way around the ring.
>
>I'm not saying that's a good way to do it, just another idea
>for the collection.

You are right, I don't need two UARTs :-)
For one single array of sensors I would prefer using MCUs with two
UARTs than having to run a second 300 m cable (to connect the control
station to the furthest node, and so close the ring), but it turns out
my linear arrays of sensors will have to be installed by pairs[*], so
I can create rings without running separate cables. This means even
longer delays, and lower reliability, but also cheaper nodes and
cables (which need one less wire).

[*] The sensors detect the presence/absence of vehicles in covered
parking lots. There are two lines of sensors per aisle, one at each
side. On each pair of lines, the lines are separated by about 10 m, so
closing the ring is relatively cheap.

I don't know if I will use it, but thanks for the idea.

Best,

Hal Murray wrote:

>>I forgot to say that the sensors also receive data from the control
>>station, so each sensor needs to be able to transmit to its left and
>>to its right, and to receive from both sides too. That's why I
>>mentioned "packets going to and from the sensors 'to its right.'" So I
>>need two UARTs.
> 
> 
> I'm not sure you need a second UART.  Think "ring".  Everybody
> sends to the left and listens to the station on the right.
> To send right, you go left all the way around the ring.

Correct.

  I have also seen two-ring designs (which would use 2 UARTS),
and with that, you gain ring-break tolerance, as with a single break 
anywhere in the circle, there is still a 2 way path to the master, and 
the master can also deduce where the break must be, and report it.

-jg

On Mon, 29 May 2006 23:53:35 +0200, Mochuelo
<cucafera@RE_MO_VE_THIStelefonica.net> wrote:

>Anyway, strugling my mind I realized that maybe I can make it without
>CAN. This was for a long, linear array of sensors, about a hundred,
>and 3 m apart, for which I initially thought of a bus topology, but
>maybe it is not so bad a point-to-point channel from each sensor to
>the following one. Instead of CAN, I just need an MCU with (at least)
>two UARTs, which happens to be much cheaper. Each sensor would
>generate its own data, and would act also as a repeater, for the
>packets going to and from the sensors "to its right." This application
>does not need to transfer lots of data, and does not have to react in
>very very short times, so I think I can live with the added delays of
>this topology.

The problem with using every node as a repeater is that a single
hardware or software failure near the control unit will take out
nearly the whole system.

I would suggest a simple RS-485 multidrop bus with the control unit
addressing each unit at a time. The only single node failure that
could take out the whole array is that the node transmitter remains
active all the time, but this could be prevented by some kind of
watchdog timer.

A bus systems with about one hundred nodes will have 2-3 times the
number of connectors, so the connector reliability is essential. This
applies to CAN as well as RS-485 networks.

The one hundred RS-485 nodes could be handled if each node had 1/4
unit load transceivers, however, with standard RS-485 transceivers
only 32 nodes (e.g. one master and 31 slaves) can be connected to a
single line. 

The array should be split into 4 sensor segments, each driven by an
RS-485/RS-485 repeater. The other port of each repeater is connected
to an other RS-485 bus, which is also connected to the control unit.
Thus, the control unit could poll all 100 nodes one at the time.

A better solution is to use four RS-422 ports on the control unit and
connect separate cables to four RS-422/RS-485 repeaters driving their
own sensor segments. In this way, the line speed would be only 1/4
compared to the previous case, since the nodes on each segment can be
polled in parallel. 

One might even consider using four Ethernet/RS-485 converters to drive
the sensor segments, but the converter latencies should be studied
carefully. It might be hard to access all 25 nodes in each segment
within a second regardless of the segment line speed :-).

Paul