PaulStoffregen / teensy_loader_cli

Command line Teensy Loader
http://www.pjrc.com/teensy/loader_cli.html
332 stars 152 forks source link

Uploading code to ARM MCU's from OSX #11

Open vishnubob opened 9 years ago

vishnubob commented 9 years ago

Hi Paul (et al). Thanks for the Teensy project, the hardware combined with the libraries are an outstanding contribution to the maker community.

I would like to modify the command line tool to support uploading code to a Teensy3.0 on OSX. The documentation states this is only possible for Linux, and before I start digging through the code, I was wondering if you could explain why this is. Is there something special about the boot loader and/or the USB libraries on Linux?

neonsoftware commented 9 years ago

Hi vishnubob,

I can confirm you that it is possible to uploading code on Teensy3.0 on OSX as I do it. On the resources and in the code you see just Linux. Probably test support just for linux is because that is where the code is developed and tested and also maybe linux is where the share of cli users is higher. But this is just me guessing. I try to wrap up what you need more exactly.

neonsoftware commented 9 years ago

You probably do not need to modify the teensy_loader_cli repository. The code has a switch that divides the code depending on the operating system, and therefore it has a part of code for linux (using the library LIBUSB) and one part for OSX (using the native Apple API)

Now, IMHO, since Paul refers to use Linux, I think that the best thing to use the most maintained and updated code is to use the code that is meant for linux by using Libusb on your OSX.

neonsoftware commented 9 years ago

It is incredibly easy, if you do it with brew. Do you know brew ?

If yes

brew install libusb-compat

If no then you can check it out here http://brew.sh It installs packages on OSX. In particular with lubusb it is my experience that it does a great job, rather than having to download compile the libusb binaries manually.

(there are different libusb available, 0.1 and 1.0, but libusb-compat is exactly what you need as it gives you the interface of 0.1, which is used by the teensy loader code, but using the engine of the latest and more maintained and available 1.0 version. compat stands for compatibility in this case )

neonsoftware commented 9 years ago

Then in the Makefile you actually want to leave

OS ?= LINUX

and NOT OS ?= MACOSX

Because what OS ?= LINUX already does is setting for you:

neonsoftware commented 9 years ago

If too verbose, here is a recap for you:

it should do give you the binary that you request, just tested on OSX Yosemite :D :+1:

neonsoftware commented 9 years ago

[the following is over the scope of your question question, please ignore if you are ok with the process above or other answers will solve your problem] If you do not want to handle the dependency of libusb your-self AND by chance you are a golang user (you have golang installed and set-up on your OSX) you can check https://github.com/neonsoftware/teeloader in that case by running

go get github.com/neonsoftware/teeloader

you get a compiled and created binary of the loader on linux, osx, and win (did not check on every every architecture) at $GOPATH/bin/teeloader-cli of your system

The project is just a quite bare golang wrapper around this repo that includes compilation and dependencies to provide cli binaries using the golang compilation system. Note :

PaulStoffregen commented 9 years ago

documentation states this is only possible for Linux, and before I start digging through the code, I was wondering if you could explain why this is.

Teensy 3.0, 3.1 and LC implement buffering, where a USB stall indicates not ready. Previously a stall indicated error. Now, an error needs to be treated as "not ready" and a retry-and-timeout approach needs to be used.

If you look at the 4 sets of code, you'll see the retry and timeout was added on the Linux libusb code. The Mac IOkit, Windows WIN32 and BSD versions simply abort on the first error, rather than implementing tries and a timeout.

PaulStoffregen commented 9 years ago

Hardly anyone uses this command line tool on platforms other than Linux, so reworking the other 3 sets of USB code is pretty much at the bottom of my priority list... meaning it'll probably never happen.