Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 26 to 50 of 110

Thread: Teensyduino 1.58 Beta #2

  1. #26
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,020
    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.

  2. #27
    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.

  3. #28
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    1,020
    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?

  4. #29
    Quote Originally Posted by BriComp View Post
    Isn't the above clear?
    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.

  5. #30
    Quote Originally Posted by joepasquariello View Post
    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

  6. #31
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,697
    This:
    Quote Originally Posted by joepasquariello View Post
    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

  7. #32
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    Quote Originally Posted by joepasquariello View Post
    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)

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    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.

  9. #34
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    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

  10. #35
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    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....

  11. #36
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    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.

  12. #37
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    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

  13. #38
    Quote Originally Posted by Mcu32 View Post
    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
    Are you referring to the f32 version of the sin function for T3.x?

  14. #39
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    Quote Originally Posted by Mcu32 View Post
    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.

  15. #40
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    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.

  16. #41
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    ... 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 by Mcu32; 09-16-2022 at 08:36 PM.

  17. #42
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,538
    Quote Originally Posted by Mcu32 View Post
    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...ht=newlib+sinf

    https://forum.pjrc.com/threads/66738...l=1#post284142

    Not sure if these are good references as of today. I don't really use these functions much.

  18. #43
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,538
    Quote Originally Posted by PaulStoffregen View Post
    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-commun...trollers-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/57433...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/53809...l=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 by mjs513; 09-16-2022 at 10:37 PM.

  19. #44
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    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").

  20. #45
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    Quote Originally Posted by PaulStoffregen View Post
    A huge backlog of far more important things are pending.
    Would you publish this backlog? It would be interesting and nice to know what fixes or features are still to come. I can also imagine that some people want to help there.

  21. #46
    Senior Member
    Join Date
    Sep 2021
    Posts
    169
    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

  22. #47
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    Quote Originally Posted by PaulStoffregen View Post
    ... mostly just a reminder to future me to check ATOMIC_BLOCK macros on Teensy LC.
    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/Ra...561ac0c8517b94

    https://github.com/PaulStoffregen/co...f3de93b60efe44

  23. #48
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,538
    Quote Originally Posted by PaulStoffregen View Post
    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/Ra...561ac0c8517b94

    https://github.com/PaulStoffregen/co...f3de93b60efe44
    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

  24. #49
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,538
    @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.

  25. #50
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,361
    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.


    Quote Originally Posted by mjs513 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •