MCU with CANbus + 10-bit ADC

On 26 May 2006 16:03:35 -0700, "Mike Noone" <nleahcim@gmail.com>
wrote:

>I haven't seen any cheap CAN uCs.

Yes, that was my impression (and frustration), too. I bet the reasons
have more to do with marketing than with manufacturing costs.

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 LPC2103 seems to be a good candidate for what I need, but I've
seen that Rowley Associates Crossworks for ARM does not explicitly
support it (it does support the 2104, though). That's why I'm posting
a new question in another thread.

Thanks again,

Mochuelo wrote:

> On 26 May 2006 16:03:35 -0700, "Mike Noone" <nleahcim@gmail.com>
> wrote:
> 
> 
>>I haven't seen any cheap CAN uCs.
> 
> 
> Yes, that was my impression (and frustration), too. I bet the reasons
> have more to do with marketing than with manufacturing costs.
> 
> 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. 

You do not need 2 uarts for the link - is the 2nd uart used locally ?


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

We have done similar systems using what I call a 'twisted ring' loop.
In this, the 9th uart bit acts like a johnson counter, and every node
extracts as many bytes as it needs, from the leading 9th bit edge, and 
inserts its size-matched reply, with the 9th bit low.
All other bytes are simply passed-on.

Thus each stage extracts adjacent packets, and the host can auto-count 
slaves, by looking for when the replacement-domino finishes.

Works best with some deadband between bytes (wider stop bits ).

> 
> The LPC2103 seems to be a good candidate for what I need, but I've
> seen that Rowley Associates Crossworks for ARM does not explicitly
> support it (it does support the 2104, though). That's why I'm posting
> a new question in another thread.
> 
> Thanks again,
> 

On Tue, 30 May 2006 10:33:20 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Mochuelo 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. 
>
>You do not need 2 uarts for the link - is the 2nd uart used locally ?

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.

Best,

> 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 LPC2103 seems to be a good candidate for what I need, but I've
> seen that Rowley Associates Crossworks for ARM does not explicitly
> support it (it does support the 2104, though). That's why I'm posting
> a new question in another thread.
>

You might want to consider the AT91SAM7S32/S321 as well.
The DMA on the UARTs + other nice features like RS-485 support should make 
it quite attractive.
(Did you consider RS-485 instead of RS232?)

You can get a free IAR Kickstart edition which will support the SAM7S32/S321
Maybe the same with Rowley, but I do not know.

> Thanks again,




-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

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

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

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
  

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 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,

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.

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)