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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I was previously poking around this newsgroup for help deciding on a
microcontroller to use.  Along the way the CAN bus architecture was
suggested several times over for linking the individual parts together.

This gave me an idea of a moderate paradigm shift with respect to the idea
I had originally planned.

How many individual nodes can be placed on a single CAN bus (what
practical impact does adding another node have on maximum bus
length/speed), and how well does it handle multiple nodes trying to
transmit at the same time (assuming a random source and target
distribution)?  I expect to have something in the range of 70 or so
(worst case figure) nodes in total (instead of 10 in my original design)
by the time I'm finished.

If I am to consider this new layout, my priorities become minimum
component count to achieve uC + CAN (as opposed to modular flexibility).
Being able to update the code via network is still important to me, but as
each node will only be performing a single task that code will be
substantially simpler.  (Except for the "controller" nodes (8 to 10 of
the above 70), which I may even implement using a different/bigger uC
later on down the line, and will be carrying the burden of some of my more
interesting plans.)

So, what's the minimum component count of, for instance, a CAN device able
to monitor a switch and turn a power point on or off?


Fredderic

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

Quoted text here. Click to load it

One.  ;-)

There's a special category of micro-minimalistic CAN nodes tailored
for such usages.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

Quoted text here. Click to load it

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

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

[minimalistic CAN devices]

Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Minimal uC's with CAN? (still a hardware newbie)
Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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:
  http://www.kvaser.com/can/index.htm
  http://www.can.bosch.com
  http://www.can-cia.de /


Roberto Waltman

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

Quoted text here. Click to load it

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)


Quoted text here. Click to load it

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


Fredderic

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Well, that rules me out then.  ;)


Quoted text here. Click to load it

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

Re: Minimal uC's with CAN? (still a hardware newbie)
Quoted text here. Click to load it

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.


 > Set prioritization by delaying the message a
Quoted text here. Click to load it

CAN has other, more sophisticated means to achieve prioritization.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


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

Quoted text here. Click to load it

Etschberger's CAN book is available in English.  I found it to contain a lot
of good, practical information.  It's rough reading in spots because the
translation isn't the best (the translated version obviously wasn't edited
by a native English speaker), but I don't know of anything better.

It really is a shame not to have the translation edited properly -- when you
pay $80 for a book, you ought to get decent editing.  There are plenty of
starving english and journalism majors who probably would have been willing
to dproof-read the book for a few hundred dollars.  I guess as long as there
are no competing books in English...

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: Minimal uC's with CAN? (still a hardware newbie)

Quoted text here. Click to load it

The arbitration phase...  I'm not entirely sure that "more sophisticated"
is the term I'd apply.  Especially if you're stuck using the 2A spec,
where you're rather limited in the number of available bits.

A delay inserted between messages should achieve much the same effect,
although at a slight disadvantage if the node wishes to send a large
sequence of "low priority" messages.


Quoted text here. Click to load it

Well, yes it is.  Planning out your ID's before hand applies a static
prioritization to everything.  What I was suggesting was a dynamic
priority, designed to adjust to the current bus traffic in the event that
a given message is continually overridden by a stream of higher priority
messages.  Adding a delay probably wouldn't be a whole lot harder than
adjusting the ID to manipulate a "priority" field under the same
conditions.


Quoted text here. Click to load it

Or if you're lacking in sensayuma...  :)


Quoted text here. Click to load it

I was reading somewhere about line termination, but haven't come across
any appropriate details as of yet.  Is it necessary?


Quoted text here. Click to load it

Hmmm.....  Fair enough.


Quoted text here. Click to load it

Urgh.  That's probably about $125AU...  My budget for this project is
presently about $20 a month (most of my workbench is donated from family
and friends).  Might take me a while to save up my pennies...  (Should get
a little easier after Christmas, though)  As it is I'm going to absolutely
love purchasing a devel kit or programming hardware if I can't manage to
avoid it.


Fredderic

Re: Minimal uC's with CAN? (still a hardware newbie)
Quoted text here. Click to load it



Limited?  I'd say 2048 different priorities *really* should be enough
for everybody.  That's already a hundred times more than your typical
Unix kernel scheduler has, for Pete's sake!

Quoted text here. Click to load it

A node can still delay its own messages any way it wants to.  It's
just not a part of the CAN spec, so CAN controllers typically won't
help you with it.

Quoted text here. Click to load it


Planning your delays such that you don't disrupt the system yields
either the exact same kind of static prioritization, or anarchy.  You
choose.

The key problem with delays is that they either achieve nothing or
waste bandwidth.  CAN's prioritized arbitration mechanism makes sure
that priorities actually do what the term implies: as long as there's
traffic of high priorities going on, any node with low-priority
messages to send keeps its mouth shut, period.

Also note that nobody's forcing you to make the IDs used completely
static, either.  If you are going to encode priority into the ID, you
would obviously *mask*out* that part of the ID before doing the
address acceptance check in the recipient's message box, thus leaving
it entirely up to the sender to choose the priority of the message.

Quoted text here. Click to load it

And nothing in the way CAN IDs work is preventing you from doing
exactly that.  Very minimalistic CAN controllers may not fully support
that mode of operation in hardware, but the more flexible ones do have
ID masks for that.

Quoted text here. Click to load it

Absolutely.  No termination means pulse reflections, and you
definitely don't want those.

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

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

Quoted text here. Click to load it

Only for as long as you don't use the identifier for anything else, such
as carrying a node address.  Then you start to run a little lower on
priorities.  Still, it's not too bad.  Until you start reserving bits to
carry other information such as message classes, destination addresses
for 1-to-1 messages, etc.

Now, I want room for 70 nodes, that's 7 bits, which leaves only 4 in
which to carry other information.  2B's better, but it still doesn't solve
the problem that I want something approximating fair queuing, with the
only prioritization being on message classes.


Quoted text here. Click to load it

I'm aware of this...  I'm kind of hoping someone will chime up with a
suggestion of a CAN controller that will.  I've looked at a few CAN
controllers so far, but this seems to be a facility which, as you say,
they don't make easy.

Some of the uC's with CAN support seem to require a lot of software
backing to make the thing tick; one of them could probably be coerced into
doing it.  Don't think the gain of being able to use 2A chips quite
warrants that though.


Quoted text here. Click to load it

Well, anarchy isn't quite what I had in mind.  And a shift of
prioritization out of the arbitration field happens to be the whole point.


Quoted text here. Click to load it

Which is not what I want.  I want a node to yield the bus once it's gotten
a few packets out.  So I either have to allocate a few priority bits up
front so I can lower the priority of a given message stream periodically,
or find some other means.  Since I can't do what I need with the 2A spec
(at least, not without sacrificing part of the packet section), and the 2B
spec gives me just enough room to fit everything in, I'm quite content to
simply go that way.  Still, the idea's worth looking into at least.


Quoted text here. Click to load it

That's what I figured.  I wasn't paying attention during the line
termination portion of my classes, unfortunately.  What's the usual
termination technique for a CAN bus?  Given the dominant 0 (IIRC) nature
of CAN, I presume it's a resistor to the +ve supply?


Fredderic

Re: Minimal uC's with CAN? (still a hardware newbie)
Quoted text here. Click to load it


Maybe you're just trying to cram too much stuff into the arbitration
field.  Not all of it has to be put in there.

Quoted text here. Click to load it

A static design with "fair" queuing, and made without rather a lot of
up-front analysis of what will be going through the queue is,
unfortunately, an illusion.  It just won't work.

Quoted text here. Click to load it


You keep misunderstanding me.  You say you want to use dynamically
chosen delays (like, e.g., the classic Ethernet exponential back-off
tactic for collision handling) to solve queueing without doing a
static up-front analysis.  I'm saying you don't need delays for that
--- you can escalate the priorities of messages dynamically, instead.

And I'm recommending against both those practices, because both risk
killing the reliability of high-priority transmissions, which of
course is the whole point of that whole priority business.

Having two independent prioritizations schemes active on the same
communication channel is going to cause confusion rather than help you
achieve your goal.  If a node can't get its low-priority messages sent
off, the means one of three things:

1) you've over-loaded the bus --> a design error
2) the priority of that message isn't high enough --> a design error
3) that message truly isn't important enough, at the moment, to warrant
   interrupting the flow of higher-priority message --> All OK, nothing
   to be fixed.

In none of those cases would a change of prioritization technique have
any desirable effect.  A change of priority levels, though, may.

Quoted text here. Click to load it

Then you'll have to program that node accordingly.  

Quoted text here. Click to load it

A resistor betwen the CAN_HI and CAN_LO wires, of same size as the
cable impedance.  Usually 100 Ohms for high-speed CAN.  Depends on the
transceivers being used.

