torriem
Junior Member

Yeah I'm not sure everything was strictly necessary. I definitely had issues without seq=1, and a few days ago I still saw frames getting out of order (could see some text transposed) with setMaxMB(24). I don't...

Many thanks to you both. I think have a combination that's working now. I updated to the latest version from git, increased the constructor queue sizes to 1024, setMaxMB(32). I was still having problems so I set...

I really appreciate your help and thoughts on this. So far nothing I've tried is working. I initially tried setMaxMB(9), normal callbacks, and no events() calls. That didn't work at all (no traffic to the DISPLAY)....

Interesting. So to get this behavior I should simply set the seq field in my callback before I write out the frame to the other interface? That sounds like what I want. I'll give it a shot!

Good idea. Yes messages out of order is a very possible cause. That would exactly explain some of the corruption in the display. I am not sure about the Due code. The CAN library is due_can and more specifically...

I played around with different clock speeds and queue sizes in the constructor. Nothing helped, unfortunately. Just to make sure I wasn't imagining things, I went back to the Due and everything works great there with...

Great thanks. I do not know if I'm having issues transmitting or receiving. I'll give the clock changes a try. So simply not calling events() will let it call my callback directly from the handler? I've been...

Tried using ext_output1 and it is working properly but the weird timing/data corruption issues persists. Maybe it's harmless. Only seems to be affecting this OEM display, not the underlying functions of the machine. ...

Been thinking about it, and maybe the issues more related to timing than losing packets. I noticed the special-purpose ext_output#() weak externs in the code (and looked at how they are used in TeensyCAN). I'm going...