Teensyduino 1.53 Released

Status
Not open for further replies.
Hi @defragster,

Thanks for the reply.

I had actually started using the all in one to update from a previous beta of 1.53 that was installed in arduino and also had the problem.

So I thought I would delete the original arduino app and re-install so I could make some timings of the issue compared to the default.

So with 6 file editors:

Starting Arduino is still pretty slow and takes around 10 seconds, starting teensyduino takes around 19 seconds.

File menu popping down in arduino is 0.5 seconds, file menu in teensyduino takes 8.5 seconds.

Sketch menu popping down in arduino is instant, teensyduino around 0.5 seconds.

Other menus are fine in both.

In both arduino and teensyduino once the file menu has had this slow behaviour as long as you stay on the same editor window it then works quickly, change to another editor window and it is slow the next time.

So I'm guessing it is something to do with the number of examples rather than the teensy stuff, I bet if I had another board with the same number of examples I would see a similar thing.


Edit:

So I ran the Instruments profiler on it to see what is going on, maybe doesn't look like a disk issue.

7.66 s 100.0% 1.00 ms Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl

So some Java toolkits run loop, with majority of time here:

5.07 s 66.2% 129.00 ms CFSetContainsValue

So it looks like it is some dodgy code looking stuff up in a set.

I also ran a filesystem profile and there is no disk access at all in this period.

So looking like an Arduino problem based on number of examples and some dodgy code!
 
Last edited:
Sounds to me like you need to tell the jvm to use more memory so that it gc's less often?
The
Code: 
-verbose:gc
option should be helpful.
On my system, 16GB RAM, 16 cpu's, Linux 64bit:

IBM's java:
Code: 
/usr/lib/jvm/java-ibm-x86_64-80/jre/bin/java -XshowSettings:vm -version 2>&1 | head --lines=6
Here's the output:
Code: 
VM settings:
    Max. Heap Size (Estimated): 512.00M
    Ergonomics Machine Class: client
    Using VM: IBM J9 VM

java version "1.8.0_241"

and for openjdk/jre:
Code: 
/usr/lib/jvm/java-11-openjdk-amd64/bin/java  -XshowSettings:vm -version 2>&1 | head --lines=6
Here's the output:
Code: 
VM settings:
    Max. Heap Size (Estimated): 3.90G
    Using VM: OpenJDK 64-Bit Server VM

openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1)

So it *might* even matter which jvm you are using.
 
Thanks for all the info, from the command line:

Code: 
$ java -XshowSettings:vm -version 2>&1
VM settings:
    Max. Heap Size (Estimated): 7.11G
    Ergonomics Machine Class: server
    Using VM: Java HotSpot(TM) 64-Bit Server VM

Does Arduino use its own version of Java or the one on the OS path?
 
Probably the one in the OS path, even so, you can increase the initial allocation at startup.
type
Code: 
java -X
to see the memory options.
it's usually -Xms
Code: 
    -Xms<size>        set initial Java heap size
 
Thanks for the info.

I looked into it a bit and the JRE that arduino uses is included with it.

So I looked at the files opened when running teensyarduino and noticed that it was also using the internet java plugin on my machine, a bit of both!

So I deleted the internet java plugin and now it works perfectly!

Thanks very much for pointing me at Java being the villain in some way.
 
AndyCap said:
So I deleted the internet java plugin and now it works perfectly!
Click to expand...

This is the first time I've heard of this problem, though I'll admit it may have come up before and been unresolved as just mysterious Mac or Java issues.

Can you give me any more specific info about this extra java plugin your machine had? Any info we might be able to share with others who see this same issue in the future would really help.
 
The plugin was JavaAppletPlugin.plugin and located in /Library/Internet Plug-ins/

When I looked at the files arduino was using it was using this as well as the embedded JRE.

The tools needed to check the files used are standard so users can check by running "Activity Monitor" and double clicking "Arduino".

Then in the next window choose "Open files and ports", command f to search and then type in JavaAppletPlugin.plugin
 
Last edited:
Good Morning all
Running into a something while trying to get a sketch to load to a brand new toy I got recently and something out of my normal wheel house. So here goes.

I picked up a PI4 with 8GB of mem, and installed Ubuntu 18.04 64bit as the OS. I finally managed to get linuxarm64 installed for the Arduino 1.8.13. Then i installed Teensyduino 1.53 Linux Installer (AARCH64 / Jetson TX2) which may be the problem.

What happens is the simple Blink sketch compiles with no issues and when the sketch goes to upload I get the error:
Code: 
Opening Teensy Loader...
Teensy Loader could not find the directory /tmp/arduino_build_489937
quitexit status 1
and the TD screen is blank = all white.

If i look in /tmp I do see the build directory:
Code: 
arduino_build_489937
arduino_cache_274431
and files
Code: 
-rw-rw-r-- 1 ubuntu ubuntu     34 Oct 13 08:08 Blink.pde.eep
-rwxrwxr-x 1 ubuntu ubuntu 388532 Oct 13 08:08 Blink.pde.elf
-rw-rw-r-- 1 ubuntu ubuntu  40257 Oct 13 08:08 Blink.pde.hex
-rw-rw-r-- 1 ubuntu ubuntu 385490 Oct 13 08:08 Blink.pde.lst
-rw-rw-r-- 1 ubuntu ubuntu  11056 Oct 13 08:08 Blink.pde.sym
-rw-r--r-- 1 ubuntu ubuntu    566 Oct 13 08:07 build.options.json
drwxr-xr-x 2 ubuntu ubuntu   4096 Oct 13 08:08 core
-rw-r--r-- 1 ubuntu ubuntu    249 Oct 13 08:07 includes.cache
drwxr-xr-x 2 ubuntu ubuntu   4096 Oct 13 08:07 libraries
drwxrwxr-x 2 ubuntu ubuntu   4096 Oct 13 08:07 pch
drwxr-xr-x 2 ubuntu ubuntu   4096 Oct 13 08:07 preproc
drwxr-xr-x 2 ubuntu ubuntu   4096 Oct 13 08:07 sketch

Or is this just a matter that the TD version I used is only for the jetson?
 
I just installed 1.8.12 on RPI4-8GB on SSD with current Teensyduino... Did not find the 1.8.13 64 bit linux. Running Ubuntu 20.04.

I get the error
Code: 
Opening Teensy Loader...
Teensy Loader could not find the directory /tmp/arduino_build_445002
quitexit status 1
Error compiling for board Teensy 3.2 / 3.1.
Next up turn on verbose.
 
@KurtE - I am using 1.8.13 aarch64 version - arduino-1.8.13-linuxaarch64

If i turn on verbose mode I didn't notice anything strange, looks like it compiled without error. Also as I mentioned when TeensyLoader opened it was a blank window.
 
The Arduino site kept failing to find that file, I even tried on my windows machine and it failed, so went to 1.8.12.

I also found a blank window like you mentioned.

BUT if I kill off the window

And run the Teensy program manual from a terminal window, I see:
Code: 
buntu@ubuntu:~/Desktop/arduino-1.8.12/hardware/tools$ ./teensy
Gtk-Message: 23:59:00.682: Failed to load module "canberra-gtk-module"

It hange waiting ... If I then press the program button on T3.2, it will take a bit of time, but it will program the teensy.

So I think the error message is bogus. It is having issues internal to Teensy app.

Probably Paul needs to look
 
I didn't try running it manualy but I did try and just press the button on the T4,1 just in case but didn't load - probably got impatient and didn't wait long enough.

Agree - Paul probably needs to take a look unless there is a way maybe to recompile the just the loader for the PI4 64bit OS?
 
I am completely new to Teensy. For my current project, I had to graduate from Arduino and get something more powerful. I noticed that the library Adafruit_GFX was removed in the newest update. I need some library to use my 5110 now. Any suggestions for a library for a 5110 LCD, a NEO 6M GPS unit and a HC-05/HC-06 Bluetooth module?
 
Typically libraries removed are done when they are equivalent and more current from the source - and perhaps had Teensy compatibility added. In this case using the published Adafruit library should work with Teensy AFAIK.

Those other things may have related forum post a search might turn up ...
 
You can use Adafruit_GFX.

In Arduino, click Tools > Manage Libraries and type "GFX" in the search. Most libraries are found and installed that way.

Many years ago, in the early days of 32 bit Teensy, all of Adafruit's display libraries ran very slowly. Back then Adafruit only sold 8 bit boards. As we found ways to make those displays and their libraries run much faster on Teensy, lots of modified copies were made and the code diverged from Adafruit's original code. That's all ancient history now. Adafruit's libraries are now much better, and of course they sell plenty of 32 bit products, and their libraries now work well on pretty much all 32 bit boards including Teensy.

As Adafruit improved their libraries, the copies we had for Teensy would become out of date. Sometimes those differences would cause minor but really annoying compatibility issues (and who want's to dig through a mountain of library code?) Keeping separate modified copies of Adafruit's libraries just didn't make sense anymore, since Adafruit's modern libraries work on Teensy with pretty good performance.

We do still have several libraries like ILI9341_t3 which are highly optimized for Teensy, but they don't require Adafruit_GFX to run.

So starting with version 1.53, we're no longer packaging a copy of Adafruit_GFX and some of Adafruit's other libraries. The ones you can install from Arduino's library manager work well, and that way you can avoid compatibility issues and always get the latest version as Adafruit updates them.
 
r3stl355 said:
What is the shasum of current Teensyduino_MacOS_Catalina.zip (version 1.53)? Is it listed anywhere?
Click to expand...

No, hashes aren't listed anywhere, but here are the numbers.

shasum Teensyduino_MacOS_Catalina.zip
34a0fe608bf96084618b4c8553c9703377a13a6e Teensyduino_MacOS_Catalina.zip

sha256sum Teensyduino_MacOS_Catalina.zip
401ef42c6e83e621cdda20191a4ef9b7db8a214bede5a94a9e26b45f79c64fe2 Teensyduino_MacOS_Catalina.zip

The software is digitally signed with a valid developer certificate. You can verify the signature on a Mac using this command.

codesign -vvvv --deep --strict Teensyduino.app/

The signed software is also properly notarized from Apple. You can check the notarization with this command:

spctl --assess -vvv Teensyduino.app/

At least those are the commands which work on Mojave. I haven't tested those on Catalina or Big Sur.


Anyone who could alter the zip file between PJRC and you could probably also alter the SHA hash numbers you download the same way you download the ZIP file. But altering the software and managing to fake the digital signature and Apple notarization would require a feat of breaking strong encryption!
 
Hi,
I am trying to compile the NativeEthernet / UDPSendReceiveString example from teensyduino for a teensy 4.1 and I get a strange error:
Error while detecting libraries included by C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FNET\src\service\serial\fnet_serial.c
Click to expand...
The code that I am developing have the same problem
Doesn't do it on the example through normal ethernet library.
any idea
 
Status
Not open for further replies.
Back
Top