Teensyduino 1.49 Beta #5

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a fifth beta test for Teensyduino 1.49.


Linux 32 bit:
https://www.pjrc.com/teensy/td_149-beta5/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_149-beta5/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_149-beta5/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_149-beta5/TeensyduinoInstall.linuxaarch64

MacOS Catalina 10.15:
https://www.pjrc.com/teensy/td_149-beta5/Teensyduino_MacOS_Catalina.zip

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

Windows:
https://www.pjrc.com/teensy/td_149-beta5/TeensyduinoInstall.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
 
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...
 
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
 
...

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
 
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.
 
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:
50°C	 loopTime=6934840 	run mins=42.729317	F_CPU=600000000
49°C	 loopTime=6934841 	run mins=42.844900	F_CPU=600000000
[B][U]50°C	 loopTime=107618035 	run mins=44.638533	F_CPU=600000000[/U][/B]
50°C	 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:
49°C 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.
47°C loopTime=6934844 run mins=555.793200 F_CPU=600000000
Both displays Wire and Wire2 still fast cycling the Adafruit test sequence.
 
Last edited:
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:
@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?
 
...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.
 
- 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.


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.
 
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
 
...
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
 
@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
 
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
 
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.
 
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
 
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:
49°C 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
 
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?
 
@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:
35°C	 loopTime=357230 	run mins=0.157983	[B][COLOR="#FF0000"]F_CPU=996000000[/COLOR][/B]

with this:
teensy40.menu.speed.1008=1.008 GHz (overclock, cooling req'd)
teensy40.menu.speed.1008.build.fcpu=1008000000

I do get this:
43°C loopTime=357059 run mins=0.157750 F_CPU=1008000000
 
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.


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...
 
...
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
@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

...
 
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?
 
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.
 
Status
Not open for further replies.
Back
Top