Teensyduino 1.20 Released

Status
Not open for further replies.
The uploader works as it should now on Linux too. I think Paul nailed the problem finally.
 
Fastrun

I need help with the new "FASTRUN" Feature, how can i use it ?
Could you please provide an example ?
 
Here's an example. A rather silly one, since you'd want to use FASTRUN on functions that matter for performance.

Code: 
FASTRUN void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Sometimes FASTRUN can help a lot, especially when running at faster clock speeds (eg, overclocking stuff that's disabled by default in boards.txt), but more often than not it gives little to no benefit, for a lot of extra RAM usage, when used on functions that don't matter for performance.
 
Thank you!

Different topic: While experementing with GCC 4.8.3, i got this warning:
Code: 
C:\Arduino\libraries\Audio\effect_fade.cpp:31:22: warning: type of 'fader_table' does not match original declaration [enabled by default]
 extern const int16_t fader_table[256];
                      ^
C:\Arduino\libraries\Audio\data_waveforms.c:81:15: note: previously declared here
 const int16_t fader_table[257] = {
 
PaulStoffregen said:
Here's an example. A rather silly one, since you'd want to use FASTRUN on functions that matter for performance.

Code: 
FASTRUN void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Sometimes FASTRUN can help a lot, especially when running at faster clock speeds (eg, overclocking stuff that's disabled by default in boards.txt), but more often than not it gives little to no benefit, for a lot of extra RAM usage, when used on functions that don't matter for performance.
Click to expand...

Thanks for the example. How does it make things faster, inlining to avoid call and return overhead?
 
Nantonos said:
Thanks for the example. How does it make things faster, inlining to avoid call and return overhead?
Click to expand...
No, the FASTRUN macro uses an __attribute__ to put the code for the function into the .fastrun data section, instead of the the .text section. The linker script puts the .fastrun section into the read/write SRAM instead of the read-only FLASH memory that normally the code goes into. I would imagine the trade off is SRAM is much faster to reference, but by using it, you have less data for your data. Because it is in read/write memory, you also run the risk of something that writes outside of its bounds changing the code.
 
In the new SPI library in 1.20, is it possible to change
Code: 
#elif defined(__arm__) && defined(TEENSYDUINO)
to this?
Code: 
#elif defined(__arm__) && defined(CORE_TEENSY)

I'm running sublime text 3 with the Stino plugin, and for some reason, TEENSYDUINO is not defined, but CORE_TEENSY is.
In the previous version of the SPI libraries, CORE_TEENSY is used instead of TEENSYDUINO.

Otherwise, upon compiling, the whole section for the Teensy 3.x is not used and I get all these errors with SPIClass is not defined etc.

I have manually changed this, but it'd be great if it could be added to the next release.

Thanks.
 
Last edited:
Hey Paul, Any chance of bundling the teensy_loader_cli under hardware/tools/ ?? This would be very handy.
 
I don't know what the compiler would do, but inlining a "FASTRUN"-Function (which means that it should run in the RAM) to code which is in the FLASH would be pretty obscure...
 
This is the definition:
Code: 
 #define FASTRUN __attribute__ ((section(".fastrun"), noinline, noclone ))
You'll notice the "noinline" :)
 
Status
Not open for further replies.
Back
Top