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.
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"
email@example.com Info for manufacturers: http://www.trexon.com
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.
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.
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 :-).
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.
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.
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)