Searching \ for '[ee]: Some CAN thoughts...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=can+thoughts
Search entire site for: 'Some CAN thoughts...'.

Exact match. Not showing close matches.
PICList Thread
'[ee]: Some CAN thoughts...'
2005\06\08@173405 by Jan-Erik Soderholm

face picon face
Hi.
I've been looking at CAN the last couple of days.
I'd just like to sum up what I have found out so far
and see if there are any comments...

>From a software point of view, it doesn't look too
complicated. Much simpler then to setup USB, as
far as I can see. Quite managable from assembler also.

Better to use the new 18Fxx80 devices that has replaced the
18Fxx8 (now matured), right ? Any thoughts of the new ones ?
Programmer support (e.g Wisp628) ?

There are a number of specs for a higher level protocols then
the basic CAN spec, such as CANopen. But they seems to have
some licensing issues, not ? And besides, for a not too complicated
CAN net, one can just as well define own packages/protocols,
right ?

It looks like DB9 or standard RJ plugs are the most popular.
What about using standard (and cheap) TP cable between
the CAN nodes ? Using two connectors on each module so
ne don't need separate drop-down cable hardware.

This is a rather harsh electrical envir (think large kitchen
stoves and owens). The currect test-design uses plain TTL/CMOS
connections over a TP cable, but the diff-lines that CAN uses
seems much better in a EMI-rich environment, not ?
(Besides the fact that they use 2 of the 4 TP pairs to
form a 4-bit "address" to select which node to talk to.
In CAN you use the 11 or 22 bit identifier for this, of course.)

Any other reason *not* to use CAN in a 10-20 node net
with PIC based "controllers" in each node ? Something to
watch out for ?

Anyone using/used the CAN support in mikroPascal ?
(Not my choice, but "they" are looking at it, my contact
are a long time Delfi programmer, and he thought that
it looked "nice"...)

Best Regards,
Jan-Erik.




2005\06\08@191216 by Gerhard Fiedler

picon face
Jan-Erik Soderholm wrote:

> From a software point of view, it doesn't look too complicated. Much
> simpler then to setup USB, as far as I can see.

CAN is really in a different league than USB. The USB protocol has much
more layers to take care of.

> There are a number of specs for a higher level protocols then the basic
> CAN spec, such as CANopen. But they seems to have some licensing issues,
> not ? And besides, for a not too complicated CAN net, one can just as
> well define own packages/protocols, right ?

I've done that (making up my own scheme) for a number of quite proprietary
devices. I'd say if you have anything that fits into a standard and there
is a chance that you want it extensible, it probably makes sense to use
one. But I haven't looked at any of the available ones in detail. I think
there is at least one open source protocol out there, where you shouldn't
have any licensing issues.

> It looks like DB9 or standard RJ plugs are the most popular.

I'm using the Conxall round plugs. Not too expensive and reasonably sealed.

> What about using standard (and cheap) TP cable between the CAN nodes?

Anything that carries current... :) Of course TP is better than not TP.

> This is a rather harsh electrical envir (think large kitchen stoves and
> owens). The currect test-design uses plain TTL/CMOS connections over a
> TP cable, but the diff-lines that CAN uses seems much better in a
> EMI-rich environment, not ?

Of course. The ISO 11898-1 compatible differential interfaces are pretty
standard, usually robust (mostly designed for automotive environments) and
very easy to use. Most people include these when they say "CAN".

> (Besides the fact that they use 2 of the 4 TP pairs to form a 4-bit
> "address" to select which node to talk to. In CAN you use the 11 or 22
> bit identifier for this, of course.)

Not necessarily. Many CAN messaging schemes don't talk really about /who/
to talk to, but /what/ to say (so to speak). Everybody listens, and selects
based on the message type, not any recipient address.

The idea is that someone transmits the temperature at point 51. Whoever
needs that, picks it. Someone else transmits the humidity at point 33.
Again, who needs it, picks it. And so on. No real destination addresses in
this schema.

(Of course, that's not required by CAN. You can embed destination addresses
in the message identifier, and the stations can filter based on the bits
that encode the destination address. But I think the message broadcast
scheme is the original CAN concept, and the most popular one among the
higher-level protocols.)

> Any other reason *not* to use CAN in a 10-20 node net with PIC based
> "controllers" in each node ? Something to watch out for ?

It's probably the easiest way to get this working. Once you have figured
out the basics of how to make the CAN module work and talk to one other,
you're pretty much there. The CAN bus is quite robust. And since it's fast,
you're not likely to run into any bandwidth issues.

A reference interface that you can hook up to your PC is valuable; first
for getting the PIC module to talk, and to know when it talks and whether
the problem is on the receiving or the sending side :) and then to see
what's going on on the bus, what your nodes send out. I have the IXXAT
USB-to-CAN compact. Works well, never had a problem, and comes with a
rudimentary bus monitor application.

Gerhard

2005\06\10@041036 by Alan B. Pearce

face picon face
> Any other reason *not* to use CAN in a 10-20 node net with PIC based
> "controllers" in each node ? Something to watch out for ?

About the only "gotcha" I see is the 8 byte message limit. If you can work
within that, and provide a means of breaking longer messages into 8 byte
blocks, then it is probably ideal.

