Teensyduino 1.58 Beta #2

One compiler warning I can't find a way to solve is this line in TeensyThreads Tests example:

Code:
  char x[128]; // use up some stack space

Of course this gives an ununsed variable warning.

Adding the usual "__attribute__((used))" just replaces it with a warning that the attribute is ignored. Apparently it can't be used on local variables with gcc 11.3.1.

Does anyone an idea of what to do about this one?
 
Does anyone an idea of what to do about this one?

This works...

Code:
  char x[128]; // use up some stack space
  delay(x[0] = 20); // "use"  x[0] to avoid "unused variable" warning

could also be...

Code:
  int x[128/sizeof(int)]; // use up some stack space
  delay(x[0] = 20); // "use"  x[0] to avoid "unused variable" warning
 
Last edited:
I haven't looked at the source code.... but from the comment "// use up some stack space" it looks like the intent is to do just that.... use up some stack space? It would be wrong to suppress the warning if that is really the intention.
The problem then is that the variable is obviously being optimized away (because it is not being used?). But that is not what is intended.- it is the opposite. Does __attribute__((used)) work for variables? Or perhaps "volatile" and assign a value.. or -O0 for the whole function.

Good night.
 
I haven't looked at the source code...

Optimizations are turned off.

Code:
// turn off optimizations or the optimizer will remove the recursion because
// it is smart enough to know it doesn't do anything
void __attribute__((optimize("O0"))) recursive_thread(int level) {
  if (stack_fault) return;
  char x[128]; // use up some stack space
  delay(20);
  recursive_thread(level+1);
}
 
CMSIS5 DSP version 1.12 + CMSIS 5.9

I figured out how to compile the latest versions to get an updated libarm_cortexM7lfsp_math. This was just a rough cut as I didn't verify I had any of the new functions (guess thats next if anyone is interested). But here are some preliminary comparisons:
Code:
	Time Current	Time Lastest (1-12)	
- arm_mult_f32         -	0.090 us ;	0.092 us ;	// real float32        8
- arm_mult_f32         -	0.393 us ;	0.420 us ;	// real float32       64
- arm_mult_f32         -	1.434 us ;	1.540 us ;	// real float32      256
- arm_mult_f32         -	5.594 us ;	6.020 us ;	// real float32     1024
- arm_mult_q31         -	0.153 us ;	0.183 us ;	// real q31            8
- arm_mult_q31         -	0.737 us ;	1.070 us ;	// real q31           64
- arm_mult_q31         -	2.737 us ;	4.110 us ;	// real q31          256
- arm_mult_q31         -	10.737 us ;	16.271 us ;	// real q31         1024
- arm_mult_q15         -	0.133 us ;	0.152 us ;	// real q15            8
- arm_mult_q15         -	0.694 us ;	0.803 us ;	// real q15           64
- arm_mult_q15         -	2.614 us ;	3.044 us ;	// real q15          256
- arm_mult_q15         -	10.294 us ;	12.004 us ;	// real q15         1024
- arm_sin_cos_f32      -	0.162 us ;	0.170 us ;	// real float32
- arm_sin_cos_q31      -	0.232 us ;	0.178 us ;	// real q31_t
- arm_cfft_radix2_q15  -	4.5 us ;	5.5 us ;	// real q15_t             64
- arm_cfft_radix2_q15  -	21.4 us ;	27.0 us ;	// real q15_t            256
- arm_cfft_radix2_q15  -	101.2 us ;	130.0 us ;	// real q15_t           1024
- arm_cfft_radix4_q15  -	3.0 us ;	2.8 us ;	// real q15_t             64
- arm_cfft_radix4_q15  -	15.6 us ;	14.4 us ;	// real q15_t            256
- arm_cfft_radix4_q15  -	77.4 us ;	70.9 us ;	// real q15_t           1024
- arm_cfft_radix2_q31  -	10.4 us ;	8.7 us ;	// real q31_t             64
- arm_cfft_radix2_q31  -	53.3 us ;	43.9 us ;	// real q31_t            256
- arm_cfft_radix2_q31  -	261.4 us ;	213.8 us ;	// real q31_t           1024
- arm_cfft_radix4_q31  -	5.0 us ;	4.2 us ;	// real q31_t             64
- arm_cfft_radix4_q31  -	28.4 us ;	22.7 us ;	// real q31_t            256
- arm_cfft_radix4_q31  -	147.1 us ;	114.6 us ;	// real q31_t           1024
- arm_cfft_radix2_f32  -	5.3 us ;	5.4 us ;	// real float32_t         64
- arm_cfft_radix2_f32  -	27.0 us ;	27.5 us ;	// real float32_t        256
- arm_cfft_radix2_f32  -	133.0 us ;	135.1 us ;	// real float32_t       1024
- arm_cfft_radix4_f32  -	3.3 us ;	3.2 us ;	// real float32_t         64
- arm_cfft_radix4_f32  -	17.5 us ;	17.1 us ;	// real float32_t        256
- arm_cfft_radix4_f32  -	88.9 us ;	86.2 us ;	// real float32_t       1024
- arm_cfft_q15         -	77.4 us ;	71.2 us ;	// real q15_t           1024
- arm_cfft_q31         -	147.1 us ;	115.9 us ;	// real q31_t           1024
- arm_cfft_f32         -	87.7 us ;	87.0 us ;	// real float32_t       1024

