New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
May be dropping signals from messages with too many signals #306
Comments
The first step is to create a test that sets up 2 CAN messages with 8 signals each as in the example posted in the group, and see if it can parse all of them. If it works in a unit test, write a functional test to see if it's hardware-specific issue. |
This is a first attempt at finding the root cause of #306. It's passing without any changes, so I think the problem must be in the hardware specific parts of the code. I will work next on creating a functional test.
See #306 - still can't get it to fail. Is it UART?
I wasn't able to reproduce this issue via USB, but I did find one problem when using UART (Bluetooth) on the reference VI:
it's dropping signal8 and signal16, the last signal in each set of 8. That's not exactly what the original bug stated, but perhaps fixing that will fix the other problem too. |
I belive I've fixed this - there was a race condition with UART on the LPC17xx where you could lose outgoing data. I wasn't ever able to reproduce it as seriously as in the original bug report (i.e. missing a full 7 signals from a message) but I think that's because I was sending the 2 CAN messages with some delay in between. I'll re-open this ticket if it's still a problem after the next release. |
Discussion: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/openxc/sX0P1IBssIs/REDLCUPL1o0J
The text was updated successfully, but these errors were encountered: