Teensyduino 1.25 Beta #1 Available

Status
Not open for further replies.
No. 1.24 can't possibly support 1.6.5-r5.

1.24 was released in June.

1.6.5-r5 (the "-r5" change) was released only 12 days ago.
 
(re post #22) Updated my Win10 to 1.6.5r5 with 1,25b2.

Two devices on USB - T3_1 and an LC. This time the LC was seen as the Problem Device ! ?

Not sure how it got that way - I recompiled and then it got programmed with the new code. This was after an overnight shutdown.

The only prior odd thing was when Teensy Loader saw T3_1 upload it tried to put into the LC - before the shutdown - I had to yank the LC because even closing TeensyLoader would have it wake on Verify and freeze over wrong binary (LC left in PROG mode even on verify causes load attempt?). Not sure how it better handing would work - but once it goes into this mode - it doesn't have a graceful way to exit - as the wrong device prepped to load. Can the TLoader offer to WAIT or Reboot to prior code the affected device?
 
On Linux, the installer that is opening is the one below, that's right?
Seleção_129.png
 
Yes, I prepared a 1.25 final release, with the name in the Tools > Boards menu changed to "Teensy 3.2 / 3.1".

I ran out of time on Friday for final testing before a weekend trip. Just returning now, and lots of messages to answer. Will get this released soon.

Last Friday I considered just releasing without any final testing, since there's very little changed from 1.25-beta2. But ultimately I decided to go through at least some re-testing of stuff, just in case.
 
Running the 1.25b2 on my Win 10 box with 1.6.5r5, TeensyDuino has shown me this "device still online" more than a few times with Dual T_3.1's chatting at 6Mb over dual serial 1>2 and 2>1.

22:51:02: Device came online, code_size = 262144
22:51:02: Board is: Teensy 3.1 (MK20DX256), version 1.03
22:51:02: File "SerialEventDual.cpp.hex". 19120 bytes, 7% used
22:51:02: HID/win32: HidD_GetPreparsedData ok, device still online :)
22:51:27: Verbose Info event
Click to expand...

I've seen other anomalies and dropped notes - nothing conclusive - but something is different for the worse in reliably programming. Minutes ago I shut down TD and it worked - now it isn't working - not even catching all ProgButton presses until pressing on second unit - with action and same 'device still online' when it says anything.

Shutdown TD and hit verify in IDE to re-open - it opens and gives 'Auto Mode Disabled'. It is like the two devices are merged? Both were in ProgMode, but also before was it doing 'prog' on unit "A" then detecting unit "B" still active? Not seeing enough diagnostic spew to say more than that.

Just went to only A or B unit plugged in and that didn't work for either. I did just move to a USB3 hub in a USB2 hub in a USB2 port - but it worked just before this? And going back to USB2 hub - still the same.

Verify puzzling - after opening TYQT again - they printed usb 'start' but failed to run though one may have programmed earlier to 600KB from 6MB - I hit IDE "verify" again - then TD reprogrammed BOTH and they are running fine.

Now seeing this - then bacl to above msg:
23:54:10: Board is: Teensy 3.1 (MK20DX256), version 1.03
23:54:10: File "qBlink2k_sketch_sep19a.cpp.hex". 18848 bytes, 7% used
23:54:11: HID/win32: HidD_GetPreparsedData failed, device assumed disconnected
23:54:11: Device went offline
Click to expand...
 
Last edited:
TD UI under Win 10? Looks like below - the TITLE bar is shrunken because Win 10 grew the stupid right corner buttons Min/Max/Close. Since TD doesn't resize you can't read anything but "T..." and you can only move the window from that quoted area.
td125b3W10.png

I forget if the Max/Restore middle button ( unused on TD ) can be removed from the app? This is done in effect as it is not resizable but the extra button persists:: 'by setting Window.ResizeMode property to ResizeMode.NoResize. '
 
Last edited:
defragster said:
I forget if the Max/Restore middle button ( unused on TD ) can be removed from the app?
Click to expand...

Teensy Loader is built with wxWidgets version 2.8.

So really, the question is not just whether the middle button can be removed, but whether it's possible to do from the wxWidgets 2.8 API, or a direct WIN32 function that can be used within the wxWidgets environment.
 
I have 64 bit Ubuntu 14.04 LTS running Arduino 1.6.5 with Teensyduino 1.24.

I thought I would load the Teensyduino software from this link. This would be only my second time installing it, or the first time updating. I assume that I should be able to install from this link without uninstalling version 1.24.

When I double click on the downloaded teensyduino.64bit a popup menu comes up complaining that there is no application install for "executable files". When I try and execute it from a terminal with the command sudo ./teensyduino.64bit it also complains that the command is not found.

When I try the same with the previous download of version 1.24, both techniques work.

Help appreciated.
 
I feel embarrassed, but thanks for the suggestions. chmod 777 teensyduino.64bit worked.
The ldd command just tells me it is not a dynamic executable.
 
Wow, that's not overly dramatic at all! ;)

Apple sure does make things difficult to support older macs and their latest. I can't get older macs to sign the installer for new versions, and newer macs can't build applications that run on older macs (at least, not that I can figure out how to do).

I'm sure there'll be plenty of complaints if fixing this suddenly means we can't support anything older than 10.8 or 10.9. But at the moment, I don't see a lot of alternatives....
 
PaulStoffregen said:
Wow, that's not overly dramatic at all! ;)

Apple sure does make things difficult to support older macs and their latest. I can't get older macs to sign the installer for new versions, and newer macs can't build applications that run on older macs (at least, not that I can figure out how to do).

I'm sure there'll be plenty of complaints if fixing this suddenly means we can't support anything older than 10.8 or 10.9. But at the moment, I don't see a lot of alternatives....
Click to expand...

Nice thing: why not releasing then, two teensy add ons of the same version; one supporting newer OS X and one supporting the older ones ?
 
I do that now for Linux, 2 separate downloads. Releasing 2 files is more work and more long-term maintenance. In theory, it's twice as much testing.... but the reality is I pretty much never do any testing of the 32 bit Linux version. I simply don't have a 32 bit Linux test machine set up.

I'm pretty sure 2 versions targeting new and old OS-X won't avoid the need for testing as 2 Linux versions built with the same tools and targeting the same kernels+desktop can. Two Mac versions probably means I need to buy another Mac for testing, and add quite a lot more work to how to prepare and test the software. If it comes to that, I may have no choice... but I really want to avoid adding another Mac version.
 
Status
Not open for further replies.
Back
Top