Was wondering about CPU free time - figured dropping CPU speed would be easier to call FAIR and get right and it showed value.
24 MHz T_3.6 is enough to do an all in one test Just catching the I/O reading & parsing:
> onehorse MPU9250 on under pins [ i2c Wire.setSCL(47); Wire.setSDA(48); ]
> Interrupts catching IMU at 1KHz :: Performs IMU.readSensor() in the isr() - pin #50
> uBlox M8N 5Hz @460,800 baud
> Parse 5 'UBX NAV-PVT' GPS emissions per second
> Triggering isr() on Serial2 Start bit to time start of the coming GPS data.
> PPS at 1Hz to get a time base [ RTC works as well with more slop ]
> ADDED counter of passes per second through loop()'s for feel of 'free time'
Results: 24 Hz everything is caught and kept up - except intermittent failure to fully parse GPS, unless default yield() is replaced!
>> LTO adds seconds to build time but seems to free up runtime for loop()
Code:
@_24MHz:: loop()'s _20 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, misses a few+ GPS $'s per 10sec
@_24MHz:: loop()'s _44 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << Fastest, void yield()
@_24MHz:: loop()'s 125 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << w/ LTO, void yield()
@_48MHz:: loop()'s _63 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s
@_48MHz:: loop()'s 165 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << w/ LTO
@_48MHz:: loop()'s 402 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << w/ LTO, void yield()
@180MHz:: [U]loop()'s 1.47 MHz[/U] : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << w/ LTO, void yield()
@240MHz:: loop()'s 309 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << FAST
@240MHz:: loop()'s 608 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << FAST, void yield()
@240MHz:: loop()'s 926 KHz : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << Fastest, void yield() :: F_BUS120 MHz
[U]@240MHz:: [B]loop()'s 2.40 MHz[/B] : 1001 IMU int()/sec, and 5 GPS Rx start, All GPS $'s << Fastest w/LTO, void yield() :: F_BUS120 MHz[/U]
Note: 24 and 48 MHz compile and run FASTEST, but 240 MHz IMU errors - noted above compiled FAST
>> Error -5 - bad WhoAmI(): Doesn't happen 180 MHz w/LTO. Added delay() in .begin did not find a fix.
FIX: EDIT TD Sources ~line 765 in T:\arduino_b1.9_B34_td141\
hardware\teensy\avr\cores\teensy3\kinetis.h
Code:
#if (F_CPU == 240000000)
#define F_PLL 240000000
#ifndef F_BUS
[COLOR="#FF0000"] //#define F_BUS 60000000[/COLOR] // COMMENT THIS LINE
//#define F_BUS 80000000 // uncomment these to try peripheral overclocking
[B] #define F_BUS 120000000 // all the usual overclocking caveats apply...[/B] [COLOR="#FF0000"]// UNCOMMENT THIS LINE[/COLOR]
** ::
void yield() {}; // Void yield() to bypass default PJRC yield overhead - Add this to user sketch .INO
>> PJRC yield() just includes a walk across all (6) UARTS for calls to serialEvent() - this overhead breaks 24 MHz GPS parsing
Sample output 1 second at 240 MHz and Fastest w/LTO, void yield() :: w/F_BUS 120 MHz shows:
> count of IMU isr()'s, running PPS ticks, GPS Rx start bits caught and GPS $'s parsed, loops cycled
> "X" is rounded count of 100 IMU isr() readSensor()'s, interwoven with parsed GPS string output
IMU Read #1001 PPS Ticks 783 GPS Rx= 5 Parsed= 5 loops= 2405940
X 1/22 @ 7:58:16 5 36.55
XX 1/22 @ 7:58:16 5 36.78
XX 1/22 @ 7:58:16 5 36.79
XX 1/22 @ 7:58:16 5 36.85
XX 1/22 @ 7:58:16 5 36.90
XX
@Brian - I see uBlox sets the Teensy baud rate - but doesn't call out to the device which is where I was at. [ it can't without prior baud and of course saving to FLASH fixes this ]
<edit>: Code not included - Was just smashed together to test to see how low it could go, and code includes PPS that nobody else likely has. Has no added value except minor operational details perhaps. I will #ifdef it to default to RTC PPS. Also note IMU similarly fails to run at 216 MHz - but I did not bother looking to solve that as 240 MHz is stable on all my units when F_BUS is bumped to 120 MHz. Also - I really made debug spew sparse and I thought that was killing 24 MHz before I thought to replace the default 'weak' yield() - with the GPS active that 6 UART scan was a killer to find minimal needed speed. I could try at 16 MHz - but then I'd have to work without USB, which would be a good excuse for second PROXY debug teensy.
I placed on this thread (though the findings really hits the UBlox and MPU9250) because 'everyone' is here - and this thread/code can use all the spare horsepower it can get.
Also: 24 MHz FAST without LTO only parses about 10 of 50 GPS messages in 10 seconds, even FAST with LTO misses many of those 50 - even with a high 98 KHz loop count. So 24 MHz is on the edge without proper optimization selected. I'm not sure why uBlox fails parsing - the code looked nice and clean, but something can kill it some seconds while running loop() that fast means it should be able to catch all the chars since it only get 500/sec? Hopefully this won't show later with more intensive filters active.