Programming Teensy3.x attached to MIPS OpenWRT wireless router

Status
Not open for further replies.

slomobile

Well-known member
My project is to wirelessly communicate with a Neato Botvac85(link has relevant pictures only, not relevant code AFAIK) and Teensy 3.2 via GL-AR300M-Ext wireless travel router, all mounted on the robot vacuum.
The robot vacuum has a 3.3v serial console, so does the router. Eventually(once I figure out how to stop them from occasionally spewing garbage), they will be connected together. But for now they are both connected to the Teensy 3.2 who's display provides local output(pseudo terminal) for troubleshooting. Soon, the Teensy will support several additional sensors and be used for a variety of experiments. The Teensy can be plugged into the USB host port on the travel router.

My question involves how to repeatedly reprogram the Teensy in situ from a remote computer on the network. I do not know how to do that and am seeking advice. I suspect your answers will also help pictographer and others in a similar bind.

It doesn't seem to make much sense to install Arduino and Teensyduino on the host Linux computer(GL-AR300M-Ext router) to which the Teensy is attached by USB. It is only accessed via SSH wirelessly.

My first thought was to put CLI Teensy loader on the GL-AR300M-Ext router. But how do I do that? I am very newb with the openWRT build system and makefiles in general. I have used menuConfig to build firmware, but never built a new package from scratch. The target is not x86, or ARM, but MIPS. QCA9531 very similar to the 9331 in a YUN. If someone could post a useable OPKG makefile, or better an actual OPKG for the CLI Teensy loader I would greatly appreciate it.

Would it do any good to copy the /opt/arduino-1.8.x/hardware/tools folder from x86 Ubuntu unto the GL-AR300M-Ext? How would I use them?

Another option is to capitalize on the similarity to the Yun. I've installed the yunbridge package on the GL-AR300M-Ext, and found Paul's version of the Bridge library for Arduino/Teensy. But even after reading documentation, I can't seem to understand what else I need to do to put new sketches on the remote Teensy while I use the Arduino IDE on a computer across the network. I do not have a real Yun. A walkthrough would be helpful.

Yet another option may be something like USBIP which I've never used.

I do not know which, if any, of these will work. Please comment with any info you have, or missing info you need from me. At this point, I do not know how to move forward.

Other configuration info
The GL-AR300M-Ext router is configured as a WISP repeater. So it behaves as a STA client toward my main internet gateway, and simultaneously as an AP toward client computers connecting to its WWAN. It runs recent stock firmware 2.27 with additional packages:
libudev for persistent naming of usb devices like teensy
yunbridge hopefully for programming arduino and teensy
nano for text editing
usbutils USB devices listing utilities: lsusb, …

Code:
user@remotebox:~$ ssh root@10.x.x.x
root@10.x.x.x's password: 


BusyBox v1.25.1 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01.4, r3560-79f57e422d)
    \________\/    -----------------------------------------------------------

root@GL-AR300M:~# lsusb
Bus 001 Device 004: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@GL-AR300M:~#

After installing libudev package, /etc/udev/ was still not present. So I manually created /etc/udev/rules.d/49-teensy.rules
How do I test if it is working?
 
Attempted compile teensy_loader_cli on router

When trying to make teensy_loader_cli I get this error.
Code:
root@GL-AR300M:/teensy_loader_cli# make
cc -O2 -Wall  -s -DUSE_LIBUSB -o teensy_loader_cli teensy_loader_cli.c -lusb 
make: cc: Command not found
make: *** [Makefile:15: teensy_loader_cli] Error 127
Error 127 is file not found. That makes sense because the file it is looking for is cc for some reason, not gcc. Lower case, like gcc with the first letter gone, not the variable CC.
Edit line 15 and I get this result.
Code:
root@GL-AR300M:/teensy_loader_cli# make
gcc -O2 -Wall  -s -DUSE_LIBUSB -o teensy_loader_cli teensy_loader_cli.c -lusb 
teensy_loader_cli.c:223:17: fatal error: usb.h: No such file or directory
compilation terminated.
make: *** [Makefile:15: teensy_loader_cli] Error 1
root@GL-AR300M:/teensy_loader_cli#
It can't find usb.h which should be included with libusb-compat as far as I can tell. libusb-compat is installed, but I cannot find usb.h on my system. Anyone know where it should go?
 
I'm not a linux expert, and don't know which variant you have installed, but as ar as i know, the usb.h is in the develeopment-package. perhaps search for libusb-dev or similar..

p.s. let us know where you found it :)
 
Still unresolved libusb-1.0

the usb.h is in the develeopment-package. perhaps search for libusb-dev or similar.
p.s. let us know where you found it :)

I am still searching. Haven't found it yet. It seems that the development package is named differently for each distro and I have yet to discover what the name is, or if it even exists for current openWRT, which is actually LEDE 17.01.4 since the 2 projects forked and remerged, keeping the openWRT name and the LEDE codebase.

The packages on my system are libusb-1.0_1.0.21-1_mips_24kc.ipk libusb-compat_0.1.4-2_mips_24kc.ipk

What I did learn is that apparently Teensy uses an old version of libusb, libusb-0.1 which is incompatible with the current libusb-1.0. They should not both be installed on the same host and my system requires libusb-1.0.
libusb-0.1 implements usb.h and is found by gcc with option -lusb
libusb-1.0 implements libusb.h and is found by gcc with option -lusb-1.0 or `pkg-config --libs --cflags libusb-1.0`

libusb-1.0 has a backward compatibility layer called libusb-compat-0.1 unfortunately I do not yet understand how to use it, or even how to use the logging etc. tools the developers want when requesting help.

Any Linux gurus out there, please correct any errors I may have stated and help show us the way forward. Whether that be how to invoke libusb-compat with teensy_loader_cli or how to create a teensy_loader_cli-1.0 that is compatible with libusb-1.0

Thanks
Dustin Maki

Note to Linux developers- if you want people to provide detailed information, it is just as easy and much more productive to provide specific command lines to type
Code:
uname -a
lsusb
dmesg
rather than saying "edit the .foo config file and grok the fram". Don't assume a random user understands how to do what seems simple to you. Even saying "type abc -xyz" is useless to someone that has never used the terminal. Say "open a terminal, type abc -xyz". At least it gives the user a term to Google and greatly mollifies the frustrated masses.
 
I'm rooting for you, Dustin. The troubles you're encountering sound familiar. If I had solved them, I would have posted.
 
I am no linux expert, but do try to fumble along... I do lots of internet searches!

I agree that it would help to tell novice users how to get the details on the information that would help others help debug... (Wiki?)

My assumption usually has been, if someone is using Linux... they hopefully have some experience...

Hopefully the last message has the actual answer to getting this up and running for you.

Note: when I am on a Linux machine and something does not build and it requires something I try to use the apt or DPKG code to help me find what it is I need to install.

Again a refresher google. ... https://superuser.com/questions/109...ce=google_rich_qa&utm_campaign=google_rich_qa

And what I have done in the past is to use apt-file to find which package to install... or you can use dpkg -S ...

Example to my up board:

Code:
kurt@kurt-UP-CHT01:~$ apt-file search /usr/include/usb.h
libusb-dev: /usr/include/usb.h
kurt@kurt-UP-CHT01:~$ dpkg -S /usr/include/usb.h
libusb-dev: /usr/include/usb.h
kurt@kurt-UP-CHT01:~$

So I am pretty sure it comes from a libusb-dev...

