Reply by John Theofanopoulos ●February 17, 20042004-02-17
Steven,

I was actually referring to the transport layer that is used with
Keyword Protocol 2000 (used primarily for vehicle diagnostics). Not
sure what the actual name of the transport layer is, but it is based on
some iso standard (ISO 15765-2) >I agree with your points John. I think maybe I might be mixing
>up some points between creating your own protocol vs. using
>an existing protocol vs. buying a protocol stack. I have never
>found an existing protocol that was readily available without
> paying much $$$, either for the specs or for the code. Are
>you referring to J1939 or some derivative? S

Steven D. Letkeman BSc.
President - Zanthic Technologies Inc.
403-526-8318
www.zanthic.com Embedded micro-controllers and CAN interfaces
www.brightan.com Automated lighting systems

----- Original Message -----
From: "John Theofanopoulos" <>
To: <>
Sent: Monday, February 16, 2004 11:19 AM
Subject: RE: [68HC12] HCS12 and CAN Bus > >>The reason I will tend to create a CAN protocol over using an
> >>existing
> one comes down to a couple of reasons
> >>1) Time. Existing protocols have tried to be all things to all apps
> and have ended up becoming very complex. The amount of time
> >>required to fully understand a full blown protocol stack would be
> months. Sometimes a person only needs to transfer some simple
> >>data and a simple protocol could be created in a day.
>
> Ok, I'll give you that. Although, it seems to me (by the questions
> being asked here), that no one is really trying to build a simple
> protocol that you could put together in a day.
>
> >>2) Cost. In order to implement a full blown protocol, you either
> >>have
> to spend months writing your own or purchase one, usually at a
> >>pretty high cost (20-30K) Again, why spend months writing in
> >>features
> that your app doesn't need? Also, the time required to
> >>understand someone elses code is not to be underestimated, not to
> mention the fact that a lot of this code is generated in
> >> Germany and is in a different style of coding and commenting than I
> am used to.
>
> Understanding the spec, means that you don't have to buy anybody's
> code. Also, the code that you are buying for 20-30k, isn't code
> specific to your hardware. Its designed to meet many
> needs/processors, and the #ifdefs determine what the build is like.
> If you were to implement that protocol solely for your hardware it
> would be more compact.
>
> >>3) Compatibility. If your not going to write in all the features of
> the protocol than you are not going to be compatible, why bother being
> >>somewhat compatible? Better to write something simple and easy to
> understand. If, on the other hand, you are trying to create a
> >>product that will be sold to the masses, than an existing protocol
> would be the way to go, but beware of the cost and time required.
> >> I'm not the only one that has gotten months into a CANOpen
> implemention to find that it is simply not suitable for the
> application.
>
> Never looked at the CANOpen spec. It's not used with the automotive
> clients we deal with. The protocol stack they use, we were able to
> implement in house. Total code space is 1.3k of code space.
>
> >>4) Size, a typically slave node implementation of CANOpen requires
> around 32K and this isn't even doing anything 'useful' yet.
>
> >>5) Speed. Because an existing protocol stack tries to cover all the
> bases, and tries to be completely configurable, you end up take a
> >>large performance hit in the speed of data transfer.
>
> The problem with developing your own protocol (instead of a spec
> that's been tested and in use for a significant period of time), is
> that you not only end up debugging your code, but the spec you
> developped as well.
>
> In our case, we developped one protocol based on a known spec and we
> use it repeatedly. If a customer happens to ask for something else,
> then we'll do it for them, but that's it. We don't reinvent the wheel

> with every new project that comes up.
>
> Just my opinion on the matter.
>
> John
>
> ----- Original Message -----
> From: "John Theofanopoulos" <>
> To: <>
> Sent: Saturday, February 14, 2004 9:38 AM
> Subject: RE: [68HC12] HCS12 and CAN Bus > > I see a lot of discussion on how to communicate over CAN, and since
> > there's enough protocols out there already, not sure why people are
> > busy inventing more...
> >
> > Anyway having worked with CAN for quite a number of years, here's
> > my take on it.
> >
> > If you need to see data often, have the device collecting the
> > broadcast the data frequently and with a high priority id. The
> > devices that don't care about this data, can simply filter out that
> > ID. Less critical data, well, less frequent transmissions and lower
> > priority id.
> >
> > Diagnostic data (more than 8 bytes), use a transport layer as
> > described by ISO 15765-2.
> >
> > If you like the slave/master approach (I personally don't care for
> > it), you can use DeviceNet, CANOpen, etc.
> >
> > John
> > -----Original Message-----
> > From: Sydney Faria [mailto:]
> > Sent: Saturday, February 14, 2004 10:46 AM
> > To:
> > Subject: Re: [68HC12] HCS12 and CAN Bus
> >
> >
> > There was an app note describing a 'linked list' set up to send msgs
> > with more than 8 bytes, so I set up a data buffer area with a
> > pointer to it along with a byte counter. Then I made a routine that

> > entered IDR0 - IDR3, TXPrior, DLC and upto 8 bytes of data from the
> > data buffer and kept track of the remaining total. The message frame

> > is Txd
>
> > and the the next frame until
> > the data was completely sent -- works great! Each node has a FIFO
> > queue
> > with atomic pointers and the nodes process their normal code until 1
> > or more
> > messages are Rxd, then the messages are handled. My nodes handle a
> > group
> > of standard IDs, 6 to 8, and all the nodes accept 000 and 008 which
> > I use as
> > a 'broadcast' msg from the master to all the slave nodes. Lets say
> one
> > of
> > the slave nodes also has the ID of 200: my filtering is setup to
> > receive 000, 008, 200, 202, 204,,,,20E. All the nodes can figure an

> > offset of 0, 1, 2, 3, ,,, from these IDs. Now my messages are
> > handled
>
> > by this node as computed gotos based on the offset. My master works
> > the same way. I use up to 40 slave nodes with a master to run
> > engine testing where the slave nodes control such things as laser
> > power levels and other control functions. By assigning meaning to
> > the address IDs I can ask a node to send me information such as
> > critical voltages, temperatures, power levels by sending a message
> > with a particular ID. I don't waste data bytes telling me this
> > stuff. Since I am using the lowest three bits of the standard ID to
> > calculate an offset at the receiving node, I only have to know the
> > first 8 bits for
>
> > a destination address. The 000 message sent by the master asks all
> > nodes to send a short frame with ID byte and 2 other peices of
> > information that I need. The master collects all these msgs in the
> > queue and makes a list of who is out there for future reference!
> >
> > The identifier paragraph of your message reminds me of much of my
> > earlier experimentation in this area about three months ago: you can

> > check out my earlier posting on this site as well as the CAN-CIA
> > site mirrored by Yahoo. Check out vector-informatik.de to register
> > for it there is good information there but it is more oriented
> > towards higher
>
> > level protocols and not so much the msCAN protocol that is
> > implemented
>
> > in the 68HC12 set. In any case it would behoove you to get a
> > freebie copy of the filtergen tool that is referenced by the
> > Motorola application on filtering. What I did was to purchase a
> > tinCAN interface so that I could Tx and Rx on a CANbus to my D60A
> > development
>
> > board to check out my programs and what I thought could be done with
> > filtering. Well worth the effort.
> >
> > One more note: on the Axiom site they now have a list of books
> > relating to the 68hc12 processors - the Valvano book discusses
> > atomic data and FIFO queues, while Huang's book discussed CAN
> > specifically for the 68hc12D60 -- they both saved me much time.
> > ----- Original Message -----
> > From: hc08jb8
> > To:
> > Sent: Thursday, February 12, 2004 10:52 PM
> > Subject: [68HC12] HCS12 and CAN Bus
> >
> >
> > Hi Folks
> >
> > I am trying to use CAN bus as a communication link in a project. I
> > have a CAN 'Master' connected to the PC and several CAN 'Nodes'.
> > These nodes are based on Motorola HCS12C32 MCU with CAN. I have
got
> > the communication working however I find the default maximum
> transfer
> > of 8 bytes per transaction somewhat limiting.
> >
> > When searching for higher level protocol layers, most of them seem
> to
> > be quite expensive or complex. I would like to find out if there
is
> > any simple low cost higher level layer that could handle messages
> and
> > so forth greater than 8 bytes?
> >
> > Another question is, the MCU i use has a Identifier Acceptance
> > Register and a Identifier Mask Register, I am a bit confused as to
> > which should I set if I need to filter only one ID, say for
example:
> > accept only messages with ID of 0x105.
> >
> > Regds
> > Jay
> >
> >
> >
> > --------------------To learn
> > more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --------------------------------
> > --
> > --
> > ----
> > --
> > Yahoo! Groups Links
> >
> > a.. To
> >
> >
> >
> >
> >
> >
> >
> > --------------------To learn
> > more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu o learn more about Motorola
> > Microcontrollers, please visit http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> > --------------------To learn
> > more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu o learn more about Motorola
> Microcontrollers, please visit http://www.motorola.com/mcu
>
> Yahoo! Groups Links > --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links
--------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu o learn more about Motorola
Microcontrollers, please visit http://www.motorola.com/mcu

Yahoo! Groups Links


Reply by hc08jb8 ●February 17, 20042004-02-17
Hey Nick

I am in Singapore, nifty island country, and indeed the CAN spec was
a good read.

Regds
Jay

--- In , "Allen, Nick" <nick.allen@t...> wrote:
> "by the beach" ????
> where are you????
> Nick
>
> > -----Original Message-----
> > From: hc08jb8 [mailto:hc08jb8@y...]
> > Sent: Friday, February 13, 2004 8:52 PM
> > To:
> > Subject: [68HC12] Re: HCS12 and CAN Bus
> >
> >
> > Thanks Tony, Steve, Bob, Nick and all for valuable input. I know
> > coming out with a own protocol isnt easy, especially not on CAN
where
> > testing it can be a big issue. Anyways, I ahve decided to make
up a
> > simple protocol using the 29 bit ID as the node address + command
> > type or command value. I need to sit and think on how to use the
bits
> > appropriately, this will greatly depend on the number of type of
> > commands to be send and to a maximum number of nodes.
> >
> > Juz printed out the CAN spec, looks like it would be a good read
by
> > the beach this weekend ;)
> >
> > Thanks again guys, I have been pointed into the right direction
and
> > been warned as well, this amazing level of peer support is what
makes
> > me choose a HC12 anyday.
> >
> > Cheers
> > Jay
> >
> >
> >
> > --- In , "Allen, Nick" <nick.allen@t...>
wrote:
> > > His USB--CAN converter works great.
> > > Comes with a nice app to get you going on transmitting
> > > and receiving without having to write any code for it.
> > > Nick
> > >
> > > -----Original Message-----
> > > From: Steve Letkeman [mailto:hc12list@z...]
> > > Sent: Friday, February 13, 2004 4:43 PM
> > > To:
> > > Subject: Re: [68HC12] HCS12 and CAN Bus
> > >
> > >
> > > Ya, that's my $15 mil yacht I earned doing embedded processor
> > > work, doesn't everyone have one? The CAN-4-USB is an interface
> > > that I've designed and have been selling for a number of years
now.
> > > http://www.zanthic.com/can4usb.htm
> > <http://www.zanthic.com/can4usb.htm>
> > > (thanks for asking and sorry for the blatant plug)
> > > S
> > >
> > > > Hi Steve
> > > >
> > > > > ..most of what I was describing comes from the
> > > > > protocol I designed for the HC12+CAN based lighting
> > > > > system I've been developing.
> > > > >
> > > > > www.brightan.com Automated lighting systems
> > > >
> > > > Impressive!
> > > >
> > > > Your Yacht?
> > > >
> > > > What do you use as the USB4CAN device? Did you roll this
> > yourself? Or, is
> > > it
> > > > an off-the-shelf item?
> > > >
> > > > Bfn,
> > > >
> > > > Bob Furber
> > > >
> > > > __________________________________________________________
> > > >
> > > > Connect your micro to the internet the easy way
> > > > www.microcommander.com
> > > >
> > > > Microcontroller with an obscenity of I/O & features
> > > > ..in a small footprint www.steroidmicros.com
> > > > __________________________________________________________
> > > >
> > > >
> > > >
> > > > --------------------To
learn
> > more
> > > about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu <http://www.motorola.com/mcu>
> > > > o learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu <http://www.motorola.com/mcu>
> > > >
> > > > > .
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --------------------To
> > learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >




Reply by Allen, Nick ●February 17, 20042004-02-17
"by the beach" ????
where are you????
Nick

> -----Original Message-----
> From: hc08jb8 [mailto:]
> Sent: Friday, February 13, 2004 8:52 PM
> To:
> Subject: [68HC12] Re: HCS12 and CAN Bus > Thanks Tony, Steve, Bob, Nick and all for valuable input. I know
> coming out with a own protocol isnt easy, especially not on CAN where
> testing it can be a big issue. Anyways, I ahve decided to make up a
> simple protocol using the 29 bit ID as the node address + command
> type or command value. I need to sit and think on how to use the bits
> appropriately, this will greatly depend on the number of type of
> commands to be send and to a maximum number of nodes.
>
> Juz printed out the CAN spec, looks like it would be a good read by
> the beach this weekend ;)
>
> Thanks again guys, I have been pointed into the right direction and
> been warned as well, this amazing level of peer support is what makes
> me choose a HC12 anyday.
>
> Cheers
> Jay >
> --- In , "Allen, Nick" <nick.allen@t...> wrote:
> > His USB--CAN converter works great.
> > Comes with a nice app to get you going on transmitting
> > and receiving without having to write any code for it.
> > Nick
> >
> > -----Original Message-----
> > From: Steve Letkeman [mailto:hc12list@z...]
> > Sent: Friday, February 13, 2004 4:43 PM
> > To:
> > Subject: Re: [68HC12] HCS12 and CAN Bus
> >
> >
> > Ya, that's my $15 mil yacht I earned doing embedded processor
> > work, doesn't everyone have one? The CAN-4-USB is an interface
> > that I've designed and have been selling for a number of years now.
> > http://www.zanthic.com/can4usb.htm
> <http://www.zanthic.com/can4usb.htm>
> > (thanks for asking and sorry for the blatant plug)
> > S
> >
> > > Hi Steve
> > >
> > > > ..most of what I was describing comes from the
> > > > protocol I designed for the HC12+CAN based lighting
> > > > system I've been developing.
> > > >
> > > > www.brightan.com Automated lighting systems
> > >
> > > Impressive!
> > >
> > > Your Yacht?
> > >
> > > What do you use as the USB4CAN device? Did you roll this
> yourself? Or, is
> > it
> > > an off-the-shelf item?
> > >
> > > Bfn,
> > >
> > > Bob Furber
> > >
> > > __________________________________________________________
> > >
> > > Connect your micro to the internet the easy way
> > > www.microcommander.com
> > >
> > > Microcontroller with an obscenity of I/O & features
> > > ..in a small footprint www.steroidmicros.com
> > > __________________________________________________________
> > >
> > >
> > >
> > > --------------------To learn
> more
> > about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu <http://www.motorola.com/mcu>
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu <http://www.motorola.com/mcu>
> > >
> > > > .
> >
> >
> >
> >
> >
> --------------------To
> learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links



