Teensyduino 1.10 and Teensy3 "beta7"

Status
Not open for further replies.
Paul

Paul

Administrator
Staff member
 
I'm using the Arduino Enhanced Release for Windows which is a derived version of the official Arduino IDE with bugfixes, updates and improvements.

However, for Teensy, I have to use the official IDE because the Teensyduino installer will let me install to for example, f:\Arduino\arduino-1.0.2 but not to f:\Arduino\arduino ERW 1.0.2

Is this because there is a known incompatibility between the ERW release and Teensyduino? Or is it simply that it wasn't tested? Or because the installer can't cope with spaces in directory names?

I was rather tempted to rename arduino-1.0.2 to arduino-1.0.2-official and arduino ERW 1.0.2 to arduino-1.0.2 and then give it a try, but thought I wold ask here first in case there was a genuine known incompatibility.
 
IIRC there is a known bug with spaces in filenames on the Mac platform. Not sure about others.
 
OK so I gave this a try - renamed arduino-1.0.2 to arduino-1.0.2-official and Arduino ERW 1.0.2 to arduino-1.0.2 then ran the Teensyduino installer. No dice; the 'Next' button remains grayed-out if I select arduino-1.0.2 to install into (and is fine with installing into arduino-1.0.2-official). So its not a 'magic filename' but something else, perhaps the directory structure inside the selected directory.

Paul, is it documented anywhere what the Teensyduino installer does, so I could carry out those steps manually?
 
The Teensyduino installer does CRC checks on specific java objects within pde.jar, to be absolutely sure the version of Arduino is supported. Numerous files and directories are also checked, but the CRC checks on java objects are the main thing you're seeing. It then replaces several of the java objects with patched copies. Even if you manage to defeat the CRC checks, which would be quite difficult, the result will almost certainly be a horribly broken Arduino IDE, because the installer replaces bytecode objects. With each Arduino release, I go through quite a bit of trouble to verify all 4 of my build environments are compiling an exact match to the binary files Arduino publishes, because the installer selectively replaces binary objects which are heavily interdependent on the many others it doesn't touch.

Just to be absolutely clear, there is no way to use the installer's java objects with the ERW version.

I went to a lot of effort on those CRC checks because this patch process only works if the java bytecode is exactly expected code. So far, there has never been even one report of the installer corrupting an Arduino installation, because the Next button simply will not enable unless the code is compatible. But if it weren't for that safety check, replacing specific binary objects within a large application would certainly result in corrupted code.

The only workable approach would be to merge my source code changes with those from ERW and compile a custom IDE. The modified .java files are "installed" to a src directory. You can get the Arduino source from github (the source code download on Arduino's website is incomplete... get full source from github), replace the .java files with the same names (hint: they're buried in 5-6 levels of subdirs, use search to find them and quickly look at the code to make sure they're approx the same before replacing). Once you have all my .java files in place, use "git diff" to produce a patch file. The odds of that patch applying cleanly to the heavily modified ERW codebase are somewhere between slim to none, but at least patch can do much of the work and leave you with reject files to manually merge. You'll need to go through each reject carefully and figure out how to merge my code with ERW's.

After you've merged the source and recompiled the IDE, then simply copy Teensyduino's hardware/teensy and hardware/tools/teensy* (from an installed copy of 1.0.2) and perhaps modified libraries if you're using them. That's the very easy part, just copying files. But first, you must merge the java source and compile a custom IDE.

The ERW version looks really interesting. I might merge some of those patches into Teensyduino......
 
Last edited:
PaulStoffregen said:
Just to be absolutely clear, there is no way to use the installer's java objects with the ERW version.
Click to expand...

Yups, thanks for the clear explanation. I hadn't realised it was patching binary code.
PaulStoffregen said:
The only workable approach would be to
Click to expand...
(Paul explains how to do the merge properly)
PaulStoffregen said:
The ERW version looks really interesting. I might merge some of those patches into Teensyduino......
Click to expand...
Well, that would be ideal. I particularly like:
  • upload then open serial monitor
  • pause serial output
  • display of variable size as well as code size
  • use of up-to-date compiler
 
I've been working with the ERW code today.

I brought over the scrolling menus, which is actually based on Darryl Burke's code, with modifications that assumed Windows fixed menu font sizes. I rewrote that bit, so it'll automatically scale and should be compatible with all 3 systems.

I also implemented the RAM usage estimate, again rewriting it slightly because Teensy uses some other memory segments.

Next I intend to look at the serial monitor stuff....

On the AVR toolchain, I believe the lack of backwards compatibility with so many Arduino sketches and libraries is a huge downside, for very little gain due to the newer versions.

On ARM, I do plan to build a newer toolchain soon, with a native 64 bit linux compile. That will probably be beta 11... but my hope is to get a few of this nice IDE improvements into beta 10.
 
The ERW code makes a LOT of intrusive changes to the IDE's java code. The Teensyduino changes are already a large patch set which usually breaks in some way on each Arduino release. I'm not so excited about adding a huge number of intrusive changes. Tiny changes and big additions as entirely new files are much easier to maintain as Arduino releases new versions.

I personally like the serial monitor auto-open idea, but I'm wondering if I can add only a subset. On the auto-open, maybe if it was open at the time you click Upload, it should automatically reopen when the upload finishes? That would eliminate the many changes to menus and toolbars and GUI action listener stuff.
 
The other big problem with the auto-open, as implement by ERW, is it's rooted in Arduino's "always the same serial port" concept. That's nice for Arduino boards with a dedicated USB-serial chip, like Uno, Mega and Due's programming port. But Teensy (and also Leonardo and Due's native port) are a different USB device while programming. After the upload, that USB device disappears and then another one appears a short time later (or several seconds if using Windows... Mac & Linux are fast, Windows is slow). So the ERW code probably will not work. To make this work properly on Teensy, a java thread will need to launch and keep trying to open the serial monitor when the new USB device appears. Maybe this is a bigger project to be done another day?
 
PaulStoffregen said:
I personally like the serial monitor auto-open idea, but I'm wondering if I can add only a subset. On the auto-open, maybe if it was open at the time you click Upload, it should automatically reopen when the upload finishes? That would eliminate the many changes to menus and toolbars and GUI action listener stuff.
Click to expand...

Yes, that would probably be fine. I see two advantages to auto-open (which I use, a lot):

- avoids either the need to add a big delay() or a scramble to open serial, so you don't miss the initial output
- avoids tediously re-opening it each time when making lots of little changes or re-running the same sketch with different inputs

The other ERW serial features I use are the ability to pause output, and saving output to a file.
 
Status
Not open for further replies.
Back
Top