Minimal uC's with CAN? (still a hardware newbie)

One. ;-)

There's a special category of micro-minimalistic CAN nodes tailored for such usages.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

The CAN arbitration mechanism is bit based. Two nodes that begin transmitting simultaneously will detect it at the first bit that differs. The node sending the "recessive" bit will relinquish the bus. The other node can continue transmitting.

There is a 29 bit addressing space for messages identifiers, more than enough for 70 nodes.

Probably the minimal component count for any microcontroller (CPU, crystal, a few passive components) + the CAN bus drivers and whatever is required for the "power point"

Microcontrollers with built-in CAN controllers are available from Philips, Atmel, Motorola and others.

See:

Roberto Waltman

try

stolen from the CAN-CIA web site The attributes of a Controller Area Network (CAN) are

the multi-master capabilities that allow building smart and redundant systems without the need of a valuable master,

the broadcast messaging that is the first piece of the gurantee for 100% data integrity as any device within the network uses the very same information,

the sophisticated error detecting mechanism and the retransmission of faulty messages which is the second piece of the guarantee for 100% data integrity,

the availability of more than 50 controllers from low-cost devices to high-end chips from more than 15 manufacturers,

and the availability of CAN for the next 15 years as its use within the European automotive industry and the decision for CAN from the US and Japan automotive industry is guaranteed

In article , Fredderic writes

the identifiers are 11 or 29 bits to the answer is "lots"

Bus contention. It depends how many nodes want to transmit. The bus length depends on the speed.

I think 1Mb is OK for up to about 50 meters

OK. It handles it about as well as ether net.

Not a problem. The average car has about 70 CAN nodes these days!!

One 8051

Atmel cc01 Infineon 505, 515 Philips 591, 592

All are single chip parts with a full CAN node built in. OK so you will need a cystal some capacitors and a driver chip but the MCY includes the CAN module. They are small and cheap.

If you design your SW well the same SW (bar the actual CAN register interface code) will run on all the parts listed.

If you need more power then try:-

Infineon 16*

These parts powerful enough to be used and an ECU

After that there is the Philips ARM parts..

Then the PPC 565 but as this is a little more powerful than most PC servers I doubt you will need it...

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[snip]

There are a lot of microcontrollers with integrated CAN. See the small collection on this site:

Nevertheless, power supply, optional transceivers if you want to have the CAN signal levels, is needed by all of them.

Heinz

It should actually handle it quite a bit better than Ethernet, because it handles collisions by arbitration instead of back-off/retry. Which means even in case of a collision no bandwidth is lost. One of two colliding frames will survive the collision and continue to be transmitted, whereas Ethernet throws away both of them.

Not necessarily all on the same bus though, right? They're using separate busses for high-speed engine/transmission control and low-speed general switching/lighting/heating/whatever stuff.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hmmm..... Now that could be just what I need to make this idea viable in conjunction with my original one (which is still the way to go for the control nodes). I can see myself building the system around dumb controller nodes which require PC-based software to do the actual thinking, for the time being, and moving the software onto more sophisticated controller nodes at a later date (a major requirement of this project).

Basically, I need to get the component count for the leaf nodes to not much more than the component count of the daughter boards I've already tentatively designed. And all most of these boards have are a pair of bus drivers (one bi-directional with latching, another simple tri-state output to supply hard-wired board ID and a few device capability flags), appropriate current drivers (the input/output), and a comparator or two so the daughter board can signal when there's been a change of input (to avoid having to poll). That almost screams on-board CAM at the very least if this design shift is to work.

Some references could be nice... I've been slowly plowing through a Google search of everything CAM, but haven't yet come across such an all-in-wonder...

Fredderic

Added to the list. :)

This I've heard tinkerings about. I presume there are standard transceivers designed for the CAN bus? Given my application, I don't think there's any doubt I'll be pursuing the "with drivers" option, if for no reason other than to protect the uC a little. I was just wondering, what are the practical differences with and without driving?

Fredderic

I presume they detect the end of a current message, and then all jump in to send their own messages hot on its tail? (Or is there a delay between the end of one message and the start of another?)

This sort of suggests some degree of inherent prioritization, in the event that there's a node which is transmitting quite heavilly. I'm assuming it would basically boil down to prioritized on message class, then one of the addresses? I can foresee one of the devices in particular hogging the bus at times, so I'm wondering what kind of facilities exist to give other nodes a chance to get in first without starving it completely. (I noticed in one piece of CAN documentation that they recommend keeping the bus loading to no more than 80%, and even as low as 30% in some cases)

I'm more interested in the speed and network length impact of having that many nodes...?

Fredderic

Of course. Several classes of such, in fact. You'll want to check out the web site of Can-in-Automation

for lots of pointers.

The difference is that between a working and a non-existent CAN bus. CAN *requires* transceivers for proper operation. The only question is whether they come as separate chips or integrated into the CAN controller. Likewise, the CAN controller can be integrated with some micro, or be a standalone device. So you can have anywhere between one and three chips to handle a CAN connection.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

There is a short delay, but it's fixed, so yes, nodes waiting to send a message will start hot on the tail of the previous one.

Exactly. So you have to choose your priorities cleverly to avoid some high-priority node hogging the bus.

There are no "message classes" as such. Prioritization is entirely based on the message identifier, which you get to choose for yourself. You can install some meaning to individual bits of the identifier and thus create "message classes" if you want to, but CAN itself doesn't care about such distinctions at all.

The main facility to do that comes in the form of a skilled designer who knows what he's doing. ;->

Neither depends on the number of nodes, as such. It's the choice of transceiver that determines how many nodes you can have. 79 would be a bit on the high end for some of them.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

