Teensyduino 1.51 Beta #1

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a first beta test for Teensyduino 1.51.


Linux 32 bit:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 10.15:
https://www.pjrc.com/teensy/td_151-beta1/Teensyduino_MacOS_Catalina.zip

MacOS 10.7 to 10.14:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_151-beta1/TeensyduinoInstall.exe


Changes since Teensyduino 1.50

Support for Arduino 1.8.12
Add USB Flight Sim for Teensy 4.0 (Jorg Neves Bliesener)
fix panic temperature power off on Teensy 4.0 (FrankB)
SerialFlash support AT25SF128A (FrankB)
Wire lib minor updates
 
fix panic temperature power off on Teensy 4.0 (FrankB)
Note, at the moment it switches off the CPU, but not the on-board voltage regulator TLV75733 (3v3 pin stays on)
I'm working on a solution to switch 3v3 off, too (->same behaviour as power-button)

I hope to get it working tomorrow. Problem is, on "temperatur panic alarm" the "system assumes software has lost control" ;) and wants to do a reset. Only way I see is to use the high-temp alarm instead to switch off - and if this not works(i.e. cpu still runs and the temp rises more), "panic" will reset the cpu.
 
I hope to get it working tomorrow. Problem is, on "temperatur panic alarm" the "system assumes software has lost control" ;) and wants to do a reset. Only way I see is to use the high-temp alarm instead to switch off - and if this not works(i.e. cpu still runs and the temp rises more), "panic" will reset the cpu.
Be forwarned that the there is no separate HIGH alarm the LOW-HIGH ISR is the same if I remember right so you have to test for temp in the ISR to make sure its not a low alarm but from what I see at the current setting of 25degC it may never trip for low under normal conditions but think you will still have to check. So you are going to have to do something like this:
Code:
void High_Low_Temp_isr(void){
  if(tempmonGetTemp() >= highAlarmTemp){  //High temp
    digitalWrite(13, HIGH);
  }
  if(tempmonGetTemp() <= lowAlarmTemp){  //Low temp
    digitalWrite(13, LOW);
  }
  asm volatile ("dsb");
}
 
Just downloaded 1.8.12 and installed TD1.51 on a windows 10x64 with absolutely no issues. Had a ILI9341 already hooked up for some graphics test and it compiled and ran with NO [edit - thanks @defragster] issues. Just for fun here is @Frank B's memory usage I put into setup:
Code:
OpenGL Test!

D:\Users\Merli\Documents\Arduino\libraries\T4_PowerButton-master\T4_PowerButton.cpp Feb 13 2020 16:27:00

Teensyduino version 1.51

ITCM: 64kB, DTCM: 448kB, OCRAM: 0(+512)kB [DDDDDDDDDDDDDDII]
ITCM:   56496 86.21% of   64kB (   9040 Bytes free) (RAM1) FASTRUN
OCRAM:  12384  2.36% of  512kB ( 511904 Bytes free) (RAM2) DMAMEM, Heap
FLASH:  81952  3.91% of 2048kB (2015200 Bytes free) FLASHMEM, PROGMEM
DTCM:
   458752 Bytes (448 kB)
-   58048 Bytes (56 kB) global variables
-    1340 Bytes (1 kB) max. stack so far
=========

   399364 Bytes free (390 kB), 59388 Bytes in use (57 kB).
 
Last edited:
@Frank/Mike - the FLASH isn't 2048KB with the reserved 64KB top block of EEPROM and the 15sRestore sketch.

Assume p#4 was :: compiled and ran with NO issues

Downloaded TD 1.51b1 - will start 1.8.12 download ...
 
Installed {unzip} IDE 1.8.12 and TD 1.51b1 - No issues on Win 10

First run Windows wanted me to not run the IDE - but pushed past that with 'Run Anyway'

Opps - TyCommander was left open owning the T4's COM3 port - a couple of failures - getting port and open SerMon … Opps.

But first upload gave this bogus warning as first run of Teensy Loader took too long to run?
Code:
Opening Teensy Loader...

Unable find Teensy Loader.  (p)  Is the Teensy Loader application running?

Is a firewall (eg, ZoneAlarm) blocking localhost communication?


This looks NEW - did not see this "Invalid library found" on IDE 1.8.11??::
Code:
T:\arduino-1.8.12\hardware\teensy/../tools/teensy_post_compile -file=T4_i2c_tb_[B][U]vk_slavev1.ino[/U][/B] -path=T:\TEMP\arduino_build_636481 -tools=T:\arduino-1.8.12\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/5/2 -portlabel=COM3 Serial -portprotocol=Teensy 
Invalid library found in T:\tCode\libraries\Arduino-EasyTransfer: no headers files (.h) found in T:\tCode\libraries\Arduino-EasyTransfer
Invalid library found in T:\tCode\libraries\Arduino-EasyTransfer: no headers files (.h) found in T:\tCode\libraries\Arduino-EasyTransfer

Second run Windows - made quick edit to boards.txt for fun and TyCommander now closed.

Issues above reproduce: <EDIT>: resolved with restart and lib removal - see below p#9

> First open of TeensyLoader about 5+ seconds AFTER the "Unable find Teensy Loader …"

> Builds a usable and good HEX file - BUT still dislikes "Arduino-EasyTransfer" as pulled from github and used okay with IDE 1.8.11 - perhaps KurtE/mjs513 could verify on slavev1 i2c sketch build?

IDE Help About shows expected Versions for both IDE and TD.

Close Teensy Loader with IDE open. Do another Upload and the T_Loader is delayed open at least 8 seconds … running on an i7 from SSD -

Close T_loader and double click on takes some 12+ seconds to appear :: "T:\arduino-1.8.12\hardware\tools\teensy.exe"

NOTE: My machine is requesting a restart for updates - has been abused for 8 days and 6 hours as of now. Will update ...
 
Last edited:
@defragster
Just did a test using the vk_slave.ino sketch and got the same messages that you saw.

However on a check I had a copy of EasyTransfer in my Arduino libraries folder as well as what was installed with Teensyduino. I deleted the copy in Arduino libraries and recompiled with no messages. Check if you have an extra copy floating around.
 
Machine restarted for 2nd Tuesday Windows updates.

TeensyLoader comes up in a FLASH now! No problem. Something was gummed up in there.

First upload this time did the APPROVE JAVA (firewall?} - that did not happen last time before restart of computer as it normally does?

Removed local sketchbook library of 'EasyTransfer' and the Teensy copy creates a working HEX.

Using library Wire at version 1.0 in folder: T:\arduino-1.8.12\hardware\teensy\avr\libraries\Wire
Using library Watchdog_t4 in folder: T:\tCode\libraries\Watchdog_t4 (legacy)
Using library EasyTransferI2C in folder: T:\arduino-1.8.12\hardware\teensy\avr\libraries\EasyTransferI2C (legacy)
Using library FRAM_MB85RC_I2C in folder: T:\tCode\libraries\FRAM_MB85RC_I2C (legacy)
Using library Adafruit_SSD1306 at version 2.1.0 in folder: T:\tCode\libraries\Adafruit_SSD1306
Using library SPI at version 1.0 in folder: T:\arduino-1.8.12\hardware\teensy\avr\libraries\SPI
Using library Adafruit_GFX at version 1.5.6 in folder: T:\arduino-1.8.12\hardware\teensy\avr\libraries\Adafruit_GFX
Using library MPU9250 at version 1.0.1 in folder: T:\tCode\libraries\MPU9250
Using library Adafruit_Sensor at version 1.1.1 in folder: T:\tCode\libraries\Adafruit_Sensor
Using library Adafruit_BNO055 at version 1.1.10 in folder: T:\tCode\libraries\Adafruit_BNO055
Using library SparkFun_BNO080 at version 1.1.6 in folder: T:\tCode\libraries\SparkFun_BNO080
Using library LIDARLite at version 3.0.2 in folder: T:\tCode\libraries\LIDARLite
Using library SparkFun_Qwiic_Keypad_Arduino_Library at version 1.2.0 in folder: T:\tCode\libraries\SparkFun_Qwiic_Keypad_Arduino_Library
Using library SparkFun_Qwiic_Button_Arduino_Library at version 2.0.4 in folder: T:\tCode\libraries\SparkFun_Qwiic_Button_Arduino_Library
Using library Adafruit_SHT31 at version 1.1.6 in folder: T:\tCode\libraries\Adafruit_SHT31
"T:\\arduino-1.8.12\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_31740/T4_i2c_tb_vk_slavev1.ino.elf"
Sketch uses 73264 bytes (3%) of program storage space. Maximum is 2031616 bytes.
 
..found a bug in tempmon.c :)
I know now the reason why the interrupt is always firing..
takes a while to fix it - i'm too tired now (1:00 here)
Good night.

p.s. will fix powerbutton tomorrow, too.
 
..found a bug in tempmon.c :)
I know now the reason why the interrupt is always firing..
takes a while to fix it - i'm too tired now (1:00 here)
Good night.

p.s. will fix powerbutton tomorrow, too.

Ok - you can't leave me hanging - give me a clue :(
 
:D

Only thing I can think of now it the automatic repeat time for temp measurement in TEMPMON_TEMPSENSE1n register. Based on what Frank said maybe too short. Frequency is set at frequency = 0x03U; which is the RTC clock/3. Yep too much probably could be the Max of 2 seconds at 0xFFFF or whats best. Didn't cross my mind until Frank found it. More I play with this stuff more I learn - thank you Frank. PS. mean that - not being sarcastic.
 
Ok - you can't leave me hanging - give me a clue :(

Oops. sorry. Did'nt want to leave you hanging.
It's not really a "bug" (sorry again), too. The main code is OK - besides switching off which was my fault because the manual is unclear.

The interrupt fires as soon the teensy starts - when the alarms get set.
The reason is simple - but wasn't that easy to see.
LOW_ALARM_VALUE: This bit field contains the temperature count that will generate a low alarm interrupt when the field is
exceeded by TEMP_CNT.
The higher the temperature is, the lower is TEMP_CNT. The lower the temp is -> the higher is temp_cnt.
The issue here is just, that it is fireing from the beginning on because it is just set too high. Not really a bug.
It is 25°C now. I'll set it to -100°C because we're not going to use it.

The interrupt is firering all the time, because:
LOW_ALARM_VALUE: This bit field contains the temperature count that will generate a low alarm interrupt when the field is
exceeded
by TEMP_CNT.
It's by design. There simply is no flag "fire only once" and they left it to the poor guy who writes the software :)
(Edit: can be done by setting new alarm values - in our case, we don't need that.)

So, it's quite easy to make it work.
Another little issueis, that the code assumes that the alarm values are all set to zero. On startup, this may be true (did not verify that). As we're setting the alarms anyway, I'll make three functions for that so the user can use them and they will not assume that all bits are cleared.
 
Last edited:

Was looking at the code and see what you do. Nice approach on making the LOW temp -100 to ditch it from firing. Also saw that you turned off the autosampling for freq - wasn't 100% sure about that one when I originally read the manual. Nice changes - thank you.

I did just run a quick test with tempHigh = 46 and tempPanic set to 48. Shutdown at the correct temp so looks like it works. Not sure what else you want to test. Still on first cup of coffee and have to take the car in for service now.

Oh - before I forget - thanks for changing the freememoryinfo() function to show the heap, now I can see the heap info very nicely:
Code:
_t3n::begin mosi:11 miso:12 SCLK:13 CS:10 DC:9 SPI clocks: 30000000 2000000
   T4 setup CS/DC

_t3n::begin - completed

OpenGL Test!

FLASH:  85248  4.20% of 1984kB (1946368 Bytes free) FLASHMEM, PROGMEM
ITCM:   56560 86.30% of   64kB (   8976 Bytes free) (RAM1) FASTRUN
OCRAM:
   524288 Bytes (512 kB)
-   12384 Bytes (12 kB) DMAMEM
-   64216 Bytes (62 kB) Heap
   447688 Bytes heap free (437 kB), 76600 Bytes OCRAM in use (74 kB).
DTCM:
   458752 Bytes (448 kB)
-   29376 Bytes (28 kB) global variables
-    1276 Bytes (1 kB) max. stack so far
=========

   428100 Bytes free (418 kB), 30652 Bytes in use (29 kB).
 
Windows 10 pro x64
Arduino 1.8.12
Teensyduino 1.51-beta1
In the library manager I now get this error:
"Comparison method violates its general contract!"
This is something new here.
 

Attachments

  • snap.png
    snap.png
    11.9 KB · Views: 139
Windows 10 pro x64
Arduino 1.8.12
Teensyduino 1.51-beta1
In the library manager I now get this error:
"Comparison method violates its general contract!"
This is something new here.

Same system/IDE/TD software versions here and open lib mgr no problem, even search to accellstepper display and click <more info> works.

That error does not present. Likely issue with corruption or local setup. TeensyDuino itself doesn't use elements of LibMgr so problems would be Arduino IDE related to function or installed libraries.
 
A uninstall / delete "C:\Program Files (x86)\Arduino" / reinstall solved that issue. But now it is a new feature: Teensyduino does no longer update libraries existing in the sketchbook. I just forgot how I made this work in the past. Libraries in the sketchbook have now priority, even if they are older than "C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries". Anyway, it does not seem to be a good idea to use Teensyduino and ESP and others together in the same Arduino installation. Is it better to have completely separate installations and sketchbooks for each of the boards?
edit: I just copied the libraries from "C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries" to the sketchbook by hand. Now everything is back to normal. For now.

Edit2: no. Not good. This kills ESP and everything else. What a mess. Deletet now all the libraries in the sketchbook and now have to copy them manually into the individual sketch folder, as in the old days.
 
Last edited:
TeensyDuino stores libraries it maintains in the tree it installs and it works for there for Teensy builds. Best not to edit or move them.

Anything in sketchbook\libraries is user controlled - if there it will be used as requested. If it is old or unwanted it needs to be manually removed or updated.
 
Best not to edit or move them.
edits will be gone after the next update..


@Paul do you plan to repair CMSIS and make shiftOut()* or tempmon work?

*my son wants to build a working clock with 7segs but your lib does not work with teensy4 :rolleyes: *kidding* It works on UNO!!!11!
Or should i help him to patch the lib instead (and do a PR) ? would be possible, too.
 
Last edited:
Restored a backup of everything. 1.8.10, 1.5 and everything works perfectly, like it did before.

btw:
I've tried 1.8.12 and 1.51-beta1 on an other clean formerly arduino-free PC. Same error. What I see is the libraries from Teensyduino show as not installed in the Library Manager!
But the sketch like ILI9341_t3 example demosauce compiles. When I call the Libryry Manager and install the ILI9341_t3 from there, it does not compile for T4 any more. This as an example.
 
Last edited:
Restored a backup of everything. 1.8.10, 1.5 and everything works perfectly, like it did before.

btw:
I've tried 1.8.12 and 1.51-beta1 on an other clean formerly arduino-free PC. Same error. What I see is the libraries from Teensyduino show as not installed in the Library Manager!
But the sketch like ILI9341_t3 example demosauce compiles. When I call the Libryry Manager and install the ILI9341_t3 from there, it does not compile for T4 any more. This as an example.

Library manager is for when needed libraries are not present by default on the machine.

For Teensy/PJRC maintained or optimized libraries … like "anything_t3" or other that will be installed and found to build when TeensyDuino is installed.

When those libraries are installed with TeensyDuino they should be used and any updates will come through TeensyDuino updates, except work in progress or updates that may happen on the Forum between/during beta updates to TeensyDuino.

It is more work and effort for PJRC to own/maintain these libraries - but unless outside concerns (like AdaFruit) incorporate the Teensy specific code when it comes to core functionality or device libraries - they are part of the TeensyDuino installation for the good reason that they are tested to provide best use of the Teensy family of devices, and are tested with each release when changed to provide best user experience and functionality possible.

Paul provides code back to the Arduino IDE group that is regularly used for all IDE installs - but his unique hardware and USB pnly bootloader are best and only usable with TeensyDuino with intense work on his part to make the IDE usable with higher speed more capable Teensy devices. That requires an install to update the JAVA code in the IDE - and at the same time deliver the best available libraries for Teensy use.

When using most Arduino hardware the library manager is essential. For Teensy it works out of the box with TeensyDuino. And when added libraries are needed I end up with github ZIP files extracted to sketchbook. For ESP and others staying current with LibMgr was the way, for Teensy I turn off the time wasted by LibMgr to check for updates and tell me about them as it starts up.
 
ok. Understand. So it may be better to prevent teensyduino libraries from showing up in Library manager. Anyway, for existing things I use 1.8.10/1.5 the way it works and for new tings I use each a separate Teensyduino installation without LibMgr and a separate full Arduino/ESP/Adafruit installation for the rest of Arduino projects. Maybe it would be a good idea to fork Arduino?
Ed: To use different installations on a single PC, one needs to switch users or use run as user, because of the appdata that are saved by Arduino in the user profile.
http://woshub.com/run-program-as-different-user-windows/
 
Last edited:
for new tings I use each a separate Teensyduino installation without LibMgr and a separate full Arduino/ESP/Adafruit installation for the rest of Arduino projects.

Arduino on Windows and Linux has a self-contained "portable mode". Teensyduino supports it.

https://www.arduino.cc/en/Guide/PortableIDE

Maybe this could help you? Sadly, it's not supported on Macintosh due to Apple's signing and notarization requirements on newer MacOS versions. But it works great on Windows and Linux.
 
Status
Not open for further replies.
Back
Top