Thank you!
I'm sure, I'll do that with a final version board, and find out.....
Last edited:
Teensy 4? testing mbed NXP MXRT1050-EVKB (600 Mhz M7)
- Thread starter manitou
- Start date
Thank you!
I'm sure, I'll do that with a final version board, and find out.....
PaulStoffregen
Well-known member
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...
I'm gonna get these heat sinks:
https://www.amazon.de/dp/B07FTLT9H3/ref=psdc_1626220031_t1_B07FXY7TQ8
They are a bit too large: 13mm x12mm, but I think i can make them a bit smaller if needed, they're made of copper, copper is soft - so it's not too hard to remove 1mm (I hope). They have a heat conduction foil.
Because they are for the Raspberry Pi, they are available everywhere.
https://www.amazon.de/dp/B07FTLT9H3/ref=psdc_1626220031_t1_B07FXY7TQ8
They are a bit too large: 13mm x12mm, but I think i can make them a bit smaller if needed, they're made of copper, copper is soft - so it's not too hard to remove 1mm (I hope). They have a heat conduction foil.
Because they are for the Raspberry Pi, they are available everywhere.
Theremingenieur
Senior Member+
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...
But as I said, that’s pure theory, just thinking out loud...
daywalker03
Member
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.
PaulStoffregen
Well-known member
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.
MichaelMeissner
Senior Member+
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.
defragster
Senior Member+
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.
PaulStoffregen
Well-known member
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.
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.
MichaelMeissner
Senior Member+
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.
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.
defragster
Senior Member+
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 ::
For F_BUS it is: (- mostly WIRE and SPI, Analog, PJRC):
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 ::
For F_BUS it is: (- mostly WIRE and SPI, Analog, PJRC):
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.
KurtE
Senior Member+
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.
defragster
Senior Member+
+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.
Question is how can one combine flexibility of changing clock speed with rigidity of Arduino F_CPU usage.
defragster
Senior Member+
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
.