Reply by John Theofanopoulos ●February 16, 20042004-02-16
>>Since my application was written entirely in assembly for the
>>68hc912d60a chip which already contained the msCAN module, just how
would it be possible to use a higher level protocol?

I don't follow your question. Are you suggesting that higher level
protocols cannot be written in assembly?

>>My project needed hard real-time constraints and the CAN protocol
>>supplies that requirement.

Again, not following your question. Most projects have hard real-time
constraings, and yes, CAN supplies that (unless of course your ID is too
low on the priority chain, and the bus is too busy, etc....) What does
that have to do with the higher level protocol?

>>My choice would have been to use C and include some canned code to do
the CAN communication. Assembly language
>>requirements precluded using this idea. Having all the CAN
implemented in HCS12 now gives me a much better idea of what
>>some of the higher level protocols are really doing behind the scenes.
I have also wondered exactly what the real predictiblity
>>of the system with CAN implemented is now that I realize that all
there are many interrupts with a much higher priority than any
>>of the CAN interrupts. I know that my system is based on the idea
that all CAN Rxd msgs are treated with the highest
>>non-maskable priority that I could assign by promotion, which leaves
the rest of the CAN ints much lower, but how is this treated
>>with higher level protocols?

This all depends on what you are trying to do. In automotive apps there
is no 'protocol' as the various nodes communicate with each other.
There is a protocol for diagnostic data and for flashing purposes.

>> It would seem to be a reasonable assumption that the CAN routines are
all left in their original priority
>>levels, so even though the CAN protocol itself is completely
predictable, much of the predictability is lost because of the
relatively low
>>priority of the entire CAN module. This could have become a serious
factor in our system which is handling vibration analysis and
>>signal acquisition of a large number of signals each of which has to
be treated separately with a FFT.

>>Then again when I started the CAN portion of the project I was told
that the CAN portion was the most scarey part of the project and
>>that 3-4 months was alloted to this portion of the project: working
without previous CAN experience, and little 68HC12 experience it still
>>only took about 6 weeks to get the whole CAN protocol running from the
Motorola application notes and the assistance of this and
>>the CAN-CIA site.

----- Original Message -----
From: John Theofanopoulos
To:
Sent: Saturday, February 14, 2004 11:38 AM
Subject: RE: [68HC12] HCS12 and CAN Bus I see a lot of discussion on how to communicate over CAN, and since
there's enough protocols out there already, not sure why people are
busy
inventing more...

Anyway having worked with CAN for quite a number of years, here's my
take on it.

If you need to see data often, have the device collecting the
broadcast
the data frequently and with a high priority id. The devices that
don't
care about this data, can simply filter out that ID.
Less critical data, well, less frequent transmissions and lower
priority
id.

