Teensy cli loader and Teensy 3.1

Status
Not open for further replies.
In looking at the C code it seems out of date and doesn't have provisions for the Teensy 3.1. Is there updated code available?
 
I'm trying to do this on OSX (10.9) but it looks like the mk20dx128 entry in the code is only available when using LIBUSB which OSX doesn't seem to use. I know running the command line loader must be possible on OSX because the loader in the Teensyduino environment works great.

Surely, someone must have run the command line loader for the Teensy 3.1 under OSX.

Any help would be appreciated.
 
Teensyduino under OSX uses the graphical Teensy.app, not the CLI loader.

Looking at the GitHub repository for teensy_loader_cli, it does look like the CLI loader is out of date.

On top of what you mentioned, the Teensy3.1 part is actually a mk20dx256, which isn't mentioned in the code. The mk20dx128 is the chip in the Teensy3.0.

It looks like Paul hasn't had a chance to update it yet. Obviously if it hasn't come up yet, there aren't many people using the CLI with T3.x, probably because it's not yet friendly to compile for T3.1 outside of the Arduino environment, but I do hope Paul gets to it.

Cheers,
Dave
 
Hardly anyone uses the command line loader on anything other than Linux.

Updating it has been a much lower priority than many other things, like porting lib and developing the audio library.
 
OK Paul I understand why it is low priority but unfortunately I need it to work. So is it possible to fool the Teensyduino environment into downloading my hex file? That is can teensy_reboot (I think that is what it is called) be fooled into downloading my hex file?
 
If you just need to upload an arbitrary .hex file, you can use the Teensy Loader application that came with Teensyduino.

It's inside your Arduino.app bundle.

Find your Arduino.app (whatever you installed Teensyduino into).

Right click on it and "show package contents".

Inside the bundle, go to Contents/Resources/Java/hardware/tools, and you'll find a "teensy.app".

You can copy (not move, or Teensyduino might break) that app out somewhere and run it on its own. Or, save an alias to it somewhere.

You can use File/Open and tell it to manually load a .hex file.

If you click on the green button on the Teensy Loader app, then it will reload that .hex file any time it changes. Just push the programming button on the Teensy each time you want to load a new copy of the .hex file.


If by "I need it to work" you mean you need it to automatically load from your makefile, I don't know how to do that, sorry.
 
Last edited:
OK Paul I understand why it is low priority but unfortunately I need it to work.

Well, how about trying the obvious in parse_options() near line 990?

Code:
#if defined(USE_LIBUSB)
                                } else if (strcasecmp(arg+6, "mk20dx128") == 0) {
                                        code_size = 131072;
                                        block_size = 1024;
                                } else if (strcasecmp(arg+6, "mk20dx256") == 0) {
                                        code_size = 262144;
                                        block_size = 1024;
#endif
 
I'll just chime in and say that I use the CLI as a customized firmware updater for a pro-audio product I've released, which uses two Teensy++2.0's as it's brains. I'm currently updating that device to use a pair of 3.1's-direct-on-a-board, and it would be swell to have command line support for the 3.1. Being pro-audio, I expect about 90% of my end-users are on a Mac, and the other 10% are on Windows. I don't think I know of a single post production audio house that uses Linux.

I have some ideas on how to use the graphical interface, so it shouldn't be a huge problem (assuming I'm allowed to repackage it into my own software... package), but it would be a lot cleaner looking for my end users if all they ever see is my front-end. (Basically I'm going to disable the auto-load on the Teensy MCU, and they have no access to a reset button. Instead, a specific MIDI sysex command, sent from my front end, toggles a pin connected to the reset line. Tested it on some actual 3.1's and it works nicely enough for now!)
 
Last edited:
Paul,

I did that of course hoping for an easy fix but the problem is the teensy_write for OSX fails.

But this no longer matters as I used the Teensyduino loader to load the hex file that I needed so all is well.

Thanks for the response.
 
Adding a vote for the Windows build of the teensy CLI loader!

I am developing firmware on the Teensy 3.1 that is intended to communicate to software running on a Windows host, and I will need an automated method of pushing firmware updates.

I looked at the source code provided for the CLI loader and noticed that that it explicitly excludes the Teensy 3.x boards. Why is that? Obviously, the Windows GUI loader (teensy.exe) works with the 3.1 board just fine. A CLI version of the loader will be essential for pushing automated firmware updates.
 
Id like to add another vote for a Windows version of the CLI loader.

Similar to jwhoag's situations, I work for a company thats using Teensy 3.1's and would like to be able to easily distribute new firmware occasionally.

Thanks for all the great work Paul!
 
Can I vote twice? Either way, thought I'd pop in to say I have worked out a (rather roundabout) way of using the graphical Teensy Loader as a sub-process. My little app runs the various command-line tools as necessary, which pops up the GUI loader when it actually does the loading. Once it's done loading, it then quits the GUI interface (so as not to confuse end users). If there was a way to tell the GUI loader to load 'headless' at least, or minimized/hidden, or even just a way to swap out some of the graphics and maybe even rename it, that would be enough for my purposes.
 
Can I vote twice?

Sure. Just submit you 2nd vote in the form of a working pull request on github!

The main issue is Teensy 3.x changed the protocol somewhat. Previously (Teensy 1.0 & 2.0), any error was an error. But newer Teensy uses a buffering scheme where transfers return an error if Teensy isn't ready to receive data. Instead of immediately aborting, the code needs to sleep for about 10 to 20 ms and try again. If errors persist for more than a couple seconds, then you conclude things have gone wrong and you need to abort.

Look at how the Linux code does it....
 
Hi Paul et al.,

I'm also in a situation where we need a program for users to be able to update the firmware on their Teensy 3.1 device. The bulk of users are will be on Windows or Mac OS X. teensy_loader_cli is the obvious starting point, but does not support Windows or Mac OS X at the moment. Given that Teensy development and firmware upload is possible on Windows/Mac OS X through the Teensy Loader, is the Teensy Loader source code available somewhere as a source of inspiration to make the required modifications to teensy_loader_cli? I couldn't find Teensy Loader on your GitHub page.

Cheers,
Tom
 
Hi Paul big fan. I have several Teensy's 3.1 and a LC. I'm also a big part of the LabVIEW community and I want to help get Teensy support in the LINX toolkit. LINX is the successor to LIFA which was targeted to just Arduinos, where LINX is a more general toolkit. One of the new features is the ability to have it upload the base firmware to your device so users don't need to deal with another IDE to get it working. For Teensy's to be fully supported there needs to be a way to programmatically upload a firmware and I was hoping a command line tool existed but it doesn't seem Windows is supported.

NI is trying to get into the maker space more, and are offering a home version of their LabVIEW programming language. And again I'd love to be able to recommend Teensy hardware for solutions to users, and getting support for Teensy's in LINX would be a big step towards that.

If you haven't noticed yet I'd like to put another vote in for being able to upload a HEX binary over the command line. Thanks again.
 
I'm not planning to work on this anytime soon. But if anyone who's interested in Windows wants to take it on, I'd be happy to merge a pull request.

The teensy_write() function is the part that needs to be updated, on Windows and Mac.

Here's the Linux version:

Code:
int teensy_write(void *buf, int len, double timeout)
{
        int r;

        if (!libusb_teensy_handle) return 0;
        while (timeout > 0) {
                r = usb_control_msg(libusb_teensy_handle, 0x21, 9, 0x0200, 0,
                        (char *)buf, len, (int)(timeout * 1000.0));
                if (r >= 0) return 1;
                //printf("teensy_write, r=%d\n", r);
                usleep(10000);
                timeout -= 0.01;  // TODO: subtract actual elapsed time
        }
        return 0;
}

As you can see, it has a "while (timeout > 0)" loop. Inside the loop, a failure to send the message is NOT immediately considered a failure to write. Instead, the software sleeps for 10 ms, and retries. Only after repetitive failure for the full timeout is the write considered to be a failure.

Here's the Windows code:

Code:
int teensy_write(void *buf, int len, double timeout)
{
        int r;
        if (!win32_teensy_handle) return 0;
        r = write_usb_device(win32_teensy_handle, buf, len, (int)(timeout * 1000.0));
        //if (!r) print_win32_err();
        return r;
}

All that's needed is the while loop, sleeping for 10 ms... and actually setting up a Windows machine for development and testing (the part I don't have time to do..... I mainly use Linux for everything).

On Teensy 1.0 & 2.0, the protocol used simple success or failure of the USB control transfer to indicate if the write was successful. On Teensy 3.0, 3.1 and LC (and all future Teensy), the control transfer status is used for flow control, to indicate if the Teensy was able to queue the incoming data. Failure is indicated by repetitive failure for the max timeout. This new way allows for much faster loading times, by almost completely removing delays due to USB latency and operating system scheduling latency.

If anyone who loves Windows could take this on, the Linux code ought to be a reasonable guide.

Likewise, the Mac version needs a similar update.

Pull requests are welcome................
 
Last edited:
I'm going to guess the odds of National Instruments ever porting Labview to Linux are pretty much zero, right?

LabVIEW is already supported on Linux, Mac, and a version of Real-Time Linux. But I've never known anyone to use the Linux or Mac versions.

Edit: I can look into this, but I'll be honest my experience with one dimensional programming is probably far behind anyone on this forum.
 
Last edited:
LabView for the 'maker' community makes no sense. The base price for windoze is approx $1k USD, and $3k USD for Linux. Although an academic license probably much less. And these prices do not include the App Builder, required for executable.

For the engineering/production community, cannot recommend LV. It has made my professional life miserable. More than three or four VIs, two or more off-page connections, and bizarre non-deterministic run-time performance makes this critter a dangerous beast in the production environment. See it used much by natural scientists for quick, one-time experimental control drivers. Otherwise do not understand why some company's management insist on torturing engineers with LV.
 
This is not the right place to discuss LabVIEW as a general purpose language, I would just like to help promote the Teensy hardware in the LabVIEW community and getting support in LYNX is a great start. There are many who have careers around LabVIEW and would have it no other way. Please feel free to discuss the merits or difficulties of LabVIEW else where. By the way the academic version of LabVIEW is free, and home is $50.
 
Clearly a lot of people do use and love Labview. Occasionally Labview usage questions come up.

Is there a $50 "home" version that works with Linux? I don't have $2999 to spend on Labview, and I really do not wish to invest ANY of my time into an eval or limited time span license that expires. But I'd happily spend $50 for Labview if I could run it on Linux and know it'll work in a year or two or next week... whenever the next Labview enthusiast runs into a usage issue with Teensy.
 
Status
Not open for further replies.
Back
Top