[minimalistic CAN devices]

The keyword to look out for is "SLIO" for "serially linked I/O".

The Philips chip P82C150 would be one example of such a gadget. That particular chip appears to have been discontinued, though.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Do you have any pointers to devices with integrated tranceivers? I'd like to see them.

Robert

I spent quite a bit of time the past couple months looking at mid-range (16 bit) uC's with CAN controllers, and I never found any with integrated transceivers. Perhaps there are some low-end or high-end parts I missed that had transceivers, but based on my limited knowledge of the economics of mixed-mode ICs I'd be surprised.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                               visi.com

Not really --- as I said: it can be done. That doesn't automatically imply anybody actually did it; or if they did, that they'll sell the chips on the open market.

Design sanity says that you always should have the transceivers as separate chips, so you can select whatever line characteristics you need (high-speed, or fault-tolerant, opto-isolated or not). OTOH, some applications may want them integrated just to save yet another couple of mm^2 on the PCB.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Ah, sorry, I missunderstood you. I thought you meant you knew of such devices.

That's where I thought matters sttod. I can think of a few applications I've been involved in that could have benefitted from a wholly integrated solution but even for them that would have been secondary to cost (and considering how inexpensive the tranceivers are... ).

Thanks for the clarification. Robert

Hmmm..... Is it's possible to set a dynamic synthetic delay before the message gets transmitted...? Set prioritization by delaying the message a certain number of bits after the last bus activity was detected.

That's difficult when you don't know ahead of time what's going to be on the bus, and how much activity it'll see. For the most part the bus should only see occasional use (I'll reserve the "lowest priority" number for firmware updates, and the highest for emergency broadcasts), so this won't be an issue. Until I start playing around with some of my more esoteric ideas.

I could assign some message type flags to the first few bits, or possibly implement an aging scheme based on messages sent a second or something. (The greater the number of messages sent this second, the greater the chance it'll get clobbered by something else also wanting to transmit)

But it's going to be interesting deciding how to divide up the 29-bit (if I remember correctly) message ID field...

A few "message classes" (emergency, node status changes, connection protocol management, connection protocol data). A few bits for node "aging" (up the priority on each miss?). Then in the connection case, destination node "address" and a "port number".

Well, that rules me out then. ;)

Okay... What's the main factor to watch out for here, then?

On the other hand, I was originally considering linking the 9 or so nodes with a simple 1-to-1 serial link in a tree structure (each node would have

3 ports standard; one parent and two child). Perhaps I should blend the ideas, and use a two-level network. The control nodes (initially just "dumb terminals") could plug into the primary network, plus a local network for which they're responsible. I'd like to avoid doing that, though, but it might be the best solution.

Fredderic

Care to share what you DID find?

I'm particularly interested in the 16-bit uC range...

Fredderic

Not per the CAN protocol. Some CAN controllers may be able to do such a thing, but that's outside the scope of the protocol itself.

CAN has other, more sophisticated means to achieve prioritization.

Exactly. But that's no different from what you're proposing. Guaranteed perfect scheduling without nearly complete advance knowledge about message lengths, rates, and maximum allowable delays, for every single message, is well-known to be impossible. Dynamic delays won't change that fact.

Only if you refuse to sit down and learn some new skills. Which would be a pretty stupid way to approach a hard problem like that, of course.

Baud rate and physical bus length are directly coupled to each other through the good old light-speed barrier (with some additional influence by electronic delays in the transceivers).

That shouldn't be necessary for 79 nodes, as long as you choose your transceiver chips well.

You *really* ought to get yourself a solid textbook on CAN. And probably another one about real-time distributed computing. I would recommend the ones I have --- but they're in German, so they probably wouldn't help you at all.

ST ST10Fxxx Infineon C16x, C26x, XC16x Mitsubishi MC16/6Nxxx Hitachi H8S/26xx Fujitsu MB90Fxxx National CR16xxxx Motorola 68HC912xxxx Intel 80C96 (??)

Prices generally run in the 10-15 USD range for parts with CAN and 128K-256K of flash. If you want to include ARM7T in the "16-bit" camp, then there may be some OKI parts with CAN -- I don't remember.

The C166 architecture seems widely used and tool support is pretty good. H8 also seems popular and there's plenty of info and support available. M16C support isn't as good: technical information on some features of the part was impossible to obtain. Tool support wasn't as good, and Mitsubishi's documentation is lacking.

The Motorola part is a joke: it's the same tired old 6811 architecture with built-in bank-switching so they can claim to support 128K of internal flash. Bank switching was an evil, time-wasting hack 20 years ago, and it still is today. I can't believe Mo has integrated it into a die.

Fujitsu and National seemed poorly supported by both commercial and free tools.

Intel's parts seem to be at end-of-life, and I didn't like the '96 architecture when I worked with it a many years back.

The cheapest 16-bit solution I've found is a Hitachi H8 "value series" part at $4 plus an external CAN controller for $2. That's compared with several comparable parts with integrated CAN that come in at about $10. Another advantage is that the external CAN controller has a much larger Rx FIFO and is therefore better suited for the protocol I'm using than any of the internal ones.

My main complaint about all of the parts listed above is the ROM/RAM ratio. It seems to be fixed at about 32:1, and my applications always seem to need something around 8:1. I wondered if that was just a personal problem, but recently a buddy of mine mentioned that he always ran into the same problem.

My other complaint is that all CAN parts (both external and integrated uCs) seem to be 5V. 5V would be OK, except it looks like many other categories of parts are going to start getting scarce in 5V, and I really want to avoid a mixed 3.3/5v board.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
                               visi.com