Teensyduino 1.21 Features

MichaelMeissner said:
The syntax is without the - sign:

Code: 
#pragma GCC optimize ("O2")

Thank you for your detailed explanations. It is very informative and interesting !
I played a bit with that, and got the following error:
Code: 
Arduino: 1.0.6 + Td: 1.21-test1 (Windows 7), Board: "Teensy 3.1"
C:\Arduino\hardware\tools\arm\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=120 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_RAWHID -DLAYOUT_US_ENGLISH -Os -IC:\Arduino\hardware\teensy\cores\teensy3 -IC:\Arduino\libraries\Audio -IC:\Arduino\libraries\Wire -IC:\Arduino\libraries\SPI -IC:\Arduino\libraries\SD C:\Users\Frank\AppData\Local\Temp\build3217826331405170921.tmp\WavFilePlayer.cpp -o C:\Users\Frank\AppData\Local\Temp\build3217826331405170921.tmp\WavFilePlayer.cpp.o 

In file included from C:\Arduino\libraries\Audio/Audio.h:37:0,
                 from WavFilePlayer.ino:11:
C:\Arduino\hardware\teensy\cores\teensy3/DMAChannel.h: In member function 'void DMAChannel::attachInterrupt(void (*)())':
C:\Arduino\hardware\teensy\cores\teensy3/DMAChannel.h:480:43: error: invalid conversion from 'void (*)()' to 'void (*)()' [-fpermissive]
   _VectorsRam[channel + IRQ_DMA_CH0 + 16] = isr;                                           ^

This occurs, when #pragma GCC optimize ("O2") is used as the very first line of the sketch. I stripped it down to the following:
Code: 
#pragma GCC optimize ("O2")
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>

void setup() {
}

void loop() {
}

invalid conversion from 'void (*)()' to 'void (*)()' sounds a bit strange...
Note when i use -O2 as parameter instead, all is ok.
I get then same message "invalid conversion from 'void (*)()' to 'void (*)()'" in my own code at a place where i use a function pointer to set an entry in the vectorTable when using this pragma.

Edit:The Table is: void (* _VectorsRam[NVIC_NUM_INTERRUPTS+16])(void);
The function is: void func(void)

p.s. i know the "hot" functions of the codecs, but that are nearly all... ;-). thats why i tried pragma.
I will try __attribute__ now.
Click to expand...
 
Last edited:
This works (??!!) :confused: - no errormessages.
Code: 
#pragma GCC optimize ("O2")

void isr(void){
}

void setup() {
 _VectorsRam[110] = isr; 
}

void loop() {
}
 
