Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 101 to 125 of 133

Thread: Teensy 3.1 overclock to 168MHz

  1. #101
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,111
    Yes, you have Serial1 (and Serial2 and Serial3) all available. See the pinout diagram at
    http://www.pjrc.com/teensy/pinout.html
    for the RX and TX pins for each one.

  2. #102
    Junior Member
    Join Date
    Nov 2014
    Location
    Long Beach CA
    Posts
    15
    Quote Originally Posted by Nantonos View Post
    Yes, you have Serial1 (and Serial2 and Serial3) all available. See the pinout diagram at
    http://www.pjrc.com/teensy/pinout.html
    for the RX and TX pins for each one.
    i am locking to this http://www.pjrc.com/teensy/td_uart.html
    and now i understand , i need use
    Code:
    #define Serial7Segment Serial1
    and pin 1 TX.

  3. #103
    Junior Member
    Join Date
    Nov 2014
    Location
    Long Beach CA
    Posts
    15
    Quote Originally Posted by xxxajk View Post
    I made a better patch and a pull request on github.
    https://github.com/PaulStoffregen/cores/pull/37
    http://forum.pjrc.com/threads/26776-...-1-20-Released

    https://github.com/PaulStoffregen/cores

    Works
    i can compile :-) error going
    i downloaded this https://github.com/FrankBoesing/Teen...8MHz-Overclock 3 days ago and whit this trouble.

    Thanks

    Dirk
    Last edited by dirk; 11-12-2014 at 06:52 AM.

  4. #104
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    i downloaded this https://github.com/FrankBoesing/Teen...8MHz-Overclock 3 days ago and whit this trouble.
    Dirk

    Yes, as can you read in the "readme" - on the page where you dowloaded it - this is obsolete....

    Maybe i should delete it...?

  5. #105
    Junior Member
    Join Date
    Dec 2014
    Posts
    17
    Quote Originally Posted by PaulStoffregen View Post
    Also, with overclocking, consider that 144 and 168 MHz modes overclock the flash memory. 144 MHz mode overclocks the flash by 20% and 168 MHz overclocks it by 40%.

    168 MHz mode also overclocks the peripherals by 17%.

    120 MHz mode runs the flash memory within spec, but overclocks peripherals by 25%.

    96 MHz mode runs the flash and peripherals within spec, and it's only a modest overclock of the CPU. I personally test nearly all code at 96 MHz and everything has worked very well at this speed.

    But technically, anything over 72 MHz on Teensy 3.1 and anything over 48 MHz on Teensy 3.0 is overclocking.
    How does this affect delay(), micros(), millis()?

    Im trying to calculate FPS. This code outputs ~ once a second. Im getting 16-17 FPS.
    Can this be?

    Why does it need an offset of ~9000ms?

    Code:
    void loop(void) {
      long t = 0;
      long start_t = millis();
      int sec = 9000;
      int i = 0;
      
      while(1) {
        //tft.setRotation(rotation);
        testText();
        //delay(1000);
        
        t += (millis() - start_t);
        i++;
        if (t >= sec){
          t -= sec;
          Serial.print(F("FPS: "));
          Serial.println(i);
          i=0;
          start_t = millis();
        }
      }
    }
    Code:
    ILI9341 Test!
    Display Power Mode: 0x0
    MADCTL Mode: 0x0
    Pixel Format: 0x0
    Image Format: 0x0
    Self Diagnostic: 0x0
    Benchmark                Time (microseconds)
    Screen fill              224096
    Text                     16712
    Lines                    58739
    Horiz/Vert Lines         18570
    Rectangles (outline)     11750
    Rectangles (filled)      465397
    Circles (filled)         79067
    Circles (outline)        81241
    Triangles (outline)      14294
    Triangles (filled)       159296
    Rounded rects (outline)  33748
    Rounded rects (filled)   510878
    Done!
    FPS: 17
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 17
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 17
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 17
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 16
    FPS: 17
    FPS: 16
    Last edited by origami; 01-10-2015 at 02:44 AM.

  6. #106
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    Quote Originally Posted by origami View Post
    How does this affect delay(), micros(), millis()?
    The hardware timers automatically reconfigure, so you always get 1ms and 1us, regardless of the CPU speed.

    Well, plus a tiny amount of code execution overhead in the call and return, which obviously does improve with clock speed.

    Im trying to calculate FPS. This code outputs ~ once a second. Im getting 16-17 FPS.
    For SPI-based displays, you'll probably see best performance at 120 MHz, if your display can handle 30 MHz SPI clock.

    The maximum SPI clock is F_BUS/2. F_BUS has to be an integer divide of F_CPU. When F_CPU is 144 MHz, F_BUS is 48 MHz (divide by 3). However, when F_CPU is 120 MHz, F_BUS is 60 MHz (divide by 2)... so you can get faster SPI data transfer at 120 MHz than you can at 144 MHz.

  7. #107
    Senior Member
    Join Date
    Jun 2013
    Location
    So. Calif
    Posts
    2,828
    Can one run the F_BUS clocks at 60MHz per spec or is that overclocking?

  8. #108
    Junior Member
    Join Date
    Dec 2014
    Posts
    17
    Quote Originally Posted by PaulStoffregen View Post
    For SPI-based displays, you'll probably see best performance at 120 MHz, if your display can handle 30 MHz SPI clock.

    The maximum SPI clock is F_BUS/2. F_BUS has to be an integer divide of F_CPU. When F_CPU is 144 MHz, F_BUS is 48 MHz (divide by 3). However, when F_CPU is 120 MHz, F_BUS is 60 MHz (divide by 2)... so you can get faster SPI data transfer at 120 MHz than you can at 144 MHz.
    Indeed 96 and 144 MHz have almost the same results
    Code:
                           	96 Mhz	120 Mhz	144 Mhz
    			
    Screen fill         	280148	224147	280108
    Text              	19602	16714	16412
    Lines                 	73320	58736	73112
    Horiz/Vert Lines      	23153	18571	23057
    Rectangles (outline)	14668	11748	14635
    Rectangles (filled)	581709	465393	581661
    Circles (filled)      	95745	79087	90845
    Circles (outline)	96136	81252	76478
    Triangles (outline)	17805	14290	17719
    Triangles (filled)	197576	159282	194515
    Rounded rects (outline)	40185	33739	34236
    Rounded rects (filled)	637565	510878	635961

    Quote Originally Posted by PaulStoffregen View Post
    The hardware timers automatically reconfigure, so you always get 1ms and 1us, regardless of the CPU speed.
    The thing is though, if I run the modified code with 1000ms to get FPS, I get several outputs per second. I need to wait ~9000ms "Teensy-time" (int sec) to get output once per second
    Last edited by origami; 01-10-2015 at 03:59 AM.

  9. #109
    Member mixania's Avatar
    Join Date
    Oct 2014
    Location
    New York, NY
    Posts
    20
    This turbo overclock should come as an option with the Teesny loader, why not? I mignt be underestimating and unaware of the dangers that pose when overclocking microcontrollers.

  10. #110
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    In the grand scheme of things, you're overclocking a $20 microcontroller board. People overclock their several hundred dollar graphics cards and PC motherboards all the time. Much like PC overclocking, theoretically you're risking the hardware, but actual damage is very rare. Usually the processor just locks up or does wrong things, but usually works fine when you run again at lower speeds.

    When you press the button on Teensy 3.1, the Mini54 takes over. It hard resets the MK20 chip. When your finger releases the button, the Mini54 starts it up again at only 24 MHz. This always should recover from overclocking crashes. Well, unless the chip got damaged, which it theoretically possible but very unlikely.

    168 MHz is not very stable. Reports are mixed on 144 MHz. Many people say it's working well, but a few have reported crashes after long periods. So far, consensus seems to be 120 MHz works very well.

    120 MHz is also a bit special. Even though the CPU isn't as fast as 144 or 168, this speed has the fastest peripheral clock, because that clock must be an integer divide of the CPU clock. If your project is I/O bound, especially with SPI, this speed can let you get 30 MHz SPI clock rates, instead of the usual 24 MHz maximum. Sometimes that matters more than the CPU speed.

  11. #111
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    532
    The memory, flash, and peripherals run at a much slower speed. They also usually all run at different speeds too.
    So there is a trade-off when going at that speed.
    The idea though, is that if you can keep a small computational intense loop in the cache, you will see a benefit. The trick is to avoid memory cache misses. Access to memory that causes a cache miss will gain you nothing. So it would break-even. This is usually the case for most code.
    Now the bad news...
    Accessing I/O may in fact get slower, depending on the wait states and I/O clocking.

  12. #112
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    The RAM runs at the full CPU speed. Flash runs much slower.

    There's a "FASTRUN" feature that lets you put your speed critical functions into RAM. It rarely makes much difference at normal speeds, but at 144 or 168 it can have a much more dramatic effect.

  13. #113
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Yes, but to interpret the results you must know what are you measuring. If there are library-calls or floating-point calculations for example, they will run from flash, despite of "FASTRUN".

    168MHz had never been stable on my Teensys. 144MHz is ok for mine.
    Is there an option to tune the voltage on the 3.1 ? maybe one could try that... if possible.

  14. #114
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,665
    Quote Originally Posted by PaulStoffregen View Post
    The RAM runs at the full CPU speed. Flash runs much slower.

    There's a "FASTRUN" feature that lets you put your speed critical functions into RAM. It rarely makes much difference at normal speeds, but at 144 or 168 it can have a much more dramatic effect.
    Running the FFTs with FASTRUN (i.e. tables and code in Memory) at 144 MHz, makes a significant difference.

  15. #115
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    532
    Yes, it can be a mixed bag.
    Generally it isn't worth doing. In my experience, regardless of the price.
    Even with the Teensy 3/3.1, I've seen I/O actually get slower. It depends totally on the divisors though, and we know that.
    I suggest like Paul... but from a different perspective.
    Think of it this way: Yes you COULD load 100 people onto a car, strapping them to various parts of the body of it, but are you willing to risk the passengers?
    as compared to: Yes you COULD overclock the MCU or CPU, but are you willing to risk the possibility of the program running incorrectly?

  16. #116
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    120MHz is a good compromise, and it has the fastest f_bus.

  17. #117
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    I'm very comfortable with 96 MHz.

    All the Kinetis chips are made with the same 90 nm process. There's also very good reason to believe the 72 MHz parts are the same or a very similar design as the ones rated for 100 MHz.

    The other options are commented out in boards.txt. Perhaps 168 should be removed?

  18. #118
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Quote Originally Posted by PaulStoffregen View Post
    I'm very comfortable with 96 MHz.

    All the Kinetis chips are made with the same 90 nm process. There's also very good reason to believe the 72 MHz parts are the same or a very similar design as the ones rated for 100 MHz.

    The other options are commented out in boards.txt. Perhaps 168 should be removed?
    I would say "yes".

  19. #119
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    532
    Quote Originally Posted by Frank B View Post
    I would say "yes".
    I actually agree on this point. 120 is actually what I tend to find works very well... I also actually use other 120MHz Kinetis MCU as well, same family infact. What I find interesting about them though is that you can't overclock those.
    It would seem to me that Freescale does like everyone else does... some chips won't be able to reach the higher speeds reliably, so they are badged as a lower speed after using some form of HV secret sauce programming.

    What this all means is that you may get chips that can exceed the ratings, sometimes because a lower speed is more in demand, but what ones will do this reliably can be quite random, even from the same lot and wafer.

  20. #120
    Member mixania's Avatar
    Join Date
    Oct 2014
    Location
    New York, NY
    Posts
    20
    Adding a 120 MHz overclock option will certainly be awsome! I get a general picture based on this thread that most people agree that overclock at 120MHz can cause some turbulence but never a plane crash. At least when compared to what the higher overclock speeds (<120MHz) can cause.

  21. #121
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    @mixania: all you need to do is editing robots.txt, there are already options for 120MHz. Just remove the comments.

    Yes, i ran my mp3-player on 120mhz for days without crash or warmth

  22. #122
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    532
    Yes, but it should come with a cautionary note and not be a "supported" option.
    in fact I personally would not support any of the overclocked speeds.
    What I mean by support is that if your stuff does not work at the higher speed, then PJRC is not responsible for it not working.
    It is a hack and thus fully disclosed as such, with no promises that it will actually work every time, in every situation.
    There are a multitude of problems that can occur just by certain sequences on the data bus, for example, that could cause an electron to jump onto the wrong pathway, thus crashing your program.

    Generally, I think one of the requirements for posting a "bug" is to make sure the same thing happens at the rated speed of the chip.
    If things work at the lower speed, you've found the "bug"... I've actually encountered this, across many platforms in the past.

  23. #123
    Member mixania's Avatar
    Join Date
    Oct 2014
    Location
    New York, NY
    Posts
    20
    Quote Originally Posted by Frank B View Post
    @mixania: all you need to do is editing robots.txt, there are already options for 120MHz. Just remove the comments.
    Thank you, didn't know that.

  24. #124
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,743
    Quote Originally Posted by Frank B View Post
    @mixania: all you need to do is editing robots.txt, there are already options for 120MHz. Just remove the comments.
    I suspect you meant boards.txt. Robots.txt is the file you place in web sites to prevent web spiders from visiting a page.

  25. #125
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    oops. yes :-)

Posting Permissions

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