Update README.md: add bluetooth introduction to features
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: fix description about SERIAL8
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: fix description about RC
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: add description about "LED" pin
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: fix description about Loading Firmware
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: fix description about update firmware
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
remove defaults.parm and defined default params in hwdef file
Update README.md: fix description about osd
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
remove parameter define about serial4
Update README.md: add a section about BlueTooth
Update README.md: uses internal esc
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: introduction about RC input
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Update README.md: introduction about PWM groups
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
remove defaults.parm and defined default params in hwdef file
on H730 we are overflowing the ITCM area for SPRacingH7RF and other boards are not far behind.
Step away from the edge by removing this function which should never be in a fast path
this replaces the two booleans used to mediate TX and RX buffer
protection with mutexes.
The booleans were a hangover from the very early HAL_ChibiOS code, and
can lead to a deadlock. The sequence is as follows:
- a very high CAN bus bandwidth usage, triggered by MissionPlanner
requesting CAN_FORWARD on a CAN serial port. That causes a
"infinite" number of CAN_FRAME messages which saturates the bus,
and leads to the DroneCAN thread looping with no pause
- a serial port configured as GPS type AUTO, auto-probing for a GPS
that isn't there. This calls begin() periodically
- the UART TX thread assocated with that UART not making progress as
the TX thread priority is below the DroneCAN thread priority
- this causes the begin() in main thread waiting for _in_tx_timer to
loop forever, which triggers a watchdog
The CAN port as it was is a valid CAN port for the nucleo, but on the development board the CAN silkscreen is actually on PD0 and PD1. This change makes it easier to get the example running on the Nucleo