I have tried __attribute__((optimize("O2"))), (and, because i was unsure about the syntax, __attribute__((optimize(2)). I tried the "HOT" attribute too.

The compiled result is a bit larger, but not really faster. Because i saw no difference, i used this for nearly every function (..it's ~100KB compiled code :) ). Still no difference.
With -O2 at commandline, for example the mp3-Codec is 4%-10% faster per audioframe (depends on the contents). -> huge difference :)
The codecs are not using any "teensy-core"-functions or other calls to not-optimized funtions outside. Most is pure calculation.

I am sure that I overlooked something ... what could it be ? :)
 
I don't know. Somebody is going to have to disassemble the code to see what the compiler is doing. If you modify the options (like to set -O2), you can add the -save-temps=obj option, and the compiler will drop .s and .ii files in your object directory. The .s file is the file that will be fed into the assembler and the .ii file is the file after preprocessing.

Note, in terms of speed, you may be wanting to think about higher level options, rather than just -O2, such as:
  • -O3: add auto-inline, auto-vectorization, and some loop optimizations;
  • -funroll-loops: do loops unrolled (do the loop body multiple times to avoid loop overhead);
  • -ffast-math: If you were doing heavy floating point and the Teensy had hardware FP support, this option tells the compiler to ignore some corner cases (like negative 0, infinity, denorms, and NaNs);
  • -flto: do whole program analysis (note, this may or may not work in the embedded environment) -- ideally you want 4.9.x, but 4.8.x may be stable for -flto.

While I can point to you things, I don't have the time or desire to look at a second GCC backend for a hobby project. I've also never looked at the ARM instruction set in detail -- I may have scanned it a few years ago in another job, but when you've dealt with 20+ architectures over the years, I find the details get all jumbled together, and I only really keep the architecture I'm currently working on in my head. Also, selecting the right options is somewhat of a black art, and sometimes what works for one piece of code is slow for another.
 
Last edited:
MichaelMeissner said:
I don't know. Somebody is going to have to disassemble the code to see what the compiler is doing. If you modify the options (like to set -O2), you can add the -save-temps=obj option, and the compiler will drop .s and .ii files in your object directory. The .s file is the file that will be fed into the assembler and the .ii file is the file after preprocessing.

Note, in terms of speed, you may be wanting to think about higher level options, rather than just -O2, such as:
  • -O3: add auto-inline, auto-vectorization, and some loop optimizations;
  • -funroll-loops: do loops unrolled (do the loop body multiple times to avoid loop overhead);
  • -ffast-math: If you were doing heavy floating point and the Teensy had hardware FP support, this option tells the compiler to ignore some corner cases (like negative 0, infinity, denorms, and NaNs);
  • -flto: do whole program analysis (note, this may or may not work in the embedded environment) -- ideally you want 4.9.x, but 4.8.x may be stable for -flto.

While I can point to you things, I don't have the time or desire to look at a second GCC backend for a hobby project. I've also never looked at the ARM instruction set in detail -- I may have scanned it a few years ago in another job, but when you've dealt with 20+ architectures over the years, I find the details get all jumbled together, and I only really keep the architecture I'm currently working on in my head. Also, selecting the right options is somewhat of a black art, and sometimes what works for one piece of code is slow for another.
Click to expand...

Hi,

yes i know about these switches, and used them in the past. Unfortunately i want the codecs to be used as library for other users, and telling them "use this commandline-switches" is not practical. You have to modify a file in teensyduino.
Okay, maybe using Pragma is not ideal too.
By the way -flto does not work the linker gives an error.
Just for fun (i don't believe that it has benefit for the teensy, but wanted to give it a try), i tried the new ARM-switch -mslow-flash-data. It shows the same error (I don't remeber excactly, something with "can't move location pointer backwards").
Unimportant, that's not a showstopper.


Do you think the behavior in Post #26 is a bug ? Only if you add the #pragma,this error is shown. Not with -Os, O2 or -O3.
@Paul: Is there any special reason for -Os ? We have a LOT space in the teensy 3.x.. :) and for my 100kb-project, the codesize grows less than 10 KB (with -O2).
 
Last edited:
Hey Paul.......how about an update to the ILI9341_t3 library that would include larger and
smoother looking fonts for TD 1.21 ?
 
In terms of post #26, yeah it may some sort of weird interaction between C++ and the include files that the IDE puts in before the first line of the source file with the #pragma's. Maybe declare the one function that is causing problems to be -Os instead of -O2.

There are some in the GCC community that wish the optimize feature had not gone in, because it does expose a lot of corner cases, and as I said, as more of the optimizations are being moved earlier to trees and SSA passes instead of RTL, it makes it problematic. My original proposal on the subject was just to add the target options as attributes (which are only provided by 3 backends -- x86, powerpc, and nios) as attributes, but I did have some people from the embedded community asking for at least hot/cold attributes for space savings, which is where the optimize attribute came from. And then later pragmas were added.
 
It seems, that this is not related to Arduino..
Try this "Sketch":
Code: 
#pragma GCC optimize ("O2")
#ifdef __OPTIMIZE_SIZE__
#error help!
#endif
(-Os ist standard with Arduino)

...it prints "help!"
This Bug was reported 2011-03-07: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026 (i modified the example a bit)
List of predefined macros: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Without Arduino:
Code: 
C:\temp>C:\temp\gcc-arm-none-eabi-4_8-2014q3-20140805-win32\bin\arm-none-eabi-gcc -Os -S bug.c

