This fixes unspecified behaviour due to evaluation order of args.
It's up to the compiler whether next_number() or next_dots() is executed
first which means that the behaviour is not properly specified.
src/lib/tunes already knows which tunes are interruptable, so add
return values to expose than and use than in tone_alarm.
This fixes the issue that repeating tunes cannot be interrupted without
tune_override set to true.
Signed-off-by: Alex Mikhalev <alex@corvus-robotics.com>
- drivers/tone_alarm: move to ModuleBase and purge CDev (/dev/tone_alarm0)
- drivers/tone_alarm: only run on tune_control publication (or scheduled note) rather than continuously
- drivers/tone_alarm: use HRT to schedule tone stop (prevents potential disruption)
- msg/tune_control: add tune_id numbering
- systemcmds/tune_control: add "error" special case tune_id
- move all tune_control publication to new uORB::PublicationQueued<>
- start tone_alarm immediately after board defaults are loaded to fix potential startup issues
- for SITL (or other boards with no TONE output) print common messages (startup, error, etc)
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)
Adds a single file definition to provide a single point to add
new tunes and clearly understand, the useage: it need to be
stopped will it not allow interruption.
Since the tune library also contains logic how tunes can be overriden,
a user of the tunes library cannot know the strength of the current tune
without replicating some logic. Easy solution is to add strength to the
output of Tunes::get_next_tune().
Otherwise the only way of interrupting a repeated tune would be with the override flag, which should only be used rarely.
Now repeating tunes have lowest priority, followed by one-shot tunes, followed by anything with an override flag.
Now it is possible to set a string and a control.
The get_next_tune function use the same return values as the erliaer
implemented parse_cmd and parse_string functions.
