Teensyduino 1.45 Released

Status
Not open for further replies.
...
Changes since Teensyduino 1.44

Support for Arduino 1.8.8
Updated libraries: i2c_t3, Snooze
Teensy 3.6 overclock to 256 MHz (Frank B)
Fix serial begin() lockup if framing error received in FIFO when end() called
Audio add AudioControlTLV320AIC3206 (Chip Audette)
Teensy Loader icon added for Gnome desktop on Linux

...

Changes since Teensyduino 1.45-beta1

Add 256 MHz Teensy 3.6 to Tools > CPU Speed menu
Fix asm in delayMicroseconds on Teensy LC (Frank B)
Audio: Fix ADAT output with 168 MHz (Frank B)

… The only change since 1.45-beta2 was commenting the 256 MHz overclock lines in boards.txt, as Frank B suggested.

<edit>: and the cool thing is TyCommander still works
 
Last edited:
I'm afraid some stuff is broken for the 8-bit series of controllers:
- Teensy 2.0(++) worked fine with Arduino 1.8.7 + Teensyduino 1.44
- the hardware definitions in Teensyduino 1.45 are probably corrupted because I only get the 32-bit operating speeds with the Teensy 2 boards.
 
Can't reproduce the problem here. Looks fine when I try. Here's a screenshot.

sc.png

Maybe I tried the wrong way? Any chance you could be more specific about the problem? Maybe show a screenshot, so we can actually see the same problem you're seeing?
 
Paul: Have you changed the factory boot test Blink code to present the Teensy Type to the SerMon Teensy_ports indication? It seems that would work as a diagnostic since the IDE supports that now - I asked as that was released with TD update and not sure if it got answered?

TD 1.45 didn't get the change for usb_init_serialnumber() to return MCU Ser# when -1 was the result of one time serial # reading? @crees left code he saw working but I never tried it - and this K66 PROTO board could use it.
POST :: Custom-Teensy-Write-Once-Memory-quot-Burn-quot-Direction-needed

<edit>: I just tested that on the K66 PROTO board and it works to have Serial # for TyCommander … mostly :: 1313158531-Teensy
On Power up plug in and AFTER reprogramming TyCommander shows that as the Serial#.
BUT - on transition with TyComm RESET or Upload with reset it reverts to showing:: 4294967295-Teensy until it restarts. And that confuses TyComm as it expects Serial# continuity. Seems the bootloader chip returns the chip's one time write Serial # when it gets control?
 
Last edited:
<edit>: I just tested that on the K66 PROTO board and it works to have Serial # for TyCommander … mostly :: 1313158531-Teensy
On Power up plug in and AFTER reprogramming TyCommander shows that as the Serial#.
BUT - on transition with TyComm RESET or Upload with reset it reverts to showing:: 4294967295-Teensy until it restarts. And that confuses TyComm as it expects Serial# continuity. Seems the bootloader chip returns the chip's one time write Serial # when it gets control?

interesting. I have the same issue hitting reset on tycommander. However if I hit reset twice I get the board back again the way it should. This issue will add some complexity to custom teensy boards. I have some ideas on a work around but will need to do some tesing
 
@Paul : I can see that being low import - might help newbies, and risky to change the tested and working system without extensive testing.

@crees : Same process - I removed the code :( … I posted on the TyComm thread to see if koromix has an idea to fix the transition through reset change. Best thing would be to implement a write to the one time area.
 
@Paul : I can see that being low import - might help newbies, and risky to change the tested and working system without extensive testing.

@crees : Same process - I removed the code :( … I posted on the TyComm thread to see if koromix has an idea to fix the transition through reset change. Best thing would be to implement a write to the one time area.

Arduino / teensyduino doesn’t seem to have issue with the load / reset and the board comes back with the expected ID. Be interesting to see what tycomm thread has in regards to this.
 
Hi all, sorry... it took me a while to get back on my reported issue.
Apperently it was me. I did a clean GNU/Linux install on a laptop and copied my ~/Arduino folder over.
Maybe there were incompatible remnants in there. Now that I reverted to Arduino 1.8.7 + Teensyduino 1.44, I can no longer reproduce the behavior with Arduno 1.8.8 and Teensyduino 1.45.
 
It works very well for me, but... again that noising java exception when starting the Arduino IDE for the first time (i.e. after running TeensyduinoInstall.linux64).
The graphic is messed at the first start. I've tested it again on a fresh new installation of IDE 1.8.8 on Ubuntu 16.04.

Selection_558.jpg

Again that exception when setting the serial port:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at processing.app.EditorLineStatus.setSerialPort(EditorLineStatus.java:136)
.
.
.

After setting the port for programming the Teensy 3.2 (e.g. /dev/tty/ACM0), the problem don't arise anymore, even after restarting the IDE more times.
So seems that the program needs the port to be set in order to not block the thread refreshing the graphic interface. Anyway, it's a minor bug.
 
again that noising java exception when starting the Arduino IDE for the first time
same/similar error here on a new computer with windows 10. If I change the size of the window, the surface will be displayed again normally. Prior to the Teensyduino installation Arduino loaded normal.

Code:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at processing.app.EditorLineStatus.setSerialPort(EditorLineStatus.java:136)
	at processing.app.EditorLineStatus.paintComponent(EditorLineStatus.java:101)
	at javax.swing.JComponent.paint(JComponent.java:1056)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JSplitPane.paintChildren(JSplitPane.java:1047)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paint(JComponent.java:1065)
	at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
	at javax.swing.JComponent.paintChildren(JComponent.java:889)
	at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217)
	at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
	at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
	at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
	at javax.swing.JComponent.paint(JComponent.java:1042)
	at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
	at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
	at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
	at java.awt.Container.paint(Container.java:1978)
	at java.awt.Window.paint(Window.java:3906)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:842)
	at javax.swing.RepaintManager$4.run(RepaintManager.java:814)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:789)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:738)
	at javax.swing.RepaintManager.access$1200(RepaintManager.java:64)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1732)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

EJLK0zF.png
 
Yup, it's a bug. Already fixed in the 1.46 betas, if you want to grab the installer from msg #2 in the huge beta test thread.
 
Status
Not open for further replies.
Back
Top