This can be used to test & control the new uorb-based led backend.

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

This makes it clear that it's used to control the board LED's, not external
LED's.

In addition this is almost a copy of the rgbled driver

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 of upstream NuttX PR 264

   As discovered by dcabecinhas. This fix assume the 8 byte
   alignment options for size stack size or this will overwrite
   the first word after TOS
   See https://github.com/PX4/Firmware/issues/6613#issuecomment-285869778

 - sync posix_sitl_default and px4fmu-v4pro/v5 with fmu-v3
 - fixes #6667

In SITL, logging rate reduces from 70kB/s to 45kB/s.

Now AeroFC is making use of both flash memory banks so it need this
workaround.

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.

   5a6d95dd9f051be548a8d2378aaef75f0a1ba5e1 and ee5ae3a57dbbe835584f164c956e0374da1ed2eb

   Applies to STM32F4 and STM32F7

   Save elapsed time before handling I2C in stm32_i2c_sem_waitdone()
   It is possible that a context switch occurs after stm32_i2c_isr() call
   but before elapsed time is saved in stm32_i2c_sem_waitdone(). It is then
   possible that the handling code was executed 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
   handling code was not executed "recently".
   Fix this by inverting the order of operations in the loop - save elapsed
  time before handling I2C. This way a context switch anywhere in the loop
  will not cause an erroneous "timeout" error.

This backend will keep all updated data in RAM and
persist the data between reboots using flash memory.

Using only flash memory would result in a slow backend that
would decrease the lifetime of the flash memory, using both
we can reduce the several cycles of erase & write into flash
and keep the performance of the backend almost as fast
as the RAM only backend.

Note: Do not use this backend on a sector from the same flash memory
bank as the memory bank that STM32 read instructions or it can block
the CPU from fetching instructions from flash during the erase and
write operations and cause your drone crash.

So flash sector of 64Kbyes and 128Kbytes can also be used.

Also having just a boolean to track if backend is running.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.

This saves almost 2kb of RAM when using the mavlink shell. 70 matches the
size of the mavlink message. Since the pipe is blocking, a process writing
a lot of data will just wait, data will not be dropped.

The mavlink shell is the only process creating a pipe.