MCU with CANbus + 10-bit ADC

PIC18F2480, around $5 for single quantities.

Try digikey's webpage and search for "Microcontrollers". They have a parametric search.

I haven't seen any cheap CAN uCs. Cheapest solution I can think of would be your choice of uC that has SPI and a Microchip MCP2515. In single quantities you can get a MCP2515 for $3 and an Atmel ATMEGA48 for $2.50. Obviously in larger quantities price will decrease substantially. Cheapest part with CAN integrated into it that I know of is the Microchip PIC18F2480 at about $10 in single quantities.

-Mike

Mochuelo wrote:

Where are you seeing this price? Digi-Key lists the cheapest PIC18F2480 for $9.73.

-Mike

Well,

you can use an 8-bit PIC or a 32-bit ARM7 device for the same price. The LPC2119 at Digikey is $9.50 with 128k Flash, 16k SRAM, 10-bit ADC and runs up to 60 MHz.

An Schwob

a Freescale 9S12C32 is "cheap".

There might be also cheaper 9S08 or newer HC908 derivatives with 10 bit ADC.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)

TI has ARM7TDMI core devices with CAN for similar prices ($5/1K). Most of these devices will require you to use an external SPI or I2C SEEPROM, if you want true EEPROM which you can erase one byte at a time.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Microchip Direct -- $5.76. Mouser has the PIC18F248 for $5.99.

This press release

mentions "the XC886/888 goes for about $2.68" /10K so you'll need to enquire for a more exact price, as not all XC886 family members have CAN enabled.

-jg

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,

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

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,

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.

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

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

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

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,

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.

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)

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,