Please note I only updated to 5.5 for some of the files in the core.

Let me know what you all think.
 
Maybe some of these warnings aren't worthwhile and we should have suppress them? The unused variable and variable set but not used warnings in particular come up quite often and rarely mean anything valuable.

I could get behind such a change. The vast majority of warnings I get in my code are either "You never used this variable" or "you set a value to the variable then never read it" both of which I don't really care about. Usually such warnings are do to stubbed out code more than any sort of actual problem. A variable never used or never read is probably there for a reason, such as future coding. I suppose it might be kind of nice to see the warning in that it could remind users of areas they stubbed out and never finished. That can be handy in a project with 4 directories, 60 source files, and tens of thousands of lines of code. In such a case it is easy to lose sight of all the unfinished sections. But, if the goal is to help novices then I really don't think they want to see errors about unused variables. As you said, it isn't actually that valuable to get that warning. Obviously it should be possible to compile in a more pedantic mode but I think by default it may be OK to ignore those two specific warnings.
 
I, personally don't like suppressing warnings by default.

For the use case you mentioned (stubs for future coding), I'd simply declare the objects as [[maybe_unused]] to get rid of the warning and clearly tell the reader of the code that this is intended.
If this would be too much effort I'd disable the relevant warnings in my *.cpp file using #pragma diagnostics ....
E.g. a
Code:
#pragma GCC diagnostic ignored "-Werror=unused-variable]"
at top of your *.cpp file should silence the warning. If used in a header, I'd use
Code:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Werror=unused-variable]"

... header code

#pragma GCC diagnostic pop
To limit the ingore to the header.

Just my 2 cents
 
I, personally don't like suppressing warnings by default.

...
Just my 2 cents

@luni as usual earns my vote, much better logic than here ...

Of the many test sketches posted by defragster - few get typed right the first time - missing this or that. Happy to have annoying warning text to point out whatever typo failure is left from copy paste or failed typing, including an 'unused var' that when on purpose, could be made: // TODO uint32_t fooGen2=42;

That's why the IDE's "Ctrl+T" is known, to find what the compiler chokes on and can't properly express when 'standard formatting' is applied with Ctrl+T, one of the few things customized here in SublimeText is finding that and assigned 'Formatting' to Ctrl+Alt+F.

Annoying warnings can be ignored {except in library code} ... often though in 'user sketch' they may be best handled.
 
I, personally don't like suppressing warnings by default.

Just my 2 cents

Mine too!

Wondering what impact, the Arduino Preferences has:
Screenshot.png

On the Teensy builds? I have not experimented yet to find out.

Thanks for tip about [[maybe_unused]]

@PaulStoffregen - Another possible way to reduce the workload of going through all of those libraries with the new toolchain, is to see if you can reduce the number of libraries that are installed by Teensyduino and/or board manager.

There are I think there is near 100 libraries. How many of these are duplicates of others, which originally needed to have run on a new Teensy, that hopefully the original library now has support for.

And at some point, might be nice to have libraries which are not directly tied to a specific TD release might be installed through the library manager... But that is a different story.
 
Today the Arduino prefs for compiler warnings aren't used. I'm not a fan of the "None" setting, which is the default, so when Arduino added this (years ago) I didn't bother to adopt it for Teensy. I haven't looked recently at how IDE 2.0.0 is handling this.

Eventually I do want to reduce the number of libraries we're packaging. The library set is mostly a matter of old history, from before the Arduino IDE had a library manager, and from the days when almost everyone shipped 8 bit AVR and few library authors would accept patches for 32 bit boards. Today the situation is much better. (except of course for semiconductor shortages & wild changes in delivery schedules, which have again come up over the last few days...)

These last couple days I've sort of run out of enthusiams for fixing the remaining compiler warnings. But there aren't many left. Here's a list of what's left from the perl script finding.

Code:
  teensy2  Adafruit_NeoPixel/examples/buttoncycler/buttoncycler.ino
  teensy2  Adafruit_NeoPixel/examples/RGBWstrandtest/RGBWstrandtest.ino
  teensy2  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy2  Adafruit_VS1053/examples/player_gpiotest/player_gpiotest.ino
  teensy2  Adafruit_VS1053/examples/player_interrupts/player_interrupts.ino
  teensy2  Adafruit_VS1053/examples/player_simple/player_simple.ino
  teensy2  Adafruit_VS1053/examples/record_ogg/record_ogg.ino
  teensy2  Ethernet/examples/BarometricPressureWebServer/BarometricPressureWebServer.ino
  teensy2  SD/examples/SdFat_Usage/SdFat_Usage.ino
  teensy2  SPI/examples/BarometricPressureSensor/BarometricPressureSensor.ino
  teensy2  Tlc5940/examples/BasicAnimations/BasicAnimations.ino
  teensy2  XBee/examples/AtCommand/AtCommand.ino
  teensy2  XBee/examples/RemoteAtCommand/RemoteAtCommand.ino
  teensy2  XBee/examples/Series1_IoSamples/Series1_IoSamples.ino
  teensy2  XBee/examples/Series1_Rx/Series1_Rx.ino
  teensy2  XBee/examples/Series1_Tx/Series1_Tx.ino
  teensy2  XBee/examples/Series2_IoSamples/Series2_IoSamples.ino
  teensy2  XBee/examples/Series2_Rx_Nss/Series2_Rx_Nss.ino
  teensy2  XBee/examples/Series2_Rx/Series2_Rx.ino
  teensy2  XBee/examples/Series2_Sleep/Series2_Sleep.ino
  teensy2  XBee/examples/Series2_Tx/Series2_Tx.ino
  teensy30  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy30  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy31  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy31  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy31  ssd1351/examples/banding/banding.ino
  teensy31  ssd1351/examples/fonts/fonts.ino
  teensy31  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy31  ssd1351/examples/simpletest/simpletest.ino
  teensy35  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy35  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy35  ssd1351/examples/banding/banding.ino
  teensy35  ssd1351/examples/fonts/fonts.ino
  teensy35  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy35  ssd1351/examples/simpletest/simpletest.ino
  teensy36  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensy36  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensy36  FlexCAN/examples/ObjectOrientedCANExtendedIDs/ObjectOrientedCANExtendedIDs.ino
  teensy36  FlexCAN/examples/ObjectOrientedCAN/ObjectOrientedCAN.ino
  teensy36  ssd1351/examples/banding/banding.ino
  teensy36  ssd1351/examples/fonts/fonts.ino
  teensy36  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy36  ssd1351/examples/simpletest/simpletest.ino
  teensy36  USBHost_t36/examples/Joystick/Joystick.ino
  teensy40  FastLED/examples/Pacifica/Pacifica.ino
  teensy40  FNET/examples/FNET_Native_Ethernet/FNET_Native_Ethernet.ino
  teensy40  SdFat/examples/TeensyDmaAdcLogger/TeensyDmaAdcLogger.ino
  teensy40  ssd1351/examples/banding/banding.ino
  teensy40  ssd1351/examples/fonts/fonts.ino
  teensy40  ssd1351/examples/indexedcolors/indexedcolors.ino
  teensy40  ssd1351/examples/simpletest/simpletest.ino
  teensy40  USBHost_t36/examples/Joystick/Joystick.ino
  teensyLC  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensyLC  Adafruit_nRF8001/examples/echoDemo/echoDemo.ino
  teensyLC  FreqCount/examples/Serial_Output_T4/Serial_Output_T4.ino
  teensyMM  SdFat/examples/TeensyDmaAdcLogger/TeensyDmaAdcLogger.ino
  teensypp2  Adafruit_NeoPixel/examples/buttoncycler/buttoncycler.ino
  teensypp2  Adafruit_NeoPixel/examples/RGBWstrandtest/RGBWstrandtest.ino
  teensypp2  Adafruit_nRF8001/examples/callbackEcho/callbackEcho.ino
  teensypp2  Adafruit_VS1053/examples/player_gpiotest/player_gpiotest.ino
  teensypp2  Adafruit_VS1053/examples/player_interrupts/player_interrupts.ino
  teensypp2  Adafruit_VS1053/examples/player_simple/player_simple.ino
  teensypp2  Adafruit_VS1053/examples/record_ogg/record_ogg.ino
  teensypp2  Ethernet/examples/BarometricPressureWebServer/BarometricPressureWebServer.ino
  teensypp2  SD/examples/SdFat_Usage/SdFat_Usage.ino
  teensypp2  SPI/examples/BarometricPressureSensor/BarometricPressureSensor.ino
  teensypp2  Tlc5940/examples/BasicAnimations/BasicAnimations.ino
  teensypp2  XBee/examples/AtCommand/AtCommand.ino
  teensypp2  XBee/examples/RemoteAtCommand/RemoteAtCommand.ino
  teensypp2  XBee/examples/Series1_IoSamples/Series1_IoSamples.ino
  teensypp2  XBee/examples/Series1_Rx/Series1_Rx.ino
  teensypp2  XBee/examples/Series1_Tx/Series1_Tx.ino
  teensypp2  XBee/examples/Series2_IoSamples/Series2_IoSamples.ino
  teensypp2  XBee/examples/Series2_Rx_Nss/Series2_Rx_Nss.ino
  teensypp2  XBee/examples/Series2_Rx/Series2_Rx.ino
  teensypp2  XBee/examples/Series2_Sleep/Series2_Sleep.ino
  teensypp2  XBee/examples/Series2_Tx/Series2_Tx.ino

Over half this list is Teensy 2.0 and Teensy++ 2.0 which are now discontinued. More are seldom-used libraries like Adafruit_nRF8001. Would be nice to clean this last part up, but just doesn't feel as important.
 
... CMSIS is not slow but just wrong...

BUG Report:
.....

Output:
Code:
6.28
-0.00

CMSIS fixes are on Github, for example here: https://github.com/ARM-software/CMSIS_5/pull/439

Even if CMSIS is low piority.. nowbody wants wong basic functions ;-)
It might be also worth checking all the other libraries that come with TD if there are newer version or bug fixes. Also, some "warnings" could have been fixed long ago in newer versions, may be. Could even save some time!

And why don't you just update the whole CMSIS? Can't take more than 2-3 hours.
I'm afraid most will agree that such an old CMSIS version is not a good flagship. Stating "Low Priority" does not help.

I am getting 0 for both with the updated library.
Test Data:
Code:
const float32_t testInput_f32[MAX_BLOCKSIZE] =
{
  -1.570795,  -4.793533929171324800,   0.360705030233248850,   0.827929644170887320,  -3.299532218312426900,   3.427441903227623800,   3.422401784294607700,  -0.108308165334010680,
   0.941943896490312180,   0.502609575000365850,  -0.537345278736373500,   2.088817392965764500,  -1.693168684143455700,   6.283185307179590700,  -0.392545884746175080,   0.327893095115825040,
   3.070147440456292300,   0.170611405884662230,  -0.275275082396073010,  -2.395492805446796300,   0.847311163536506600,  -3.845517018083148800,   2.055818378415868300,   4.672594161978930800,
  -1.990923030266425800,   2.469305197656249500,   3.609002606064021000,  -4.586736582331667500,  -4.147080139136136300,   1.643756718868359500,  -1.150866392366494800,   1.570795
};

Output:
Code:
cos: 0.000001, sin: -1.000000
cos: 0.081054, sin: 0.996692
cos: 0.935631, sin: 0.352928
cos: 0.676389, sin: 0.736519
cos: -0.987545, sin: 0.157282
cos: -0.959408, sin: -0.281968
cos: -0.960824, sin: -0.277131
cos: 0.994130, sin: -0.108095
cos: 0.588209, sin: 0.808692
cos: 0.876326, sin: 0.481712
cos: 0.859060, sin: -0.511851
cos: -0.495156, sin: 0.868790
cos: -0.122067, sin: -0.992520
cos: 1.000000, sin: 0.000000
cos: 0.923937, sin: -0.382542
cos: 0.946709, sin: 0.322044
cos: -0.997438, sin: 0.071384
cos: 0.985475, sin: 0.169784
cos: 0.962333, sin: -0.271807
cos: -0.734333, sin: -0.678772
cos: 0.661999, sin: 0.749501
cos: -0.762295, sin: 0.647203
cos: -0.466219, sin: 0.884648
cos: -0.039784, sin: -0.999194
cos: -0.407870, sin: -0.913025
cos: -0.782389, sin: 0.622769
cos: -0.892733, sin: -0.450573
cos: -0.125320, sin: 0.992103
cos: -0.535675, sin: 0.844419
cos: -0.072895, sin: 0.997336
cos: 0.407691, sin: -0.913106
cos: 0.000001, sin: 1.000000
 
I am getting 0 for both with the updated library.

0 is the correct value. In Mcu32's test program he uses the hex value 0xbfc90fdc and labels it as -pi/2, but this is actually one lsb away from -pi/2 (0xbfc90fdb), and that is what triggers the bug. The version of CMSIS in Teensy now returns the correct value for _exactly_ -pi/2, but returns an incorrect value for his test value. If you haven't run his test program, you should, just to make sure that the new CMSIS does fix the error for values just slightly off of -pi/2.
 
0 is the correct value. In Mcu32's test program he uses the hex value 0xbfc90fdc and labels it as -pi/2, but this is actually one lsb away from -pi/2 (0xbfc90fdb), and that is what triggers the bug. The version of CMSIS in Teensy now returns the correct value for _exactly_ -pi/2, but returns an incorrect value for his test value. If you haven't run his test program, you should, just to make sure that the new CMSIS does fix the error for values just slightly off of -pi/2.

Just as a futher update I did run @Mcu32's test sketch and yes it returned 0 for both vaules.
 
0 is the correct value. In Mcu32's test program he uses the hex value 0xbfc90fdc and labels it as -pi/2, but this is actually one lsb away from -pi/2 (0xbfc90fdb), and that is what triggers the bug. The version of CMSIS in Teensy now returns the correct value for _exactly_ -pi/2, but returns an incorrect value for his test value. If you haven't run his test program, you should, just to make sure that the new CMSIS does fix the error for values just slightly off of -pi/2.

As you know the result should be very near zero. not 6.xxx. It's totally irrelevant that it's one lsb away.
Just as info, i took the value from a cmsis bugreport, it's not mine :)

sin has a similar bug.

For HAM Radio etc it is very important that trigonomic function return correct values. You'll have suboptimal results otherwise.
Not to speak about the other improvements.

p.s. feel free to search github closed issues & closed PRs for more.
 
Last edited:
Today the Arduino prefs for compiler warnings aren't used. I'm not a fan of the "None" setting, which is the default, so when Arduino added this (years ago) I didn't bother to adopt it for Teensy. I haven't looked recently at how IDE 2.0.0 is handling this.

These last couple days I've sort of run out of enthusiams for fixing the remaining compiler warnings. But there aren't many left. Here's a list of what's left from the perl script finding.
<snip>
Over half this list is Teensy 2.0 and Teensy++ 2.0 which are now discontinued. More are seldom-used libraries like Adafruit_nRF8001. Would be nice to clean this last part up, but just doesn't feel as important.

100% agree - warnings are relevant. In Real Life writing medical device software, we configure compilers such that all warnings are errors, so you can't even test code until there are zero warnings.

I can probably take a look at (at least some of) the list, if you like - there seems to be quite a lot of duplication in it. I can't test on real hardware for most of them, but from the couple I've tried it's pretty clear what the issue is and how to fix it.
 
It's totally irrelevant that it's one lsb away. sin has a similar bug..

The bug occurs when the argument to sin() is very close to 0 or when the argument to cos() is very close to -pi/2. There is no error when the arguments are exactly 0 and -pi/2, respectively. The test program uses one LSB to show that a very small difference from -pi/2 causes the error. I don't think I would say the one LSB example is totally irrelevant, since the error only occurs for small deviations from sin(0) and cos(-pi/2).

The error occurs for both cos() and sin() because they share a table and lookup logic based on the trig identity sin(x) = cos(x-pi/2)
 
Last edited:
On a positive note, I'm pretty impressed by the error messages I'm getting from the new GCC toolchain. When you misspell a function name or provide an incorrect argument, it provides suggestions for the required fix, and in most cases they have been correct.
 
On a positive note, I'm pretty impressed by the error messages I'm getting from the new GCC toolchain. When you misspell a function name or provide an incorrect argument, it provides suggestions for the required fix, and in most cases they have been correct.

You mistype better than I do :) - Seems I've seen a few off the wall suggestions. But the meaning was clear if the suggestion directly wasn't helpful.
 
On it now, but Paul's github doesn't seem to have a fork of the XBee library - not sure how to proceed with that one, I'll skip it for the time being.

Was actually going to look at the XBEE library today - but that funny - I could have sworn it was there there that last time I was up there?
 
Back
Top