C:\temp>C:\temp\gcc-arm-none-eabi-4_8-2014q3-20140805-win32\bin\arm-none-eabi-g++ -Os -S bug.c
bug.c:3:2: error: #error help!
 #error help!
  ^

#pragma GCC optimize ("O2") does "something", but not optimizing for speed. This explains my results.

Just for info!

Regards,
Frank
 
Last edited:
What do you think, is there a chance that a self-defined macro, with "__attribute__ " which lists all the -O2 options (see this list) could help ?
One could use it for the "hot" functions.
 
Unfortunately, the problem is there are a few optimizations that are controlled only by the number, and whether we are doing space/speed optimizations. For those, there is not a separate -f option.

You can get a list of what options are enabled with -O2, etc. by using the -fverbose-asm and -save-temps=obj option, and it will list out the switches in the comments. Obviously, the list of switches changes from release to release.

For the target options on both the x86 and powerpc, we do change at least some of the macros when you use pragma GCC target. As I said, a lot of the GCC developers don't like #pragma GCC optimize, so I'm not sure there is any will to get it changed. With the benefit of hindsight, I think adding all of the separate -f options was overkill and causes a lot of problems.
 
Last edited:
#pragma GCC diagnostic ignored "-fpermissive" is ignored too.
g++ has a BIG #pragma problem...

just for info ! :)
 
Hi, Teensyduino 1.20 and 1.21 with the same installation error. changed directory, but not resolved.
What can be? Thanks
error-teensyduino121.jpg
 
Make sure Arduino is not running while you're trying to change it.

Temporarily disable your anti-virus or security software, which might be interfering with the installer's ability to modify another program. The installer never uses any network connectivity, so you can disconnect your network cable while anti-virus is disabled.

Since this is Windows, always try rebooting!
 
PaulStoffregen said:
Make sure Arduino is not running while you're trying to change it.

Temporarily disable your anti-virus or security software, which might be interfering with the installer's ability to modify another program. The installer never uses any network connectivity, so you can disconnect your network cable while anti-virus is disabled.

Since this is Windows, always try rebooting!
Click to expand...

Yes, I disabled Avira and disconnected from the Internet and installed normally. Thank
 
I'd like to make sure FastLED gets updated to 3.0.3 in Teensyduino 1.21. The current version 2.x included with Teensyduino doesn't have support for SmartMatrix, and we have to ask users to navigate into their Arduino/libraries directory to delete FastLED if they installed it through Teensyduino.

I'd also really like to see a fix to the RobotIRremote and IRremote conflict. I can think of a few solutions:

- Rename the IRremote library's header (e.g. IRremote2.h) - Likely to cause confusion with existing sketches and users that install IRremote manually, not through Teensyduino

- Delete the RobotIRremote folder if IRremote is checked to be installed with Teensyduino - what if the user still needs RobotIRremote for their non-teensy sketches? (Do they? I don't know if IRremote is a good substitute for RobotIRremote) This doesn't help users installing the library manually

- Ask Arduino to rename the RobotIRremote library header (maybe RobotIRremote.h?) - unlikely to happen and won't be timed with Teensyduino 1.21

None of these are perfect solutions. If IRremote is a good substitution for RobotIRremote, then deleting RobotIRremote after installing IRremote is probably the best solution for users that want to install IRremote with Teensyduino, but still doesn't help users that want to install it manually.
 
Since then, the 1.21 test versions have switched to a new C library, which (probably) has a different malloc.

I honestly have no idea if it's any better than the old one. Any chance you could give it a try?

The latest and best version is on the Teensy-LC beta test. Testing malloc on Teensy 3.1 should be fine.
 
PaulStoffregen said:
Any chance you could give it a try?
Click to expand...

I just gave it a try, and unfortunately, the exact same problem still occurred. All three code snippets I posted in that old thread still misbehaved in exactly the same way.

This was with Teensyduino 1.21-test4, installed over a fresh installation of Arduino 1.0.6 on Windows, using a Teensy 3.1.

This bug is top of my wish-list!
 
You must log in or register to reply here.
Back
Top