PDA

View Full Version : Teensyduino 1.49 Beta #5



Paul
01-11-2020, 07:02 PM
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 (https://forum.pjrc.com/threads/58817-Teensyduino-1-49-Beta-4)

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

ETMoody3
01-11-2020, 10:43 PM
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...

jkoffman
01-12-2020, 03:59 PM
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

defragster
01-12-2020, 05:52 PM
...

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

PaulStoffregen
01-12-2020, 06:47 PM
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.

defragster
01-12-2020, 09:16 PM
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:

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 (https://forum.pjrc.com/threads/58249-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.

KE4EST
01-13-2020, 01:24 AM
So far so good...Win 10.

PhilippeA
01-13-2020, 07:23 AM
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)

defragster
01-13-2020, 08:48 AM
@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?

PaulStoffregen
01-13-2020, 09:05 AM
...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.

PaulStoffregen
01-13-2020, 09:12 AM
- 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.

PhilippeA
01-13-2020, 09:49 AM
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

defragster
01-13-2020, 09:49 AM
...
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

PhilippeA
01-13-2020, 09:52 AM
@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

PaulStoffregen
01-13-2020, 10:20 AM
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.

PhilippeA
01-13-2020, 10:49 AM
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

PaulStoffregen
01-13-2020, 08:33 PM
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.

PhilippeA
01-13-2020, 09:08 PM
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

defragster
01-13-2020, 11:09 PM
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

ghostintranslation
01-14-2020, 12:24 AM
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?

defragster
01-14-2020, 01:16 AM
@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:


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

PaulStoffregen
01-14-2020, 01:25 AM
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...

defragster
01-14-2020, 01:38 AM
...
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 (https://forum.pjrc.com/threads/57894-Teensyduino-1-48-Beta-3?p=218037&viewfull=1#post218037)

@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

...

ghostintranslation
01-15-2020, 09:48 PM
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?

PaulStoffregen
01-15-2020, 10:12 PM
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.

ETMoody3
01-15-2020, 10:21 PM
The question seems clear.

The functionality this user is concerned with is 4 posts above. It is USB audio for the Teensy 4, a model getting plenty of press in "maker circles" about its speed and capability, but little information about the fact that it is still a work in progress.

Desiring a warning about work in progress regarding functionality common to the product family is not unreasonable. Being annoyed that a purchase was ... premature is not unreasonable.

Frank B
01-15-2020, 10:27 PM
Was USB-Audio advertised for T4? Or mentioned anywhere?
Personally, I find other USB-features more interesting - like MTP - and would prefer that. But hey, that's a hobby and I can wait.
I don't like the technique behind USB, or, more exact, I don't want to dig into that... Otherwise I would try to help or try to add it myself, but in this case... sorry, no :)

ghostintranslation
01-15-2020, 10:30 PM
I'm talking about the audio over USB yes. Nothing was letting me know it wouldn't be there for months on Teensy 4.0 and in my project I am using it.
I didn't expected the new version of Teensy to be backward on that because it wasn't advertised.
So I guess I'll have to wait but I hope this will come back. It is just frustrating.

PaulStoffregen
01-15-2020, 11:38 PM
Yes, I know it's frustrating. :(

In a perfect world, we would have implemented absolutely every feature from Teensy 3.x before releasing Teensy 4.0. The the reality is I'm not that good. PJRC isn't that good. And if you compare to pretty much every other product out there, almost nobody is. Even Raspberry Pi 4 still is features of Pi 3 like USB boot to be delivered in forthcoming firmware updates.

Teensy 4.0 was in private development for well over a year, then a public beta test for about 8 months. We did get a pretty large portion of the feature list working during that time. Also during that time, there was a growing feedback from people watching the beta test that could be best described as "shut up and take my money".

18767

We couldn't keep it in beta another year, not selling any and keeping *everyone* waiting without any access to the hardware. There had to come a point where the beta was cut off and we started to actually sell hardware.

Since then, development has continued at a pretty good pace, as anyone can see from the long lists of changes and improvements on each version.

Also yes, ideally we would have top-notch documentation with a huge feature list or matrix. We had a list during the beta test, but even then that list regularly fell behind. Maintaining that sort of documentation as things are rapidly changing is a lot of work. If I or others who wish to contribute put our time into that, it means hours not going into investigating and fixing bugs, porting libraries, and implementing missing features.

And I am planning to put several solid days into documentation soon. But it's not going to be a moving-target feature list. So much documentation work is much more urgently needed. Near the top of my list is filling in the memory model stuff, which was about 80% written a couple months ago, but lacks examples and more specific usage info (because 1.49 was coming, with the FLASHMEM keyword).

USB audio will happen. I know you wanted that, and it's disappointing we wrapped up 1.49 without it. But please try to understand there's only a limited number of hours in every day. Things can only improve at a certain rate, so time has to be prioritized. USB MIDI & HID, and Wire lib stability on troublesome chips, and the missing I2S features too priority.

ghostintranslation
01-16-2020, 12:25 AM
I totally understand why everything is not there yet.

A complete documentation would be great but also not necessary, only a quick note on those obvious things that where there before but are not back yet, or on the obvious things that just doesn't work yet would be enough.

As a more obvious example, when I received the Teensys (back in november/december) the Midi over USB wasn't even there and that's a crucial part of what I'm doing and nothing was warning me on the site. Now it is back and as you said Audio over USB will be back too later.

I'm not blaming you or anyone about the work, I know it is a lot of work. But a few notes advertising on the obvious missing things on the page of the site would be nice to order knowingly.

Anyway I'm glad that it is coming back later.

Keep up the good work :)

TDMedia
01-18-2020, 09:24 PM
Fedora 30, Arduino 1.8.10, on Teensy 4.

I'm doing some prep work to replace a Teensy LC which I've been using as a convenient tabletop IR remote for a video switch on my desk, with a T4, but I'm running into trouble getting IRsend to work on the T4. From what I can tell (in hardware/teensy/avr/libraries/IRremote/boarddefs.h), the transmit pin on the T4 is pin 7, so I hooked up my IR LED the same way I did with my working LC, except using pin 7, and it doesn't seem to be working. I tested the sketch below on two T4 boards to no avail. I'm wondering if anyone else could duplicate my results or point me to a problem with what I'm doing.

Edit to say: I've confirmed the pin is working using other visible-light LEDs.


#include <IRremote.h>

IRsend irsend;

void setup() {
pinMode(13, OUTPUT);
}

void loop() {
digitalWrite(13, HIGH);
Serial.println("Sending 'A1' signal to LED...");
irsend.sendNEC(0x1FE48B7, 32);
irsend.sendNEC(0xFFFFFFFF, 0);
digitalWrite(13, LOW);
delay(1000);
}

Dario Amabile
01-30-2020, 07:21 AM
Hello everybody. I don't know if I'm writing in the right forum. A question. I have to buy a Teensy. If I buy a teensy 4 is it recognized as a midi tool by windows? Or from OSX? From what I understand in teensyduino 1.49 have implemented this possibility. If I can't do it with the Teensy 4 I will buy a Teensy 3.6.

KurtE
01-30-2020, 11:58 AM
Hello everybody. I don't know if I'm writing in the right forum. A question. I have to buy a Teensy. If I buy a teensy 4 is it recognized as a midi tool by windows? Or from OSX? From what I understand in teensyduino 1.49 have implemented this possibility. If I can't do it with the Teensy 4 I will buy a Teensy 3.6.

You should probably read the release notes for Teensyduino 1.49... https://forum.pjrc.com/threads/59054-Teensyduino-1-49-Released
I am pretty sure it supports USB-MIDI... There are still a few USB types like Audio, which is not yet supported, but most of the types are now there.