Hello, EveryOne
I'm newbie to CAN protocole and embedded software. I need some help with the famous protocol CAN. The MCU that I use is LPC1768 and I have an evaluation bord MCB1700.
I need to use my MCB1700 to communicate with an equipement by CAN Communication. This equipement are using a special CAN protocol.
Here is the CAN protocol:
CAN 2.0A Std, 500Kbps, CAN ID : 0x401 Frame Format : [START][SESSIONID][COMMAND][LENGTH][DATA][CRC][END]
1) [START] ( Length : 1byte ) Start Byte for each frame Value : 0x7B (Fixed) 2) [SESSIONID] ( Length : 1byte ) Session IDentifier. EVSE Controller have to send same SESSIONID with received REQ SESSIONID. 3) [COMMAND] ( Length : 1byte ) COMMAND Code. Refer to '2.Command' sheet. 4) [LENGTH] ( Length : 2byte ) Data Packet Size Byte Order: Little Endian 5) [DATA] ( Length : 0~254byte ) Maximum data size : 254bytes Byte Order: Little Endian 6) [CRC] ( Length : 1byte ) XOR(exclusive-or) sum of all bytes from [COMMAND] to [DATA] 7) [END] ( Length : 1byte ) End Byte for each frame Value : 0x7D (Fixed)
According to the description, the length of data could be 254 bytes!
As I know, the CAN open protocole could transfert 8 bytes in one frame and the CAN FD protocole could transfert at most 64bytes.
My question is: 1. Can I use my MCB1700 to send a can frame more than 254 bytes? 2. If yes, should I re-write the can drivers provided by keil? 3. To send a data 254 bytes, how long will it occupy the CAN bus?
My question is: 1. Can I use my MCB1700 to send a can frame more than 254 bytes? > No, 8 bytes per frame on CAN 2.0 is maximum. 2. If yes, should I re-write the can drivers provided by keil? > So, no. 3. To send a data 254 bytes, how long will it occupy the CAN bus? > On webpage: > commons.wikimedia.org/.../File:CAN-Bus-frame_in_base_format_without_stuffbits.png > there is graphical representation of a CAN frame, by adding all bits except data it comes > to data frame containing 47 bits + data bits, you can work the math from there > BTW that is if no additional stuff bits are inserted and that depends on content
Not really. Whatever that is, it's not a CAN protocol. It may be the package description of some protocol that works on top of a transport protocol, which in turn works on top of CAN, but it's decidedly not CAN.
Hey, thank you very much for your response. I agree with you, that could be something else but not CAN. It's just some other protocole which is based on the same physique layer as CAN protocol.
Well...then, the seconde question. How can I send and receive this kind of frame?
The CAN controller of the MCU 1768 can not send a frame contains more than 8 bytes. The TX, RX buffer have only 8 bytes for each. maybe I should change the MCU?
maybe I should change the MCU?
No. You should figure out what the actual protocol is. Because it has clearly no relation to CAN.
HI,
I've asked the manufacturing of the equipement (Gridwiz peppermint plus+). They confirmed me that, the frame (>254 bytes) is similar rs485 frame but the communication used CAN 2.0A std and Specific CAN ID (0x401, 0x402).
The frame format is: [START 1 bytes][SESSIONID 1 bytes][COMMAND 1 bytes][LENGTH 2 bytes][DATA 0~254 bytes][CRC 1 bytes][END 1 bytes]
Now the question is, which MCU, which CAN transceiver allows me to send this BIG Frame?
hey confirmed me that, the frame (>254 bytes) is similar rs485 frame but the communication used CAN 2.0A std and Specific CAN ID (0x401, 0x402).
Two of three parts of that statement are wildly contradicting each other: lengths above 8 bytes simply do not exist in CAN 2.0A communication. So if they're claiming otherwise, that's just a flat-out lie. Among other things, this means that no existing CAN hardware will help you send or receive this protocol.
As to the idea of an RS485 frame, that's a figment of someone's imagination. RS485 is purely a physical layer. It does not define frames of any kind; it's purely an electric specification of how to signal individual bits. Frames are defined by several protocols that work on top of RS485. One of those is CAN, but we've already found that's not being used here.
So all we have here are a set of specifications that this protocol is not fulfilling. What you need is a specification of what it actually is. It makes no sense to talk about hardware until this mess has been sorted out.
Divide the above data by 8 bytes, every 8 bytes is a packet, send the packets one by one.???
As a reference:
AN3154 Application note CAN protocol used in the STM32 bootloader
Read Memory Command: Reads up to 256 bytes of memory starting from an address specified by the application
Write Memory Command: Writes up to 256 bytes to the RAM or Flash memory starting from an address specified by the application
www.st.com/.../jcr:content/translations/en.CD00264321.pdf
I think so too. But it's not mentioned in the user guide. I will check this point with the manufacturing. Thanks a lot for your help
Nah, that wouldn't work reliably. It needs at least some way to keep itself from the START byte showing up in any but the first CAN frame of the packet.
I said it in my first reply: there has to be some transport protocol operating between this packet format and the actual CAN bus; something like ISO 15765-2. If it's actually CAN to begin with, that is.