This allows concurrent read access, which are much more common; reducing
potential lock contention and increasing concurrency.
Taking a lock is expensive, and the reader lock is now even more expensive.
An RCU synchronization scheme would reduce the overhead of the readers to
increasing/decreasing an atomic counter.
Thus this should only be an intermediate step until we move towards RCU.
Tested on SITL & Pixracer.
param_t is only used as an offset and we have <1000 params, so an uint16_t
is enough.
This saves roughly 1KB of RAM. We only do that on NuttX because normal
integers have better performance in general.
Previously on amd64, this was even 64bits because it was an uintptr_t.
This further speeds up param loading.
On Pixracer via USB, it's possible to send up to 11 at once before the TX
buffer gets full, so there is still enough free bandwidth left.
This speeds up parameter loading. Slow links like telemetry are unaffected,
since the mavlink loop runs only with ~100Hz.
Tested on various links, like:
- telemetry link
- pixracer WiFi
- pixracer USB
- SITL
This is the new interface to control external LED's (user-facing).
Features:
- Supports maximum N Leds (where the board can define N)
- on/off/blink M times
- Different priorities
- Allows setting a single led or multiple at once
The check if stick were touched was only working in one direction (per
axis) because fabsf was used incorrectly.
However, this check is still only a differential check triggered by
fast movement and does not trigger if someone slowly moves a stick to
the side. Also, the sensitivity depends on the rate of the commander
loop and/or the RC update loop. The correct solution would be a proper
filtering and trigger for movement.
backport 3cd66af889b42b036d6c9d88e067fc3b8abbdb2a and pr 258
Applies to STM32F4 and STM32F7
STM32, STM32 F7, and STM32 L4: Clone Freddie Chopin's I2C change to similar STM32 I2C drivers.
Save elapsed time before handling I2C in stm32_i2c_sem_waitstop()
This patch follows the same logic as in previous fix to
stm32_i2c_sem_waitdone().
It is possible that a context switch occurs after I2C registers are read
but before elapsed time is saved in stm32_i2c_sem_waitstop(). It is then
possible that the registers were read only once with "elapsed time"
equal 0. When scheduler resumes this thread it is quite possible that
now "elapsed time" will be well above timeout threshold. In that case
the function returns and reports a timeout, even though the registers
were not read "recently".
Fix this by inverting the order of operations in the loop - save elapsed
time before reading registers. This way a context switch anywhere in the
loop will not cause an erroneous "timeout" error.
Beat Küng
Simone Guscetti
Lorenz Meier
David Sidrane
Julian Oes
Daniel Agar
José Roberto de Souza