Diagnostic data (more than 8 bytes), use a transport layer as
described
by ISO 15765-2.

If you like the slave/master approach (I personally don't care for
it),
you can use DeviceNet, CANOpen, etc.

John
-----Original Message-----
From: Sydney Faria [mailto:]
Sent: Saturday, February 14, 2004 10:46 AM
To:
Subject: Re: [68HC12] HCS12 and CAN Bus There was an app note describing a 'linked list' set up to send msgs
with more than 8 bytes, so I set up a data buffer area with a pointer
to
it along with a byte counter. Then I made a routine that entered IDR0
-
IDR3, TXPrior, DLC and upto 8 bytes of data from the data buffer and
kept track of the remaining total. The message frame is Txd and the
the
next frame until
the data was completely sent -- works great! Each node has a FIFO
queue
with atomic pointers and the nodes process their normal code until 1
or
more
messages are Rxd, then the messages are handled. My nodes handle a
group
of standard IDs, 6 to 8, and all the nodes accept 000 and 008 which I
use as
a 'broadcast' msg from the master to all the slave nodes. Lets say
one
of
the slave nodes also has the ID of 200: my filtering is setup to
receive
000, 008, 200, 202, 204,,,,20E. All the nodes can figure an offset of
0, 1, 2, 3, ,,, from these IDs. Now my messages are handled by this
node as computed gotos based on the offset. My master works the same
way. I use up to 40 slave nodes with a master to run engine testing
where the slave nodes control such things as laser power levels and
other control functions. By assigning meaning to the address IDs I can
ask a node to send me information such as critical voltages,
temperatures, power levels by sending a message with a particular ID.
I
don't waste data bytes telling me this stuff. Since I am using the
lowest three bits of the standard ID to calculate an offset at the
receiving node, I only have to know the first 8 bits for a destination
address. The 000 message sent by the master asks all nodes to send a
short frame with ID byte and 2 other peices of information that I
need.
The master collects all these msgs in the queue and makes a list of
who
is out there for future reference!

The identifier paragraph of your message reminds me of much of my
earlier experimentation in this area about three months ago: you can
check out my earlier posting on this site as well as the CAN-CIA site
mirrored by Yahoo. Check out vector-informatik.de to register for it
there is good information there but it is more oriented towards higher
level protocols and not so much the msCAN protocol that is implemented
in the 68HC12 set. In any case it would behoove you to get a freebie
copy of the filtergen tool that is referenced by the Motorola
application on filtering. What I did was to purchase a tinCAN
interface
so that I could Tx and Rx on a CANbus to my D60A development board to
check out my programs and what I thought could be done with filtering.
Well worth the effort.

One more note: on the Axiom site they now have a list of books
relating
to the 68hc12 processors - the Valvano book discusses atomic data and
FIFO queues, while Huang's book discussed CAN specifically for the
68hc12D60 -- they both saved me much time.
----- Original Message -----
From: hc08jb8
To:
Sent: Thursday, February 12, 2004 10:52 PM
Subject: [68HC12] HCS12 and CAN Bus Hi Folks

I am trying to use CAN bus as a communication link in a project. I
have a CAN 'Master' connected to the PC and several CAN 'Nodes'.
These nodes are based on Motorola HCS12C32 MCU with CAN. I have got
the communication working however I find the default maximum
transfer
of 8 bytes per transaction somewhat limiting.

When searching for higher level protocol layers, most of them seem
to
be quite expensive or complex. I would like to find out if there is
any simple low cost higher level layer that could handle messages
and
so forth greater than 8 bytes?

Another question is, the MCU i use has a Identifier Acceptance
Register and a Identifier Mask Register, I am a bit confused as to
which should I set if I need to filter only one ID, say for example:
accept only messages with ID of 0x105.

Regds
Jay
--------------------To learn
more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu
o learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu ----
--
Yahoo! Groups Links

a.. To

--------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu o learn more about Motorola
Microcontrollers, please visit http://www.motorola.com/mcu

Yahoo! Groups Links

--------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu
o learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu ----
--
Yahoo! Groups Links

a.. To --------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu o learn more about Motorola
Microcontrollers, please visit http://www.motorola.com/mcu

Yahoo! Groups Links


Reply by Steve Letkeman ●February 16, 20042004-02-16
I'm not saying it can't be done, I got carried away with comparing
off the shelf protocol stacks with do it yourself protocols which was
off topic of the original thread and not a fair comparison...If I had to
do another CANOpen project, I would definitely do it as you suggest.

S

----- Original Message -----
From: "Oliver Betz" <>
To: <>
Sent: Monday, February 16, 2004 11:59 AM
Subject: Re: [68HC12] HCS12 and CAN Bus > Steve Letkeman wrote:
>
> [Time, cost, compatibility]
>
> > 4) Size, a typically slave node implementation of CANOpen requires
> > around 32K and this isn't even doing anything 'useful' yet.
>
> I made my own lean CANopen implementation with some 500 lines of C-
> code resulting in _much_ less executable code.
>
> A limitation is that there is no segmented SDO transfer (only
> expedited, i.e. 4 bytes), but this could be done with acceptable
> effort. After understanding CANopen, it was not so hard.
>
> I think, it was worth the effort.
>
> Oliver
> --
> Oliver Betz, Muenchen >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links >

Reply by Oliver Betz ●February 16, 20042004-02-16
Steve Letkeman wrote:

[Time, cost, compatibility]

> 4) Size, a typically slave node implementation of CANOpen requires
> around 32K and this isn't even doing anything 'useful' yet.

I made my own lean CANopen implementation with some 500 lines of C-
code resulting in _much_ less executable code.

A limitation is that there is no segmented SDO transfer (only
expedited, i.e. 4 bytes), but this could be done with acceptable
effort. After understanding CANopen, it was not so hard.

I think, it was worth the effort.

Oliver
--
Oliver Betz, Muenchen

