Teensyduino 1.42 Beta #8

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
Here is a eight beta test for Teensyduino 1.42.

The main new feature is a "Teensy" section in the Tools > Ports menu
which tries to show Teensy in all modes, not just Serial. New native
(no Java serial library) serial monitor code is also with these ports.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Linux AARCH64: (very experimental)
https://www.pjrc.com/teensy/td_142-beta8/TeensyduinoInstall.linuxaarch64.xz
https://www.pjrc.com/teensy/td_142-beta8/arduino-1.9.0-beta-linuxaarch64.tar.xz



Changes since Teensyduino 1.42-beta7

Avoid unnecessary delays when upload can't find any board
Print more informative messages about selecting board in Tools > Ports
Added ARM 64 bit experimental installer
 
If you want to try the experimental 64 bit ARM, here's the steps needed....

First extract Arduino

Code: 
tar -xvf arduino-1.9.0-beta-linuxaarch64.tar.xz

Uncompress and run the Teensyduino installer. The normal UPX compression isn't working yet, so for now it comes xz compressed.

Code: 
unxz TeensyduinoInstall.linuxaarch64.xz
chmod 755 TeensyduinoInstall.linuxaarch64
./TeensyduinoInstall.linuxaarch64

Install the Teensy udev rules, as you would on any Linux system

Code: 
wget https://www.pjrc.com/teensy/49-teensy.rules
sudo cp 49-teensy.rules /etc/udev/rules.d/

Unfortunately the Oracle JRE with Arduino is "Headless" (doesn't support graphics yet on ARM 64 bit?), so it must be deleted. Install the OpenJDK JRE instead.

Code: 
cd arduino-PR-beta1.9-BUILD-69
rm -rf java
sudo apt-get install openjdk-8-jre

Arduino's "builder" program (written in Google Go language) is still 32 bits, so the 32 bit C libraries need to be installed.

Code: 
sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install libc6:armhf libstdc++6:armhf

Optional: nVidia Jetson TX2 ships with a kernel lacking the cdcacm driver (USB Serial). You could try installing this to get it. Fortunately Teensy uses HID for programming and has HID-based serial emulation for non-serial modes, so you don't absolutely need this to use Teensy. It is needed for all normal Arduino boards.

Now you're ready to use Arduino.

Code: 
./arduino
Select Teensy in Tools > Boards menu
Select RawHID in Tools > USB Type menu
Open File > Examples > 01.Basics > Blink
Click Upload
(press button on Teensy... needed if prior program to USB Serial)

Here's a photo of the setup on my desk right now, with the Teensy 3.6 freshly programmed by the Jetson TX2.


jetson.jpg
(click for full size)


This conversation on Arduino's issue tracker has more info. Please please please do not bother the Arduino developers with any Teensy-specific problems. Reply here on this forum for anything related to Teensy.
 
@Defragster - Any chance you could give this (probably last) beta a try with your LC & 3.6 setup on Windows? I tried to reduce as many of the delays as possible when teensy_reboot can't find a board. I think you'll like it. :)

But if there are unexpected issues on Windows, I'll probably revert these speedups and go with beta7 for the final 1.42 release.
 
TD 1.42b8 downloaded and installed on 1.85 no problem. 2 IDE's up and program well to 3.6 and LC … open, program, close All Good!

IDE #1 came up T_3.6 - adjusted port - Upload …
Start IDE #2 - Board T_LC, Port LC, Tsermon
IDE #1 programs okay - Tsermon okay
T_LC Upload …
Unplug T_3.6 - Tsermon returns okay
T_LC programs and returns to Tsermon
… alternate Upload to each as Programming completes the other

One Tports and one Tsermon per IDE.
Close IDE #1 - Tports becomes background with loss of 'host Java'
IDE #2 program LC
Close IDE #2
Tports.exe exits and all good.

Paul: In Teensy/Verbose - did you intend the callback spew stream to stay running?

<edit>: repeated those 2 in some fashion - waited … added IDE#3 to a T_3.5 and no problem through upload, monitor, close.
 
Last edited:
Did you try any cases where the upload can't work, like if you've unplugged the Teensy completely?

