The form of the PX4 GUID is as follows:
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
Where <ARCH MSD><ARCH LSD> are a monotonic ordinal number assigned by
PX4 to a chip architecture (PX4_SOC_ARCH_ID). The 2 bytes are used to
create a globally unique ID when prepended to a padded CPU ID.
In the case where the CPU's UUID is shorter than 16 bytes it will be
padded with 0's starting at offset [2] until
PX4_CPU_MFGUID_BYTE_LENGTH-PX4_CPU_UUID_BYTE_LENGTH -1
I.E. For the STM32
offset:0 1 2 3 4 5 6 - 17
<ARCH MSD><ARCH LSD>[0][0][0][0]<MSD CPU UUID>...<LSD CPU UUID>
I.E. For as CPU with a 16 byte UUID
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
This uses now the same sleep time logic as mavlink, depending on the
baudrate.
CPU usage on a Pixracer for different sleep times:
#num reads/sec sleep time CPU usage
17-18 2.8ms 0.233-0.31% (this PR)
12 5ms 0.155-0.3%
9-10 10ms 0.155-0.233%
6 20ms 0.155-0.233% (previous)
to fix Cygwin upload. It failed silently but when catching it prints
"non-standard baudrates are not supported on this platform".
Discussion about platform independet FTDI detection is in issue #10429.
A filtered update update interval is calculated for each receiver.
If dissimilar interval data is detected, blending occurs when data is received from the slower of the receivers.
If similar interval data is detected, blending occurs when receiver data with similar time stamps is available.
If no data is received from either receiver for longer than 300msec, then no blending will be performed and the most recent data will be used instead.
- previously it was possible to get a Position Control rejected message
without further advice what was actually wrong. So now we report warnings
even if gps is not required for arming (which could be annoying too...).
- the GPS failure message was very generic, making it hard to debug the
cause. Now we check every bit and send an appropriate warning
All strings were checked not to exceed the maximum length of 50 characters.
