Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 133

Thread: Teensy 3.1 overclock to 168MHz

  1. #26
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    if you use just 144MHz and 192MHz then it would be easy to update the core because their divisible without any remainders for the clocks divs.

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    I know :-)

    It depends on Paul if he wants 120 & 168.

    For me, i changed all place in the core for F_BUS 40 & 42. But, 120 is not really useful. 168 becaus "it works". 192... did not work for me, but I'll try it again.

  3. #28
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    did anyone try 144MHz? i'll try tonight also, it think being able to divide down the BUS and MEM clocks to 48MHz and 24MHz will make updating the core much easier than having non divisible clocks.

  4. #29
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    The only disadvantage of these clocks is with SPI, i think. - For example, 24MHz SPI ist not possible and therefore 21MHz.
    Unfortunately, i could not test SPI - it's changed in SPIFIFO.h - but there may be a bug in my calculations :-)
    Last edited by Frank B; 05-13-2014 at 09:04 PM.

  5. #30
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Paul, i can do a 144MHz-only Pullrequest if you want

  6. #31
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    Quote Originally Posted by Frank B View Post
    The only disadvantage of these clocks is with SPI, i think. - For example, 24MHz SPI ist not possible and therefore 21MHz.
    Unfortunately, i could not test SPI - it's changed in SPIFIFO.h - but there may be a bug in my calculations :-)

    Isnt the SPI BUS clocked? if you use those PLL speeds (192, 144) they divide down to 48MHz bus and 24MHz MEM clock exactly.

  7. #32
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    I never said that 144 or 192 are problematic for F_BUS or spi.
    If you look at github, you will see that 120, 144, 168 MHz are already implemented.
    Again, the "problem" only exists for 120 and 168 MHz. I'm not sure, if it is really a problem...
    Last edited by Frank B; 05-14-2014 at 06:38 AM.

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,927
    Quote Originally Posted by Frank B View Post
    Paul, i can do a 144MHz-only Pullrequest if you want
    Yes, please do.

    I can't possible look at it until after Maker Faire. When I return next week, there'll probably be a pile of urgent stuff to do before I can work on software. Please understand there'll be a significant delay.

  9. #34
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    Quote Originally Posted by Frank B View Post
    I never said that 144 or 192 are problematic for F_BUS or spi.
    I know its not a "problem", I was only saying that everything tied to F_BUS is configured for 24, 48 MHz use, so using those CPU frequencies make it easier to port rather than having to reconfigure everything for a "non standard" F_BUS.

    From my testing 192MHz was not usable anyway, i couldn't get the a simple blink sketch working? It seems to choke when trying to lock the PLL. Though I could divide it down to 96MHz and it was fine if I used 192MHz PLL.

    144MHz PLL worked fine for me though. Did anyone get 192MHz working?

  10. #35
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,550
    I thought it would be fun to try out with some of my stuff, so forked... I thought I would first try it out with my updated drivers for the Adafruit 2.8" tft display that I updated the test program to use SDFAT, to display bitmap on screen.

    Appears to work at 144mhz, tried the 168mhz and the bitmaps starts to display and then stops part way through. Then trying to go back to 144mhz, it would not reprogram the Teensy, until I removed the shields, and pressed the program button.

    Also it appeared like each time I changed the CPU speed, windows would install a new comm port number for the Teensy. Was 71 and it created 72 and 73... Not sure if this is normal or not? (Windows 7)

    Next up and interested to verify that at the higher speeds, still get a sufficient 1mhz serial port on Serial1 for Bioloid AX serial buss, likewise maybe again test for 2mhz/3mhz for those who have servos like MX series.

    Update: Simple test of AX servos appears to work. At first not so sure, as one board was not responding, so tried using my other carrier board design... Need to figure out what happened with other board, but that is different subject. Have not test 2/3 mhz yet

    Question: for Hardware serial ports, I believe that the baud rates work best for those (CPU/baud) is divisible by 32, so for example for 1,2,3mhz, 96mhz works great. Likewise if it works 192. So wondering if 160 would work better than 168?

    Thanks again,

    Kurt
    Last edited by KurtE; 05-14-2014 at 03:09 PM.

  11. #36
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    So if the aim is to make a square wave signal using the PWM function, you'd want to choose a frequency that is easily divisible by 4 or 8, correct? That in turn suggests that the 120MHz configuration would be just about right... trying to make a 16MHz signal and the closest I can get with the existing configurations is 12MHz. The board would be able to sample 20% faster with a 120MHz Master bus clock. Speaking of which, would a 128MHz master clock speed be feasible?

    i.e.
    #elif (F_CPU == 128000000)
    #define F_BUS 42000000
    #define F_MEM 28000000

  12. #37
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Hi Kurt,

    i calculated some Baudrates with Excel. Serial communcation can tolerate about 2.5% error.

    Code:
    #define BAUD2DIV(baud)  (((F_CPU * 2) + ((baud) >> 1)) / (baud))
    
    F_CPU       Baud        Divisor     Eff. Baud   % Error
    168000000   9600        35000       9600,00     0,00
    168000000   19200       17500       19200,00    0,00
    168000000   38400       8750        38400,00    0,00
    168000000   57600       5833        57603,29    0,01
    168000000   115200      2917        115186,84   -0,01
    168000000   230400      1458        230452,67   0,02
    168000000   460800      729         460905,35   0,02
    168000000   921600      365         920547,95   -0,11
    168000000   1000000     336         1000000,00  0,00
                                                    
    160000000   9600        33333       9600,10     0,00
    160000000   19200       16667       19199,62    0,00
    160000000   38400       8333        38401,54    0,00
    160000000   57600       5556        57595,39    -0,01
    160000000   115200      2778        115190,78   -0,01
    160000000   230400      1389        230381,57   -0,01
    160000000   460800      694         461095,10   0,06
    160000000   921600      347         922190,20   0,06
    160000000   1000000     320         1000000,00  0,00
                                                    
    144000000   9600        30000       9600,00     0,00
    144000000   19200       15000       19200,00    0,00
    144000000   38400       7500        38400,00    0,00
    144000000   57600       5000        57600,00    0,00
    144000000   115200      2500        115200,00   0,00
    144000000   230400      1250        230400,00   0,00
    144000000   460800      625         460800,00   0,00
    144000000   921600      313         920127,80   -0,16
    144000000   1000000     288         1000000,00  0,00
                                                    
    120000000   9600        25000       9600,00     0,00
    120000000   19200       12500       19200,00    0,00
    120000000   38400       6250        38400,00    0,00
    120000000   57600       4167        57595,39    -0,01
    120000000   115200      2083        115218,43   0,02
    120000000   230400      1042        230326,30   -0,03
    120000000   460800      521         460652,59   -0,03
    120000000   921600      260         923076,92   0,16
    120000000   1000000     240         1000000,00  0,00
                                                    
    96000000    9600        20000       9600,00     0,00
    96000000    19200       10000       19200,00    0,00
    96000000    38400       5000        38400,00    0,00
    96000000    57600       3333        57605,76    0,01
    96000000    115200      1667        115176,96   -0,02
    96000000    230400      833         230492,20   0,04
    96000000    460800      417         460431,65   -0,08
    96000000    921600      208         923076,92   0,16
    96000000    1000000     192         1000000,00  0,00
                                                    
    48000000    9600        10000       9600,00     0,00
    48000000    19200       5000        19200,00    0,00
    48000000    38400       2500        38400,00    0,00
    48000000    57600       1667        57588,48    -0,02
    48000000    115200      833         115246,10   0,04
    48000000    230400      417         230215,83   -0,08
    48000000    460800      208         461538,46   0,16
    48000000    921600      104         923076,92   0,16
    48000000    1000000     96          1000000,00  0,00
                                                    
    24000000    9600        5000        9600,00     0,00
    24000000    19200       2500        19200,00    0,00
    24000000    38400       1250        38400,00    0,00
    24000000    57600       833         57623,05    0,04
    24000000    115200      417         115107,91   -0,08
    24000000    230400      208         230769,23   0,16
    24000000    460800      104         461538,46   0,16
    24000000    921600      52          923076,92   0,16
    24000000    1000000     48          1000000,00  0,00
    Seems to be perfect for all F_CPU :-)

  13. #38
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Quote Originally Posted by PaulStoffregen View Post
    Yes, please do.

    I can't possible look at it until after Maker Faire. When I return next week, there'll probably be a pile of urgent stuff to do before I can work on software. Please understand there'll be a significant delay.
    No problem !
    I closed my previous pullrequest and created a new one,for 144MHz only.

    Frank.

  14. #39
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Quote Originally Posted by Constantin View Post
    Speaking of which, would a 128MHz master clock speed be feasible?
    I don't think so, because we need 48MHz for USB, and there's no divisor for 128.
    How about 144MHz?

  15. #40
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    Quote Originally Posted by Frank B View Post
    I don't think so, because we need 48MHz for USB, and there's no divisor for 128. How about 144MHz?
    I just took another look and there is conflicting information that I don't know how to digest. Here is the background - I am using an PWM pin on the Teensy to produce the clock signal for an analog front end, the MCP3911. So far, the unit has been working just fine with the maximum 12MHz square wave signal that the teensy 3 can produce out of the box. I'm doing this to reduce board space requirements and so I don't have to deal with a crystal, decoupling caps, etc.

    Coming back to 144Mhz for the Teensy 3, that would allow a 18MHz SQW signal to be produced on a PWM pin (144/8). On the one hand, every chart published by MCP shows that the master clock limit is around 20MHz for THD, SINAD, SNR, and so on as long as boost is set to 2x (see datasheet on p. 13 and 14). So if 144MHz were stable/usable, that's like getting a free 50% sampling rate improvement over the current 12MHz signal. I'd love that!

    However, MCP also recommends a ADC clock (AMCLK) no faster than 16MHz (see table 1-1 on p. 5 and table 5-2 on page 32) even with 2x boost enabled. Now, you can set up AMCLK = MCLK/2 for a 18MHz MCLK but the net result is a lower SINAD, lower ENOB, and lower sample production because the net AMCLK is now 9MHz vs. the previous 12MHz and the ADC presumably has fewer results to decimate. So, unless the teensy can be programmed to put out a 32MHz PWM signal (i.e. requiring a 256MHz processor) I guess I'm out of luck.

    All that griping aside, a 120MHz Teensy 3 would allow a 15MHz PWM signal, which gets me an additional 25% samples over the stock 96/48MHz configuration. For free(!!!) I am more than happy with that!
    Last edited by Constantin; 05-14-2014 at 10:03 PM. Reason: added introduction and further analysis

  16. #41
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    I'll have to pull and try this out. I wonder how it would fair with the spi4teensy3 stuff that operates the USB Host Shield.
    IIRC the chip used on it isn't getting hit at the maximum SPI speed yet from the teensy 3.x anyway.
    I have heard that the MAX chip can take more than it is rated at too.
    The main issue I have is that I will need to have USB. Is that working?

  17. #42
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Yes it works.

  18. #43
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    I thought I would let you know that your boards.txt modifications have just helped me harden my Makefile building system.

  19. #44
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    Code:
    /opt/Arduino/libraries/Wire/Wire.cpp:77:2: error: #error "F_BUS must be 48 MHz or 24 MHz"
    Looks like this is the only thing I will need to patch before I can actually do any testing. Shouldn't be too difficult.

  20. #45
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    521
    With F_CPU set to 144000000, there is no speed difference in my test application due to the fact that there is no speed increase in SPI, and the test is basically I/O bound.

    1MB write timing test 2048 writes, (0), (0), 7957 ms (8 sec)
    1MB read timing test 2048 reads, (20), 2367 ms (2 sec)

    If SPI could get sped up a little, then I would see a difference in the test.

    I still have other applications which are a bit more CPU intense. I'll let you know what improvements, if any, are seen.
    The test will have to wait for a few more hours, because I am currently running a test on a Teensy++2 that is using the required resources at this time.

  21. #46
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    Quote Originally Posted by xxxajk View Post
    Code:
    /opt/Arduino/libraries/Wire/Wire.cpp:77:2: error: #error "F_BUS must be 48 MHz or 24 MHz"
    oops. DISLIKE

  22. #47
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,566
    ...in former times, we used formulas for this stuff.

    In the core, it is ok to use F_CPU in this way, but in libs...
    We'd better be off now...don't want to fix the Arduino-Libs :-)

    Pls. use 144MHz *grin*
    Last edited by Frank B; 05-15-2014 at 08:00 PM.

  23. #48
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    Paul, I just downloaded the latest core from github and I'm having problems running my teensy 3.0 at 144MHz. I just uploaded blink and hello world examples and it would run for a couple of seconds then stop, i tried on two different teensy;s. Might want to make that a teensy 3.1 only mode.

    fyi: i set up my T3.0 at 120MHz and it worked like a charm.

  24. #49
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    949
    just to follow up on this, I tried again today and the T3.0 will not work at 144MHz with the latest teensdunio on github. At least i was able to still reprogram it back to 24MHz so i'm good.

  25. #50
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,927
    If you'd like to see 120, 168 or other speeds in version 1.19 (not in the Tools > CPU Speed menu, but support in the code), please submit pull requests now.

Posting Permissions

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