Quoted text here. Click to load it

No.  A CAN is a differential signal, so no +ve supply in sight to
terminate towards.


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

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

Quoted text here. Click to load it

I know I am.  But I don't know where else to put it.

In many cases, I can steal a byte or two from the payload.  But there will
be at least a few cases where I'll need every bit of payload space I can
get (trying to cram several 10's of kilobytes down the bus in 8-byte
chunks is going to be slow enough as it is).

CAN was designed for short messages between a group of linked components
in a tightly predefined system.  Not an unknown number of unknown
components sending sometimes unknown length messages to unknown recipients
in an unknown higher-level system.

What I do have, is a collection of different device classes, which all
follow the same API, and a bus.  Beyond that, I have very little
information from which to do the analysis necessary to assign the proper
priorities to everything.

Still, it seems to be the best option so far.  I just have to roll this
stuff around a while to figure out the best compromise in terms of what
can and can't be done arbitration-wise.  So far, I'm thinking that
splitting it into a two-tier network model (and hence cutting down on the
number of nodes on any given bus) is a very positive move.  In fact, I
should even be able to get away with limiting the number of nodes on a
given bus to just 32 or 64, which will give me plenty of room to maneuver.


Quoted text here. Click to load it

I don't follow your use of the term "static design" here...

And I know that fair queuing isn't going to happen.  I'm just trying to
see how close I can get to it without having to set up a bus master.


Quoted text here. Click to load it

Basically.  Problem is, there's no design to be analyzed.  The closest I
can imagine would be to have a program on a master node run some profiles
to try and guess the proper values to give each node's messages, and then
have it program all the nodes with what arbitration values they should use
for a given message.  And then modify those values not only as devices
come and go, but also as bus traffic statistics are built up.  Possible,
certainly.  But something I'd much rather avoid.


Quoted text here. Click to load it

As long as you have enough bits to spare.  As it is, I think I will by
sticking to CAN 2B.  Especially if I lower the upper bound on the number
of nodes allowed.


Quoted text here. Click to load it

Not if you maintain limits on the priority escalation, which I will be
doing.  I'll also be implementing a few "message classes", to keep things
like emergency messages clear of the rest.

Quoted text here. Click to load it

I see the delay tactic as more of an extension to the prioritization
scheme, rather than being independent.  Think of it as adding a variable
number of extra recessive bits to the front of the arbitration field.

Though from what I've been reading, it seems like it'll be far more work
than it's worth, and even simply not possible in some CAN controller
combinations.


Quoted text here. Click to load it

Occupational hazard, in this case.  There will be times when it'll need to
cope with a sustained flood of low-priority messages.  At other times I'm
expecting very little bus traffic at all.  I'm hoping the CAN bus will be
able to deal with such busy periods.  This is one place where I figured
throwing in a few bits-worth of delay might help.


Quoted text here. Click to load it

Which happens to be what I'm discussing right now.  Methods of extending
the existing bus arbitration mechanism just a little further.

How would you suggest I tackle this situation, other than with careful
design of the overall system?


Quoted text here. Click to load it

Sounds fair enough.  Makes sense in retrospect. I've heard values of 100
Ohms and 120 Ohms thrown about, but hadn't until yesterday come across
anything clearly describing where to put the resistor, except for a
diagram which kind of hinted at it but neglected to actually label the
lines.


Fredderic

Re: Minimal uC's with CAN? (still a hardware newbie)
Quoted text here. Click to load it
<Snip>
Quoted text here. Click to load it

 Two levels can work well, esp as the 'IQ' of the nodes lowers.
The lowest stub can be SPI, Chained UART, or look at the LIN-BUS for
a half duplex, low data rate stub scheme, designed to not need a
crystal.
 Slave devices can be LOGIC chips, SPLD/CPLD, or tiny uC.

 Smallest CAN+uC I am aware of is the T89C51CC02, TSSOP28 IIRC.

-jg

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

try http://www.can-cia.com /

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 < snipped-for-privacy@sumirpi.is_backwards_at.com.a
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

 [snip]

Quoted text here. Click to load it

There are a lot of microcontrollers with integrated CAN.
See the small collection on this site:
http://www.port.de/engl/canprod/sw_driv.html

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

Heinz

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

Quoted text here. Click to load it

Added to the list.  :)


Quoted text here. Click to load it

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

Site Timeline