Hi, I am evaluating the G120 SoM as a possible solution. I need to transmit and receive data over a CAN bus using 500kbps, and high performance is a requirement.
I have found, so far that, receiving CAN data into the G120 is about 50% slower than the data transfer rate. For instance, moving a block of data takes 200ms on the CAN bus, but from what I can tell, it takes a total of about 450ms to get all of it from the ControllerAreaNetwork object.
I can adjust the CAN data transfer rate as well, but I’ve found if I go much faster, I start getting Overrun errors reported and packets are lost. If I go slower, the latency is still similar (until of course the transfer actually takes more than 400-450ms or so).
I’ve measured our code optimization as well, this isn’t the problem.
I’ve spent a bunch of time reading posts on the forum about this, in particular Simon’s posts about this. I’m wondering if I need to look at using RLP to build a native CAN handler / driver. Specifically, though I’m curious to know what, if any improvements anybody has found by using RLP for CAN access?
@ Nobody - By implementing your own CAN handler, you can tune it to your specific system, skipping everything that is not related. For example, our system runs only at 1Mbps, 8 bytes per message, 11bits ID and no RTR frames, so we only implemented maybe 20% functions available in CAN protocol. Another example; fo whatever reasons, GHI only used one G400’s mailbox for incoming messages; we use four or five, and we found that this greatly improves throughput and reliability.
So, with your own implementation you will definitely go faster. The downside is that you’ll have to eat chip’s manual twice, and debugging will be difficult, since you cannot debug RLP<-> Managed code interaction…
@ Gus - Are you suggesting then the latency is more likely related to the CPU speed? I did find if I don’t set the overdrive bit, the latency seems to be even longer.
In the context of this discussion, the application is receiving a CAN multi frame message. There is some processing that is performed while the data is incoming (that could be handled with RLP). Perhaps I’ll perform some additional tests and see how long it takes to simply receive and buffer the same number of packets without any processing.
Thank you for the welcome! My name? Would it be too cheesy to say “Garfunkel”? And I doubt anybody would believe my name is “Nobody” if I stuck to that. It’s Paulson.
@ Simon - Thanks for the info. I’ve seen you’ve done related work on the G120 as well, have you successfully improved throughput using this module as well? Or did you ultimately switch to the G400 for improved performance?
Gus, are you then suggesting that I buffer all the data in managed code, then pass it to an RLP routine? Or are you talking about somehow intercepting the data directly into RLP, processing it, then passing it back up to managed code?
The data is received as a “block” which is just basically a collection of individual CAN messages transmitted by the other party very quickly. The messages contains sequence IDs, which have to be checked, then stripped out to get the actual contiguous block data out.
Since your last response, I’ve been performing a few more tests. I found if I strip out the sequence ID parsing entirely, and just dump the data into a buffer, I can cut the latency in half (so we’re down to 320ms vs 450ms on a transfer that takes 200ms on the bus, BUT we haven’t actually processed the data).
I then cut the call to Array.Copy to buffer the data, and saved another 20ms or so.
Is it possible to write a “RLP hook” to capture and process the data using native code? I could see how that might lead to further optimizations?
