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

Thread: Teensyduino 1.50 Released

  1. #26
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,071
    I have no idea why your Mac is saying Teensy Loader requires 10.14. It doesn't (or shouldn't).

    I ran it this way just now on 10.12.6. Here's a screenshot.

    Click image for larger version. 

Name:	screen.jpg 
Views:	23 
Size:	201.6 KB 
ID:	18928

    At least 2 people on Twitter have confirmed it ran on their old Macs with 10.10 Yosemite. One specifically said uploading code to a Teensy 3.2 worked.

    https://twitter.com/bikerglen/status...66258723639296

    https://twitter.com/Dithermaster/sta...77431099793408

  2. #27
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Quote Originally Posted by PaulStoffregen View Post
    I have no idea why your Mac is saying Teensy Loader requires 10.14. It doesn't (or shouldn't).
    I have no idea either.
    But I fixed the problem by copying Teensy.app 1.50 installed in Arduino 1.8.10 to Teensyduino Catalina 10.15 version.

  3. #28
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,071
    Quote Originally Posted by neurofun View Post
    But I fixed the problem by copying Teensy.app 1.50 installed in Arduino 1.8.10 to Teensyduino Catalina 10.15 version.
    Now that's *really* confusing. They've built from same code base using the same Mac (running 10.14 Mojave).

  4. #29
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Quote Originally Posted by PaulStoffregen View Post
    Now that's *really* confusing. They've built from same code base using the same Mac (running 10.14 Mojave).
    Do not want to add to the confusion but did a get info on both files and there are some differences.
    file size
    creation date
    enable app nap option

    Click image for larger version. 

