Android Teensyduino app (for programming)

Status
Not open for further replies.
Hi Paul, are there any plans to release an Android app for programming the Teensy(s)?

We are connected to Android with the USB Serial of the Teensy.
It would be fantastic for our projects where we are connected to Android via Ethernet, miles away and can update our Android apps easily. However to update our Teensy firmware, we have to physically get the unit. Which is sometimes impossible. With Google IOT and mobile/Android device projects, this may be a popular capability.

Thanks!
 
Currently no plans for an Android app.

Is it even possible for Android apps to directly access vendor-specific USB HID devices?
 
That's a library for USB serial.

Teensy uses HID protocol for uploading, not serial.

You could use that library for talking to Teensy after it's programmed (assuming the program was made with Tools > USB Type set to Serial), as the Arduino Serial Monitor does. But it won't be useful for actually programming code onto Teensy, because it's the wrong protocol.
 
Ok, now I understand. When we press the program button, it switches to HID device.

If we could get Android to recognize this device, then do you think you would make an Android programmer?

There are numerous posts on the topic of Android HID device drivers.
The Android Open Accessory Protocol 2.0 allows accessories to register one or more USB Human Interface Devices (HID) with an Android device. This approach reverses the direction of communication for typical USB HID devices such as USB mice and keyboards. Normally, the HID device is a peripheral connected to a USB host (i.e. a personal computer), but in AOA the USB host can act as one or more input devices to a USB peripheral.

Does this sound possible?
 
It's certainly possible, for a subset of devices and OSs, for all of them as a commercial offering much less so. Going off Paul's forum activity keeping the installers for Linux/Windows and Mac working takes a non trivial amount of time, and he's got pretty good at it. Adding a new version in a much more exotic and faster moving environment with 'store' mechanism to navigate would be an exciting preposition to navigate.

Can't speak for Paul and the business he runs but guessing an specific Android installer would be prioritsed well down the list behind a potential generic over the air installer process, keeping current installers running and getting his potential new hardware out the door.

Edit - If this is critical to your project the source for the command line version of the loader is available, and has been made to run on a range of Linux based single board machines and may be abusable into the Android enviroment. Difference of course is between good enough for one phone and one project and something that includes all the possible ways someone might want to use such a thing.
 
Last edited:
Hi GremlinWrangler, thanks for the background. Yes absolutely understood if Paul is too busy. I am surprised he gets time to check the forums and reply to people to be honest.

Where would one find the command line version of the loader?
 
i would like to have teensy send touch/mouse events to an android over OTG, by sniffing the i2c bus of the NEX4100 ive got a repetitive coordinate of the x/y position in a single packet that i'd want to relay that to an android host (phone/tablet) and then hdmi output from there to the radio, so i can use the radio"s touchscreen with full phone support, audio, sound, and net

here is my unit im debugging, currently ive been logging data off 2 i2c busses and 4 uarts, and able to get touches, nmea data,console, and bluetooth caller name and id info as well, for the bt part is awesome because i could relay that info to my gauge cluster
 
Normally, the HID device is a peripheral connected to a USB host (i.e. a personal computer), but in AOA the USB host can act as one or more input devices to a USB peripheral.

Does this sound possible?

For uploading code, the bootloader isn't going to be changed to implement USB host and AOA protocol. Even it if that were feasible, it's simply not something PJRC could afford to do. But there's also the technical issue that the port can't act as both device and host, so there's no way this could be done without being mutually exclusive to the existing HID device-mode bootloader protocol.

I did write a USBHost_t36 library which works on the 2nd USB port of Teensy 3.6. So far it has only a couple drivers. I do intent to write many more USB device drivers eventually... perhaps even AOA protocol. Someday I'll even write documentation for it too. But even an ideal USBHost_t36 won't give you bootloader-based uploading of code.

Yes absolutely understood if Paul is too busy. I am surprised he gets time to check the forums and reply to people to be honest.

I fell pretty far behind over the last couple weeks, while focusing on adding the blog and other changes to the website. But I do try to review all messages, and I'm catching up this weekend...
 
Status
Not open for further replies.
Back
Top