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

Thread: Teensyduino 1.49 Beta #5

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

    Teensyduino 1.49 Beta #5

    Here is a fifth beta test for Teensyduino 1.49.


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

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

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

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

    MacOS Catalina 10.15:
    https://www.pjrc.com/teensy/td_149-b...S_Catalina.zip

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

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


    Changes since Teensyduino 1.49-beta4

    Improve Wire library FIFO handling for Teensy 4.0
    ADC library updated for Teensy 4.0 (Pedvide)
    Fix priority on 3rd & 4th IntervalTimer on Teensy 4.0 (KurtE)
    Audio library I2S slave mode support on Teensy 4.0
    Fix unused USB interface string descriptors

  2. #2
    Senior Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    143
    Linux mint 19.3 "Tricia", Arduino 1.8.10, T4 final beta hardware.

    Getting "Error when uploading sketch" warning, but the sketch actually uploads and appears to execute.

    This occurred with "usbMidi InputFunctionsBasic" and "Blink".


    Update: this did not happen with a production T4, just the beta unit...

  3. #3
    Senior Member
    Join Date
    Dec 2015
    Posts
    167
    Hey Paul,

    Just curious, why does the Catalina version have to have the full Arduino app included? Is this something that you're hoping to revert back to a separate installer eventually?

    Thanks!

    Josh

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    Quote Originally Posted by jkoffman View Post
    ...

    Just curious, why does the Catalina version have to have the full Arduino app included? Is this something that you're hoping to revert back to a separate installer eventually?
    Not sure of the details and future form - but the new restrictions on Mac Secure install led to this after some effort and signing work by Paul AFAIK

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by jkoffman View Post
    Just curious, why does the Catalina version have to have the full Arduino app included?
    Apple no longer allows the installer approach.

    Technically, Gatekeeper hasn't permitted this for quite some time, but the checking has been rather lax, so we were always able to work around it until Catalina.


    Is this something that you're hoping to revert back to a separate installer eventually?
    No, we're forever abandoning the installer for MacOS. For a while we'll still offer both on the website. Eventually the installer will be dropped completely. Unless Apple sharply reverses course, the installer will never work on future MacOS.

    I considered trying more intense workarounds, but the new notarization stuff is designed to strictly enforce Apple's rules. I'm done with workarounds for MacOS.

    In the distant future, I hope to support installation by Arduino's boards manager, perhaps only in their new Pro IDE. Arduino wants us to move that way too. But much work is needed because their boards manager doesn't provide everything Teensy needs. We all currently much too busy releasing new hardware and libraries to work on lower priority stuff.... so it's unlikely to happen anytime soon.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    Installed TD 1.49b5 on IDE 1.8.10 on Win 10 no trouble.

    Tested SSD1306 i2c on a Teensy 4.0 FRDM board with native Wire pulled out and it worked, wired second display to Wire1 (also Wire2) and it worked, then both Wire and Wire1 worked together { at 4MHz } with duplicate display()/display1() code, Moved Wire1 display to Wire2 pins and that also works in parallel with Wire display. The code is the Adafruit "ssd1306_128x64_i2c" sample but edited to have nanosecond delays() between the display test func()'s and then rather than finish on falling flakes it returns to iterate on the series of tests in succesion that is 3.5 seconds for one display and 6.9 secs using shared code and common delay()'s.

    Something odd happened here ? The displays were stalled when I looked - then I touched the T4 running Wire/Wire2 and it popped back to life after pausing almost 2 minues? Restarted ... will look again over time:
    Code:
    50C	 loopTime=6934840 	run mins=42.729317	F_CPU=600000000
    49C	 loopTime=6934841 	run mins=42.844900	F_CPU=600000000
    50C	 loopTime=107618035 	run mins=44.638533	F_CPU=600000000
    50C	 loopTime=6934845 	run mins=44.754117	F_CPU=600000000
    Also a quick test confirming the T4-rtc-setting-with-time-change gives a valid time matching Win 10 PC after upload.

    <edit> restarted dual ssd1306's and both running now as they have before for much longer than 44 mins now showing this with no halt:
    49C loopTime=6934843 run mins=100.751183 F_CPU=600000000
    <edit 2> Much more runtime and no trouble - same touch that made it start may relate to it stopping - dry static air and open board/connects on my desk? Temp was a tad higher when woodstove was fired up.
    47C loopTime=6934844 run mins=555.793200 F_CPU=600000000
    Both displays Wire and Wire2 still fast cycling the Adafruit test sequence.
    Last edited by defragster; 01-13-2020 at 06:32 AM.

  7. #7
    Junior Member KE4EST's Avatar
    Join Date
    Nov 2017
    Location
    Far Western NC, USA
    Posts
    17
    So far so good...Win 10.

  8. #8
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Hello,

    I am the guy using teensy 4 with fastled.
    I have tested the beta 4 with fastled serial: I have 2 led strips connected with fastled and WS2812Serial plus an I2C connection with a rapsberry.

    The fastled and WS2812 do work perfectly (even with 2 led strips in parallel) ...but I still have I2C errors when using the fastled.show(). The I2C error stops when I do not call fastled.show().
    The errors are not systematic and do occur much less than when using standard WS2812.
    In term of interrupts, my global Teensy program use: I2C, Serial (USB console) and millis().
    I have seen that you issued a beta 5 version. Do you think it can improve ?

    Regards
    Philippe

    PS:
    - I have to manually reset the Teensy 4 when uploading code..
    - the total available ram is now 512 Ko (2nd ram bank useless ?)
    - the total emulated EEPROM size is 1Ko... I should think it could be interesting to increase it to 4 ko
    - I would like to download program via I2C. My dream: There is way to flash the program that is is in RAM. So I would transfert the new program via I2C in the RAM (best would be the unused 512 ko), then the running program call a function that flashes the new program. (Any other solution will be fine)
    Last edited by PhilippeA; 01-13-2020 at 07:33 AM.

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    @PhillippeA:
    Best to try 1.49b5 to see - there were i2c changes for robustness.

    Manual reset is typically only when USB Serial gets functionally broken with bad code, or the code prevents the USB Stack from detecting the request to enter program mode - busy loop or other of some sort.
    The second 512KB of RAM is unique and detached so now excluded from the reported RAM to prevent crashes - it can be fully used and there is some system use for USB stack freeing up lower RAM. It can be allocated dynamically or statically at compile time - see the PJRC T_4 product page about memory.
    EEPROM size requires backing FLASH in a multiple of the allocated size. 1KB was chosen as a compromise for lifespan and the amount of FLASH it consumes.
    Just recently I saw a post of a user developed non-USB upload for T_4, so it can be done other ways. Find that thread and examine it - but it isn't PJRC supported.

    Paul - with larger FLASH might the T_4.1 present a larger EEPROM area?

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by PhilippeA View Post
    ...but I still have I2C errors when using the fastled.show(). The I2C error stops when I do not call fastled.show().
    Do you want me to look into this?

    Nothing will be done unless you give me a test case that reproduces the problem. I'm not going to write code from scratch on both Teensy and Raspberry Pi, guessing everything you've done. Investigating these sorts of issues takes a lot of work, even when the precise code is provided and clear steps to reproduce the problem are given. When I have to guess, it's just too much work with too little chance of success.


    I have seen that you issued a beta 5 version. Do you think it can improve ?
    If you're using the Wire library (Teensy is the I2C master, Raspberry Pi is the I2C slave), odds are good you'll see some changes. The Wire lib was improved quite a lot in this 5th beta. If you're using other code than the Wire library, odds are you'll see little or no change, if you were using 1.49-beta4 previous.

    But even that is guessing, as your message doesn't even say which libs you're using or how you're doing the I2C communication, or even which version of the software you're currently using.

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by PhilippeA View Post
    - the total emulated EEPROM size is 1Ko... I should think it could be interesting to increase it to 4 ko
    Yes, it can be increased, but the maximum is 3825 bytes. To change the size, edit {Arduino}/hardware/teensy/avr/cores/teensy4/avr/eeprom.h. Look for "E2END".

    Larger size means you'll have less wear leveling, since the amount of flash memory used does not change. Probably not an issue, unless you change the data frequently.


    Quote Originally Posted by defragster View Post
    with larger FLASH might the T_4.1 present a larger EEPROM area?
    Too early and wrong place to talk about this.

    Right now, I'm pretty focused on wrapping up 1.49. I had meant to release before Jan 1. Now we're nearly 2 weeks into the year. Really want to finish this and get a stable 1.49 release, since so much has improved and almost everyone is still using the old 1.48 release.

  12. #12
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Quote Originally Posted by PaulStoffregen View Post
    Do you want me to look into this?

    Nothing will be done unless you give me a test case that reproduces the problem. I'm not going to write code from scratch on both Teensy and Raspberry Pi, guessing everything you've done. Investigating these sorts of issues takes a lot of work, even when the precise code is provided and clear steps to reproduce the problem are given. When I have to guess, it's just too much work with too little chance of success.




    If you're using the Wire library (Teensy is the I2C master, Raspberry Pi is the I2C slave), odds are good you'll see some changes. The Wire lib was improved quite a lot in this 5th beta. If you're using other code than the Wire library, odds are you'll see little or no change, if you were using 1.49-beta4 previous.

    But even that is guessing, as your message doesn't even say which libs you're using or how you're doing the I2C communication, or even which version of the software you're currently using.
    Thanks, for fast answer

    the teensy is 1.49 B4
    the I2C lib is https://github.com/Richard-Gemmell/teensy4_i2c as the standard wire library was not working properly in december. The teensy's are slave and the raspberry is master. I will change the teensyduino to 1.49 b5. If wire does now work better in slave mode, I could modify my code to use the standard wire. Please tell me if the slave mode of wire has been improved.

    Regards
    Philippe



    Regards
    Philippe

  13. #13
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    Quote Originally Posted by PaulStoffregen View Post
    ...
    Too early and wrong place to talk about this.

    Right now, I'm pretty focused on wrapping up 1.49. I had meant to release before Jan 1. Now we're nearly 2 weeks into the year. Really want to finish this and get a stable 1.49 release, since so much has improved and almost everyone is still using the old 1.48 release.
    No doubt 4.1 EEPROM not top of list and easy to decide before it ships - but the context was here - and you saw it

    As far as schedule ... it has been a typical or worse holiday season for timely things, half the things on my list are 2019 issues ... and yes Jan 2020 about half gone

  14. #14
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Quote Originally Posted by defragster View Post
    @PhillippeA:
    Best to try 1.49b5 to see - there were i2c changes for robustness.

    Manual reset is typically only when USB Serial gets functionally broken with bad code, or the code prevents the USB Stack from detecting the request to enter program mode - busy loop or other of some sort.
    The second 512KB of RAM is unique and detached so now excluded from the reported RAM to prevent crashes - it can be fully used and there is some system use for USB stack freeing up lower RAM. It can be allocated dynamically or statically at compile time - see the PJRC T_4 product page about memory.
    EEPROM size requires backing FLASH in a multiple of the allocated size. 1KB was chosen as a compromise for lifespan and the amount of FLASH it consumes.
    Just recently I saw a post of a user developed non-USB upload for T_4, so it can be done other ways. Find that thread and examine it - but it isn't PJRC supported.

    Paul - with larger FLASH might the T_4.1 present a larger EEPROM area?
    Thanks for the answers. At least this gives me ideas a way forward
    Philippe

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by PhilippeA View Post
    If wire does now work better in slave mode
    No, sorry, slave most is still not supported by Wire. That's planned for 1.50, but will not happen for 1.49.

  16. #16
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Quote Originally Posted by PaulStoffregen View Post
    No, sorry, slave most is still not supported by Wire. That's planned for 1.50, but will not happen for 1.49.
    At least this is clear, for information the R. Gemmel library is working well in slave mode (but has interference with fastled.show()). So I will just update to 1.49b5, let you know and if not solved, wait for 1.50. So I will work on OTA upgrade.

    Regards

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    I'm leaning towards a final 1.49 software release within the next 24 hours.

    If anyone has a bug or critical issue I should know about, now's the time to mention it. No new features are going into 1.49 at this point, only bug fixes.

  18. #18
    Junior Member
    Join Date
    Jan 2020
    Posts
    14
    Quote Originally Posted by PaulStoffregen View Post
    I'm leaning towards a final 1.49 software release within the next 24 hours.

    If anyone has a bug or critical issue I should know about, now's the time to mention it. No new features are going into 1.49 at this point, only bug fixes.
    Hello, that's still Philippe working on leds,

    I move to beta 5 and have much less error. still analysing but it could be out of interrupt part somewhere in my Raspberry et teensy code (upper part of my protocol… )
    In beta 4 I experienced uploading error as mentionned (need to manually reset the teensy board). It disapeared in beta 5 but sometime
    the teensy monitor console do not restart after download or is writen "offline" though working. I have to kill the Windows and restart it from the Arduino menu 1.8.10 - 1.49-beta 5.

    Not a big issue



    I wish you a nice official 1.49 announcement

    regard

    Philippe

    PS: Late in france,going to bed

  19. #19
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    Quote Originally Posted by PaulStoffregen View Post
    I'm leaning towards a final 1.49 software release within the next 24 hours.

    If anyone has a bug or critical issue I should know about, now's the time to mention it. No new features are going into 1.49 at this point, only bug fixes.
    No problems here in the couple of things I've done. The i2c twin ssd1306's on a T_4.0 are running fine:
    49C loopTime=7993464 run mins=908.496833 F_CPU=600000000
    Used the IDE to compile and upload a few sketches more than a few times after 1.49b5 on IDE 1.8.10 and no issue. And above output and other from the Teensy Ports SerMon showing no trouble statying up on this Win 10 box.

    Also Unpacked T4 with ili9341 on purple touch ( CS#10) and built/upload/ran : DemoSauce, XPT touch ili9341

  20. #20
    Member ghostintranslation's Avatar
    Join Date
    Oct 2019
    Location
    Halifax, NS, Canada
    Posts
    30
    Quote Originally Posted by PaulStoffregen View Post
    I'm leaning towards a final 1.49 software release within the next 24 hours.

    If anyone has a bug or critical issue I should know about, now's the time to mention it. No new features are going into 1.49 at this point, only bug fixes.
    Hi,

    Will the final 1.49 have the USB audio (including the Serial + MIDI + Audio mode) back?

  21. #21
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    @Paul - Boards.txt still shows this
    teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
    teensy40.menu.speed.1008.build.fcpu=1000000000
    Just checked again that still the gives 996 MHz at runtime:
    Code:
    35C	 loopTime=357230 	run mins=0.157983	F_CPU=996000000
    with this:
    teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
    teensy40.menu.speed.1008.build.fcpu=1008000000
    I do get this:
    43C loopTime=357059 run mins=0.157750 F_CPU=1008000000

  22. #22
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by ghostintranslation View Post
    Will the final 1.49 have the USB audio (including the Serial + MIDI + Audio mode) back?
    No, nothing new is coming in the final 1.49 release.

    In fact, since no serious bugs have turned up, the final 1.49 release is going to be nearly identical to 1.49-beta5.


    Quote Originally Posted by defragster View Post
    Just checked again that still the gives 996 MHz at runtime:
    I'm considering this a minor issue. It will not be fixed for 1.49.

    But do remain me later when we start beta testing 1.50...

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,229
    Quote Originally Posted by PaulStoffregen View Post
    ...
    I'm considering this a minor issue. It will not be fixed for 1.49.

    But do remain me later when we start beta testing 1.50...
    Minor indeed ... Maybe memory will be better then - just thought of it again after months seeing it in 1.48 beta #3 ... and that is not in github code to post a fix ... pjrc.com/threads/57894-Teensyduino-1-48-Beta-3
    Quote Originally Posted by defragster View Post
    @Paul - check speed text in boards.txt.

    Selecting :: teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
    Uses :: teensy40.menu.speed.1008.build.fcpu=1000000000

    Starts with F_CPU_ACTUAL :: F_CPU=996000000

    Changing to this works:: teensy40.menu.speed.1008.build.fcpu=1008000000

    F_CPU=1008000000

    ...

  24. #24
    Member ghostintranslation's Avatar
    Join Date
    Oct 2019
    Location
    Halifax, NS, Canada
    Posts
    30
    Quote Originally Posted by PaulStoffregen View Post
    No, nothing new is coming in the final 1.49 release.
    Well, I would have appreciated a note on the site before I buy 2 Teensy 4.0 + 2 audio boards that I can't use for my projects that work with Teensy 3.2 (bought on November 2019). Or maybe I missed the note?

    Anyway what would be the release date for this functionality to be back? Is there any plan?

  25. #25
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,516
    Quote Originally Posted by ghostintranslation View Post
    Anyway what would be the release date for this functionality to be back?
    I don't understand your question. Which functionality are you asking about? Audio shields? USB streaming audio?

    The audio library does support I2S on Teensy 4.0 and works great with the audio shields. Version 1.49 add fixed bugs in I2S2 and supported slave mode on the main I2S port, and fixed several minor issues with various audio features.

    But USB audio hasn't been done for Teensy 4.0 yet, and won't be coming within the next few weeks, but next few months looks pretty likely. It's not a simple matter. Isochronous rate feedback is done differently at 480 Mbit/sec speed, so making this work on Teensy 4.0 isn't a simple matter of just reusing code from Teensy 3.x.

    Nothing about those audio shields specifically requires USB audio streaming. They use I2S for the audio, and I2C for control. (and I2C was greatly improved, though the audio shield isn't one of the troublesome devices that prompted the improvements)

    Holding up a stable 1.49 release with so many features people want and so many important fixes would be a terrible mistake.

Posting Permissions

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