2005\06\14@055828 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> Jan-Erik Soderholm wrote:
>
> > It looks
like DB9 or standard RJ plugs are the most popular.
>
> I'm using the
Conxall round plugs. Not too expensive and
> reasonably sealed.

OK.
This seems to ba a fairly open issue, so we could
probably match the
cabling with other needs in the project.

>
> > (Besides the fact that
they use 2 of the 4 TP pairs to form a 4-bit
> > "address" to select
which node to talk to. In CAN you use
> > the 11 or 22 bit identifier
for this, of course.)
>
> Not necessarily. Many CAN messaging schemes
don't talk really
> about /who/ to talk to, but /what/ to say (so to
speak).
> Everybody listens, and selects based on the message type,
>
not any recipient address.

Yes, perfactly clear. I was just comparing
with the *currect* design
where they use a number of discrete "address-
lines" in the cable
to select the recevier. All carrying standard
TLL/CMOS signals.

>
> The idea is that someone transmits the
temperature at point
> 51. Whoever needs that, picks it. Someone else
transmits the
> humidity at point 33. Again, who needs it, picks it.
And so on.
> No real destination addresses in this schema.

Or, by
using the RTR feature in the newer PICs, the temp node
just stores the
temp reading in an RTR buffer, and then, whenever
there is a "request
for temp" message on the bus, the ECAN module
automaticly sends the
temp reading. No firmware intervention. And
no bus traffic if there is
noone that wants to know the temp... :-)

>
> (Of course, that's not
required by CAN. You can embed
> destination addresses in the message
identifier, and the stations
> can filter based on the bits that encode
the destination address.
> But I think the message broadcast scheme is
the original CAN
> concept, and the most popular one among the higher-
level protocols.)

This isn't realy a technical issue, but more a
question of how
you look at it, not ?

> I have the IXXAT USB-to-CAN
compact. Works well, never had a
> problem, and comes with a
rudimentary bus monitor application.

I'm just browsing around their
site... :-)

Regards,
Jan-Erik.



2005\06\14@072808 by Gerhard Fiedler

picon face
Jan-Erik Soderholm wrote:

>> [connectors]
> This seems to ba a fairly open issue, so we could probably match the
> cabling with other needs in the project.

Exactly. There are some pseudo-standards, and they may become important
when you're thinking of integrating other vendors' products (like the PC
CAN interface I'm using has a DB9 connector).

>> (Of course, that's not required by CAN. You can embed destination
>> addresses in the message identifier, and the stations can filter based
>> on the bits that encode the destination address. But I think the
>> message broadcast scheme is the original CAN concept, and the most
>> popular one among the higher- level protocols.)
>
> This isn't realy a technical issue, but more a question of how you look
> at it, not ?

It depends on what you mean by "technical issue" :)  That's where the
higher-level protocols that sit on top of CAN come into play. The different
encoding schemes have different characteristics.

For example, if you have many devices on the bus that may send the same
error messages, a scheme that encodes the sender address in the message id
may be useful -- you can use the same error codes for all devices, and they
are distinguished by the encoded sender address. (Note that due to the bus
arbitration, you may not have two devices that may try to send the same
message id.)

Gerhard

2005\06\14@074159 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> It depends on what you mean by "technical issue" :)  That's
> where the higher-level protocols that sit on top of CAN
> come into play. The different encoding schemes have
> different characteristics.
Right :-)
What I ment is that there is no "address field" as such
in the CAN frame be definition. Anyway...

> (Note that due to the bus arbitration, you may not
> have two devices that may try to send the same
> message id.)

I read it such as you aren't even allowed to have multiple
devices potentionally sending using the same ID !?

Jan-Erik.


Jan-Erik Söderholm
Jan-Erik Söderholm Consulting AB
Össby Skogstorp
61490 Söderköping
Sweden.

Phone : 0121-42161

2005\06\14@184934 by Gerhard Fiedler

picon face
Jan-Erik Soderholm wrote:

>> (Note that due to the bus arbitration, you may not have two devices that
>> may try to send the same message id.)
>
> I read it such as you aren't even allowed to have multiple devices
> potentionally sending using the same ID !?

I'm not sure I understand you here (or you me :) as I'm considering our two
phrases identical.

The arbitration mechanism works on the message id (plus the RTR bit). CAN
arbitration doesn't work if two devices potentially may try to send the
same arbitration data, so that's a no-no.

There's an issue with that with the RTR frame mechanism. (AFAIK several of
the higher level protocols don't use them because of this.) The reason is
that if you have multiple consumers of a data point/message id, these may
want to be able to request that data independently from each other. Using a
simple, straightforward RTR mechanism, that's not possible, because it
could create a situation where different devices send the same message id
with the RTR bit set. I worked around that by encoding the sender into the
message id (and using a bit of the message id for marking requests). That
guarantees that all requests are unique.

Gerhard

2005\06\14@185908 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> Jan-Erik Soderholm wrote:
>
> >> (Note that
due to the bus arbitration, you may not have
> >> two devices that
>
>> may try to send the same message id.)
> >
> > I read it such as you
aren't even allowed to have multiple devices
> > potentionally sending
using the same ID !?
>
> I'm not sure I understand you here (or you
me :) as I'm
> considering our two phrases identical.

Yep, it's my
miss-interpretion of the word "may" !
I've done that before... :-)

And
we fully agree on the rest of your post.

Best Regards and thanks for
your input !
Jan-Erik.



More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...