Will this CAN object work for me?
turbosupra
Posts: 1,088
Hi,
I'm delving into CAN and this is my first experience with it, I'm a total CAN newb and I'm honestly not sure why they call a low (logical 0) dominant and a high (logical 1) recessive, this seems backwards to me? I have a CAN controlled device that I can control/test with CAN messages between the prop and the device. I have a mcp2551 coming in the mail. I believe I have the bit order that I need to send worked out. The spec for the CAN device is as follows
J1939
Extended frame format
250kbps
Start-of-frame - is always 0
Identifier A - is always 11000111111
SRR - is always 1 (which is considered recessive)
IDE - is always 1 (which is considered recessive)
Identifier B - is always 111100011000000000
RTR - is always 0 (which is considered dominant)
R0 - is always 0 (which is considered dominant)
R1 - is always 0 (which is considered dominant)
DLC - is always 1000
Data field - is 8 bytes
CRC - is 15 bits
CRC delimiter - is always 1 (which is considered recessive)
ACK slot - must be 1 to transmit
ACK delimiter - is always 1 (which is considered recessive)
EOF - is always 1111111 (which is considered recessive)
Will this object work for me? I chose it because it was built on J1939 for automotive which is also what I'll be using it for. I have a PM out to the object creator (Chris Gadd), but he hasn't been online in some time. I'm not very good at PASM and the heavy lifting is done by PASM. I believe this object is 500kbps instead of 250kbps and using the Send method, I can send an ID (but I don't know if it is just Identifier A or Identifier A and B, I can send the DLC and I can send the Data Field. What I also don't know is if the rest of fields are handled in the PASM portion. If not, I'd like to try JonnyMac's CAN object as I like the way he write and lays out the code he writes.
I'm going to give deciphering the PASM portion my best effort, but I would appreciate help with that. Thanks for reading.
Object link - http://obex.parallax.com/object/690
CANbus Writer 1.0.spin OBD-II demo 1.0 - Archive.zip
I'm delving into CAN and this is my first experience with it, I'm a total CAN newb and I'm honestly not sure why they call a low (logical 0) dominant and a high (logical 1) recessive, this seems backwards to me? I have a CAN controlled device that I can control/test with CAN messages between the prop and the device. I have a mcp2551 coming in the mail. I believe I have the bit order that I need to send worked out. The spec for the CAN device is as follows
J1939
Extended frame format
250kbps
Start-of-frame - is always 0
Identifier A - is always 11000111111
SRR - is always 1 (which is considered recessive)
IDE - is always 1 (which is considered recessive)
Identifier B - is always 111100011000000000
RTR - is always 0 (which is considered dominant)
R0 - is always 0 (which is considered dominant)
R1 - is always 0 (which is considered dominant)
DLC - is always 1000
Data field - is 8 bytes
CRC - is 15 bits
CRC delimiter - is always 1 (which is considered recessive)
ACK slot - must be 1 to transmit
ACK delimiter - is always 1 (which is considered recessive)
EOF - is always 1111111 (which is considered recessive)
Will this object work for me? I chose it because it was built on J1939 for automotive which is also what I'll be using it for. I have a PM out to the object creator (Chris Gadd), but he hasn't been online in some time. I'm not very good at PASM and the heavy lifting is done by PASM. I believe this object is 500kbps instead of 250kbps and using the Send method, I can send an ID (but I don't know if it is just Identifier A or Identifier A and B, I can send the DLC and I can send the Data Field. What I also don't know is if the rest of fields are handled in the PASM portion. If not, I'd like to try JonnyMac's CAN object as I like the way he write and lays out the code he writes.
I'm going to give deciphering the PASM portion my best effort, but I would appreciate help with that. Thanks for reading.
Object link - http://obex.parallax.com/object/690
CANbus Writer 1.0.spin OBD-II demo 1.0 - Archive.zip
Comments
The ID is identifier A & B; the PASM code automatically sends an extended frame if the ID is greater than 11 bits, and all of the other bitfields (RTR, SRR, DLC...) are also handled by the PASM routine.
All of this magic happens between the Add_SOF and Add_CRC labels. The bits to be sent are in the upper bits of t1, while t2 contains the number of bits to send for each field.
Because I wanted this object to be able to handle speeds up to 1Mbps, the entire message is assembled into five longs, complete with stuffed bits, before the SOF bit is sent.
Regarding the dominant 0's and recessive 1's, the CANbus is shared between multiple senders, any one of which needs to be able to drive it. In the undriven (recessive) idle state, the CAN-HI line is high, which someone decided to call a '1'. In order to send a '0', CAN-HI needs to be driven (dominant) to a low state. This plays a big part in arbitration. If multiple senders begin transmitting simultaneously, whichever one released the line first, by sending a recessive bit, loses control of the bus while the sender with the the dominant bit continues. In this manner, a standard frame (11-bit ID) is always a higher priority than an extended frame due to the RTR/SRR bit being dominant for standard and recessive for extended, and a normal frame is higher priority than a remote frame.
I also have a MCP2515 object here: http://obex.parallax.com/object/758
Hi Chris,
Either you are psychic or some pointed you to this, either way thank you for responding.
I don't know why the other object did not come up when I searched the OBEX, but thank you for linking to it. I just got done putting comments next to the other PASM routine trying to figure it out, I will do that same thing with this new object you've pointed me to. The 2551 has a neutral state in addition to the dominant and recessive states at about 2.5v, correct? From reading about it, it appeared that recessive was > 2.5v and dominant was < 2.5v and that idle was ~2.5v, which I've called a neutral state. For some reason I naturally think of the high/1 as the dominant so I just need to change the way I think about that is all.
I'm anxious to try this out this weekend. If you're curious about the project, I'd like to email you some details? Let me know.
*correction to my previous post, it's CAN-LO that is high during recessives and low during dominants
Non-inverted serial UART and I2C data also idle in the high state.
I'll take a look at the link in the PM, and I've got my PM notifications turned on now.