Then if I am looking for alternate versions, I will sometimes use: apt-cache search like:
Code:
kurt@kurt-UP-CHT01:~$ apt-cache search libusb
libgusb-dev - GLib wrapper around libusb1 - development files
libgusb-doc - GLib wrapper around libusb1 - documentation
libgusb2 - GLib wrapper around libusb1
libhpmud-dev - HP Multi-Point Transport Driver (hpmud) development libraries
libhpmud0 - HP Multi-Point Transport Driver (hpmud) run-time libraries
libusb++-0.1-4v5 - userspace C++ USB programming library
libusb++-dev - userspace C++ USB programming library development files
libusb-0.1-4 - userspace USB programming library
libusb-1.0-0 - userspace USB programming library
libusb-1.0-0-dbg - userspace USB programming library development files
libusb-1.0-0-dev - userspace USB programming library development files
libusb-1.0-doc - documentation for userspace USB programming
libusb-dev - userspace USB programming library development files
libusbmuxd-dev - USB multiplexor daemon for iPhone and iPod Touch devices - devel
libusbmuxd4 - USB multiplexor daemon for iPhone and iPod Touch devices - library
libusbmuxd4-dbg - USB multiplexor daemon for iPhone and iPod Touch devices - debug
libusbredirhost-dev - implementing the usb-host (*) side of a usbredir connection (development)
libusbredirhost1 - Implementing the usb-host (*) side of a usbredir connection (runtime)
libusbredirparser-dev - Parser for the usbredir protocol (development)
libusbredirparser1 - Parser for the usbredir protocol (runtime)
golang-github-hanwen-usb-dev - CGO bindings for libusb.
libdevice-usb-perl - Perl module to access USB devices using libusb
libdjconsole-data - Hercules DJ Console access library - data files
libdjconsole-dev - Hercules DJ Console access library - development headers
libdjconsole0 - Hercules DJ Console access library
libfprint-dev - async fingerprint library of fprint project, development headers
libfprint0 - async fingerprint library of fprint project, shared libraries
libftdi1 - Library to control and program the FTDI USB controller
libftdi1-2 - Library to control and program the FTDI USB controllers
libftdipp1-2v5 - Library to control and program the FTDI USB controllers
libhidapi-libusb0 - Multi-Platform library for communication with HID devices (libusb backend)
libhidapi-libusb0-dbg - Debugging symbols for libhidapi-libusb0
libusb-java - Java wrapper for libusb
libusb-java-dbg - debug information for libusb java wrapper
libusb-java-doc - javadoc documentation for libusb-java
libusb-java-lib - C part of Java wrapper for libusb
libusb-ocaml - OCaml bindings to libusb-1.0 (runtime)
libusb-ocaml-dev - OCaml bindings to libusb-1.0
libusbhid-common - Common files for the USB HID devices FreeBSD library
libusbip-dev - USB device sharing system over IP network (development files)
libusbip0 - USB device sharing system over IP network (shared library)
libusbmuxd-tools - USB multiplexor daemon for iPhone and iPod Touch devices - tools
libusbprog-dev - Development files for libusbprog
libusbprog0v5 - Library for programming the USBprog hardware
libusbtc08-1 - Hardware interface library for PicoTech USB TC08 Thermocouple sensor
libusbtc08-dev - Development files for PicoTech USB TC08
lm4flash - Command-line firmware flashing tool to communicate with the Stellaris Launchpad
python-ftdi1 - Python module to control and program the FTDI USB controllers
python-usb - USB interface for Python
python-usbtc08 - Python wrapper for libusbtc08
python3-ftdi1 - Python module to control and program the FTDI USB controllers
python3-usb - USB interface for Python (Python3)
spectools - Utilities for using the Wi-Spy USB spectrum analyzer hardware
kurt@kurt-UP-CHT01:~$ apt-cache search libusb-dev
libusb-dev - userspace USB programming library development files
kurt@kurt-UP-CHT01:~$
And then I might experiment seeing if any of these make sense...


Again sorry, probably not much help, but thought I would throw out a few things
 
It is still untested as I'm not quite sure what I am supposed to do with the makefile that alzhao provided. Thank you for taking the time to create that! I'm still googling to figure it out.
KurtE, I would love to use apt in this case, but I need a .ipkg file for OPKG. and the target has 6mb left, so some linux tools just wont work on it. I'm pretty sure that libusb-compat is the correct library for my AR-300M. usb.h IS present in the LEDE source code for the library, it just doesn't install the file when installing the gl-inet supplied package, and I don't know which directory it needs to be in. I'd file a bug report on that, but I am so unfamiliar with how it is supposed to work, that I am not yet confident it is a bug, rather than my own inexperience and user error.
 
I compiled the source code and it is OK. Have no idea of how to use it though. Pls check
https://forum.gl-inet.com/t/libusb-compat-package-fails-to-install-usb-h/3357/2

To run it, use a command like this:

Code:
./teensy_loader_cli --mcu=mk66fx1m0 -w -v blink_slow_Teensy36.hex

I ran this command just now on my Ubuntu 14.04 system. Here's the result (and the LED blinks slow after programming)

Code:
Teensy Loader, Command Line, Version 2.1
Read "blink_slow_Teensy36.hex": 20780 bytes, 2.0% usage
Waiting for Teensy device...
 (hint: press the reset button)
Found HalfKay Bootloader
Read "blink_slow_Teensy36.hex": 20780 bytes, 2.0% usage
Programming.....................
Booting

I highly recommend you experiment and learn how to run it with the supplied HEX files (and watch for the LED blinking) before you go the extra step of trying to get a makefile and toolchain to compile your code to a HEX file.
 
I don't have the environment to run this. I am just helping to compile a program. I have the binary at hand. So if anybody want to try on Openwrt, I can give.
 
When trying to make teensy_loader_cli I get this error.
Code:
root@GL-AR300M:/teensy_loader_cli# make
cc -O2 -Wall  -s -DUSE_LIBUSB -o teensy_loader_cli teensy_loader_cli.c -lusb 
make: cc: Command not found
make: *** [Makefile:15: teensy_loader_cli] Error 127
Error 127 is file not found. That makes sense because the file it is looking for is cc for some reason, not gcc. Lower case, like gcc with the first letter gone, not the variable CC.
Edit line 15 and I get this result.
Code:
root@GL-AR300M:/teensy_loader_cli# make
gcc -O2 -Wall  -s -DUSE_LIBUSB -o teensy_loader_cli teensy_loader_cli.c -lusb 
teensy_loader_cli.c:223:17: fatal error: usb.h: No such file or directory
compilation terminated.
make: *** [Makefile:15: teensy_loader_cli] Error 1
root@GL-AR300M:/teensy_loader_cli#
It can't find usb.h which should be included with libusb-compat as far as I can tell. libusb-compat is installed, but I cannot find usb.h on my system. Anyone know where it should go?

Apologies if I'm way off the mark, but your atheros router won't have a development environment on it.. that seems unlikely anyway given the usual shortage of storage, so having cc missing (this is usually symlinked to gcc automatically) makes sense, and I'd expect a whole load of other build tools and headers to be missing too.
Aren't you going to be better doing the building on a pc - cross compiling as they call it (i.e. for a different target architecture) then then send the binary across?
I presume when it comes time to do your robot-updates-teensy stuff, you'll be doing the compiling of the teensyduino code on a PC rather than on the atheros router?
 
Recently, I was able to build and run teensy_loader_cli for OpenWrt 19.07.7 running on an GL-iNet Mango GL-MT300N-V2 Mini Router.

As I mentioned in another thread, I'm able to reprogram the Teensy over the air, but there are some bugs and workarounds. The OpenWrt image needs packages for USB serial ACM, and the usbreset command.

To make OTA reprogramming reliable, I made a script that calls usbreset, sends a command to the teensy to get it to call _reboot_Teensyduino_() and then calls teensy_loader_cli. Sometimes it is necessary to reboot the router to get the USB serial connection back into a working state.

This hardware has control over power to the USB port. Power cycling the Teensy doesn't appear to help, but might be useful for other things.

My build machine is a PC running Ubuntu 20.10 and I needed to install a few packages and grab the source to teensy_loader_cli version 2.1 from Git Hub.

I'd like to help maintain the teensy_loader_cli package for OpenWrt. Haven't figured out the next step on that yet, but I'm happy to answer more questions about what I did to get it working locally.
 
Status
Not open for further replies.
Back
Top