PX4 uses banks of 8 outputs as a logical structure. Boards that have
more outputs than 8 get multiple instances. This is an arbitrary choice
that helps with overall structure and enables the mixing of different
device classes (like FMU, IO or UAVCAN).
- generate PWM_MAIN 1-14
- generate PWM_AUX 1-8
- generate PWM_EXTRA 1-8
- px4io and pwm_out directly read configuration parameters
- only available and active physical outputs are actually shown for configuration
- overall saves flash despite adding many new parameters
- 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)
rc.io is called from 2 places in rc.interface:
- if [ $OUTPUT_MODE = io -o $OUTPUT_MODE = uavcan_esc ]:
- 'set OUTPUT_MODE io' is only set within USE_IO=yes, so removing
the check in rc.io has no effect.
- in case of UAVCAN, we also want the IO for RC, now covered in the next
case.
- Further down ('Start IO for RC input if needed.').
This is intended to start IO for RC only, when fmu is already started.
However the previous check '$USE_IO = yes' in rc.io prevented that.
In addition we don't start rc_input in case of $USE_IO = no.
Fixes no RC on Pixhawk 2 with SYS_USE_IO=0.
When SYS_USE_IO was disabled, px4io would not start and thus there was no
RC. SYS_USE_IO=0 is interesting on Quads to avoid the IO and reduce output
latency.
Tested on Pixhawk 1 and Pixhawk 4
Flight tested: ekf2 w/ mag and compass by @nathantsoi: https://logs.px4.io/plot_app?log=79b81031-cf1e-41f0-890b-d6cd7d559766
NOTE: external I2C devices need a pullup. I have tested with a 3.3v 2.2k pullup.
Working:
- mpu6000, bench tested and verified via nsh
- fmu
- all 6 ch output bench tested w/ pwm and oneshot via nsh
- ppm input bench tested
- dsm input bench tested
- bmp280, bench tested and verified via nsh
- hmc5883, bench tested and verified via nsh, but requires an external i2c pullup
- gps on uart6
- startuplog, nsh, mavlink on uart4, but params are not sent for some reason. RSSI pin is TX, MOTOR 5 is RX (normal mode, 57600 baud)
- rgbled over i2c, bench tested and workingp
- sbus via the shared sbus/ppm pin (which includes an inverter to the mcu SBUS in pin), remove the solder bridge or jumper to the ppm pin before use
Not yet implemented:
- ADC
- OSD: passthrough video is untested, use at your own risk until a basic driver is implemented.
Matthias Grob
Lorenz Meier
Daniel Agar
Beat Küng
Ricardo Marques
David Sidrane
BazookaJoe1900
romain
Julian Oes
David Sidrane
mcsauder
bresch
nathan