Reply by Steve Letkeman ●February 16, 20042004-02-16
I agree with your points John. I think maybe I might be mixing up
some points between creating your own protocol vs. using an
existing protocol vs. buying a protocol stack. I have never
found an existing protocol that was readily available without
paying much $$$, either for the specs or for the code. Are
you referring to J1939 or some derivative?
S

Steven D. Letkeman BSc.
President - Zanthic Technologies Inc.
403-526-8318
www.zanthic.com Embedded micro-controllers and CAN interfaces
www.brightan.com Automated lighting systems

----- Original Message -----
From: "John Theofanopoulos" <>
To: <>
Sent: Monday, February 16, 2004 11:19 AM
Subject: RE: [68HC12] HCS12 and CAN Bus > >>The reason I will tend to create a CAN protocol over using an existing
> one comes down to a couple of reasons
> >>1) Time. Existing protocols have tried to be all things to all apps
> and have ended up becoming very complex. The amount of time
> >>required to fully understand a full blown protocol stack would be
> months. Sometimes a person only needs to transfer some simple
> >>data and a simple protocol could be created in a day.
>
> Ok, I'll give you that. Although, it seems to me (by the questions
> being asked here), that no one is really trying to build a simple
> protocol that you could put together in a day.
>
> >>2) Cost. In order to implement a full blown protocol, you either have
> to spend months writing your own or purchase one, usually at a
> >>pretty high cost (20-30K) Again, why spend months writing in features
> that your app doesn't need? Also, the time required to
> >>understand someone elses code is not to be underestimated, not to
> mention the fact that a lot of this code is generated in
> >> Germany and is in a different style of coding and commenting than I
> am used to.
>
> Understanding the spec, means that you don't have to buy anybody's code.
> Also, the code that you are buying for 20-30k, isn't code specific to
> your hardware. Its designed to meet many needs/processors, and the
> #ifdefs determine what the build is like. If you were to implement that
> protocol solely for your hardware it would be more compact.
>
> >>3) Compatibility. If your not going to write in all the features of
> the protocol than you are not going to be compatible, why bother being
> >>somewhat compatible? Better to write something simple and easy to
> understand. If, on the other hand, you are trying to create a
> >>product that will be sold to the masses, than an existing protocol
> would be the way to go, but beware of the cost and time required.
> >> I'm not the only one that has gotten months into a CANOpen
> implemention to find that it is simply not suitable for the application.
>
> Never looked at the CANOpen spec. It's not used with the automotive
> clients we deal with. The protocol stack they use, we were able to
> implement in house. Total code space is 1.3k of code space.
>
> >>4) Size, a typically slave node implementation of CANOpen requires
> around 32K and this isn't even doing anything 'useful' yet.
>
> >>5) Speed. Because an existing protocol stack tries to cover all the
> bases, and tries to be completely configurable, you end up take a
> >>large performance hit in the speed of data transfer.
>
> The problem with developing your own protocol (instead of a spec that's
> been tested and in use for a significant period of time), is that you
> not only end up debugging your code, but the spec you developped as
> well.
>
> In our case, we developped one protocol based on a known spec and we use
> it repeatedly. If a customer happens to ask for something else, then
> we'll do it for them, but that's it. We don't reinvent the wheel with
> every new project that comes up.
>
> Just my opinion on the matter.
>
> John
>
> ----- Original Message -----
> From: "John Theofanopoulos" <>
> To: <>
> Sent: Saturday, February 14, 2004 9:38 AM
> Subject: RE: [68HC12] HCS12 and CAN Bus > > I see a lot of discussion on how to communicate over CAN, and since
> > there's enough protocols out there already, not sure why people are
> > busy inventing more...
> >
> > Anyway having worked with CAN for quite a number of years, here's my
> > take on it.
> >
> > If you need to see data often, have the device collecting the
> > broadcast the data frequently and with a high priority id. The
> > devices that don't care about this data, can simply filter out that
> > ID. Less critical data, well, less frequent transmissions and lower
> > priority id.
> >
> > Diagnostic data (more than 8 bytes), use a transport layer as
> > described by ISO 15765-2.
> >
> > If you like the slave/master approach (I personally don't care for
> > it), you can use DeviceNet, CANOpen, etc.
> >
> > John
> > -----Original Message-----
> > From: Sydney Faria [mailto:]
> > Sent: Saturday, February 14, 2004 10:46 AM
> > To:
> > Subject: Re: [68HC12] HCS12 and CAN Bus
> >
> >
> > There was an app note describing a 'linked list' set up to send msgs
> > with more than 8 bytes, so I set up a data buffer area with a pointer
> > to it along with a byte counter. Then I made a routine that entered
> > IDR0 - IDR3, TXPrior, DLC and upto 8 bytes of data from the data
> > buffer and kept track of the remaining total. The message frame is Txd
>
> > and the the next frame until
> > the data was completely sent -- works great! Each node has a FIFO
> > queue
> > with atomic pointers and the nodes process their normal code until 1
> > or more
> > messages are Rxd, then the messages are handled. My nodes handle a
> > group
> > of standard IDs, 6 to 8, and all the nodes accept 000 and 008 which I
> > use as
> > a 'broadcast' msg from the master to all the slave nodes. Lets say
> one
> > of
> > the slave nodes also has the ID of 200: my filtering is setup to
> > receive 000, 008, 200, 202, 204,,,,20E. All the nodes can figure an
> > offset of 0, 1, 2, 3, ,,, from these IDs. Now my messages are handled
>
> > by this node as computed gotos based on the offset. My master works
> > the same way. I use up to 40 slave nodes with a master to run engine
> > testing where the slave nodes control such things as laser power
> > levels and other control functions. By assigning meaning to the
> > address IDs I can ask a node to send me information such as critical
> > voltages, temperatures, power levels by sending a message with a
> > particular ID. I don't waste data bytes telling me this stuff. Since
> > I am using the lowest three bits of the standard ID to calculate an
> > offset at the receiving node, I only have to know the first 8 bits for
>
> > a destination address. The 000 message sent by the master asks all
> > nodes to send a short frame with ID byte and 2 other peices of
> > information that I need. The master collects all these msgs in the
> > queue and makes a list of who is out there for future reference!
> >
> > The identifier paragraph of your message reminds me of much of my
> > earlier experimentation in this area about three months ago: you can
> > check out my earlier posting on this site as well as the CAN-CIA site
> > mirrored by Yahoo. Check out vector-informatik.de to register for it
> > there is good information there but it is more oriented towards higher
>
> > level protocols and not so much the msCAN protocol that is implemented
>
> > in the 68HC12 set. In any case it would behoove you to get a freebie
> > copy of the filtergen tool that is referenced by the Motorola
> > application on filtering. What I did was to purchase a tinCAN
> > interface so that I could Tx and Rx on a CANbus to my D60A development
>
> > board to check out my programs and what I thought could be done with
> > filtering. Well worth the effort.
> >
> > One more note: on the Axiom site they now have a list of books
> > relating to the 68hc12 processors - the Valvano book discusses atomic
> > data and FIFO queues, while Huang's book discussed CAN specifically
> > for the 68hc12D60 -- they both saved me much time.
> > ----- Original Message -----
> > From: hc08jb8
> > To:
> > Sent: Thursday, February 12, 2004 10:52 PM
> > Subject: [68HC12] HCS12 and CAN Bus
> >
> >
> > Hi Folks
> >
> > I am trying to use CAN bus as a communication link in a project. I
> > have a CAN 'Master' connected to the PC and several CAN 'Nodes'.
> > These nodes are based on Motorola HCS12C32 MCU with CAN. I have got
> > the communication working however I find the default maximum
> transfer
> > of 8 bytes per transaction somewhat limiting.
> >
> > When searching for higher level protocol layers, most of them seem
> to
> > be quite expensive or complex. I would like to find out if there is
> > any simple low cost higher level layer that could handle messages
> and
> > so forth greater than 8 bytes?
> >
> > Another question is, the MCU i use has a Identifier Acceptance
> > Register and a Identifier Mask Register, I am a bit confused as to
> > which should I set if I need to filter only one ID, say for example:
> > accept only messages with ID of 0x105.
> >
> > Regds
> > Jay
> >
> >
> >
> > --------------------To learn
> > more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ----------------------------------
> > --
> > ----
> > --
> > Yahoo! Groups Links
> >
> > a.. To
> >
> >
> >
> >
> >
> >
> >
> > --------------------To learn more
> > about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu o learn more about Motorola
> > Microcontrollers, please visit http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu o learn more about Motorola
> Microcontrollers, please visit http://www.motorola.com/mcu
>
> Yahoo! Groups Links > --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links


