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

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

the OKI ARM is ML67Q2003

and OKI has a stand alone CAN, based on the Bosch C_CAN IP working with

3.3V.

If you like the Texas Instruments DSPs TMS320LF24x be counted as 16 bit controllers, add them to your list of micros with integrated CAN. They are working with 3.3V too. And most importand, as far as I know TI is the only one having transceivers working with 3.3V

On

you can find a table with prices, maintained by CAN users

Regards Heinz

I found the data sheet for the stand-alone controller as well. However, there was no trace of the part on OKI's North American web site, and none of the distributers have heard of it. Either it's vaporware or it's just not available over here yet.

Yea, I forgot to mention the TI DSPs.

--
Grant Edwards                   grante             Yow!  After THIS, let's go
                                  at               to PHILADELPHIA and have
                               visi.com            TRIPLETS!!

I didn't see any mention of this one...?

Google is my friend... ;)

Thank you very much for that lot...

Fredderic

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.

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.

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

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

Hmmm..... Fair enough.

Grant Edwards added:

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

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!

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.

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.

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

Then you'll have to program that node accordingly.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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?

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

Look at the LIN standard.