Teensyduino 1.50 Beta #1

[Paul]

Here is a first beta test for Teensyduino 1.50.


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

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

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

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

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

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

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


Changes since Teensyduino 1.49:

Support for Arduino 1.8.11
Fix soft reboot on Teensy 4.0
Fix 1 GHz in Tools > CPU Speed
Fix IntervalTimer minimum on Teensy 4.0 (KurtE)
Add defines for ethernet and PLLs
Add defines ARDUINO_TEENSY## for each board

[KurtE]

Just installed on Windows 10 machine on 1.8.11, so far appears to be working.

Should mention, it does appear like 1.8.11 may have addressed some of the issues of 1.8.10 where it appeared to rebuild everything everytime

[mjs513]

Morning all
Downloaded and installed on a Win10x64 no issues.

Did see that 1Ghz went to 1.008Ghz. The soft boot fix works that you put in. Tested with tempmon when panic temp is exceeded as well can confirm that Watchdog timer is working as well. Also retested @KurtE's ST7789 CLock display since I had it all set up anyway. Also tested a bunch of Wire devices on Wire1 and Wire with no issues this this beta anyway.

[KurtE]

@mjs513 - Note: my clock display will NOT work with currently in the build ST7735_t3, as tft.drawLine is busted in frame buffer mode.

