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 51

Thread: Teensyduino 1.54 Beta #2

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

    Teensyduino 1.54 Beta #2

    Here is a second beta test for Teensyduino 1.54.


    Linux 32 bit:
    https://www.pjrc.com/teensy/td_154-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_154-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_154-b...stall.linuxarm

    Linux ARM64:
    https://www.pjrc.com/teensy/td_154-b...l.linuxaarch64

    MacOS 10.10 to 10.15:
    https://www.pjrc.com/teensy/td_154-b...S_Catalina.zip

    MacOS 10.8 to 10.14:
    https://www.pjrc.com/teensy/td_154-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_154-b...inoInstall.exe


    Changes since Teensyduino 1.54-beta1:

    Fix 1.54-beta1 startup problem on Teensy 4.1
    EEPROM put/get handle String and warn for incompatible classes (luni64)
    Add _extram_start & _extram_end for Teensy 4.1
    Update Bounce2

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,752
    It installs

    <edit>

    T_4.1 10-15 uploads of 5 recent sketches noted in beta1 thread all good.
    Last edited by defragster; 10-24-2020 at 03:28 AM.

  3. #3
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    Update Bounce2
    Great, the EncoderTool which depends on a current Bounce2 now compiles out of the box. Thanks

  4. #4
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    EEPROM put/get handle String and warn for incompatible classes
    Tested with the code below. Works as expected.

    Code:
    #include "EEPROM.h"
    
    struct GoodType  // this is bytewise copyable
    {
        const char* text = "Good struct";
        float version = 1.54f;
        int relelase = 2;
    };
    
    struct BadType  // this is NOT bytewise copyable
    {
        String text = "Bad struct";
        float version = 1.54f;
        int relelase = 2;
    };
    
    
    void setup()
    {
      while (!Serial)  {}
    
      int pos0 = 0;
    
      // Save to EEProm -------------------------------
    
      String s1 = "Hello Teensyduino 1.54 beta 2";
      EEPROM.put(pos0, s1);
      int pos1 = pos0 + s1.length() + 1;     // need to take the delimiting /0 into account
    
      GoodType goodType;
      EEPROM.put(pos1, goodType);
      int pos2 = pos1 + sizeof(goodType);
    
      BadType badType;
      //EEPROM.put(pos2, badType);          // if uncommented this generates a compile time error since the type is not bytewise copyable
      int pos3 = pos2 + sizeof(goodType);
    
      // read from EEProm -----------------------------
    
      String storedString1;
      EEPROM.get(pos0, storedString1);
    
      GoodType storedGoodType;
      EEPROM.get(pos1, storedGoodType);
    
      Serial.println(storedString1);
    
      Serial.println(storedGoodType.text);
      Serial.println(storedGoodType.version);
      Serial.println(storedGoodType.relelase);
    }
    
    void loop(){
    }
    Prints out
    Code:
    Hello Teensyduino 1.54 beta 2
    Good struct
    1.54
    2

  5. #5
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    Quote Originally Posted by defragster View Post
    It installs

    <edit>

    T_4.1 10-15 uploads of 5 recent sketches noted in beta1 thread all good.
    Same here - all seems to be working. Ran with OpenGL, EigenTest, check42 psram test with no problem.

  6. #6
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,936
    Morning all,

    Installed Windows 10, and built T4.1 code

    Side notes: But with simple Camera test sketch I am now working through the new warnings for Serial.printf(...)

    Fixed the first obvious one, of I passed a uint... to a %d instead of a %u...

    But that still did not work, neither does %x...

    Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!


    Installed RPI4 8GB SSD Ubuntu Arm64 - Arduino 1.8.12, earlier 13 was not found on Arduino server.... It is today so downloading.

    Same issue as mentioned in the thread: https://forum.pjrc.com/threads/61623...l=1#post255856
    The build goes through but launching the Teensy tool has issues and errors out. The Teensy app shows up as a white window with nothing in it.
    But if I go into and manually start Teensy app it shows up properly. But most of the time does not automatically program properly, but will if I press the program button.
    Tested on T3.2

    Edit same thing on 1.8.13
    Click image for larger version. 