If you selected from the new Teensy part of the ports menu, it's supposed to fail quick rather retrying needlessly for 4 seconds. If you have other boards connected, it's supposed to tell you how many others it found but didn't try to upload.

Not everything is perfect (and probably won't be for 1.42) on the Arduino IDE side. If you upload *again* after a failed upload without making a selection in the ports menu, Arduino will often fall back to not knowing the port at all, which put teensy_reboot into the old mode where it searches for any Teensy rather than rebooting exactly & only the one you selected.

If you have 2 or more boards connected and it runs in search mode, you're supposed to see a (hopefully helpful) message advising you to use Tools > Ports to select the exact board you really want to upload.

At least that's how it's supposed to work, on all platforms. The hard part (for me) is always testing this stuff on Windows. My test machine is basically a fresh install+updates of Windows 10 with no other software installed and without years of daily use & accumulation of stuff in the registry.


defragster said:
did you intend the callback spew stream to stay running?
Click to expand...

That's not me. None of the code I've written creates or transmits windows events. Some other software on your PC must be creating these events and broadcasting them. All I did was listen for incoming events from the Windows system. When they're something unexpected, I just log them to the verbose info.
 
PaulStoffregen said:
Did you try any cases where the upload can't work, like if you've unplugged the Teensy completely?
…
Click to expand...

Like I try dumb things on purpose to see it break :) if you insist …

it does 'abort quickly'.

Found 2 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.
Click to expand...

That was okay the first time then I got yelled at for CPU mismatch when it tried pushing 3.6 code to LC when I unplugged the 3.6. That is in this log:
View attachment WTFlog.zip
Click to expand...

Okay it worked twice this time - then did the CPU mismatch again - shorter log file:
View attachment AgainUnplugUpload_log.txt
Click to expand...
This left my T_LC offline.

Note: The above message is for the T_3.6 unplug - after 'Upload' before Program and is in ERROR - there is only 1 T_LC online … not two.

I powered 2nd IDE and set to T_LC and pulled before Program:
Previously selected Teensy port is offline.
1 other Teensy board found. Please select
this Teensy from the Tools > Ports menu.
Click to expand...

It seems unplugging before 'Upload' press is longer than after and give another message:
Unable to open COM8 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632?p=126667&viewfull=1#post126667
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
Click to expand...

That happened a second time when it was plugged at 'Upload Press' … then leaving T_LC plugged it programmed - but also printed this IDE text { this repeats another time }:
Found 2 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.
Click to expand...

Log file:: View attachment b7_Unplug_LC.zip
Click to expand...

NOTE:: The MISMATCH CPU would not trigger on the T_LC with 2nd IDE - just the above notes as I tried.

If you could hide this message as 'known annoyance?' it would be nice - I can't cut and paste or follow bouncing lines from Verbose. It is nothing I know anything about … It is perpetual … except as noted many times … when it stopped is when the prior code would be failing.
unplugged all Teensy's and it still comes - offhand I don't see anything else that would be doing it
00:54:17.480 (ports 117): callback C1A1
00:54:19.522 (ports 117): callback C1A1
00:54:21.563 (ports 117): callback C1A1
00:54:23.608 (ports 117): callback C1A1
00:54:25.651 (ports 117): callback C1A1
00:54:27.680 (ports 117): callback C1A1
00:54:29.718 (ports 117): callback C1A1
Click to expand...

… back in some hours ...
 
opps ? Look what I found?? >> now that I know it wasn't PJRC's ….
CALLBACKS:
C:\Windows\System32\wbem\unsecapp.exe - Microsoft Community
https://answers.microsoft.com/en-us/windows/forum/windows_vista...

Sep 15, 2016 · The Unsecapp.exe application is used in the communication of two computers and this program starts automatically in Windows vista. The Unsecapp.exe application is used to send results back to a client in a process that may not have permissions to be a DCOM service.
Click to expand...
View attachment 13976
 
Last edited:
defragster said:
That happened a second time when it was plugged at 'Upload Press' … then leaving T_LC plugged it programmed - but also printed this IDE text { this repeats another time }:
Found 2 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.
Click to expand...
Click to expand...

Trying to gauge how severe this and other behavior you saw really is? Are we looking at messages with not-100%-accurate info in these strange use cases? Or is there something more serious? Should I hold up releasing 1.42?
 
PaulStoffregen said:
Trying to gauge how severe this and other behavior you saw really is? Are we looking at messages with not-100%-accurate info in these strange use cases? Or is there something more serious? Should I hold up releasing 1.42?
Click to expand...

It provides feedback that isn't ideal - but it is indicative of the problem/solution. Unless the Teensy oddly goes offline - or the user pulls the cable it will never been seen. Nothing bad happened - except when it took the LC offline - which could be a problem - but I've triggered that before when it gets bad HEX<>Port association.

Unless you can see where the messages are getting confused and safely clean that up - I'd suggest it could wait until 1.43. If there is a problematic side effect - the IDE Ports method is still present for use to bypass it.

<edit>: Ideally with new 1.42+ builds the TLoader could KNOW {with telnet 127.0.0.1 28542} what teensy is on the indicated port and scan the HEX before taking the Teensy offline to program. This would avoid the case above where T_LC went offline to find out the HEX was for T_3.6. Once that device is offline it causes grief getting programming done without extra 'futzing' around, and the running device is wrongly halted.
 
Is anyone doing anything with the ARM 64 bit software?

The files I posted are based on build 69, about 8 days ago. Martino has now posted an update using build 71, with arduino-builder now converted to Aarch64. Hopefully with this update the "apt-get install libc6:armhf libstdc++6:armhf" step should not be needed.

The 1.42-beta8 installer might work with build 71. I haven't tested. In fact, unless someone replies that they're actually using/testing the ARM 64 bit software, I'm probably going to leave my Jetson TX2 board sitting on the shelf until this matures enough for Arduino to post a copy on their main website.
 
Hi Paul,

I have the Odroid C2, that I had sitting on the Shelf. I had some arduino working withing it earlier, by getting some of the 16 bit stuff installed.

Verified it still boots (I could not remember if it was my C1 or C2 that was having problems).

I am in the process of downloading the latest image Ubuntu 16.04lts... for it which I will reburn the emmc with...

So will hopefully be able to test it out if you would like.

Edit:
The board is setup... Should I try the binaries up at the start here or do you have more recent ones that I should try.

Thanks
 
Last edited:
KurtE said:
Should I try the binaries up at the start here or do you have more recent ones that I should try.
Click to expand...

Please give the installer a try on the build 71 file. They don't seem to have made any java changes, so it will probably work.

I'm still debating how much more effort I want to put into ARM 64 bit. I want to be ready for the day they make an actual release for Aarch64. I'm less excited about making lots of updates for the moving target that is their 1.9-beta hourly build process.
 
Totally understand. Hard to hit a moving target.

Tried downloading the build you mentioned...
Code: 
odroid@odroid64:~/Downloads/arduino-PR-beta1.9-BUILD-71$ ./arduino
Picked up JAVA_TOOL_OPTIONS: 
java.awt.HeadlessException
	at java.awt.SplashScreen.getSplashScreen(SplashScreen.java:117)
	at processing.app.Base.<init>(Base.java:232)
	at processing.app.Base.main(Base.java:147)
odroid@odroid64:~/Downloads/arduino-PR-beta1.9-BUILD-71$

Info on Odroid:
Code: 
odroid@odroid64:~/Downloads/arduino-PR-beta1.9-BUILD-71$ uname -a
Linux odroid64 3.14.79-116 #1 SMP PREEMPT Tue Sep 26 01:19:06 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux
Commands above to delete java and install... worked so Arduino IDE comes up.

Try running Teensy instal, Won't go to the NEXT button choosing the folder...
 
Last edited:
Quick update:

As I mentioned, the Teensy installer would not allow me to install on build 71... So I installed on build 69.

I then used the app MELD to see what the differences are between 3 directories (unmodified 69, modified 69, and 71) and I had it copy over changed files...
Not exactly foolproof, maybe...

But was able to run Arduino, plug in a Teensy 3.2, load up the blink example and have it program the 3.2 with blink... It also showed the Teensy Ports /dev/ttyACM0

I also tried the example mouse triangle move, which worked (I built with Serial + mouse + joystick + keyboard) or some such combo. It is sort of hard to do much now with it plugged in as the mouse keeps moving ;)

Again this is on an Odroid C2
 
Not sure if this is a issue with the Arduino IDE itself or a teensduino related issue. I just tired to open the serial plotter and received the following message:
Code: 
Error opening serial port 'usb:0/140000/0/1'. (Port busy)
Went back and checked nothing else open and then tried to open the serial monitor and received the message:
Code: 
Serial monitor not available while plotter is open
And of the course the Serial Plotter was not open.

Mike
 
Mike - assume this was TD_1.42 - what 'Port' type was selected - the new 'Teensy' branch? Does it change using the old IDE Port?

Does TeensyLoader 'Help / Verbose' show any details in the process?
 
Sorry. Should have added more info. Running Arduino IDE 1.8.5 with TD1.42. Am on a Windows 10 machine.

Ok. Took a few seconds to try a different IDE. Just tried it with IDE1.8.4 with TD 1.39-beta2. It worked fine no issue. And before you ask I did a recompile with the 1.8.4/1.39 combo.
 
mjs513 said:
Sorry. Should have added more info. Running Arduino IDE 1.8.5 with TD1.42. Am on a Windows 10 machine.

Ok. Took a few seconds to try a different IDE. Just tried it with IDE1.8.4 with TD 1.39-beta2. It worked fine no issue. And before you ask I did a recompile with the 1.8.4/1.39 combo.
Click to expand...
Am wondering if the Plotter conflict is from the TD_1.42 added TeensyPorts insterface not leaving the IDE in charge of a known port … see post #17 to use 'IDE old style port' selection.
 
When using 1.42, you should see Teensy listed twice in the Tools > Ports menu.

Maybe the serial plotter works when you select one of them, but not with the other? Or does it fail with either one selected?

Looks like I need to work on this for 1.43, but knowing if both are broken or just 1 of them doesn't work would really help narrow things down a bit.
 
Just checked. Com6 (Teensy 3.5) Serial does not work. I get the error message. When I try COM6 (Teensy) it works fine. I had to close the IDE and reopen it to try the later since I lock the port with the first try :) Just retested to be sure.
 
Good Mike - that's what I expected. The Upper "Teensy … Com6 (Teensy 3.5)" is the new TD_1.42 enhanced implementation from PJRC.

The IDE's version is "Serial Ports … COM6 (Teensy)" and using that allows it to connect the IDE's Plotter code to that port.

Not used the Plotter interface ever/recently and was between things and referring to the Port menu text by memory away from the IDE.
 
Paul: Looking at doing more on the debug_t3 for Fault enunciation and for the T_3.6 I find this where it seems known func()'s are missing in ...\hardware\teensy\avr\cores\teensy3\mk20dx128.c:

~line #616 under > #elif defined(__MK66FX1M0__)
Code: 
uart4_status_isr,				// 82 UART4 status
	uart4_error_isr,				// 83 UART4 error
[B]	unused_isr,					// 84 --
	unused_isr,					// 85 --
[/B]

Unless that 6th port is unique on T_3.6?

Where the T_3.5 has this under > #elif defined(__MK64FX512__)
Code: 
	uart4_status_isr,				// 82 UART4 status
	uart4_error_isr,				// 83 UART4 error
	uart5_status_isr,				// 84 UART4 status
	uart5_error_isr,				// 85 UART4 error
 
For T3.6, Serial6 is LPUART0, not same as T3.5

/* this is in SPI_MST slave code */

Code: 
#if defined(__MK64FX512__)
  NVIC_SET_PRIORITY(IRQ_UART5_STATUS, 0);
#endif
#if defined(__MK66FX1M0__)
  NVIC_SET_PRIORITY(IRQ_LPUART0 , 0);
#endif
 
Status
Not open for further replies.
Back
Top