Greatly improves the noise on the d-term on a Kopis 2. Apparently the order
of filtering vs differentiating matters.
Also disables the DGYRO filter by default, as the D-term now already has
a default filter of 30Hz applied.
It cause bad transfers on a Kopis 2, though not on a bench KakuteF7 unit.
Not sure if this is a single case.
nsh> icm20689 status
INFO [SPI_I2C] Running on SPI Bus 4
INFO [icm20689] FIFO empty interval: 1000 us (1000.000 Hz)
icm20689: transfer: 46375 events, 6790549us elapsed, 146.43us avg, min 54us max 1709us 81.564us rms
icm20689: bad register: 0 events
icm20689: bad transfer: 4284 events
icm20689: FIFO empty: 0 events
icm20689: FIFO overflow: 1 events
icm20689: FIFO reset: 2 events
icm20689: DRDY interval: 375585 events, 124.93us avg, min 99us max 250us 2.322us rms
INFO [drivers_accelerometer] /dev/accel device instance: 0
INFO [drivers_accelerometer] calibration scale: 1.02174 0.99918 0.98338
INFO [drivers_accelerometer] calibration offset: 0.76124 -0.00725 -0.16437
INFO [drivers_gyroscope] /dev/gyro device instance: 0
INFO [drivers_gyroscope] calibration offset: -0.08153 0.02432 0.00050
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.
Beat Küng