Name:	Screen Shot 2020-02-02 at 05.14.18.png 
Views:	30 
Size:	131.3 KB 
ID:	18930

    I consider for myself this problem fixed but if you want to get to the bottom of this I will gladly help troubleshooting.
    Sadly my HighSierra installer is corrupted and cannot test on a clean OS install.

  5. #30
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Because I was bored, because I put my debugger idea ad-acta and I had to wait for something else, I played with the compiler again - this time
    GCC9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]


    GCC 5.4.1:
    Coremark with -O2: 2313.57
    Coremark with -O2 -fgcse-after-reload -finline-functions : 2344.67
    Coremark with -O3: 2476.88

    GCC 9.2.1:
    Coremark with -O2: 2433.48
    Coremark with -O2 -fgcse-after-reload -finline-functions : 2474.23
    Coremark with -O3: 2399.04

    -O2 is faster, and -fgcse-after-reload -finline-functions gives a little more speed.
    Performance-wise GCC 9.2.1 still does not make much sense (if you choose the right flags - which depend on the version), and there is a regression with -O3.
    Otherwise I couldn't find problems with 9.2.1 and it may have some bugs fixed.

  6. #31
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    935
    I can confirm the compatibility with the core libs. I'm using GCC 9 as default for a couple of weeks now. Didn't notice any issues so far.

    Advantages I found:
    • It is more strict (standard conform) on pointer conversions (it actually found some 'bugs' in my code which GCC 5.4 didn't complain about)
    • It also has a working objDump for the M7. The list files generated by GCC 5.4 are often not readable.
    • Compiler output (errors/warnings) is more nicely formatted

  7. #32
    Member
    Join Date
    Jan 2020
    Location
    Port Elizabeth
    Posts
    51
    I am pleased to say that Teensyduino 1.50 and Arduino 1.8.11 with Teensy 4.0 work nicely on my Ubuntu 19.10. Software reboot works too.

  8. #33
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    1,010
    So it looks like I have the same problem that @neurofun has with the Catalina version. When I try to open the Teensy.app it says it needs 10.14:
    Click image for larger version. 

Name:	Screen Shot 2020-02-04 at 5.51.32 PM.png 
Views:	10 
Size:	27.4 KB 
ID:	18956
    Click image for larger version. 

Name:	T_ISSUE.png 
Views:	308 
Size:	92.8 KB 
ID:	18955
    Got it to work when I copied the 1.50 Teensy.app from another Arduino install I did. I'll try to download the Catalina version again now.

    edit: Teensy.app is still is X out

  9. #34
    Junior Member
    Join Date
    Nov 2019
    Posts
    13
    Admin-less installation on Windows 10 64-bit over Arduino IDE 1.8.11 worked fine.

    The bug with the supposedly required admin rights - probably for installing USB drivers on obsolete Windows versions - is still there though.

  10. #35
    Chiming in here, first time in a while. Teensyduino 1.50 on a macbook pro running 10.15.3 working fine so far.

  11. #36
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    https://www.pjrc.com/teensy/td_libs_LedControl.html which is part of teensyduino uses shiftout(), which is too fast on T4.

    I want to fix it - what is better ?

    a) add own slow _shiftOut for T4 to the library
    b) rewrite it to use SPI - which limits the usable pins
    c) patch Teensyduino and insert the delay to the Core-shiftOut()?

    What do you want?

    Code:
    void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
    {
            uint8_t mask;
            const int dly = 10;
            for (mask=0x80; mask; mask >>= 1) {
                    digitalWrite(dataPin, value & mask);
                    delayNanoseconds(dly);
                    digitalWrite(clockPin, HIGH);
                    delayNanoseconds(dly);
                    digitalWrite(clockPin, LOW);
                    delayNanoseconds(dly);
            }
    }
    Edit: I would vote vor c) to keep Arduino-compatibility.
    In LedControl, it happens for >= 396MHz - my display uses a MAX7219.
    Might be that other chips are even slower..
    Last edited by Frank B; 02-09-2020 at 04:29 PM.

  12. #37
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    @Frank - what about alternate F_CPU_ACTUAL timings? Does the same delay work at 24 and 800 MHz?

  13. #38
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    well, the time is independent from f_cpu, so, the f_cpu should'nt matter (but I have tested up to 960MHz ;-) . (..and I hope the laws of nature have taken T4 into account)
    Last edited by Frank B; 02-09-2020 at 07:24 PM.

  14. #39
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    Quote Originally Posted by Frank B View Post
    well, the time is independent from f_cpu, so, even the speed should'nt matter (but I have tested up to 960MHz ;-) . (..and I hope the laws of nature have taken T4 into account)
    Indeed the time is fixed - but the bus timing changes for the write speed?

  15. #40
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    The only issue I see that it is a little slower - but that's the intention.
    For my max7219 it works without the delays if f_cpu is < 396MHz. So of course one could add a bunch of #ifdefs - would that be better?
    I don't think so. I'd think we have to increase the delays someday and we will find chips (ATMEL? with "shiftIn()" ) where my added delay is too small.

    the bus-mhz does not matter that much here..

  16. #41
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    With T4 having runtime changeable F_CPU an #ifdef would not be perfect - adding a runtime conditional would be time consuming too.

    Thought a test of that code at 24 and 800 MHz would quickly show if the delay ended up being too much or too little since the problem comes from the speed of the T4. Assuming a T_3.6 at 256 MHZ doesn't have this trouble?

  17. #42
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    The delay is (almost) the same for 24 and 800Mhz (it will be a bit more with 24MHz due to the nature of the waiting loop).. But I understand your point - digitalWrite is slower with 24MHz. Edit: Adding an if-statement would slow it down even more, maybe
    Is that an issue? It would be an issue if it was slower than 8-Bit Arduino. I don't think, it is.. anyway, I have no hardware to compare both.

    I've not tried 3.6 - can do that in the next days (don't want to rip my hw now)

  18. #43
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    Quote Originally Posted by Frank B View Post
    The delay is (almost) the same for 24 and 800Mhz (it will be a bit more with 24MHz due to the nature of the waiting loop).. But I understand your point - digitalWrite is slower with 24MHz.
    Is that an issue? It would be an issue if it was slower than 8-Bit Arduino. I don't think, it is.. anyway, I have no hardware to compare both.
    Opps - I thought you had hardware in front of you testing it to see it run to observe and select the delay time in action.

  19. #44
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Quote Originally Posted by defragster View Post
    Opps - I thought you had hardware in front of you testing it to see it run to observe and select the delay time in action.
    No i have no ATMEL-Arduino. I should buy some, some day..
    Shiftout is just too fast for the display ( "too fast" is definitely NOT compatible with ATMEL-Arduino.. ) - it does not work.

    Just try it - the display are sold for 1.- EUR at ebay.
    Edit: Datasheet says, it is good for 10MHz. I doubt Atmel-Arduino can reach that.taken the usual overclocking-possibility into account it's much more.

    We could make it like this, perhaps:
    Code:
    if f_cpu_actual > XY //<-dunno...
            for (mask=0x80; mask; mask >>= 1) {
                    digitalWrite(dataPin, value & mask);
                    delayNanoseconds(shiftOutDly );
                    digitalWrite(clockPin, HIGH);
                    delayNanoseconds(shiftOutDly );
                    digitalWrite(clockPin, LOW);
                   delayNanoseconds(shiftOutDly );
            }
    else 
      same without delays..

  20. #45
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    @defragster:
    What do you think?
    Code:
    static const int shiftOutDly = 10;
    static const int maxSpeedBeforeDelay = 300e6;
    
    void shiftOut_lsbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
    {
      uint8_t mask;
      if (F_CPU_ACTUAL > maxSpeedBeforeDelay)
        for (mask = 0x01; mask; mask <<= 1) {
          digitalWrite(dataPin, value & mask);
          delayNanoseconds(shiftOutDly );
          digitalWrite(clockPin, HIGH);
          delayNanoseconds(shiftOutDly );
          digitalWrite(clockPin, LOW);
          delayNanoseconds(shiftOutDly );
        }
      else
        for (mask = 0x01; mask; mask <<= 1) {
          digitalWrite(dataPin, value & mask);
          digitalWrite(clockPin, HIGH);
          digitalWrite(clockPin, LOW);
        }
    }
    
    void shiftOut_msbFirst(uint8_t dataPin, uint8_t clockPin, uint8_t value)
    {
      uint8_t mask;
      if (F_CPU_ACTUAL > maxSpeedBeforeDelay)
        for (mask = 0x80; mask; mask >>= 1) {
          digitalWrite(dataPin, value & mask);
          delayNanoseconds(shiftOutDly );
          digitalWrite(clockPin, HIGH);
          delayNanoseconds(shiftOutDly );
          digitalWrite(clockPin, LOW);
          delayNanoseconds(shiftOutDly );
        }
      else
        for (mask = 0x01; mask; mask >>= 1) {
          digitalWrite(dataPin, value & mask);
          digitalWrite(clockPin, HIGH);
          digitalWrite(clockPin, LOW);
        }
    }
    Last edited by Frank B; 02-09-2020 at 07:23 PM.

  21. #46
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Quote Originally Posted by defragster View Post
    Assuming a T_3.6 at 256 MHZ doesn't have this trouble?
    Tested this - works wonderful.

  22. #47
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    Both F_CPU_ACTUAL and delayNanoseconds are new for T_4 and only #ifdef __1062__

    But that seems reasonable to test with. Though not sure how close delayNanoseconds(10) is to accurate for that low value?

    I wrote a test delayCycles() on T4 and min execution wasn't good until about 20 cycles - and then it went in groups of 4 cycles. That seems to agree with 10 and 3 ns request below?

    Check my math/code but I get:
    Code:
    100 ns cycles == 71
    100 ns time == 118.333333
    and ::
    Code:
    10 ns cycles == 18
    10 ns time == 30.000000
    and:
    Code:
    3 ns cycles == 19
    3 ns time == 31.666667
    with::
    Code:
    uint32_t yy = ARM_DWT_CYCCNT;
    #define iWait 10
    delayNanoseconds(iWait);
    yy = ARM_DWT_CYCCNT-yy;
      Serial.print(iWait);
      Serial.print(" ns cycles == ");
      Serial.println(yy);
      double xx=yy*1000000 ;
      xx = xx/(double)F_CPU_ACTUAL;
      Serial.print(iWait);
      Serial.print(" ns time == ");
      Serial.printf("%f\n",xx*1000);

  23. #48
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    Quote Originally Posted by defragster View Post
    Both F_CPU_ACTUAL and delayNanoseconds are new for T_4 and only #ifdef __1062__
    Sure - it's in the T4 core...
    Quote Originally Posted by defragster View Post
    But that seems reasonable to test with. Though not sure how close delayNanoseconds(10) is to accurate for that low value?
    Don't know, is not important and does not matter - 10 is the lowest value that works. It's not the goal to get a reproducable timing. (SPI would be better, then) It should just shift out the data. But not too fast.
    As said - we may have to increase this value even more. Depends on the receiving chips.

  24. #49
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,750
    Good it works! I thought you had hardware to test on Teensy, I wasn't worried about ATMEL.

    Wasn't sure if this was for generic lib change or for your purposes when #ifdef would be needed.

  25. #50
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,906
    I have hardware to test on teensy. But I have no Atmel*.
    shiftOut is in the core and is part of arduino-compatibility! (digital.c)


    *By the way, I really do not care if it works on the Atmel or other Arduinos. But it should'nt be slower than Atmel - thank you for pointing out 24MHz...!
    Last edited by Frank B; 02-10-2020 at 07:07 AM.

Posting Permissions

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