Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 25 of 25

Thread: Starting 1.52 Beta Soon

  1. #1
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,821

    Starting 1.52 Beta Soon

    Planning to start 1.52 beta soon. Now's a good time to remind me of libraries and contributions I should merge.

    Over the weekend I worked on USB audio for Teensy 4.0. I also merged a contribution for dual & triple USB serial on Teensy 3.x. Unfortunately it broke building in Arduino (looks like it was developed with a makefile), so I need to get that fixed. Also planning to bring it into Teensy 4.0. Might do a couple more long-needed things before the first 1.52 beta.

    So this is also a good time to remain me of important features we're missing on Teensy 4.0, or just features that ought to be added.

    The idea is to start 1.52 betas soon, with the goal of implementing lots of features during this lull between Arduino releases, and while we're wait for Teensy 4.1 hardware.

  2. #2
    Junior Member
    Join Date
    Feb 2020
    Posts
    8
    Please please please could you take a look at the TouchScreenUSB issue on Teensy 4.0 as per this thread.

    https://forum.pjrc.com/threads/59675...TouchScreenUSB

  3. #3
    Junior Member
    Join Date
    Feb 2020
    Posts
    4
    I am new on the forum and just wanted to say Hi and Big Thank You to Paul for all his hard work. I got already two Teensy 4 boards. Currently I am C++ programmer by profession (started with Zilog Z80 assembler back in 90s) and consider both Teensy hardware and libraries pleasure to work with. I am using Platformio IDE as Arduino is almost 19th century as far as IDE standards are considered.
    As far as libraries are considered, the only piece missing for me is USB audio so I am happy to hear it is going to arrive soon. Programming wise, it would be great if Teensy 4 supported on chip debugging that Platformio offers. Keep up the great work.

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,628
    It might be interesting to Pull in some additional things like:

    How to handle Serial.available() on T4 where there is at least a one character delay before you will see the last character... Have a few different PRs on that.

    SPI - I cleaned up a little the definitions of hardware

    Display drivers: There are several of the ones (mainly currently hosted by @mjs513) that would be good to update, like RA8875, ILI9488_t3, I think ST7735_t3 is up to date....

    Wonder about the stuff on Wire to allow faster buss speeds on T4?

    That is all I can think of so far.

  5. #5
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,679
    It may be useful to add a list to the beta/final announcement of libraries/functionality that still does not have Teensy 4.0 support, just to gather the information where the announcement is.

    Of course speaking of compatibility, it would probably be useful to go through the library pages and add Teensy 4.0 compatibility where it currently exists. Serial is the one I always notice. Spi and Wire also. It would also be nice if we could get the pages that are Teensy 2.0/1.0 only to be marked as such.

    If we have the old Sumatoy display libraries, it may be better to drop them. And/or make them fully supported, possibly with new names.

    It would be useful to add some of the specific 4.0 libraries, such as:

  6. #6
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896

    Fix boards.txt and linker files to support STL

    Maybe it is by purpose but to me it looks like there is a small glitch in boards.txt for the T3.X boards.

    Code:
    teensy31.build.flags.ld=-Wl,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk20dx256.ld"  -lstdc++
    teensy31.build.flags.libs=-larm_cortexM4l_math -lm
    The T3x boards include libstdc++ in "teensy31.build.flags.ld" which effectively moves it in front of the other object files which will toss out some functions required by the STL. Moving -lstdc++ at the end of the next line fixes this. Here some related info from StackOverflow
    The GNU ld linker is a so-called smart linker. It will keep track of the functions used by preceding static libraries, permanently tossing out those functions that are not used from its lookup tables. The result is that if you link a static library too early, then the functions in that library are no longer available to static libraries later on the link line.

    The typical UNIX linker works from left to right, so put all your dependent libraries on the left, and the ones that satisfy those dependencies on the right of the link line...
    (see https://stackoverflow.com/a/409402/1842762)

    For T4 the position of the -lstdc++ is correct, but unfortunately the linker script misses the required definition of the symbols __exidx_start and __exidx_end. Here the corresponding definition from the T3.2 linker script which is missing in the T4 script.

    Code:
    .ARM.exidx : {
       __exidx_start = .;
       *(.ARM.exidx* .gnu.linkonce.armexidx.*)
       __exidx_end = .;
    } > FLASH
    Copying this to the T4 script enables the STL for the T4. (needed to replace > FLASH by >RAM but this probably is only since I have no real understanding of linker scripts)

    Would be great if you could fix this in one of the next releases to enable the more modern parts of c++ for those who care.



    Here a quick test sketch if someone wants to try: (compiles with T3 and T4 with the above mentioned changes)
    Code:
    #include <map>
    #include <vector>
    
    void setup()
    {
      while (!Serial){}
    
      std::map<int, std::string> myMap;
      myMap.emplace(17, "Hello");
      myMap.emplace(12, "STL");
    
      std::vector<std::string> vec;
      vec.push_back("Hello Again");
      vec.emplace_back("Vector test");
    
      for (auto &&i : myMap)
      {
        Serial.printf("%d: %s\n", i.first, i.second.c_str());
      }
    
      for (unsigned i = 0; i < vec.size(); i++)
      {
        Serial.println(vec[i].c_str());
      }
    }
    
    void loop()
    {
    }
    Prints:
    Code:
    12: STL
    17: Hello
    Hello Again
    Vector test
    Last edited by luni; 02-24-2020 at 05:16 PM.

  7. #7
    Junior Member
    Join Date
    Feb 2020
    Location
    South Africa
    Posts
    12
    Quote Originally Posted by PaulStoffregen View Post
    Planning to start 1.52 beta soon. Now's a good time to remind me of libraries and contributions I should merge.

    Over the weekend I worked on USB audio for Teensy 4.0. I also merged a contribution for dual & triple USB serial on Teensy 3.x. Unfortunately it broke building in Arduino (looks like it was developed with a makefile), so I need to get that fixed. Also planning to bring it into Teensy 4.0. Might do a couple more long-needed things before the first 1.52 beta.

    So this is also a good time to remain me of important features we're missing on Teensy 4.0, or just features that ought to be added.

    The idea is to start 1.52 betas soon, with the goal of implementing lots of features during this lull between Arduino releases, and while we're wait for Teensy 4.1 hardware.
    Yes as my first post I would also like to congratulate you on the fine work you are doing with the Teensy - hope you will continue for many years.
    As I have previously done something with the VS1053 I will lurk for while before trying to contribute.
    The Teensy 4 USB Audio will be a nice addition..

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,875
    Quote Originally Posted by MichaelMeissner View Post
    It would be useful to add some of the specific 4.0 libraries, such as:
    Perhaps it is better to take the button specific functions from it and copy them to the core.

    Additional:
    - make CMSIS work
    - additional Linkerscripts
    - My pullrequest for a better "switch off if too hot"
    - You're working on audio - don't know why you did not merge SPDIF_INPUT - no reaction from you for a year now - I guess you have reasons not to merge it - I don't know which, so I can not help (and i have NOT tested it for a year now)
    - https://github.com/PaulStoffregen/SD/pull/21

    Audio GUI for T4

    - Not for TD1.52 - but spend a day for updates of documentation and the website...
    Last edited by Frank B; 02-24-2020 at 07:38 PM.

  9. #9
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,875

  10. #10
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,102
    Will add to the list that the quadrature encoder library for the T4 should be updated as well.

    At this point all I can do is second what pretty much everyone else has said.

  11. #11
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    510
    Looks like it’s about time for MIDI 2.0 to be worked on with the official specs now available for download: https://www.midi.org/articles-old/de...perty-exchange

  12. #12
    Any chance, please, of incorporating this pull request into the Teensy T36 host library USBHost_t36 ? Without it I can you can only get the status of modifiers when another key is pressed and cannot perform a full keyboard / mouse pass through (Shift + Mouse , CNTRL + Mouse).

    Many thanks and Regards
    Pull request - new function hooks in KeyboardController class #18

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,821
    Quote Originally Posted by vjmuzik View Post
    Looks like it’s about time for MIDI 2.0
    I downloaded the spec. Haven't read any of it yet.

    Just to be clear, I have absolutely no plans to touch MIDI 2.0 until at least 1 of the major operating systems has a driver and at least some sort of software we can use for testing.

  14. #14
    Paul

    Is that a maybe for the KeyboardController class #18 ?

  15. #15
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    510
    Quote Originally Posted by PaulStoffregen View Post
    I downloaded the spec. Haven't read any of it yet.

    Just to be clear, I have absolutely no plans to touch MIDI 2.0 until at least 1 of the major operating systems has a driver and at least some sort of software we can use for testing.
    That's fair, looks like only profiles are supported in MacOS 10.15.4 Beta right now so it'll probably do a while before it's completely done for an official release.
    Click image for larger version. 

Name:	Screen Shot 2020-02-25 at 8.56.29 AM.png 
Views:	24 
Size:	48.3 KB 
ID:	19168

  16. #16
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,638
    MTP responder deserves some cores decisions and modifications
    - MTP Disk + Serial for T3.x and T4 (needs own PID and Boot capability and usc_desc modifications)
    - MTP needs decision if usb_mtp.(h/c) is in cores or can be in user library (suggest mtp_library)

    USB2 Device deserves some decision for Arduino IDE (menu entry and compiler flag)

  17. #17
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,628
    Paul,

    Was wondering also about not just what updates should be brought in, but also maybe how to handle file changes within the included libraries.

    Example: suppose we choose to convert the ILI9488_t3 library and maybe a few others like it, to be setup as a "Proper" Arduino library, such that we can potentially make it build an archive file, this will require that the source files move from the root directory to a sub directory "src"

    Can Teensyduino somehow know this information and either move the files and/or know to delete the ones from the root directory?

    A few benefits of moving to archive files is that the linker will only include those objects out of the archive that has current outstanding external references. So for example if a library such as this has lets say 4 different font files included with it, which your sketch does not use, then these won't take up space in your executable...

    The risk is that it can uncover some interesting build issues with Arduino. That is if an archive file is included in the link stage before another library or source file that references parts of it, then those later references may not be satisfied.

    I ran into this with my attempt to make Wire library into an archive, which I may still like to do. The issue is that in a test case where I only referenced Wire1, it turned out that an Adafruit library referenced Wire as a default in a constructor that was not even used and caused the link to fail. One simple fix for that one, it to assume that Wire object needs to be always included and have it's objects as part of the main Wire class file...

    But again it was nice that with the above you could define Wire1 for LC and Wire4 for T3.6 ... and they will only take up space if a sketch actually uses it.

  18. #18
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    896
    A few benefits of moving to archive files is that the linker will only include those objects out of the archive that has current outstanding external references. So for example if a library such as this has lets say 4 different font files included with it, which your sketch does not use, then these won't take up space in your executable...
    Are you sure that this has anything to do with archives? IIRC the linker is supposed to remove code which is not used in any case since we have --gc-sections in the linker options?

  19. #19
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,628
    I can not say for sure, but I know in earlier tests where I split up each of the Wire objects up into their own source files and built without doing an archive.

    The linker included each of the source files into the link phase and size of the generated exe (mainly data usage) did not decrease.

    When instead I made them into an archive where the .a file was included into the link phase, only the ones that were used were brought in and the data sizes reflected it.

  20. #20
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    232
    Quote Originally Posted by WMXZ View Post
    MTP responder deserves some cores decisions and modifications
    - MTP Disk + Serial for T3.x and T4 (needs own PID and Boot capability and usc_desc modifications)
    - MTP needs decision if usb_mtp.(h/c) is in cores or can be in user library (suggest mtp_library)

    USB2 Device deserves some decision for Arduino IDE (menu entry and compiler flag)
    Yes! MTP!

    Chip

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,494
    Paul: This thread shows details on failures with Teensy 4.0 RawHID:

    RawHID-recv()-hangs-after-updating-to-Teensyduino-1-4-9-or-higher-for-Teensy-4-0

    Two users - at least one suggested client/Teensy code set for repro - on MAC OS. 2nd is pending posting

  22. #22

  23. #23
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,875
    Is it correct, that the Teensy 4 Linkersript misses "FLASHMEM" for _flashimagelen ?

    Code:
    [...]
        .text.progmem : {
            KEEP(*(.flashconfig))
            FILL(0xFF)
            . = ORIGIN(FLASH) + 0x1000;
            KEEP(*(.ivt))
            KEEP(*(.bootdata))
            KEEP(*(.vectors))
            KEEP(*(.startup))
            *(.flashmem*)
            *(.progmem*)
    [...]
    
        _flashimagelen = SIZEOF(.text.progmem) + SIZEOF(.text.itcm) + SIZEOF(.data);
        _teensy_model_identifier = 0x24;
    [...]
    
    }

  24. #24
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,821
    So many excellent suggestions on this thread. Some are going to make it into 1.52-beta1. Others are not. If I want to merge everything, we'll never get to 1.52. If something you suggested didn't make it into this first beta, and I've not clearly said I'm rejecting it, then please do bring it up again on the 1.52 beta thread.

    Some things, like MTP, I want to do, but with more carefully considered Arduino-like API. I know a lot of people want MTP. I want it too. But APIs are very painful to change later, and I'm not happy with the SdFat-only API. Will explain more on MTP later.

    Right now, I'm going to package up a 1.52 first beta with everything that's already merged and implemented.

    Closing this thread. Please look for the 1.52 beta thread and continue conversation about missing features there.

  25. #25
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,494
    FIRST 1.52 Beta 1 :: Teensyduino-1-52-Beta-1

Posting Permissions

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