- perform reset as per the datasheet (disable I2C immediately, set power mode, wait for appropriate time, etc)
- remove interrupt perf counter and instead only count misses
- minor style changes to stay in sync with the other Invensense drivers
- perform reset as per the datasheet (disable I2C immediately, set power mode, wait for appropriate time, etc)
- only track consecutive errors (not total) to trigger full reset if necessary
- remove interrupt perf counter and instead only count misses
- minor style changes to stay in sync with the other Invensense drivers
- update copyright year
- perform reset as per the datasheet (disable I2C immediately, set power mode, wait for appropriate time, etc)
- only track consecutive errors (not total) to trigger full reset if necessary
- remove interrupt perf counter and instead only count misses
- minor style changes to stay in sync with the other Invensense drivers
- perform reset as per the datasheet (disable I2C immediately, set power mode, wait for appropriate time, etc)
- track consecutive errors and trigger full reset if necessary
- remove interrupt perf counter and instead only count misses
- minor style changes to stay in sync with the other Invensense drivers
- read FIFO count along with full transfer as a sanity check
_num_outputs is set according to the mode_pwmX call, which is required
for camera triggering.
This fixes camera triggering via PWM, as it avoids overwriting the channel.
- always check system field for validity
- reject any data outside of "servo position" valid range from Spektrum specification
- properly support XPlus channels (12+)
- debug message if channel count changes
1. The spec specifies that the mode change condition should be met for 10
consecutive frames before changing to the next mode.
2. The spec (and comment) says that "PAW3902JF should not operate with Shutter < 0x01F4 in Mode 2" -
however the if condition checked the reverse condition
Signed-off-by: Koby Aizer <koby.aizer@tg-17.com>
I changed the input constraint in #15349 but screwed up the usage
because I was convinced it's püass by reference. I'll double check
for sure next time.
- the latch would actually cause more problems if the backup schedule hit
- this reduces the number of cycles where the FIFO is actually empty at max rate (when there's only 1 sample in the FIFO expected)
Took the existing uavcan_stm32 driver and replaced all bxCAN code with
the equivalent for FDCAN following ST Reference Manual RM0433.
Note: There is still a bug somewhere in regards to FDCAN2 (probably
incorrect setup of the message RAM? Not sure.) But (FD)CAN1 is fully
functional (Classic CAN only, no CAN-FD).
Also TODO: Configure CAN filters. Right now there are no filters; all
incoming messages are accepted.
Daniel Agar