cyberia
Member
I am using a maple r5 with an xbee reporting back data and every now and then i get a strange "gap" in reporting where it will stop halfway through the packet and restart after a delay with a new one.
as far as i can tell this delay is happening on-board the maple and I have observed behaviour which might indicate this in other applications.
am i doing it wrong, or is there some intermittent system overhead that can cause this to happen?
robodude666
Member
As gbulmer said, the USB interrupts and systick timers are known to cause small delays in execution.
For example, in the VGA Scope example file they had to be disabled in order to make sure the video image is sent without interruption. They both causes minor delays that would disrupt the image (see comments in the example file).
Try turning them off and see if it helps?
Also, if you're using Interrupts please note that there is an overhead for timer-based interrupts.
An example of what communications are experiencing delays, and how they're being triggered might help in the analysis of this issue.
-robodude666
cyberia
Member
what it is sending is odometry back from a remote controlled vehicle, i.e.
[millis()] [left] [right]
this is a example
1332 -4 58
1363 57 57
13951523 55 22
1554 52 -8
1586 54 -10
specifically the bit in the middle where it has just dropped like 100ms...
is it possible to disable specific interrupts? USB is not connected so that should not be an issue, systick might though.
gbulmer
Moderator
In your data:
1332 -4 58
1363 57 57
13951523 55 22
1554 52 -8
1586 54 -10Have you diagnosed the cause of the millis value '13951523'?
There may be something else going on which is not a delay.
It looks like characters were lost or a buffer overwritten before being sent.
That could be a real bug, and not something caused by a delay.
Can you force each line to be sent? Or even send it twice?
Can you add an extra value? Put a 'packet sequence number' or 'packet count' at the front so that you can see how many packets the Maple thinks it has sent.
When you said delay, I thought you meant a fraction of a millisecond.
Losing 100ms is way beyond anything that I'd expect to cause a delay other than your code or blocking IO.
If you switch Systick off, you'll lose the millisecond timer, and the interrupt routine is only a microsecond.
I'd put the vehicle 'on bricks' or whatever needs to be done so that you can test subsets of its functionality. I'd start by skipping all IO except the xbee; just count up to show that it is alive.
Other than the motor control, have you any other IO? If not, it is likely that or the xbee.
You must log in to post.