Re: [ee]: Some CAN thoughts...

[Alan B. Pearce]

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

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Jan-Erik Söderholm]

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.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Jan-Erik Söderholm]

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 : [phone]


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Jan-Erik Söderholm]

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.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist