I think we can just directly use send() and don't need to use the
workaround of resetting the send flag to trigger one send.
Also, we don't need to override it if we don't need to check any params.
Instead of creating the stream and deleting it again, we now create it
with a rate of 0 and trigger it once.
This should avoid heap fragmentation by continous allocations.
The defualt in NuttX is OSPEED of 50Mhz. This is realy a slew
rate control. At the default high slew rate the overshoot was
.7 Volts. On a ICM20649 this was causing the device to output
garbage. All 0s
N.B. A passive scope or Logic analyser's probes load will mask
the failure. Useed a FET probe to verify the issue.
Todate I have not fould a way to differentiate a 74 from a 75.
as all parts map to Device ID 0x450: STM32H742, STM32H743/753
and STM32H750.
One the CPU is fully differentiate in Nuttx, this can be a
#ifdef.
Without this ninja supposedely builds with the default of the system
which is 10 for my 4 core, 8 thread CPU. With this argument, you can now
actually set it.
This has the benefit that the Gazebo plugins can be built with less
cores in order to avoid running out of RAM.
The previous check for the -j argument was not actually working.
Therefore, the build always used 4 cores, unless when building with
ninja when presumably the ninja default was used.
- IMU integration move from drivers (PX4Accelerometer/PX4Gyroscope) to sensors/vehicle_imu
- sensors: voted_sensors_update now consumes vehicle_imu
- delete sensor_accel_integrated, sensor_gyro_integrated
- merge sensor_accel_status/sensor_gyro_status into vehicle_imu_status
- sensors status output minor improvements (ordering, whitespace, show selected sensor device id and instance)
Daniel Agar
Mirko Denecke
David Sidrane
Julian Oes
David Jablonski
Dusan Zivkovic