>>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 |
HCS12 and CAN Bus
Started by ●February 12, 2004
Reply by ●February 16, 20042004-02-16
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●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 |