|
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:] 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> > > > . |
|
|
HCS12 and CAN Bus
Started by ●February 12, 2004
Reply by ●February 13, 20042004-02-13
Reply by ●February 13, 20042004-02-13
|
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> > > > > > . |
Reply by ●February 14, 20042004-02-14
|
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 |
|
|
Reply by ●February 14, 20042004-02-14
|
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 |
Reply by ●February 15, 20042004-02-15
|
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? My project needed hard real-time constraints and the CAN protocol supplies that requirement. 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? 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 |
|
|
Reply by ●February 16, 20042004-02-16
|
Hi, It is very surprizing that nobody seems to adapt a ModbusCAN protocol - any volunteers? Frank ----- Original Message ----- From: "Steve Letkeman" <> To: <> Sent: Friday, February 13, 2004 6:13 AM Subject: Re: [68HC12] HCS12 and CAN Bus > Here's how I see it...if you are thinking about creating your own CAN > protocol you need to consider the following (first, study as many of the > other CAN protocols as you CAN) > You are going to have to consider three areas > 1) How to define the CAN ID's to transfer data to and from your node > 2) How are you going to define the packet data to transfer data in > a standardized method > 3) How are you going to handle the flow of data with respect to nodes > communicating on their own, in response to polls and in response to > emergency or unexpected events. > > For 1) this can be as simple as each node getting a node number and > that is used in its ID. Any messages sent to that node are sent to that > ID. The problem is that if you have more than one node sending to > the same node, you'll have a problem with the ID's being the same > and they might get sent at the same instant. So, the easiest is to add > the senders ID to the ID so that the ID is based on some number of > bits making up the sender address and some number of bits making > up the receiver ID. The receiver uses its filters to except any message > that is addressed to it without regard to the senders address. Now, > you could also take this one step further and instead of just sending > to and from the node in general, you could add devices within the > node. You could use the CAN ID to encode a 7 bit sender node address, > a 7 bit sender device, a 7 bit receiver node address and a 7 bit > receiver device. (assuming 29 bit ID is used) This would give your > network 128 nodes with each node having 128 unique devices, being > whatever you want, motors, switches, outputs, etc etc. Keep in mind > this is just one method and other protocols like CANOpen and J1939 > have different methods. Also, you can reserve the node address zero/ > device address zero for anybody that wants to broadcast data to > everybody in general. This means if you have a switch that changes > state and you don't know who on the network cares about it, you > broadcast it to mynode/mydevice/zero/zero and it is up to the reciever to > know to look > for that node/device packet. > 2) Ok, so now you can send data to and from any node on the network, > now you must define what the data looks like. For a simple protocol, > you can just define that the first byte of the protocol is a command byte > and that this defines how the rest of the data is organized. For example, > define the command value of one to mean "send my your value" and > two to be "Here is my value". You could leave it up to the receiver > to know that a particular node/device will be sending data in a particular > format, with regards to the rest of the packet or you could define a > second byte to be a data type identifier that defines the following data > to be 1 bit, 1 byte, 2 bytes, 4 byte floating point etc. If you are sending > data that spans more than one packet, than you need to define a command > for multipacket data and a byte or two to define the index number of > the packet currently being sent. With one command byte, a two byte > index, this leaves 5 data bytes*0xFFFF(index) for 320K of data. Again, > this is a simple method for a simple protocol. > 3) OK, this is turning into a novel...actually, I think I'll leave it here > for now, I've > covered some of point three already anyway. > > 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: "hc08jb8" <> > To: <> > Sent: Thursday, February 12, 2004 8: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 > > > > > > > > > > > > --------------------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
|
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.... Perhaps I misunderstand the Modbus protocol? John -----Original Message----- From: linktek [mailto:] Sent: Monday, February 16, 2004 3:40 AM To: Subject: Re: [68HC12] HCS12 and CAN Bus Hi, It is very surprizing that nobody seems to adapt a ModbusCAN protocol - any volunteers? Frank ----- Original Message ----- From: "Steve Letkeman" <> To: <> Sent: Friday, February 13, 2004 6:13 AM Subject: Re: [68HC12] HCS12 and CAN Bus > Here's how I see it...if you are thinking about creating your own CAN > protocol you need to consider the following (first, study as many of > the other CAN protocols as you CAN) > You are going to have to consider three areas > 1) How to define the CAN ID's to transfer data to and from your node > 2) How are you going to define the packet data to transfer data in a > standardized method > 3) How are you going to handle the flow of data with respect to nodes > communicating on their own, in response to polls and in response to > emergency or unexpected events. > > For 1) this can be as simple as each node getting a node number and > that is used in its ID. Any messages sent to that node are sent to > that ID. The problem is that if you have more than one node sending > to the same node, you'll have a problem with the ID's being the same > and they might get sent at the same instant. So, the easiest is to add > the senders ID to the ID so that the ID is based on some number of > bits making up the sender address and some number of bits making up > the receiver ID. The receiver uses its filters to except any message > that is addressed to it without regard to the senders address. Now, > you could also take this one step further and instead of just sending > to and from the node in general, you could add devices within the > node. You could use the CAN ID to encode a 7 bit sender node address, > a 7 bit sender device, a 7 bit receiver node address and a 7 bit > receiver device. (assuming 29 bit ID is used) This would give your > network 128 nodes with each node having 128 unique devices, being > whatever you want, motors, switches, outputs, etc etc. Keep in mind > this is just one method and other protocols like CANOpen and J1939 > have different methods. Also, you can reserve the node address zero/ > device address zero for anybody that wants to broadcast data to > everybody in general. This means if you have a switch that changes > state and you don't know who on the network cares about it, you > broadcast it to mynode/mydevice/zero/zero and it is up to the reciever > to know to look for that node/device packet. > 2) Ok, so now you can send data to and from any node on the network, > now you must define what the data looks like. For a simple protocol, > you can just define that the first byte of the protocol is a command byte > and that this defines how the rest of the data is organized. For example, > define the command value of one to mean "send my your value" and > two to be "Here is my value". You could leave it up to the receiver > to know that a particular node/device will be sending data in a particular > format, with regards to the rest of the packet or you could define a > second byte to be a data type identifier that defines the following data > to be 1 bit, 1 byte, 2 bytes, 4 byte floating point etc. If you are sending > data that spans more than one packet, than you need to define a > command for multipacket data and a byte or two to define the index > number of the packet currently being sent. With one command byte, a > two byte index, this leaves 5 data bytes*0xFFFF(index) for 320K of > data. Again, this is a simple method for a simple protocol. > 3) OK, this is turning into a novel...actually, I think I'll leave it > here for now, I've covered some of point three already anyway. > > 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: "hc08jb8" <> > To: <> > Sent: Thursday, February 12, 2004 8: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 > > > > > > > > > > > > --------------------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
|
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 |
|
|
Reply by ●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 |
Reply by ●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 > |
|
|
