Teensy 4? testing mbed NXP MXRT1050-EVKB (600 Mhz M7)

Personally I really want to find out the answer. But we have only 31 beta boards, at this time. Can't afford to lose several...
 
Can’t it be overclocked without increasing the voltage? I mean, increasing the voltage asks for more electrons charging or discharging the parasitic gate capacitances of the mosfet switches, so that alone increases already the power dissipation without forcibly speeding up things, while increasing the clock frequency would require faster switching times, which would, at least in theoretical physics, ask for smaller charges, rather obtainable by lowering the threshold voltages through lowering the supply voltage.

But as I said, that’s pure theory, just thinking out loud...
 
Can’t it be overclocked without increasing the voltage? I mean, increasing the voltage asks for more electrons charging or discharging the parasitic gate capacitances of the mosfet switches, so that alone increases already the power dissipation without forcibly speeding up things, while increasing the clock frequency would require faster switching times, which would, at least in theoretical physics, ask for smaller charges, rather obtainable by lowering the threshold voltages through lowering the supply voltage.

But as I said, that’s pure theory, just thinking out loud...

If I remember correctly, on PC the best option is a combination of voltage and clock adjustments, but I'm not sure if it would be easily accomplished on something like a Teensy in the same manner.
 
Can’t it be overclocked without increasing the voltage?

Yes. In fact, the default core library will have OVERCLOCK_MAX_VOLT defined at 1300, so by default you can't go over the absolute max voltage spec by just calling functions from Arduino code. To go higher, you have to edit clockspeed.c and uncomment the line that says "Danger Will Robinson". ;)

On the 1 board I've tested overclocking, the limit seems to be about 780 MHz with 1.3V. The chip gets quite warm, but not so hot you can't leave your finger in contact.

I tried a couple quick tests with the limit lowered to 1.25V (the official spec for 534 to 600 MHz). 732 MHz is the fastest I can get to pass the Coremark benchmark without crashing or CRC errors.

All these tests were done on only a single beta board, and only at room temperature.
 
I've been wondering whether if we give the users easy methods to change the clock speed, whether F_CPU needs to be a run time variable instead of a constant (and other settings that are set from F_CPU could be modified as well). I imagine there are pluses and minutes to making F_CPU vary at runtime (i.e. decisions made at program startup might not reflect the reality after the clock speed has been changed). This is more of a theoretical question, as I haven't looked at the details of any of the Teensy chips.
 
I've been wondering whether if we give the users easy methods to change the clock speed
...

That'd be cool. Snooze does what it does - but sleeps and restores as needed on return. T_3.6 EEPROM write drops speed with some bus compromises for the duration.

Perhaps anything with a .begin( F_CPU ) of any sort where time/freq is resolved could register a callback to recalibrate on .beginAgain( F_CPU )

Given the noted Temp Detect post, being able to drop speed could be useful - even at non-OC speeds - in addition to saving power between true need for speed - and yet when sleep isn't an option. Some installs may have cyclic daily environment/enclosure temp to deal with.
 
I considered making F_CPU a variable. I even wanted to make it a C++ object with operator overloading, so you could just assign a number to it and the ARM clock would change. But there is a universe of Arduino code which expects F_CPU to be a preprocessor symbol, doing stuff like "#if F_CPU > 16000000UL". Don't see how we can make it anything else without breaking all that code.

One of the really awesome features of this new chip is nearly everything that needs to run at a consistent speed clocks from PLL2 (fixed 528 MHz) or PLL3 (fixed 480 MHz). So unlike Teensy 3.6 where the baud rates on Serial1 & Serial2 change, we get all 8 serial ports in this new chip running from PLL3 or directly from the crystal. Likewise for I2C, CAN, audio, and many other things (most of that huge clock tree) we get stable clocks to pretty much all important peripherals separate from the ARM clock on PLL1.
 
I considered making F_CPU a variable. I even wanted to make it a C++ object with operator overloading, so you could just assign a number to it and the ARM clock would change. But there is a universe of Arduino code which expects F_CPU to be a preprocessor symbol, doing stuff like "#if F_CPU > 16000000UL". Don't see how we can make it anything else without breaking all that code.

Yep, but then perhaps we limit progress to what the least common denominator can do.

Perhaps have a build option that fixes the speed (and perhaps does not give easy access to changing it), and one for people that want/need finer control.

One of the really awesome features of this new chip is nearly everything that needs to run at a consistent speed clocks from PLL2 (fixed 528 MHz) or PLL3 (fixed 480 MHz). So unlike Teensy 3.6 where the baud rates on Serial1 & Serial2 change, we get all 8 serial ports in this new chip running from PLL3 or directly from the crystal. Likewise for I2C, CAN, audio, and many other things (most of that huge clock tree) we get stable clocks to pretty much all important peripherals separate from the ARM clock on PLL1.

Yes, it was things like serial ports, USB, audio, and things like ws2812b LEDs that need consistent time that are driven off of the main clock in other processors that prompted me to ask the question. I wondered if you could change the cpu clock frequency, whether it would make everything else stop working (much like the EEPROM issue in 3.6). It sounds like things are a lot better with separate clocks.
 
Nice that the bus clocks are tied to stable clocks. Of course F_BUS on T_3.6 often changed with F_CPU … with stable clock those will be "nearly" unaffected.

Doesn't that mean the T_4 code would special case the F_CPU in many cases where before F_CPU related to it if it seemed to matter? Existing code wouldn't know what to do with 600,000,000. The places it might matter to have F_CPU change at runtime could get a way to update.

Search F_CPU in Teensy's AVR tree of 2988 files - tree scans include PJRC and included libraries ::
781 matches across 135 files

For F_BUS it is: (- mostly WIRE and SPI, Analog, PJRC):
420 matches across 41 files
 
If most of the devices have new clock sources and are not F_CPU or F_BUS depended: Don't libs need corrections anyway? And which code will still need F_CPU/F_BUS after that? Not much..
 
One could just set F_CPU to a fake value..180MHz like T3.6. Or a unusual value: 201MHz or just fixed 600MHz to indicate something is different.. but most software will work with that(after editing the libs..)
 
If most of the devices have new clock sources and are not F_CPU or F_BUS depended: Don't libs need corrections anyway? And which code will still need F_CPU/F_BUS after that?

I would add: it is time to implement core functions that manage clock speeds and remove all conditional compiling for libraries. All teensies ave sufficient program space, so conditional compiling is not necessary anymore.
This change has only to be done ones.
It should also be easy to provide instructions for new users for to change from conditional compiling to conditional run-time execution.
 
Yes. I'd just use fixed 600MHz as default, without any clock selections in Teensyduino and provide a optional "set_clock()".

set_clock_CPU()
set_clock_BUS()
set_clock_I2S0()
set_clock_I2S1()...
+ getters
 
Last edited:
I would add: it is time to implement core functions that manage clock speeds and remove all conditional compiling for libraries. All teensies ave sufficient program space, so conditional compiling is not necessary anymore.
This change has only to be done ones.
It should also be easy to provide instructions for new users for to change from conditional compiling to conditional run-time execution.
I would be careful with this, as I have seen forum posts of people running out of space on a Teensy LC and 3.2... So I would not assume we can or should significantly grow things, especially on the lower end.

But maybe that would make sense to allow this on the higher end boards like 3.5/3.6 and now the 4.0


If it were me, I would probably still leave F_CPU and the like as #defines, which are set to the values specified by the user in the IDE, but then maybe introduce a set of system variables or object(s) with the current F_CPU (F_CPU_CURRENT?), which can be updated. As mentioned looks like many of the devices on the 4.0 may not be effected by changes made to CPU speed, so hopefully most of the code on this new chip will not need to look at the F_CPU, but for the vast majority of programs that don't change speeds should just work.
 
I'd say a single #define F_CPU 600000000 (+ F_BUS, F_PLL) is much easier to handle, otherwise we end with another set of #if..#else..#else tree in the all the library sourcecodes and earn nothing.
 
I would be careful with this, as I have seen forum posts of people running out of space on a Teensy LC and 3.2... So I would not assume we can or should significantly grow things, especially on the lower end.

But maybe that would make sense to allow this on the higher end boards like 3.5/3.6 and now the 4.0


If it were me, I would probably still leave F_CPU and the like as #defines, which are set to the values specified by the user in the IDE, but then maybe introduce a set of system variables or object(s) with the current F_CPU (F_CPU_CURRENT?), which can be updated. As mentioned looks like many of the devices on the 4.0 may not be effected by changes made to CPU speed, so hopefully most of the code on this new chip will not need to look at the F_CPU, but for the vast majority of programs that don't change speeds should just work.

+1 with Kurt. T_LC is special and small, T_3.2 is great for Audio but stored samples in Flash or whatever can quickly fill 256 KB. Also larger code means more cache misses - even the 1062 only has 32 KB instruction cache - and the T_3.6 next best is much smaller. #define code is an abomination - but serves a real purpose in this world keeping down code bloat and keeping incompatible things apart.

Paul has the best idea so far of how all this is coming together. So far __IMXRT1052__ is only in github_CORES:: makefile, pins_arduino.h.
 
+1 with Kurt. T_LC is special and small, T_3.2 is great for Audio but stored samples in Flash or whatever can quickly fill 256 KB. Also larger code means more cache misses - even the 1062 only has 32 KB instruction cache - and the T_3.6 next best is much smaller. #define code is an abomination - but serves a real purpose in this world keeping down code bloat and keeping incompatible things apart.

Paul has the best idea so far of how all this is coming together. So far __IMXRT1052__ is only in github_CORES:: makefile, pins_arduino.h.

I was speaking of T4 only... additional changes for t3.x would be overkill now.
 
Paul has the best idea so far of how all this is coming together. So far __IMXRT1052__ is only in github_CORES:: makefile, pins_arduino.h.

Question is how can one combine flexibility of changing clock speed with rigidity of Arduino F_CPU usage.
 
Where's the problem ? T3.x can stay as they are (otherwise you'd make all existing code incompatible), T4 - is new :)
 
Where's the problem ? T3.x can stay as they are (otherwise you'd make all existing code incompatible), T4 - is new :)

Agreed - per my post many posts back that Frank then echoed - the T4 #ifdef will be needed to exclude others - but within that all is new. A T4 user will need new TeensyDuino - and an older TeensyDuino won't be changed. As long as TeensyDuino covers any additions for T4 - fcpuGetClock(), fcpuSetClock() can be added and for non-T4 code just return F_CPU or be a NOP - with an #ifdef in that code :).
 
Back
Top