Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast
Results 176 to 200 of 216

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

  1. #176
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    Quote Originally Posted by PaulStoffregen View Post
    So I'd look for heatsinks in the 10-12 mm range.
    Thank you!
    Quote Originally Posted by PaulStoffregen View Post
    I really have no idea how long you could expect your board to last if running it that far beyond the absolute max voltage.
    :-) I'm sure, I'll do that with a final version board, and find out.....
    Last edited by Frank B; 12-25-2018 at 08:29 PM.

  2. #177
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,707
    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...

  3. #178
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    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.

  4. #179
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,321
    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...

  5. #180
    Junior Member
    Join Date
    Dec 2014
    Posts
    16
    Quote Originally Posted by Theremingenieur View Post
    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.

  6. #181
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,707
    Quote Originally Posted by Theremingenieur View Post
    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.

  7. #182
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,943
    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.

  8. #183
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,016
    Quote Originally Posted by MichaelMeissner View Post
    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.

  9. #184
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,707
    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.

  10. #185
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,943
    Quote Originally Posted by PaulStoffregen View Post
    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.

    Quote Originally Posted by PaulStoffregen View Post
    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.

  11. #186
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,016
    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

  12. #187
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    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..

  13. #188
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    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..)

  14. #189
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    ... If code does not check the range of allowed values, its buggy anyway :-) Adding a #ifdef IMX... is simple.

  15. #190
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,087
    Quote Originally Posted by Frank B View Post
    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.

  16. #191
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    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 by Frank B; 12-26-2018 at 09:52 AM.

  17. #192
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,390
    Quote Originally Posted by WMXZ View Post
    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.

  18. #193
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    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.

  19. #194
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,016
    Quote Originally Posted by KurtE View Post
    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.

  20. #195
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    Quote Originally Posted by defragster View Post
    +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.

  21. #196
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,087
    Quote Originally Posted by defragster View Post
    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.

  22. #197
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    Where's the problem ? T3.x can stay as they are (otherwise you'd make all existing code incompatible), T4 - is new

  23. #198
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,016
    Quote Originally Posted by Frank B View Post
    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 .

  24. #199
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,707
    Still so many finer details to be decided....

    Quote Originally Posted by WMXZ View Post
    Question is how can one combine flexibility of changing clock speed with rigidity of Arduino F_CPU usage.
    A very good question indeed.

  25. #200
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,514
    I've proposed a very flexible, compatible solution.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •