Updated uNavINS_MPU9250_I2C_MAGV1.ino
I've restored the F&F's and pintoggle() and
removed the loop() call to aHRS.events().
System running as desired for some few++ minutes with 11 to 17 SATS!
Here is my main.ino with changes as noted ( including new counters detailed in edit below):
This just removes the Slave's talkback ability. It was being called on EACH LOOP pass without a limiter << with limiter it would likely be fine! >> -
Now Avg over 552,000/second !!! from 549K to 556K - only way I can see it as a problem was bad digital noise to the GPS.
Reminder Note: Add "
void yield() {} " to sketch! Adding that increased loop counts to 891K to 901K! // unless sketch uses serialEvent()
@tonton81 - might want to add an optional .events( param MinTime=100 ) and return immediately on calls made in less than MinTime - at least for MASTER? Though the caller could regulate that as well?
Mike: Puzzled: Why is this 'TEENSYDUINO' in the main INO? :: #if defined(TEENSYDUINO) status = Imu.begin();
Also the 30000000 is hard coded in :: SPI_MSTransfer aHRS = SPI_MSTransfer() - might be nice in config defines if that ends up personally adjusted?
<edit> NOTE:: My GPS has not lost FIX in all this testing since .events() went away! Seeing 10 to 13 SATS. After posting this I see SATS==16 !!!! { with 500 Hz IMU to TViewer }
My MPU9250 doesn't work with restore of setSrd() as done in calibrateGyro - have to add this line in ...\B_loadCalValues.ino
Imu.calibrateGyro();
cout.println("Gyro Calibration Complete"); cout.println(" ");
Imu.setSrd(IMU_SRD);
Doing SPEED test with Master:T_3.6@ F_CPU=240 and F_BUS=120 with Slave::T_3.5 @120 MHz
Code:
Imu.readSensor();
Filter.update(uBloxData.iTOW, // ...
serialPrint();
>> This shows passes through loop() as Loop#:__ and processed Imu.readSensor group as IMU#:__
With TViewerSPI and :: #define IMU_SRD 1
-----
Loop#:442K IMU#:502
Without TViewerSPI - it still does 500 IMU updated/sec - but spare loop() passes drop way more from 890K above.
-----Loop#:102K IMU#:501
-----Loop#:45K IMU#:500
With TViewerSPI and :: #define IMU_SRD 0 { I see some
Bad CRC: detects on SLAVE }
-----Loop#:0K IMU#:936
Without TViewerSPI -
-----Loop#:0K IMU#:560
-----Loop#:0K IMU#:561
So my system as configured can complete 500 [IMU updates&Filters&Prints]/sec with Srd=1 with plenty of spare on Master time using TViewer, without TViewer it is getting close to MAX it can do of 560.
Or using above numbers at 500 Hz::
No TViewerSPI is hitting 89% MAX capacity, and
with TViewerSPI it is hitting 54% capacity.
>> SOMEHOW this is over 2X faster than last time I tested with more math and more big numbers?
Loops goes to 0K because it is barely/NOT finishing one update when the next arrives, and the Slave - even bumped to 168 MHz is catching Bad_CRC's. Infact dropping Slave T_3.5 back to 120 MHz it is the same or better.
{ 144 on T_3.5 may be worse and dropping MASTER SPI from 30 MHz to 24 MHz did no BIG help (some?) and that drops TViewer loop count 10K to 433 }
{ I did not instrument the Slave to count the Bad_CRC's - but it is ~1/1000+ lost messages to TVIewer. }
I had to repower after the last reprogram with Srd==0 is throttling the MASTER it seems - as it printed ONLY "Serial Initialized" and STOPPED.
Dropped back to 500 Hz IMU and I still see Bad_CRC scroll by - one or two every few seconds.
Above code updated with the LOOP&IMU counters so Mike can see where the T_3.5 safe zone is. The prints are from the gpsDebug() added when the second changes.