Name:	ScreenShot.jpg 
Views:	15 
Size:	76.4 KB 
ID:	22190
    Last edited by KurtE; 10-24-2020 at 02:14 PM.

  7. #7
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    733
    > Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!

    > printf("uint32_t var : %"PRIu32"\n", u32x);

    I see one here:
    Audio/input_adc.cpp:341:45: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}'

    Where appropriate, I'd maintain portability with this idea (from bperrybap):

    printf("uint32_t var : %"PRIu32"\n", u32x);

  8. #8
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    Quote Originally Posted by KurtE
    Installed RPI4 8GB SSD Ubuntu Arm64 issue
    Seeing exactly the same thing using Ubuntu 18.04, the screenshot matches exactly.

    Code:
    Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!
    Ran across an instance of that myself this morning. There are probably quite a few Lib's and examples that will need updating? Think there was a post where Paul mentioned this somewhere?

  9. #9
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,936
    Quote Originally Posted by jonr View Post
    > Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!

    > printf("uint32_t var : %"PRIu32"\n", u32x);
    Sorry I am old dog who has not learned the new trick yet

    What does that mean? Yes I can and will google it,
    but does this print Hex or Decimal? Not terribly clear. Or maybe an example might help. Here is one I just fixed up:

    Example how would you translate this one I just updated to remove the warnings:
    Code:
    void dumpDMA_TCD(DMABaseClass *dmabc)
    {
      Serial.printf("%lx %lx:", (uint32_t)dmabc, (uint32_t)dmabc->TCD);
    
      Serial.printf("SA:%lx SO:%d AT:%x NB:%lx SL:%ld DA:%lx DO:%d CI:%x DL:%ld CS:%x BI:%x\n", 
                    (uint32_t)dmabc->TCD->SADDR,
                    dmabc->TCD->SOFF, dmabc->TCD->ATTR, dmabc->TCD->NBYTES, dmabc->TCD->SLAST, (uint32_t)dmabc->TCD->DADDR,
                    dmabc->TCD->DOFF, dmabc->TCD->CITER, dmabc->TCD->DLASTSGA, dmabc->TCD->CSR, dmabc->TCD->BITER);
    }
    This dumps out a DMA structure I am using to help debug some code...
    I wonder what would that translate to 8)

  10. #10
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    321
    I just installed TD 1.54B2 and I was going through some sketches using USBHost_t36 and found that "#define USBHOST_PRINT_DEBUG" was uncommented.

    So far all of everything is working well

  11. #11
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    Sorry I am old dog who has not learned the new trick yet
    What does that mean? Yes I can and will google it,
    PRIxN -> x is the usual u, d, x, X etc N is the width of the variable.

    E.g.
    PRIu16 will print a 16bit unsigned
    PRId64 will print a 64bit signed
    PRIX32 will print a 32bit hex number with uppercase letters
    ...

    Advantage: doesn't rely on the platform dependent width of int, unsigned etc.
    Disadvantage: a pain to type

    I think I'll stick with lu, lx etc...

    Edit: They and a lot more of them are defined in 'inttypes.h'

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    7,936
    @luni - Thanks, Yep I think I will too stick with the easy way... With the more typing version wonder if one an do things like:
    printf("Var: %08xl", my_var);

    Would it be something like: printf("Var: %08"PRIu32"\n", u32x);

    Again I could try but for now...

    Thanks again!

  13. #13
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    Nearly :-). You also need to add spaces:

    Code:
    void setup()
    {
        while(!Serial){}
    
        uint32_t test = 42;
        Serial.printf("Var: %08" PRIu32 "\n", test);
    }
    
    void loop(){}
    Prints:
    Code:
    Var: 00000042
    Without the spaces I get a warning:

    Code:
    src/main.cpp:8:19: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
         Serial.printf("Var: %08"PRIu32"\n", test);
    I'm sure this syntax was invented to scare users away from printf :-)

  14. #14
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    More tests with the PRIs

    Code:
    void setup()
    {
        while(!Serial){}
    
        Serial.println("int64_t");
        int64_t test0 = -2;
        Serial.printf("PRIi64: %" PRIi64" \n", test0);
        Serial.printf("PRIu64: %" PRIu64" \n", test0);
        Serial.printf("PRIX64: %" PRIX64" \n", test0);
    
        Serial.println("\nint32_t");
        int32_t test1 = -2;
        Serial.printf("PRIi32: %" PRIi32" \n", test1);
        Serial.printf("PRIu32: %" PRIu32" \n", test1);
        Serial.printf("PRIX32: %" PRIX32" \n", test1);
    
        Serial.println("\nint16_t");
        int16_t test2 = -2;
        Serial.printf("PRIi16: %" PRIi16" \n", test2);
        Serial.printf("PRIi16: %" PRIu16" \n", test2);
        Serial.printf("PRIX16: %" PRIX16" \n", test2);
    
        Serial.println("\nint8_t");
        int8_t test3 = -2;
        Serial.printf("PRIi8: %" PRIi8" \n", test3);
        Serial.printf("PRIu8: %" PRIu8" \n", test3);
        Serial.printf("PRIX8: %" PRIX8" \n", test3);
    }
    
    void loop(){}
    Prints:
    Code:
    int64_t
    PRIi64: -2 
    PRIu64: 18446744073709551614 
    PRIX64: FFFFFFFFFFFFFFFE 
    
    int32_t
    PRIi32: -2 
    PRIu32: 4294967294 
    PRIX32: FFFFFFFE 
    
    int16_t
    PRIi16: -2 
    PRIi16: 65534 
    PRIX16: FFFE 
    
    int8_t
    PRIi8: -2 
    PRIu8: 65534 
    PRIX8: FFFE
    Looks like the 8bit variants are not working as advertised?

  15. #15
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    @luni - thanks for the lesson. Learning something new now. Never realized those things were defined in inttypes.h. I have seen something similar in some .h files though.

    EDIT: did a google search on the PRIX8 issue and came across this post first thing: https://stackoverflow.com/questions/...any-characters

    A int8_t will go through the usual integer promotions as a parameter to a variadic function like printf(). This typically means the int8_t is converted to int.

    Yet "%X" is meant for unsigned arguments. So covert to some unsigned type first and use a matching format specifier:

    For uint8_t, use PRIX8. With exact width types, include <inttypes.h> for the matching specifiers.

    #include <inttypes.h>
    printf(" int negative var is <%02" PRIX8 ">\n", iNegVar);`
    With int8_t iNegVar = -1;, convert to some unsigned type before printing in hex

    printf(" int negative var is <%02" PRIX8 ">\n", (uint8_t) iNegVar);`
    Using that format for 8 bit variants gets you:
    Code:
    int64_t
    
    PRIi64: -2 
    PRIu64: 18446744073709551614 
    PRIX64: FFFFFFFFFFFFFFFE 
    
    int32_t
    
    PRIi32: -2 
    PRIu32: 4294967294 
    PRIX32: FFFFFFFE 
    
    int16_t
    
    PRIi16: -2 
    PRIi16: 65534 
    PRIX16: FFFE 
    
    int8_t
    
    PRIi8: -2 
    PRIu8: 65534 
    PRIX8: FFFE 
     int negative var is <FE>
    Last edited by mjs513; 10-24-2020 at 05:47 PM. Reason: Additional info

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,084
    Quote Originally Posted by mjs513 View Post
    Never realized those things were defined in inttypes.h.
    I've never heard of this syntax either.


    Quote Originally Posted by mjs513 View Post
    Think will need to convert many many %u %x %d to %lu %lx %ld Will be sort of a pain!
    ....
    There are probably quite a few Lib's and examples that will need updating? Think there was a post where Paul mentioned this somewhere?
    This thread.
    https://forum.pjrc.com/threads/62473...ments-checking

  17. #17
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,225
    I've never heard of this syntax either.
    So far I've used it only for 64bit variables where this is the only way (I know of) to 'printf' them.

    @mjs513: funny how complicated a simple thing like printing an 8bit variable can get :-).

    IMHO, most of the code written here is tightly coupled to the used processor anyway. So, using all this complicated syntax just to get platform independent printfs for platform dependent code seems a bit, say, overengineered to me.
    I like the new printf warnings but I personally think fixing it by lu, lx etc. should be good enough in most cases.

  18. #18
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    Quote Originally Posted by PaulStoffregen View Post
    I've never heard of this syntax either.

    This thread.
    https://forum.pjrc.com/threads/62473...ments-checking
    Was just playing with the different types and added results to my previous posts. Looking at inttypes.h appears there are a few more variants for PRIxxxx usage as well:
    Which i think is defined as:
    • Least-width integer types that are guaranteed to be the smallest type available in the implementation, that has at least specified number n of bits. Guaranteed to be specified for at least N=8,16,32,64.
    • Fastest integer types that are guaranteed to be the fastest integer type available in the implementation, that has at least specified number n of bits. Guaranteed to be specified for at least N=8,16,32,64.


    ---https://en.wikipedia.org/wiki/C_data_types#inttypes.h

  19. #19
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    Quote Originally Posted by luni View Post
    So far I've used it only for 64bit variables where this is the only way (I know of) to 'printf' them.

    @mjs513: funny how complicated a simple thing like printing an 8bit variable can get :-).

    IMHO, most of the code written here is tightly coupled to the used processor anyway. So, using all this complicated syntax just to get platform independent printfs for platform dependent code seems a bit, say, overengineered to me.
    I like the new printf warnings but I personally think fixing it by lu, lx etc. should be good enough in most cases.
    I agree with you on how something simple can get overly complicated. Always subscribed to the KISS principal

  20. #20
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    700
    I've made a pull request here for some more SPI transfer functions for the Teensy 4.x. These can offer a significant speed improvement when you are sending large buffers such as pixel data for displays, is there any chance this can make it into a beta for testing?

  21. #21
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,084
    Has anyone looked at the new map() function yet?

    Several issues were reported on these 2 threads:

    https://forum.pjrc.com/threads/63230...uino-vs-teensy

    https://forum.pjrc.com/threads/44503...l=1#post241232

    There is also quite a bit about map() problems on Arduino's issue trackers. Here's a message where Cristian Maglie (then Arduino's lead developer) compared 3 implementations and concluded "there isn't still a good solution".

    https://github.com/arduino/ArduinoCo...mment-69585614

    My hope is we'll finally have that "good solution" in Teensy, where the results are correct at the extremes of the mapped range and the numbers are fairly distributed throughout the range, and no weird non-linearity exists if you extrapolate beyond the mapped range (within numerical range of 32 bit long, of course).

    I will admit, the new implementation is probably slower. How much I don't know. Also unknown is whether just using 32 bit float on Teensy 3.5 & 3.5 and maybe 64 bit double on Teensy 4.x would be faster than such a complicated integer-only approach?

  22. #22
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,084
    Quote Originally Posted by vjmuzik View Post
    is there any chance this can make it into a beta for testing?
    I'm not eager to extend the SPI library public API this way, so as written, no, probably not.

    But I would be happy to merge this if it didn't change the public API. Maybe some trickery with inline methods and possibly __builtin_const_p could let these be private functions that get automatically used when the inputs are conducive?

  23. #23
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,918
    I have a PR pending on adding a function to DMAChannel.h to allow ISR to be executed at specific interrupt level.

  24. #24
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,909
    Quote Originally Posted by PaulStoffregen View Post
    Has anyone looked at the new map() function yet?

    Several issues were reported on these 2 threads:

    https://forum.pjrc.com/threads/63230...uino-vs-teensy

    https://forum.pjrc.com/threads/44503...l=1#post241232

    There is also quite a bit about map() problems on Arduino's issue trackers. Here's a message where Cristian Maglie (then Arduino's lead developer) compared 3 implementations and concluded "there isn't still a good solution".

    https://github.com/arduino/ArduinoCo...mment-69585614

    My hope is we'll finally have that "good solution" in Teensy, where the results are correct at the extremes of the mapped range and the numbers are fairly distributed throughout the range, and no weird non-linearity exists if you extrapolate beyond the mapped range (within numerical range of 32 bit long, of course).

    I will admit, the new implementation is probably slower. How much I don't know. Also unknown is whether just using 32 bit float on Teensy 3.5 & 3.5 and maybe 64 bit double on Teensy 4.x would be faster than such a complicated integer-only approach?
    Was looking that over this morning and planned on testing. That cmaglie sketch helps. I changed it to read:
    Code:
    // This is the original map() function in Arduino Core
    long map1(long x, long in_min, long in_max, long out_min, long out_max)
    {
      return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
    }
    
    // This is the same but with the +1 "range extrension" as suggested by st42
    long mapPlus1(long x, long in_min, long in_max, long out_min, long out_max)
    {
      return (x - in_min) * (out_max - out_min + 1) / (in_max - in_min + 1) + out_min;
    }
    
    // This is another version of map with rounding done only with integer calculations
    // as suggested by M.Kooijman
    long mapRound(long x, long in_min, long in_max, long out_min, long out_max)
    {
      return ((x - in_min) * (out_max - out_min) + (in_max - in_min)/2) / (in_max - in_min) + out_min;
    }
    
    void setup(void) {
    
            Serial.begin(115200);
            delay(2000);
            long x;
            Serial.printf("Range 0-20 to 0-4\n");
            Serial.printf("     x     map  map1  map(+1) map(round)\n");
            for (x=-10; x<=30; x++) {
                    Serial.printf("%6ld %6ld %6ld %6ld %6ld\n", x,
                            map(x, 0, 20, 0, 4),
                            map1(x, 0, 20, 0, 4),
                            mapPlus1(x, 0, 20, 0, 4),
                            mapRound(x, 0, 20, 0, 4));
            }
    
            Serial.printf("\n\n");
            Serial.printf("Range 0-5 to 0-1023\n");
            Serial.printf("     x     map  map1  map(+1) map(round)\n");
            for (x=-5; x<=10; x++) {
                    Serial.printf("%6ld %6ld %6ld %6ld %6ld\n", x,
                            map(x, 0, 5, 0, 1023),
                            map1(x, 0, 5, 0, 1023),
                            mapPlus1(x, 0, 5, 0, 1023),
                            mapRound(x, 0, 5, 0, 1023));
            }
    }
    
    void loop() {}
    with the results:
    Code:
    Range 0-20 to 0-4
         x     map  map1  map(+1) map(round)
       -10     -2     -2     -2     -1
        -9     -2     -1     -2     -1
        -8     -2     -1     -1     -1
        -7     -1     -1     -1      0
        -6     -1     -1     -1      0
        -5     -1     -1     -1      0
        -4     -1      0      0      0
        -3     -1      0      0      0
        -2      0      0      0      0
        -1      0      0      0      0
         0      0      0      0      0
         1      0      0      0      0
         2      0      0      0      0
         3      1      0      0      1
         4      1      0      0      1
         5      1      1      1      1
         6      1      1      1      1
         7      1      1      1      1
         8      2      1      1      2
         9      2      1      2      2
        10      2      2      2      2
        11      2      2      2      2
        12      2      2      2      2
        13      3      2      3      3
        14      3      2      3      3
        15      3      3      3      3
        16      3      3      3      3
        17      3      3      4      3
        18      4      3      4      4
        19      4      3      4      4
        20      4      4      4      4
        21      4      4      5      4
        22      4      4      5      4
        23      5      4      5      5
        24      5      4      5      5
        25      5      5      5      5
        26      5      5      6      5
        27      5      5      6      5
        28      6      5      6      6
        29      6      5      6      6
        30      6      6      7      6
    
    
    Range 0-5 to 0-1023
         x     map  map1  map(+1) map(round)
        -5  -1023  -1023   -853  -1022
        -4   -819   -818   -682   -818
        -3   -614   -613   -512   -613
        -2   -409   -409   -341   -408
        -1   -205   -204   -170   -204
         0      0      0      0      0
         1    205    204    170    205
         2    409    409    341    409
         3    614    613    512    614
         4    818    818    682    818
         5   1023   1023    853   1023
         6   1228   1227   1024   1228
         7   1432   1432   1194   1432
         8   1637   1636   1365   1637
         9   1841   1841   1536   1841
        10   2046   2046   1706   2046
    Now have to figure the output out and reread the rest of the issue.

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,084
    I should have mentioned, another property some people are expecting is identical result for "reverse" mapping.

    In other words, ideally these should give the same result for all inputs:

    map(x, 0, 5, 0, 1023);
    map(x, 5, 0, 1023, 0);

    And these 2 should give the same result as the 2 above, but "reversed"

    map(x, 0, 5, 1023, 0);
    map(x, 5, 0, 0, 1023);

    Of course Arduino's map() doesn't do any of this, and I do not believe any of the proposed map() functions on their issue trackers do either, especially when considering extrapolating beyond the mapped range.

Posting Permissions

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