I am using the due_can library and need some help. Has anyone implemented a way to read a mulit-line message using the due_can library? I know how to set a RxFilter and read the message from that filter but I need some help in figuring out how to read a multi-line message into a buffer to parse. I know how to read the first frame/message of the multi-line message into the buffer but the part I am having an issue with is once I read the first frame into the buffer how do I go to the next message in the mailbox to read the next 8 bytes into the buffer and so on until the message length is reached.
Well, the due_can library has a big buffer behind the scenes so what happens is that all the messages get buffered automatically for you and you just keep reading them to build up the message. But, you haven't said much about what you're actually doing. I don't know what a multi-line message really is. Do you mean a message that requires multiple frames to send? Just something longer than 8 bytes? If so, the traditional way to do that with little overhead is ISO-TP. That system uses the first 1-3 bytes of the message for control leaving the rest (5-7) available for actual data. If your data are in that format then I can probably dig up some code to help with that. If it is in some form of custom format then you're a bit more on your own. Is this a custom format of some sort? Do you need 8 bytes to be actual data? How many frames do you expect to get in? (What is the real size of the data?)
As always thanks for replying. The format is as you stated. If a multi line message is received the first frame will begin with a 0x10 in byte 0 position. byte 1 will be how many bytes of data are to be sent in the entire message in hex. This excludes byte 0 of each following frame for that will be a flow control byte I then have to respond with a frame that begins with 0x30 in byte 0 position to let the sender know I am ready for the rest of the data. Byte 0 in the rest of the frames will increment from 21 to 2F (and loop if necessary) until all the data is sent. And yes bytes 1 through 7 all have the data that is to be used. Byte 0 is only used for flow control.
pleslie, I’m not any wiser with what you mean a multi-line message is.
Can you break down what you say with some greater clarity please ?
In the past few weeks I have coded some code for a DUE to communicate with a Lithium (BMS) battery management system that communicates with CANBus, and hence the CAN library that Collin has worked on. It appears to work quite well with setting up multiple mailboxes and interrupt driven reception.
I am using incorrect terminology. The expert Collin pointed out what I meant. I am speaking about a Multi Frame message not a multi line message. I am working with automotive diagnostic specification. Some responses to diag requests are more than 8 bytes in length. When this is the case the responses are sent in multiple frames. Withe the protocol I am working with when a response requires a multi frame message byte one of the response is 0x10. the next byte defines how many bytes are left to transmit. The next 5 bytes of this frame are data.
After that frame is sent the requester sees this frame and responds with a 8 byte frame with 0x30 in byte one. When the ecu that is responding sees this frame it starts transmitting data. The response frames at this point will have a flow control byte in byte 1 position. The flow control bytes go from 0x21 to 0x2F. It will keep cycling through 7 bytes at a time (8 byte message minus one byte used for flow control) until all data is sent.
Also I would like to add that I have used the due_can library for many projects at work. The problem is everything I have coded is only single frame messages. This project was the first time I am trying to use multi frame messages. I have actually just finished today coding for this project. Tomorrow I am going to start testing and work out the bugs. If I can get it working I will post here.
My project uses HTML, PHP, Jquery, and Arduino to read diagnostic data from an ECU in a vehicle.
Collin80: If so, the traditional way to do that with little overhead is ISO-TP. That system uses the first 1-3 bytes of the message for control leaving the rest (5-7) available for actual data. If your data are in that format then I can probably dig up some code to help with that.
i'm trying to do exactly that - i.e. send multi-frame CAN messages that require ISO-TP. I haven't really been successful in finding a library on the net that can help with this, I'm in a little over my head...
Have you successfully built this before ?