Teensy 3.1 overclock to 168MHz

You can pull it from my Github, it's already there.
Or, i can submit the pullrequest this evening, when i'm back home.
 
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.
I forked your core to do pulll request but the deeper i delved into enabling 120MHz i realized my previous comment on this post that having F_BUS not at 24 or 48MHz is real pain. Yes you can get the core to work but SPIFIFO and ADC config bits assume that having different F_BUS are fine and any library using F_BUS would not be affected with a "non standard" F_BUS speed.

Also if you enable 120MHz your Audio library and I'm sure many more would have to be updated.
 
Have to tried F_BUS at 60 MHz.

Yeah, I know pretty much nothing supports it yet, but if 60 MHz is stable, it could be really nice for programs needing faster I/O.
 
Have to tried F_BUS at 60 MHz.

Yeah, I know pretty much nothing supports it yet, but if 60 MHz is stable, it could be really nice for programs needing faster I/O.

No, but i can try it tomorrow.

Github is driving me.... i tried to do a pullrequest, but github shows only two changed files. This is not correct... :-(
 
Paul, speaking of the upcoming rc-1, Don't forget the patch to the java bits that gives more flash... http://forum.pjrc.com/threads/25196-How-to-get-a-little-bit-more-FLASH-room-on-Teensy-3-x

I'm going to merge this into 1.20.

1.19 will only have updates in the core library, but no changes in the java IDE or toolchain.

1.19 will have 72 MHz added in the Tools > CPU Speed menu, and definitions internally for 120, 144 & 168 MHz, but you'll have to edit boards.txt to enable them.
 
Is the following a PJRC Java IDE issue or that goes to the Arduino committees....

In other IDEs, the serial monitor window can stay open despite downloads on a USB/Serial adapter and an on-board USB like the Teensy 3 has.
It is so nice to not have to reopen the serial monitor over and over, with these other IDEs, e.g., Atmel Studio w/Visual Micro (VS/VM) - where I often have 4 serial monitors going at one, displayed as paned windows. Each window monitors for USB "unplugged" and "re-plugged". We see serial monitor messages like "Port no longer available" and "Port is now open", all automatically done. The Serial monitor windows stay open.
Also.. when switching IDE board types in VS/VM, the Serial monitor windows don't abruptly close due to this change in the IDE compiler settings (nothing to do with serial monitor), but Arduino's IDE closes the serial monitor window for innocuous reasons.
 
Last edited:
Stevech,

i use teensy_gateway.exe and putty as workaround. Works perfect, so i need no serial monitor.
ou're right, the usb-serial connection is a pain.

Paul, thank you for the great solution with teensy_gateway. It's a way to "speak" with the teensy over network, too.
 
Last edited:
Later this year I'm going to switch to 1.5.7 (or whatever version Arduino is up to...) and make a number of these improvements.
 
Stevech,

i use teensy_gateway.exe and putty as workaround. Works perfect, so i need no serial monitor.
ou're right, the usb-serial connection is a pain.

Paul, thank you for the great solution with teensy_gateway. It's a way to "speak" with the teensy over network, too.
I've very happy with the serial monitor scheme in Atmel Studio/VM. Multiple connections, ever-present serial window, integrated with the IDE. Very nice. Good complement to a great IDE.
Targets Teensy 3 and AVR easily with the change to boards.txt.
 
Last edited:
I installed Atmel studio some days ago, but had no much time to test.

Which files must be (how) changed to use it with Teensy 3 ? Can you help me with that ?
Or, is there a "howto" ?
 
I installed Atmel studio some days ago, but had no much time to test.

Which files must be (how) changed to use it with Teensy 3 ? Can you help me with that ?
Or, is there a "howto" ?
You already have Arduino 1.0x installed, I assume.
Install Atmel Studio 6.1. I've not used beta 6.2
Install Visual Micro. It's free. The debugger is an optional shareware. You can procrastinate that.
Take all the defaults for these.

For more automation of switching board types from AVR to Teensy:
In the installation directory for Arduino 1.0x and in the teensy directory for teensy, edit the boards.txt file with an editor that copes with no CR's like Programmer's Notepad.
The path may be: C:\Arduino\hardware\teensy\boards.txt
Add these to the Teensy 3.1 section
teensy31.build.option5=-DF_CPU=96000000
teensy31.build.option6=-DUSB_SERIAL
teensy31.build.option7=-DLAYOUT_US_ENGLISH

Add these to the Teensy 3.0 section
teensy3.build.option5=-DF_CPU=96000000
teensy3.build.option6=-DUSB_SERIAL
teensy3.build.option7=-DLAYOUT_US_ENGLISH

save, restart

(I haven't worked with Teensy 2 with Studio and VM).

Takes some learning to use this.
Some quick notes
Visual Micro adds a new toolbar, 3rd down. You'll find Teensy boards among the choices. Same toolbar, you'll see the COM ports for Teensy and AVR. You can choose one, click the PC icon and a new window opens for that COM.
You can drag the terminal window and drop it to pane it into the other windows. You can open more serial monitor COM ports and add that window to the other, and stack them paned rather than floating. These terminal windows will
stay put despite changing board types, downloading, etc.

Use the FILE menu, and NEW and "sketch" for a new project that's Arduino/Teensyduino specific.
It'll open and use a .ino file.
It has the "solution" concept where you may have multiple projects in one work session. I don't use that.
I do use the same source code file but change the target board type, compile, download. Jump back and forth between board types. I run 4 boards at once in my wireless work.

The editor in Studio is great. Right-click to lookup functions, refactor names. Click on a function that you're calling then use the "goto" button to jump to the file and line where that's implemented. And so many more.
Productivity increased 1000% versus a dumb editor.

I've used Eclipse too, but it's not well done for the Teensy. Same, Codeblocks.

much more on the visual micro website
 
Last edited:
That was easy ! Thank you !!!

i also added

teensy31.build.option8=-g3
teensy31.build.option9=-O2
teensy31.build.option10=-finline-functions
teensy31.build.option11=-funswitch-loops

Which toolchain is used ? The one from teensyduino or atmel ?
 
Here are some benchmarks i did (120 MHz - 2MHz) on the Teensy 3.0 with the latest core from github. Don't have T3.1 with me. I used this sketch: View attachment speedTest.ino

Screen Shot 2014-05-30 at 9.19.45 PM.pngScreen Shot 2014-05-30 at 9.19.59 PM.pngScreen Shot 2014-05-30 at 9.20.07 PM.pngScreen Shot 2014-05-30 at 9.20.16 PM.png

I'm doing some power measurements also I'll post them when I'm done.
 
Last edited:
Here are some benchmarks i did (120 MHz - 2MHz) on the Teensy 3.0 with the latest core from github. Don't have T3.1 with me. I used this sketch: View attachment 2141

View attachment 2142View attachment 2143View attachment 2144View attachment 2145

I'm doing some power measurements also I'll post them when I'm done.

Cool Stuff.

but I'am not sure if "PORTB |= _BV(PORTB5);" is the fastest way for the Teensy 3 /3.1 to toggle an Pin may Paul can light us up about this.
 
but I'am not sure if "PORTB |= _BV(PORTB5);" is the fastest way for the Teensy 3 /3.1 to toggle an Pin may Paul can light us up about this.

The fastest way is always this:

Code:
  digitalWriteFast(5, HIGH);
  digitalWriteFast(5, LOW);

When the pin number and logic state are compile-time constants, this always compiles to a single write operation. It's always the fastest possible way, exactly the same as if you'd put the raw registers right into your code.

On ARM, all writes are through pointers, so this may involve multiple instructions, where 1 does the actual write and others load the registers with the I/O register address and constants. The compiler is actually pretty crafty about optimizing those other instructions outside of loops, if you're not calling other functions or doing stuff that consumes all the registers. However, the speed can vary, depending on the surrounding code, which is different from AVR where a dedicated instruction always takes exactly 2 cycles for bitwise manipulation pf the I/O registers.

Using "PORTB |= _BV(PORTB5);" goes through avr_emulation.h, which compiles to digitalWriteFast(), but also some extra code which checks if the pin is configured for input mode and emulates the AVR pullup resistor. The pullup resistor emulation is relatively slow, but necessary to faithfully emulate the AVR register behavior.
 
Cool Stuff.
but I'am not sure if "PORTB |= _BV(PORTB5);" is the fastest way for the Teensy 3 /3.1 to toggle an Pin may Paul can light us up about this.

Ya I know, i didn't optimize anything for the teensy. I thought it would be nice to see the actual code speed regardless if it is the fastest way.

I especially like the -0.158 us second delay we can get at 2 MHz! Anyway, thanks for the table!
Thats because a delay of 1 micro sec at 2MHz does not work. You will have to dig into the code to see but 2 MHz is truly limited in performance but reduces power substantially!
 
One awesome thing I discovered while testing is the UART high-res baud rate feature allows 115200 baud, even when running at only 2 MHz.
 
Back
Top