The existing implementation had a flaw: when the buffer was getting full,
mavlink started to busy-loop, as the uart has data (poll returns immediately)
but no new data was read from the uart due to the buffer being full.
As rtps is running at lower prio, it never got the chance to read again,
making the problem even worse.
After 1s the timeout triggered and the buffer was cleared, so it recovered.
Instead of allowing for CPU spikes, we now immediately clear the buffer
(only as much as we have to), ensuring that new data is read from the uart.
The existing implementation has about 100ms difference to a reference clock. With the changes this error less than 25us.
- Use sensor_gps messages with hrt timestamps as RTC reference and not the system realtime clock. The PPS interrupt can then be aligned with the GPS clock system.
- Keep fallback based on system RTC when no PPS pulse was captured
- camera_trigger module always publishes the camera_trigger msg (independent of the camera feedback)
- Use camera_trigger msg and set the feedback flag
- Subscribing modules determine if the message is relevant based on the feedback message
When using an FMU channel as PPS capture GPIO, the rtc_edge_time is now set as well. The delay between actual capture and callback is compensated with the elapsed time of the rtc clock.
- this was necessary to get the secondary ms5611 working reliably on a
particular CubeOrange
- the sensor is transferring very little data, so lowering the speed by
default everywhere is harmless
Use the same memory allocation in sw_crypto driver as what is used in
src/lib/crypto libraries
In addition, in nuttx protected build, allocate all memory from kernel heap
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This fixes the following compile error on Mac:
src/drivers/gps/gps.cpp:562:23: fatal error: use of undeclared identifier 'B921600'
case 921600: speed = B921600; break;
^
It is possible to either set the keyfile locations in board configuration or
with the same environment variables as before.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This is more logical place for the "backend" implementation than
directly under platform.
This also allows making other implementations as "real" drivers, as well as proper configuration via Kconfigs
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Daniel Agar