Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 3 1 2 3 LastLast
Results 1 to 25 of 59

Thread: Teensyduino 1.54 Beta #8

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    415

    Teensyduino 1.54 Beta #8

    Here is a eighth beta test for Teensyduino 1.54.

    Digital signatures have changed on Windows. Edge/IE might show a dire warning.
    Please click the site is safe button.

    Install into a clean copy of Arduino if you previously installed beta3 or beta4.



    Edit: Links removed. Please use 1.54-beta9
    https://forum.pjrc.com/threads/67252...no-1-54-Beta-9



    Changes since Teensyduino 1.54-beta7:

    Support for Arduino 1.8.14
    Fix MPU settings, solve mystery 1.7 sec stalls (FrankB)
    Fix Ethernet W5100 on Teensy 4.0 running at > 150 MHz
    Wire library names updated for MicroMod (mjs513)
    Add Kurt's FlexIO_t4 library (KurtE)
    Add missing FlexIO defs to imxrt.h
    Fix IMXRT_GPIO_t ISR name on Teensy 4
    Serial.begin() to wait up to 2 seconds for serial monitor
    Audio add WaveFolder (Mark T)
    Audio fix double promotion warnings (FrankB)
    Audio improve ladder filter (Richard van Hoesel)
    LittleFS updates to lowLevelFormat (Defragster, KurtE)
    RA8875 updates
    ST7735_t3 updates
    USBHost_t36 update mass storage
    USBHost_t36 undo zero interrupt latency change, breaks some drivers
    Fix memory usage on MicroMod
    Show ITCM actual memory usage & padding
    Last edited by Paul; 05-18-2021 at 11:44 AM. Reason: changes list updated

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    Windows 10 accepted the IDE 1.8.14 download - but again is Yelling at the TD 1.54.Beta8 ... Had to explicitly ask for it to be KEPT! Then second screen repeat and then right click and 'Unblock' in properties.
    Not yet unzipped 1.8.14 or installed new TD b8.

  3. #3
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,559
    I have 1.8.14 and beta8 and things run...

    Will test more during the day. And yes I received warning from both Windows... And Norton... on trying to install it.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    Unzipped the IDE 1.8.14 - running Arduino.exe system also wanted to Block that - had to click More and Run Anyway.

    Ran the 'unblocked' TeensyduinoInstall_1.54_b8.exe with no issue. Not built anything yet but ...
    Click image for larger version. 