Simple to fix: It is currently part of a Pull Request: https://github.com/PaulStoffregen/ST7735_t3/pull/9
But in the mean time (and probably after this Teensyduino release...

Simple change two #ifdef lines (673, 696) in ST7735_t3.h
from:

		#ifdef ENABLE_ST7735_FRAMEBUFFER

To:

		#ifdef ENABLE_ST77XX_FRAMEBUFFER

Again not a show stopper

[MichaelMeissner]

I just got an Adafruit Airlift featherwing, and I compiled the ScanNetworks example program. It compiles fine for the Teensy 3.6, but it gives the following error for Teensy 4.0. I have tried both Teensydunio 1.49 with Arduino 1.8.10 and Teensydunio 1.50 beta1 with Arduino 1.8.11.

Here is the Adafruit version of the WiFiNANA library that includes pin definitions for the various Featherwings:

• https://github.com/adafruit/WiFiNINA.git

Here is the error:

Arduino: 1.8.11 (Linux), TD: 1.50-beta1, Board: "Teensy 4.0, Serial, 600 MHz, Faster, US English"

In file included from /rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/IPAddress.h:29:0,
                 from /home/meissner/Arduino/libraries/Adafruit_WiFiNINI/utility/wifi_drv.h:26,
                 from /home/meissner/Arduino/libraries/Adafruit_WiFiNINI/WiFi.cpp:21:
/rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Printable.h:37:13: error: 'size_t' does not name a type
     virtual size_t printTo(Print& p) const = 0;
             ^
In file included from /rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Stream.h:24:0,
                 from /rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Udp.h:40,
                 from /home/meissner/Arduino/libraries/Adafruit_WiFiNINI/WiFiUdp.h:24,
                 from /home/meissner/Arduino/libraries/Adafruit_WiFiNINI/utility/wifi_drv.h:27,
                 from /home/meissner/Arduino/libraries/Adafruit_WiFiNINI/WiFi.cpp:21:
/rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Print.h: In member function 'size_t Print::print(const Printable&)':
/rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Print.h:82:51: error: 'const class Printable' has no member named 'printTo'
  size_t print(const Printable &obj)  { return obj.printTo(*this); }
                                                   ^
/rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Print.h: In member function 'size_t Print::println(const Printable&)':
/rock/shared/arduino/teensy-1.50beta1-1.8.11/hardware/teensy/avr/cores/teensy4/Print.h:102:53: error: 'const class Printable' has no member named 'printTo'
  size_t println(const Printable &obj)  { return obj.printTo(*this) + println(); }
                                                     ^
Error compiling for board Teensy 4.0.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Now, if I go into hardware/teensy/avr/cores/teensy4/Printable.h, and add an include of 'stdlib.h', the example compiles file. But the Teensy 3 version does not need this. If you look at the Teensy3 version, it includes 'new.h', and inside of 'new.h' is an include of 'stdlib.h'. In the Teensy4 version, it does not include 'new.h' (and in fact 'new.h' no longer exists in the Teensy4 directory).

So either 'Printable.h' needs to include 'stdlib.h' or whatever includes it needs to include the file.

[mjs513]

@mjs513 - Note: my clock display will NOT work with currently in the build ST7735_t3, as tft.drawLine is busted in frame buffer mode.

Simple to fix: It is currently part of a Pull Request: https://github.com/PaulStoffregen/ST7735_t3/pull/9
But in the mean time (and probably after this Teensyduino release...

Simple change two #ifdef lines (673, 696) in ST7735_t3.h
from:

		#ifdef ENABLE_ST7735_FRAMEBUFFER

To:

		#ifdef ENABLE_ST77XX_FRAMEBUFFER

Again not a show stopper

Yep - already pulled in the fix and tested it with 1.50-beta1

[KurtE]

It appears to also run on my older MAC with catalina on it... Takes forever to download, but...

Note: tested simple blink program, plus simple text output program

void setup() {
  // put your setup code here, to run once:
  Serial.begin(1);

}
uint16_t loop_count = 0;
void loop() {
  // put your main code here, to run repeatedly:
  loop_count++;
  Serial.printf("Loop Count printf: %d\n", loop_count);
  Serial.print("loop count println: ");
  Serial.println(loop_count);
  delay(1000);
}

Cut and paste on MAC

Loop Count printf: 1
loop count println: 1
Loop Count printf: 2
loop count println: 2
Loop Count printf: 3
loop count println: 3

Cut and paste from Windows:

Loop Count printf: 1
loop count println: 1

Loop Count printf: 2
loop count println: 2

Loop Count printf: 3
loop count println: 3

Loop Count printf: 4
loop count println: 4

[PaulStoffregen]

So either 'Printable.h' needs to include 'stdlib.h' or whatever includes it needs to include the file.

Fixed. Thanks!

https://github.com/PaulStoffregen/co...67743bd4966a68

[defragster]

IDE 1.8.11 installed on Windows then TD 1.50b1 with no issues.

Compiled and uploaded a few recent sketches to T4 also with no issues.

[Frank B]

IDE 1.8.11 installed on Windows then TD 1.50b1 with no issues.

Compiled and uploaded a few recent sketches to T4 also with no issues.

The same. Works.

Serial monitor is still broken (at least on Windows) - Testsketch for T4:

void setup() {}
void loop() {Serial.println("12345");}

After a few seconds prints random PC memory contents. And as I have noticed now, if you let it run some time longer, Arduino gets incredible slow.

�����


�������


��


����


�����


������������������


��������������


���


��������


�����������

Seems to be more after first start of arduino & tools. Later runs seem more stable (at least it looks like that)
Best is to stop the program with pulling the USB Cable - this is the fastet way to stop the printing and you can see the contents.

[defragster]

...

Note: tested simple blink program, plus simple text output program
…

Cut and paste from Windows:

Loop Count printf: 1
loop count println: 1

Loop Count printf: 2
loop count println: 2

Seen here with Windows too from Teensy SerMon - does not happen using TyComm copy/paste.

The same. Works.

Serial monitor is still broken (at least on Windows) - Testsketch for T4:
…
Seems to be more after first start of arduino & tools. Later runs seem more stable (at least it looks like that)
Best is to stop the program with pulling the USB Cable - this is the fastet way to stop the printing and you can see the contents.

Have seen anomalies like this - but just now that sketch didn't do it here from T4/1.8.11/1.50b1 - ran and saw expected output without breakage in Teensy SerMon ( and TyComm )

[Frank B]

Yup, often it works.
It apears to be more frequent after a fresh Arduino start. (close all Arduino, Teensyloader etc and restart all) (Not initialized (zeroed) memory???)
But it's more or less random. Sometimes it appears after a minute. Sometimes never. Sometimes after 3 seconds.
Sometimes it prints human readable text that can NOT come from the Teensy. Looks like a crazy pointer in sermon.
But it may be a mixture of bugs on teensy and sermon.

[defragster]

Might depend on the state of the computer memory. I tried with already open IDE - then closed IDE and it worked again … that time.
I was wondering if having a 'while(!Serial & time)' in setup might alter it? That would stop Teensy from flooding system before/during connection? But couldn't try that as it didn't repro just now.

Seems I did see it doing a quick run of 'lines per second' the other day, though not sure. I know I saw Teensy SerMon stall and restore with other USB change again - Teensy SerMon can still get messed up with high speed T4 output - but generally usable.

[PaulStoffregen]

But it may be a mixture of bugs on teensy and sermon.

I'm pretty sure it's a bug in Windows anonymous pipes (how Windows does stdin, stdout) used between teensy_serialmon and the Java JRE running the Arduino serial monitor. It could also be in the Java JRE on Windows. It's definitely a problem associated with the lower level OS or runtime buffering far too much data.

I put *many* hours into this before 1.49. It definitely will not be fixed in 1.50.

[Frank B]

I'm pretty sure it's a bug in Windows anonymous pipes (how Windows does stdin, stdout) used between teensy_serialmon and the Java JRE running the Arduino serial monitor. It could also be in the Java JRE on Windows. It's definitely a problem associated with the lower level OS or runtime buffering far too much data.

I put *many* hours into this before 1.49. It definitely will not be fixed in 1.50.

Sure. It's only a cosmetic problem.

[mjs513]

Not sure if you want to do anything with the printf error at 24 MHz with teensy4.0 . Last post says he is seeing the same issue at 100Mhz?

[KurtE]

Seen here with Windows too from Teensy SerMon - does not happen using TyComm copy/paste.



Have seen anomalies like this - but just now that sketch didn't do it here from T4/1.8.11/1.50b1 - ran and saw expected output without breakage in Teensy SerMon ( and TyComm )

Me too...

Definitely not a show stopper, but since I had a MAC running with the new stuff, though I would try it out, since I figured out it was the CR that is different... And verified that the issue appears to be probably Windows only...

[Frank B]

@Paul, please re-think this: make audio buffer pool DMA friendly


by blackaddr, for T4 only. Having 32-byte aligned audioblocks is valuable.

[PaulStoffregen]

At this moment I'm waiting to see what Arduino does (within the next ~36 hours) with this MacOS issue.

https://github.com/arduino/arduino-builder/issues/349

If they don't publish a recompiled copy of 1.8.11 for MacOS, or at least update the arduino-builder used for beta testing, then I'm going to quickly publish 1.50 this weekend without any more changes, unless of except if serious bugs turn up. On Monday, Apple's notarization policy changes, which will forever prohibit publishing any MacOS software using 1.8.11's arduino-builder (unless people disable Apple's system integrity checks). So I'm not making any more changes to the core lib or adding any features right now. We need to be ready to go if this weekend really is the final opportunity to release on MacOS based on Arduino 1.8.11.

If Arduino does fix this by Friday afternoon, I'll pull in their fix and post 1.50-beta2. If it passes Apple notarization, then I'll merge stuff and add features for beta3 and maybe a beta4, before we transition to about 1 week of bug fixes only.

[Frank B]

#include "core_cm7.h" does not work because of some missing files (at least cmc_version.h, cmsis_compiler.h, cmcis_gcc.h [..?..])

Paul, can you fix this?

[PaulStoffregen]

Arduino did not fix the old SDK issue with arduino-builder on MacOS.

That means I have to release 1.50 now, as the window to get anything built with Arduino 1.8.11 through Apple notarization will forever close in just a couple days.

Paul, can you fix this?

Yes, but not for 1.50. Like so many things, it will have to wait for 1.51.

My intention is to start 1.51 betas in just a few weeks. Will probably just not build 1.51 beta copies for MacOS Catalina until Arduino updates their copy of arduino-builder. I have no plans to mess with Google Go at this time!

[khoih-prog]

Just installed 1.50beta1 and tested with T4 on Ubuntu 18.04.1 LTS x64 with Arduino IDE 1.8.11, no problem so far.

[HallMark]

Is SD Library issue addressed in this realease? 1.48 is having SD library working but 1.49 does not. (I tested on Both)
Hardware : Teensy 4.0
Interface: SPI

[mjs513]

Is SD Library issue addressed in this realease? 1.48 is having SD library working but 1.49 does not. (I tested on Both)
Hardware : Teensy 4.0
Interface: SPI

@PaulStoffregen. Tested with the SDCard library. I just tested the library using the original T4 breakout board that has the builin_sdcard and the audio shield on pins 10, 11, 13 witch is SPI. Everything appears to be working with the SD Card library on SPI for Arduino 1.8.11 and TD1.50 release. However, can not seem to get it to read from the Builtin card reader. Verified this using loglow's breakout board as well.

Using Bill G's SDfat-beta library the builtin sd card does read without a problem.

[HallMark]

@mjs513:
Thank you for this update. I didn't updated my Arduino because of Teensyduino only, As now both are updated I am going to give it a go and update here.