Reply by John Theofanopoulos ●February 16, 20042004-02-16
>>The reason I will tend to create a CAN protocol over using an existing
one comes down to a couple of reasons
>>1) Time. Existing protocols have tried to be all things to all apps
and have ended up becoming very complex. The amount of time
>>required to fully understand a full blown protocol stack would be
months. Sometimes a person only needs to transfer some simple
>>data and a simple protocol could be created in a day.

Ok, I'll give you that. Although, it seems to me (by the questions
being asked here), that no one is really trying to build a simple
protocol that you could put together in a day.

>>2) Cost. In order to implement a full blown protocol, you either have
to spend months writing your own or purchase one, usually at a
>>pretty high cost (20-30K) Again, why spend months writing in features
that your app doesn't need? Also, the time required to
>>understand someone elses code is not to be underestimated, not to
mention the fact that a lot of this code is generated in
>> Germany and is in a different style of coding and commenting than I
am used to.

Understanding the spec, means that you don't have to buy anybody's code.
Also, the code that you are buying for 20-30k, isn't code specific to
your hardware. Its designed to meet many needs/processors, and the
#ifdefs determine what the build is like. If you were to implement that
protocol solely for your hardware it would be more compact.

>>3) Compatibility. If your not going to write in all the features of
the protocol than you are not going to be compatible, why bother being
>>somewhat compatible? Better to write something simple and easy to
understand. If, on the other hand, you are trying to create a
>>product that will be sold to the masses, than an existing protocol
would be the way to go, but beware of the cost and time required.
>> I'm not the only one that has gotten months into a CANOpen
implemention to find that it is simply not suitable for the application.

Never looked at the CANOpen spec. It's not used with the automotive
clients we deal with. The protocol stack they use, we were able to
implement in house. Total code space is 1.3k of code space.

>>4) Size, a typically slave node implementation of CANOpen requires
around 32K and this isn't even doing anything 'useful' yet.

>>5) Speed. Because an existing protocol stack tries to cover all the
bases, and tries to be completely configurable, you end up take a
>>large performance hit in the speed of data transfer.

The problem with developing your own protocol (instead of a spec that's
been tested and in use for a significant period of time), is that you
not only end up debugging your code, but the spec you developped as
well.

In our case, we developped one protocol based on a known spec and we use
it repeatedly. If a customer happens to ask for something else, then
we'll do it for them, but that's it. We don't reinvent the wheel with
every new project that comes up.

Just my opinion on the matter.

John

----- Original Message -----
From: "John Theofanopoulos" <>
To: <>
Sent: Saturday, February 14, 2004 9:38 AM
Subject: RE: [68HC12] HCS12 and CAN Bus > I see a lot of discussion on how to communicate over CAN, and since
> there's enough protocols out there already, not sure why people are
> busy inventing more...
>
> Anyway having worked with CAN for quite a number of years, here's my
> take on it.
>
> If you need to see data often, have the device collecting the
> broadcast the data frequently and with a high priority id. The
> devices that don't care about this data, can simply filter out that
> ID. Less critical data, well, less frequent transmissions and lower
> priority id.
>
> Diagnostic data (more than 8 bytes), use a transport layer as
> described by ISO 15765-2.
>
> If you like the slave/master approach (I personally don't care for
> it), you can use DeviceNet, CANOpen, etc.
>
> John
> -----Original Message-----
> From: Sydney Faria [mailto:]
> Sent: Saturday, February 14, 2004 10:46 AM
> To:
> Subject: Re: [68HC12] HCS12 and CAN Bus > There was an app note describing a 'linked list' set up to send msgs
> with more than 8 bytes, so I set up a data buffer area with a pointer
> to it along with a byte counter. Then I made a routine that entered
> IDR0 - IDR3, TXPrior, DLC and upto 8 bytes of data from the data
> buffer and kept track of the remaining total. The message frame is Txd

