Main UAVCAN protocol handling and ESC updates run on the same thread/wq as
before. There are 2 WorkItems for separate scheduling of the 2, so that
ESC updates run in sync with actuator_control updates. UAVCAN is scheduled
at a fixed rate of 3ms (previously the poll timeout) and on each UAVCAN
bus event.
This leads to roughly the same behavior as before. CPU & RAM usage are
pretty much the same (tested on Pixhawk 4).
Testing done: Motors still work (with feedback), param changes and a
UAVCAN optical flow sensor.
and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
This could happen in the following cases:
- IRQ/publisher rate is faster than the processing rate, and therefore
WorkQueue::Add is called at a higher rate
- a long-running or stuck task that blocks the work queue a long time
Both cases are not expected to happen under 'normal' circumstances (if the
system runs as expected).
* adds a work_queue systemcmd that will bring a tree view of all active work queues and work items
* WorkQueues now track attached WorkItems and will shutdown when the last WorkItem is detached
Script to update include paths:
for i in $(grep -rl 'include <px4_work_queue' src platforms); do sed -i 's/#include <px4_work_queue/#include <px4_platform_common\/px4_work_queue/' $i; done
David Sidrane
Daniel Agar
Beat Küng
Matthias Grob