Name:	TeensyduinoInstall_1.54_b8.png 
Views:	30 
Size:	62.9 KB 
ID:	24772

  5. #5
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,548
    Downloaded the new IDE as as well as teensyduino.

    Microsoft edge decided to block and had to explicitly tell it to keep the file. I also reported it as safe. However if I download it with Firefox it will download fine and at least my norton accepts it without complaint. When installing TD1.54-beta8 still had to tell windows to run it anyway - pretty much have to that with most installs.

    Fired up the TMM example 1 and loaded and running no issues that I can see. Will play more as the day progresses. Now to delete some duplicate libraries in my local library.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    With installed IDE 1.8.14 and TD 1.54.b8

    For another post I just built LittleFS for T_4.1 Program Flash and all looks good and right.

    Did not use IDE, but used TSET and programmed with TeensyLoader and TyComm as SerMon. Confirmed all LIBS were from installed TD 1.54.b8

  7. #7
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,548
    Almost forgot but I just compiled another sketch for obstacle avoidance for the micromod and memory usage now works. So that change definitely took:
    Code:
                 ^
    Opening Teensy Loader...
    Memory Usage on Teensy MicroMod:
      FLASH: code:36628, data:6116, headers:7212   free for files:16465116
       RAM1: variables:12992, code:34760, padding:30776   free for local variables:445760
       RAM2: variables:12384  free for malloc/new:511904

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    Quote Originally Posted by mjs513 View Post
    Almost forgot but I just compiled another sketch for obstacle avoidance for the micromod and memory usage now works. So that change definitely took:
    Code:
                 ^
    Opening Teensy Loader...
    Memory Usage on Teensy MicroMod:
      FLASH: code:36628, data:6116, headers:7212   free for files:16465116
       RAM1: variables:12992, code:34760, padding:30776   free for local variables:445760
       RAM2: variables:12384  free for malloc/new:511904
    Good catch @mjs513 - I glanced over that but didn't look and see the change to show the ITCM 'padding' called out.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,026
    Opps, headers are still only 7212. I forgot to merge a 1K alignment change needed for future encryption. This beta was a bit hasty, since Arduino released 1.8.14 this morning.

  10. #10
    Just a reminder of a pull request on FreqMeasureMulti with a bug fix for incorrect read of capture registers for T4.x

    https://github.com/PaulStoffregen/Fr...eMulti/pull/13

  11. #11
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,623
    Another reminder:
    it still breaks compatibility with the STL for newer compilers. E.g. this:

    Code:
    #include <map>
    
    void setup()
    {
        while(!Serial){}
    
        std::map<int,const char*> m{{1,"first"}, {2,"second"}, {42,"answer"}};
        Serial.println(m[42]);
    }
    
    void loop()
    {
    }
    compiles and works perfectly with gcc 9 and TD1.53 but generates compile errors with TD1.54 (and gcc9). Here more information and the commit which introduced the issue: https://forum.pjrc.com/threads/66357...l=1#post274861

  12. #12
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,267
    Will there be a way to disable all the encryption additions when I don't need it?

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,026
    Quote Originally Posted by Frank B View Post
    Will there be a way to disable all the encryption additions when I don't need it?
    I don't have answers to all questions about encryption yet, because I'm still working on how we'll eventually support encrypted firmware.

    I can say 3 pretty general things.

    1: Encryption will not be used by default. To enable, at a bare minimum you have to generate your own encryption key.

    2: You can't ever fully secure the default Teensy 4.0 & 4.1 which have "unbrickable" fuse settings. PJRC will eventually need to offer a "lockable" version, which is exactly the same hardware but certain fuses configured differently. Custom PCBs built with the bootloader chip are essentially the lockable version.

    3: Minor things like padding and placeholder data will be fixed in the linker script. For example, recent betas have been appending 3K of empty data which is intended to be used as a placeholder for the digital signature. Today we're aligning certain sections of the program to only 16 byte boundaries. NXP's documentation recommends 4K or 8K. For beta9, two of those 16 byte aligned sections will change to 1024 byte aligned.

    So to answer your question with the word "all", most of the encryption stuff will be disabled by default and will only be used if you have created a key. But some small parts, like the extra padding and empty data which reserves space for a digital signature get built into every program whether encryption is used or not. I don't consider 4-5K of unused padding within a 2M flash memory to be a big issue.

  14. #14
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21
    I am running 1.8.14 and added teensyduino 1.54 Beta #8. I attempted a compile of a program that has been operational under previous version 1.8.13 and the earlier version of Teensyduino. The IDE complains about EEPROM.h not finding <type_trait> EEPROM.h reference: #ifndef EEPROM_h
    #define EEPROM_h

    #include <inttypes.h>
    #include <avr/eeprom.h>
    #include <avr/io.h>

    #include <type_traits>

    Can I revert back to the pervious version of Teensyduino and it will work with IDE 1.8.14 ? Or should I revert back to IDE 1.8.13 and then back to the previous version Teensyduino ?

    Thanks for the assistance.

    Error message: "C:\\Program Files (x86)\\Arduino\\hardware\\teensy/../tools/avr/bin/avr-g++" -E -CC -x c++ -w -g -Wall -ffunction-sections -fdata-sections -fno-exceptions -fpermissive -felide-constructors -std=gnu++11 -mmcu=at90usb1286 -DTEENSYDUINO=154 -DARDUINO_ARCH_AVR -DARDUINO=10814 -DARDUINO_TEENSY2PP -DF_CPU=16000000L -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\cores\\teen sy" "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\libraries\\ Wire" "-IC:\\Users\\Brian\\AP\\Arduino\\libraries\\ITG3200 " "-IC:\\Program Files (x86)\\Arduino\\hardware\\teensy\\avr\\libraries\\ EEPROM" "C:\\Users\\Brian\\AppData\\Local\\Temp\\arduino_b uild_522714\\sketch\\AP_Teensy_62_b_041921.ino.cpp " -o nul
    Alternatives for type_traits: []
    ResolveLibrary(type_traits)In file included from C:\Users\Brian\AP\Arduino\Rev62_b\AP_Teensy_62_b_0 41921\AP_Teensy_62_b_041921.ino:234:0:

    -> candidates: []
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\EEPROM/EEPROM.h:29:10: fatal error: type_traits: No such file or directory
    #include <type_traits>
    ^~~~~~~~~~~~~
    compilation terminated.

  15. #15
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    It won't work to try installing an older TeensyDuino over a newer version IIRC.
    Either the IDE would need to be uninstalled and re-installed with a fresh version, or a ZIP copy installed and used from an alternate location where prior TeenyDuino version could be tried.

    These lines are suspicious, not clear why the "avr/" is included when only this is needed :: #include <EEPROM.h>
    Code:
    #include <inttypes.h>
    #include <avr/eeprom.h>
    #include <avr/io.h>
    The problem seems to come from the above includes and use of :: #include <type_traits>

    Without a full sample to reproduce this it cannot be reproduced by anyone looking to help - see 'Forum Rule' at the top of all forum pages. And given partial console output nothing else can be seen that may help.

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,026
    Quote Originally Posted by brianb00 View Post
    I attempted a compile of a program that has been operational under previous version 1.8.13 and the earlier version of Teensyduino. The IDE complains about EEPROM.h not finding <type_trait>
    Can you post a copy of that program, and a place to get the exact ITG3200 library you are using, plus any other files not part of Teensyduino which we would need to have?

    I can't investigate and fix this problem if I have no way to reproduce it.



    Can I revert back to the pervious version of Teensyduino and it will work with IDE 1.8.14 ?
    No. None of the prior versions of Teensyduino will work with IDE 1.8.14, which Arduino released only about 30 hours ago!


    Or should I revert back to IDE 1.8.13 and then back to the previous version Teensyduino ?
    To solve your immediate problem, yes. Easiest way is to run the Arduino installer again, which deletes the previously installed files before installing a fresh new copy.

    But regarding what you should do, before reverting you definitely should give us all the files needed to reproduce this problem! If we're left to only guesswork, odds are slim it will get fixed. I know right now you just want to be able to compile your code. But please think of the future. Give us a way to reproduce the problem so we can get it fixed, so your program will be able to compile with the next betas and upcoming non-beta 1.54 release.

  17. #17
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,559
    @Paul - I can reproduce it easily... Just open example eeprom_get
    And try to compile it for Teensy 2++

    As I noticed in his build: -DARDUINO_TEENSY2PP

    Code:
    Alternatives for type_traits: []
    In file included from C:\arduino-1.8.13\hardware\teensy\avr\libraries\EEPROM\examples\eeprom_get\eeprom_get.ino:18:0:
    ResolveLibrary(type_traits)
    C:\arduino-1.8.13\hardware\teensy\avr\libraries\EEPROM/EEPROM.h:29:10: fatal error: type_traits: No such file or directory
      -> candidates: []
     #include <type_traits>
              ^~~~~~~~~~~~~
    compilation terminated.
    Using library EEPROM at version 2.0 in folder: C:\arduino-1.8.13\hardware\teensy\avr\libraries\EEPROM 
    Error compiling for board Teensy++ 2.0.
    My guess is it has to do with @luni commit 9 months ago: https://github.com/PaulStoffregen/EE...c16467f2f7d779

    Maybe that stuff does not exist for AVR builds.

  18. #18
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21
    Thanks for the assist. The program is very large. I will see about re producing this in a much smaller instance of code. I will also revert this back and not take your time to debug the issue.

    Regards,

    Brian

    Quote Originally Posted by PaulStoffregen View Post
    Can you post a copy of that program, and a place to get the exact ITG3200 library you are using, plus any other files not part of Teensyduino which we would need to have?

    I can't investigate and fix this problem if I have no way to reproduce it.





    No. None of the prior versions of Teensyduino will work with IDE 1.8.14, which Arduino released only about 30 hours ago!




    To solve your immediate problem, yes. Easiest way is to run the Arduino installer again, which deletes the previously installed files before installing a fresh new copy.

    But regarding what you should do, before reverting you definitely should give us all the files needed to reproduce this problem! If we're left to only guesswork, odds are slim it will get fixed. I know right now you just want to be able to compile your code. But please think of the future. Give us a way to reproduce the problem so we can get it fixed, so your program will be able to compile with the next betas and upcoming non-beta 1.54 release.

  19. #19
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,559
    @brianb00 and @PaulStoffregen - I hacked up a version of eeprom.h that I believe now compiles on the AVR boards...
    Not sure if this is the best way...

    I checked that if it was not __AVR, but maybe should be #ifdef __arm__

    Changes in RED:

    Code:
    /*
      EEPROM.h - EEPROM library
      Original Copyright (c) 2006 David A. Mellis.  All right reserved.
      New version by Christopher Andrews 2015.
      This copy has minor modificatons for use with Teensy, by Paul Stoffregen
    
      This library is free software; you can redistribute it and/or
      modify it under the terms of the GNU Lesser General Public
      License as published by the Free Software Foundation; either
      version 2.1 of the License, or (at your option) any later version.
    
      This library is distributed in the hope that it will be useful,
      but WITHOUT ANY WARRANTY; without even the implied warranty of
      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
      Lesser General Public License for more details.
    
      You should have received a copy of the GNU Lesser General Public
      License along with this library; if not, write to the Free Software
      Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
    */
    
    #ifndef EEPROM_h
    #define EEPROM_h
    
    #include <inttypes.h>
    #include <avr/eeprom.h>
    #include <avr/io.h>
    
    #ifndef __AVR__
    #include <type_traits>
    #endif
    
    /***
        EERef class.
    
        This object references an EEPROM cell.
        Its purpose is to mimic a typical byte of RAM, however its storage is the EEPROM.
        This class has an overhead of two bytes, similar to storing a pointer to an EEPROM cell.
    ***/
    
    struct EERef {
    
        EERef( const int index )
            : index( index )                 {}
    
        //Access/read members.
        uint8_t operator*() const            { return eeprom_read_byte( (uint8_t*) index ); }
        operator const uint8_t() const       { return **this; }
    
        //Assignment/write members.
        EERef &operator=( const EERef &ref ) { return *this = *ref; }
        EERef &operator=( uint8_t in )       { return eeprom_write_byte( (uint8_t*) index, in ), *this;  }
        EERef &operator +=( uint8_t in )     { return *this = **this + in; }
        EERef &operator -=( uint8_t in )     { return *this = **this - in; }
        EERef &operator *=( uint8_t in )     { return *this = **this * in; }
        EERef &operator /=( uint8_t in )     { return *this = **this / in; }
        EERef &operator ^=( uint8_t in )     { return *this = **this ^ in; }
        EERef &operator %=( uint8_t in )     { return *this = **this % in; }
        EERef &operator &=( uint8_t in )     { return *this = **this & in; }
        EERef &operator |=( uint8_t in )     { return *this = **this | in; }
        EERef &operator <<=( uint8_t in )    { return *this = **this << in; }
        EERef &operator >>=( uint8_t in )    { return *this = **this >> in; }
    
        EERef &update( uint8_t in )          { return  in != *this ? *this = in : *this; }
    
        /** Prefix increment/decrement **/
        EERef& operator++()                  { return *this += 1; }
        EERef& operator--()                  { return *this -= 1; }
    
        /** Postfix increment/decrement **/
        uint8_t operator++ (int) {
            uint8_t ret = **this;
            return ++(*this), ret;
        }
    
        uint8_t operator-- (int) {
            uint8_t ret = **this;
            return --(*this), ret;
        }
    
        int index; //Index of current EEPROM cell.
    };
    
    /***
        EEPtr class.
    
        This object is a bidirectional pointer to EEPROM cells represented by EERef objects.
        Just like a normal pointer type, this can be dereferenced and repositioned using
        increment/decrement operators.
    ***/
    
    struct EEPtr {
    
        EEPtr( const int index )
            : index( index )                {}
    
        operator const int() const          { return index; }
        EEPtr &operator=( int in )          { return index = in, *this; }
    
        //Iterator functionality.
        bool operator!=( const EEPtr &ptr ) { return index != ptr.index; }
        EERef operator*()                   { return index; }
    
        /** Prefix & Postfix increment/decrement **/
        EEPtr& operator++()                 { return ++index, *this; }
        EEPtr& operator--()                 { return --index, *this; }
        EEPtr operator++ (int)              { return index++; }
        EEPtr operator-- (int)              { return index--; }
    
        int index; //Index of current EEPROM cell.
    };
    
    /***
        EEPROMClass class.
    
        This object represents the entire EEPROM space.
        It wraps the functionality of EEPtr and EERef into a basic interface.
        This class is also 100% backwards compatible with earlier Arduino core releases.
    ***/
    
    struct EEPROMClass {
    
    #if defined(__arm__) && defined(TEENSYDUINO)
        EEPROMClass()                        { eeprom_initialize(); }
    #endif
    
        //Basic user access methods.
        EERef operator[]( const int idx )    { return idx; }
        uint8_t read( int idx )              { return EERef( idx ); }
        void write( int idx, uint8_t val )   { (EERef( idx )) = val; }
        void update( int idx, uint8_t val )  { EERef( idx ).update( val ); }
    
        //STL and C++11 iteration capability.
        EEPtr begin()                        { return 0x00; }
        EEPtr end()                          { return length(); } //Standards requires this to be the item after the last valid entry. The returned pointer is invalid.
        uint16_t length()                    { return E2END + 1; }
    
        //Functionality to 'get' and 'put' objects to and from EEPROM.
        template< typename T > T &get( int idx, T &t ) {
    
            #ifndef __AVR__
            static_assert(std::is_trivially_copyable<T>::value, "You can not use this type with EEPROM.get" ); // the code below only makes sense if you can "memcpy" T
            #endif
            EEPtr e = idx;
            uint8_t *ptr = (uint8_t*) &t;
            for ( int count = sizeof(T) ; count ; --count, ++e )  *ptr++ = *e;
            return t;
        }
    
        template< typename T > const T &put( int idx, const T &t ) {
            #ifndef __AVR__
            static_assert(std::is_trivially_copyable<T>::value, "You can not use this type with EEPROM.get"); // the code below only makes sense if you can "memcpy" T
            #endif
            const uint8_t *ptr = (const uint8_t*) &t;
    #ifdef __arm__
            eeprom_write_block(ptr, (void *)idx, sizeof(T));
    #else
            EEPtr e = idx;
            for ( int count = sizeof(T) ; count ; --count, ++e )  (*e).update( *ptr++ );
    #endif
            return t;
        }
    };
    
    
    static EEPROMClass EEPROM __attribute__ ((unused));
    #endif

  20. #20
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,026
    Oh, yeah, I completely missed this was on the old 8 bit boards.

  21. #21
    Member
    Join Date
    Mar 2013
    Location
    Silicon Valley
    Posts
    21
    @KurtE Hey thanks for digging into this. Awesome. I will try this out soon.

    Regards,
    Brian

  22. #22
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,548
    Quote Originally Posted by KurtE View Post
    @brianb00 and @PaulStoffregen - I hacked up a version of eeprom.h that I believe now compiles on the AVR boards...
    Not sure if this is the best way...

    I checked that if it was not __AVR, but maybe should be #ifdef __arm__

    Changes in RED:

    ....
    Sorry late to the party. Just updated EEPROM.cpp and it does compile for Teensy++2.0 as well as T4.1 and T3.5. Also tried compiling 3 other sketches that use the EEPROM library and they all seem to compile fine.

  23. #23
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,559
    @Paul - I went ahead and created a Pull Request for building EEPROM on AVR builds
    https://github.com/PaulStoffregen/EEPROM/pull/8

  24. #24
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,068
    Good work KurtE - Like Paul with Teensy Model not noted I was assuming ARM - and even questioned the "avr/" without looking at the included console notes

  25. #25
    So what's the process to get bug fixes into the teensy core library? I've spend a fair amount of time debugging a couple problems I've run into, but it kinda feels like I'm posting into the wind over in the tech support forum.

Posting Permissions

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