> and the the next frame until
> the data was completely sent -- works great! Each node has a FIFO
> queue
> with atomic pointers and the nodes process their normal code until 1
> or more
> messages are Rxd, then the messages are handled. My nodes handle a
> group
> of standard IDs, 6 to 8, and all the nodes accept 000 and 008 which I
> use as
> a 'broadcast' msg from the master to all the slave nodes. Lets say
one
> of
> the slave nodes also has the ID of 200: my filtering is setup to
> receive 000, 008, 200, 202, 204,,,,20E. All the nodes can figure an
> offset of 0, 1, 2, 3, ,,, from these IDs. Now my messages are handled

> by this node as computed gotos based on the offset. My master works
> the same way. I use up to 40 slave nodes with a master to run engine
> testing where the slave nodes control such things as laser power
> levels and other control functions. By assigning meaning to the
> address IDs I can ask a node to send me information such as critical
> voltages, temperatures, power levels by sending a message with a
> particular ID. I don't waste data bytes telling me this stuff. Since
> I am using the lowest three bits of the standard ID to calculate an
> offset at the receiving node, I only have to know the first 8 bits for

> a destination address. The 000 message sent by the master asks all
> nodes to send a short frame with ID byte and 2 other peices of
> information that I need. The master collects all these msgs in the
> queue and makes a list of who is out there for future reference!
>
> The identifier paragraph of your message reminds me of much of my
> earlier experimentation in this area about three months ago: you can
> check out my earlier posting on this site as well as the CAN-CIA site
> mirrored by Yahoo. Check out vector-informatik.de to register for it
> there is good information there but it is more oriented towards higher

> level protocols and not so much the msCAN protocol that is implemented

> in the 68HC12 set. In any case it would behoove you to get a freebie
> copy of the filtergen tool that is referenced by the Motorola
> application on filtering. What I did was to purchase a tinCAN
> interface so that I could Tx and Rx on a CANbus to my D60A development

> board to check out my programs and what I thought could be done with
> filtering. Well worth the effort.
>
> One more note: on the Axiom site they now have a list of books
> relating to the 68hc12 processors - the Valvano book discusses atomic
> data and FIFO queues, while Huang's book discussed CAN specifically
> for the 68hc12D60 -- they both saved me much time.
> ----- Original Message -----
> From: hc08jb8
> To:
> Sent: Thursday, February 12, 2004 10:52 PM
> Subject: [68HC12] HCS12 and CAN Bus > Hi Folks
>
> I am trying to use CAN bus as a communication link in a project. I
> have a CAN 'Master' connected to the PC and several CAN 'Nodes'.
> These nodes are based on Motorola HCS12C32 MCU with CAN. I have got
> the communication working however I find the default maximum
transfer
> of 8 bytes per transaction somewhat limiting.
>
> When searching for higher level protocol layers, most of them seem
to
> be quite expensive or complex. I would like to find out if there is
> any simple low cost higher level layer that could handle messages
and
> so forth greater than 8 bytes?
>
> Another question is, the MCU i use has a Identifier Acceptance
> Register and a Identifier Mask Register, I am a bit confused as to
> which should I set if I need to filter only one ID, say for example:
> accept only messages with ID of 0x105.
>
> Regds
> Jay >
> --------------------To learn
> more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
> ----------------------------------
> --
> ----
> --
> Yahoo! Groups Links
>
> a.. To >
>
> --------------------To learn more
> about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu o learn more about Motorola
> Microcontrollers, please visit http://www.motorola.com/mcu
>
> Yahoo! Groups Links >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links >

--------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu o learn more about Motorola
Microcontrollers, please visit http://www.motorola.com/mcu

Yahoo! Groups Links


Reply by Steve Letkeman ●February 16, 20042004-02-16
The reason I will tend to create a CAN protocol over using an existing one
comes down to a couple of reasons
1) Time. Existing protocols have tried to be all things to all apps and
have
ended up becoming very complex. The amount of time required to fully
understand a full blown protocol stack would be months. Sometimes
a person only needs to transfer some simple data and a simple protocol
could be created in a day.
2) Cost. In order to implement a full blown protocol, you either have to
spend months writing your own or purchase one, usually at a pretty high
cost (20-30K) Again, why spend months writing in features that your
app doesn't need? Also, the time required to understand someone elses
code is not to be underestimated, not to mention the fact that a lot of this
code is generated in Germany and is in a different style of coding and
commenting than I am used to.
3) Compatibility. If your not going to write in all the features of the
protocol
than you are not going to be compatible, why bother being somewhat
compatible? Better to write something simple and easy to understand. If,
on the other hand, you are trying to create a product that will be sold to
the masses, than an existing protocol would be the way to go, but beware
of the cost and time required. I'm not the only one that has gotten months
into a CANOpen implemention to find that it is simply not suitable for the
application.
4) Size, a typically slave node implementation of CANOpen requires
around 32K and this isn't even doing anything 'useful' yet.
5) Speed. Because an existing protocol stack tries to cover all the
bases, and tries to be completely configurable, you end up take a large
performance hit in the speed of data transfer.
There are some interesting solutions, including, MicroCANOpen.com
that uses some of the basic aspects of CANOpen without being full blown,
or full compatible. I am not saying there isn't a time and place for
existing protocols, but generally I would say this is left to large budgets,
both time and money.
Steve

Steven D. Letkeman BSc.
President - Zanthic Technologies Inc.
403-526-8318
www.zanthic.com Embedded micro-controllers and CAN interfaces
www.brightan.com Automated lighting systems

----- Original Message -----
From: "John Theofanopoulos" <>
To: <>
Sent: Saturday, February 14, 2004 9:38 AM
Subject: RE: [68HC12] HCS12 and CAN Bus > I see a lot of discussion on how to communicate over CAN, and since
> there's enough protocols out there already, not sure why people are busy
> inventing more...
>
> Anyway having worked with CAN for quite a number of years, here's my
> take on it.
>
> If you need to see data often, have the device collecting the broadcast
> the data frequently and with a high priority id. The devices that don't
> care about this data, can simply filter out that ID.
> Less critical data, well, less frequent transmissions and lower priority
> id.
>
> Diagnostic data (more than 8 bytes), use a transport layer as described
> by ISO 15765-2.
>
> If you like the slave/master approach (I personally don't care for it),
> you can use DeviceNet, CANOpen, etc.
>
> John
> -----Original Message-----
> From: Sydney Faria [mailto:]
> Sent: Saturday, February 14, 2004 10:46 AM
> To:
> Subject: Re: [68HC12] HCS12 and CAN Bus > There was an app note describing a 'linked list' set up to send msgs
> with more than 8 bytes, so I set up a data buffer area with a pointer to
> it along with a byte counter. Then I made a routine that entered IDR0 -
> IDR3, TXPrior, DLC and upto 8 bytes of data from the data buffer and
> kept track of the remaining total. The message frame is Txd and the the
> next frame until
> the data was completely sent -- works great! Each node has a FIFO
> queue
> with atomic pointers and the nodes process their normal code until 1 or
> more
> messages are Rxd, then the messages are handled. My nodes handle a
> group
> of standard IDs, 6 to 8, and all the nodes accept 000 and 008 which I
> use as
> a 'broadcast' msg from the master to all the slave nodes. Lets say one
> of
> the slave nodes also has the ID of 200: my filtering is setup to receive
> 000, 008, 200, 202, 204,,,,20E. All the nodes can figure an offset of
> 0, 1, 2, 3, ,,, from these IDs. Now my messages are handled by this
> node as computed gotos based on the offset. My master works the same
> way. I use up to 40 slave nodes with a master to run engine testing
> where the slave nodes control such things as laser power levels and
> other control functions. By assigning meaning to the address IDs I can
> ask a node to send me information such as critical voltages,
> temperatures, power levels by sending a message with a particular ID. I
> don't waste data bytes telling me this stuff. Since I am using the
> lowest three bits of the standard ID to calculate an offset at the
> receiving node, I only have to know the first 8 bits for a destination
> address. The 000 message sent by the master asks all nodes to send a
> short frame with ID byte and 2 other peices of information that I need.
> The master collects all these msgs in the queue and makes a list of who
> is out there for future reference!
>
> The identifier paragraph of your message reminds me of much of my
> earlier experimentation in this area about three months ago: you can
> check out my earlier posting on this site as well as the CAN-CIA site
> mirrored by Yahoo. Check out vector-informatik.de to register for it
> there is good information there but it is more oriented towards higher
> level protocols and not so much the msCAN protocol that is implemented
> in the 68HC12 set. In any case it would behoove you to get a freebie
> copy of the filtergen tool that is referenced by the Motorola
> application on filtering. What I did was to purchase a tinCAN interface
> so that I could Tx and Rx on a CANbus to my D60A development board to
> check out my programs and what I thought could be done with filtering.
> Well worth the effort.
>
> One more note: on the Axiom site they now have a list of books relating
> to the 68hc12 processors - the Valvano book discusses atomic data and
> FIFO queues, while Huang's book discussed CAN specifically for the
> 68hc12D60 -- they both saved me much time.
> ----- Original Message -----
> From: hc08jb8
> To:
> Sent: Thursday, February 12, 2004 10:52 PM
> Subject: [68HC12] HCS12 and CAN Bus > Hi Folks
>
> I am trying to use CAN bus as a communication link in a project. I
> have a CAN 'Master' connected to the PC and several CAN 'Nodes'.
> These nodes are based on Motorola HCS12C32 MCU with CAN. I have got
> the communication working however I find the default maximum transfer
> of 8 bytes per transaction somewhat limiting.
>
> When searching for higher level protocol layers, most of them seem to
> be quite expensive or complex. I would like to find out if there is
> any simple low cost higher level layer that could handle messages and
> so forth greater than 8 bytes?
>
> Another question is, the MCU i use has a Identifier Acceptance
> Register and a Identifier Mask Register, I am a bit confused as to
> which should I set if I need to filter only one ID, say for example:
> accept only messages with ID of 0x105.
>
> Regds
> Jay >
> --------------------To learn more
> about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>
> ----
> --
> Yahoo! Groups Links
>
> a.. To >
>
> --------------------To learn more
> about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu o learn more about Motorola
> Microcontrollers, please visit http://www.motorola.com/mcu
>
> Yahoo! Groups Links >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
>
> Yahoo! Groups Links >


Reply by John Theofanopoulos ●February 16, 20042004-02-16
Which has been pretty much my point all along. Why try to get Modbus on
CAN when there is already something called KWP2000 and the associated
transport layer which already works and does what needs to be done.
With the above transport layer, you can easily transfer 4k blocks of
data in one stream...

John -----Original Message-----
From: Oliver Betz [mailto:]
Sent: Monday, February 16, 2004 9:41 AM
To:
Subject: RE: [68HC12] HCS12 and CAN Bus John Theofanopoulos wrote:

> Having implemented the Modbus protocol for the RS485/RS232 side, I
> don't see how it can be fully implemented for the CAN bus. From my
> understanding, an end of frame (Modbus message) is detected when a gap

> exists in the data that is greater than X * byte time. Since CAN
> messages can't actually be streamed together in line, this feature
> would be unavailable....

you don't need the gap for end-of-packet detection, and not the
checksum, since CAN handles this. Modbus TCP also doesn't need it.

But you need to handle longer packets as modbus allows up to 256
bytes IIRC.

There _are_ efforts to connect Modbus and CANopen, search for DSP309.

Oliver
--
Oliver Betz, Muenchen
--------------------To learn more
about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu o learn more about Motorola
Microcontrollers, please visit http://www.motorola.com/mcu

Yahoo! Groups Links