Teensyduino 1.58 Beta #2

What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.
He says which in Post #24.
 
He isn’t clear about which TD he used with 1.8.19, and my point was that the size change goes with TD version, not with IDE version.
 
I´ve used version 1.58 beta 2.
Paul mentioned to switch to 1.57, which more or less gave me the same storage amount needed like in IDE 1.8.19.

IDE 1.8.19
141 296 bytes program storage space
42476 bytes dynamic memory


IDE 2.0 + 1.57
140 848 bytes
42476 bytes

IDE 2.0 + 1.58 beta 2
151 376 bytes
42552 bytes
Isn't the above clear?
 
What version of TeensyDuino are you using with IDE 1.8.19? So far in my own testing (only with 1.57), I get identical hex files with IDE 1.8.19 and IDE 2.0.0.

The latest :) In arduino IDE 1.8.19 i used 1.57
Yes with 1.57 in IDE 2.0 I get approx the same memory amount, like i showed ;)
 
This:
Not quite. Again, my point is the IDE doesn’t matter. Hex file is determined by source code (sketch, TD, libraries) and build tools, not by IDE version, as far as I know.

The tool chain update in beta TD 1.58 is showing larger CODE space usage than prior TD 1.57 with the current faster compile/link options.

Some sketches are 20-25% larger ... noted this on the beta 1 thread IIRC
 
Not quite. Again, my point is the IDE doesn’t matter. Hex file is determined by source code (sketch, TD, libraries) and build tools, not by IDE version, as far as I know.

...and the selected optimization settings.
If you choose "O2", which is the default setting, the code is not optimized for size. This means that for the generated code, speed has a higher priority than size. So it's perfectly fine if the compiler generates code that takes up more space. It has no instructions to care about size.
-> if code size is important, you should use "Optimize for size".

On the other hand, your code has to be *really* big before size becomes important.... you can't buy anything for unused flash cells.

Translated with www.DeepL.com/Translator (free version)
 
Larger size could be due to the new compiler applying more optimizations for speed.

But it could also be other reasons, like "unused" code being linked into the final .elf file. Really needs more investigation to know the real reason.
 
If you compare different TD versions here, maybe the libraries used just got bigger or compile to more code.
- or builtin libs (libc ,libm etc) are the reason.

Or it's all reasons together :)
 
In the midst of all this talk about what may be happening, I just want to say I really appreciate that @degu234 posted a test case in msg #24. Theories about the code size increase can be valuable too, but they don't enable any sort of investigation. Specific test cases are the key to doing more than just guesswork. I do intend to look into the code size increase, but it's not my top priority right now.

At this moment I'm still going through compiler warning the perl script found. Library with a large number of examples tend to repeat the same warning over and over, so it's a slow tedious process of fixing those first, the re-running the (painfully slow) script again and again. Maybe I should convert it to Arduino CLI....
 
RadioHead/RH_RF24.cpp has compiler warning "'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]" when compiled for Teensy LC. May be a sign of a bug with ATOMIC_BLOCK_START / ATOMIC_BLOCK_END on Teensy LC. Will dig into this later... this message is mostly just a reminder to future me to check ATOMIC_BLOCK macros on Teensy LC.
 
I do intend to look into the code size increase
yes, fixing bugs is undoubtedly more useful. Then, warnings.
i.e. When will the cmsis bugs be fixed? The "sin" there is painful slow, because of a bug, for many years now :(
 
i.e. When will the cmsis bugs be fixed? The "sin" there is painful slow, because of a bug, for many years now :(

This isn't even on my list. Has it been previously reported with a reproducible test case?

CMSIS API is also a low priority. A huge backlog of far more important things are pending. Even with a test case, CMSIS stuff probably isn't going to get any updates for a very long time, maybe not ever. But no test case means it doesn't even go onto the low priority list.
 
Ah... my memory lied... it was not cmsis but the normal newlib.
sinf() was the problem.
Yes of course there were reports - they should all be in this forum. Several. Unfortunately I can't find them via search.
But that the newlib had also changed, the error should now be magically settled.
 
... CMSIS is not slow but just wrong...

BUG Report:
Code:
#include <arm_math.h>

void setup() {
  // put your setup code here, to run once:
 
 delay(2000);
 uint32_t x_bin = 0xbfc90fdc;
 float *x = (float*)&x_bin;  // *x is -pi/2 in float
 
 float cos_result;
 
 cos_result = arm_cos_f32(*x);
 Serial.println(cos_result);
 
 cos_result = cosf(*x);
 Serial.println(cos_result);
}

void loop() {
  // put your main code here, to run repeatedly:

}

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.
 
Last edited:
Ah... my memory lied... it was not cmsis but the normal newlib.
sinf() was the problem.
Yes of course there were reports - they should all be in this forum. Several. Unfortunately I can't find them via search.
But that the newlib had also changed, the error should now be magically settled.

@PaulStoffregen

https://forum.pjrc.com/threads/65783-sinf()-on-Teensy-4-0?highlight=newlib+sinf

https://forum.pjrc.com/threads/66738-to_string()-doesn-t-work?p=284142&viewfull=1#post284142

Not sure if these are good references as of today. I don't really use these functions much.
 
This isn't even on my list. Has it been previously reported with a reproducible test case?

CMSIS API is also a low priority. A huge backlog of far more important things are pending. Even with a test case, CMSIS stuff probably isn't going to get any updates for a very long time, maybe not ever. But no test case means it doesn't even go onto the low priority list.

Might be a low priority but would be good to get updated at some point. CMISI has a Neural Network API (https://community.arm.com/arm-commu...ls-boost-efficiency-in-microcontrollers-by-5x) that I did manage to get working with a Teensy 3.6 and the Teensy 4 but I had to update the CMSIS library. I know TinyML is available but that brings another set of isssues to deal with. In addition I have seen threads over the years where folks have wanted to update CMSIS to use its DSP capabilities.

Right now with getting the updated toolchain and libraries updated and some other open issues that have higher priority but think at least it should be one of those low priority updates after MTP/MSC/FS etc.

EDIT: https://forum.pjrc.com/threads/5743...ification-w-CMSIS-NN?highlight=neural+network

EDIT2: Here were the instruction set I used to update to at least 5.3 - I know its a bit out of date but:
https://forum.pjrc.com/threads/5380...-on-Teensy-3-6?p=187687&viewfull=1#post187687

EDIT3: Looks like the latest version is 5.9.0 and looks like somewhere along the line since 5.4 they broke out DSP from CMSIS so may get a bit more confusing. As a 5.9 DSP is broken out from CMSIS so NN and DSP can have there own releases and as of 5.8 pre-built binaries were purged
 
Last edited:
All the guys using Teensy for ham radio would appreciate it too. They all have to update CMSIS themselves. Only to mention two: DD4Wh and Bob Larkin. And the hundrets who put their ham projects together (some of them are in print magazines - not that good to have to read there "Tensy uses an old CMSIS, you have to update it").
 
Since you say you are in the process of fixing warnings: Would you be so kind to merge or close some of the 20 pullrequests for OneWire?

Many Thanks,
Frank
 
Turns out the ATOMIC_BLOCK stuff really wants to be inline, but with gcc 11.3.1 when optimizing for small code size (the default on Teensy LC) it isn't without __attribute__((always_inline)).

https://github.com/PaulStoffregen/RadioHead/commit/90a2414da665199413931f5203561ac0c8517b94

https://github.com/PaulStoffregen/cores/commit/9084d8e68fd772a04f3f0d601cf3de93b60efe44

Glad you found it - switching to gcc 11.3.1 has been time consuming - no wonder you can't really do much of anything else until you work the bugs out of the gcc change first
 
@PaulStoffregen

I was trying once again to see if I can get that perl script of yours working on windows using strawberry Perl for window but I keep getting this

Code:
File not found - '*.ino'
File not found - '*.ino'
Testing 0 examples
Commands created: 0
Commands to run:  0

I my case I changed the following lines to:
Code:
$dir = 'F:\arduino-1.8.19-1131';
$sketchbook = 'D:\Users\Merli\Documents\Arduino';

Any ideas.

PS. Just noticed the list of all libraries that are incompatible. Didn't register that the list was available.
 
I'm a bit embarrassed to admit many of these compiler warnings have been with us for years on gcc 5.4.1. But warnings like misleading white space and string truncation are new. Maybe spending so much time to look into why these warnings happen, rather than just quickly getting rid of them with pragmas or other quick fixes, is a waste of time.

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 was trying once again to see if I can get that perl script of yours working on windows using strawberry Perl for window but I keep getting this

Lines 28, 38, 47 (commented out) run the "find" command. To use the script, you'll need to install a unix compatible find utility and make sure PATH is set up so it gets run by the script. Or edit the script to use the Windows find command syntax.
 
Back
Top