Programing 500 Teensy 3.2

Status
Not open for further replies.
So my company is developing some test units. The goal is 500 units.
Each unit use one Teensy 3.2.
The software/Teensy 3.2 is configured for USB Serial.
So I trying to figure out how to program these 500 Teensy 3.2s.
If I use a windows computer it will try and or install a new serial port each time.
I would not let it get to that number I would go in and delete them.
But all that seems like a real pain in the neck.
I was think of setting up a Raspberry Pi to do the programing.
I have a number of R Pis and have used them for a number of thing but I'm not that knowledgeable about Linux.
So is it like windows and it would do the same thing and try and setup a new serial port each time?
I don’t think it would but not sure on that.
Anyone have any thoughts on this?
Or ideas?
Thanks
Tom
 
I don't use it, but if you want to program multiple Teensys all on the same USB bus, you should be able to use this software:

If you need to provide a way to load up firmware in the field, that is a more complex problem. I've seen various methods discussed in the past, but it sounds like you just need to program a bunch of Teensys in a gang setting at the factory.
 
@MichaelM is right about using TyCommander for bulk group programming - but the issue is the PC seeing 500 unique Teensy's will record each for posterity in the registry with a suggested COM### for each one :(

Is it correct that Paul once wrote code for a T_3.6 USB Host to upload code to a Teensy? If so that might isolate the PC from recording the 500 unique devices. Maybe that is a false memory - I didn't come up with a source for that rumor.
 
Thanks for the replies guys.
Michael I don’t need to program them in a gang one at a time will work.

Wow a T_3.6 host would be the thing if I can get it going fast.
Thanks for the ides I will search the forum for info.
 
I had the same problem in a production environment a couple of years ago. You can disable this behaviour in the windows registry. See here:

https://forum.pjrc.com/threads/46723-Teensy-Programming-without-Windows-Drivers?highlight=IgnoreHWSerNum

Edit:
Just saw that the link in the linked thread is not active anymore.
Here
https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-device-specific-registry-settings
https://blogs.msdn.microsoft.com/xiz/2013/11/03/to-ignore-a-devices-serial-number/
working links, showing how to use IgnoreHWSerNum.
 
Last edited:
Thanks for the link @luni to your code and what I was sure I recalled Paul posting! >> that links to Paul's Note as well as USB-Host-Mouse-Driver

I think, there might be some users who want to flash a Teensy 3.x with a T3.6 ....

I actually wrote a driver for this. Will merge it soon....

I posted on that thread to see if the code was published. I scanned the USBHost_T3.6 tree and the name didn't pop out.
 
Is it correct that Paul once wrote code for a T_3.6 USB Host to upload code to a Teensy?

Yes, I did. There's not much documentation or explanation of how it works. But here's the complete source code, and also a photo of the hardware. :)

https://github.com/PaulStoffregen/USB_Tester

Just days ago, I redesigned this circuit board. Still waiting for the new board from OSH Park. The new version adds a 3 digit LED display to show a count of how many boards it has programmed. I also changed the current sensing chip to a more accurate INA190A1, and I put a SD socket on the main board connected to the SPI pins. We found after daily handling, the SD card hanging off the Teensy 3.6 would eventually get broken.

With the boards that program the MKL02/MKL04 chips and also the Teensy 4.0 test fixture, we've found having a bright 7 segment display which counts the number of unique products tested really helps. They're Teensy-based, and the newer Teensy boards have plenty of RAM to keep a list of the last 999 serial numbers. If you retest the same board or reprogram the same chip, the number doesn't increment again. That's incredibly helpful when you're doing a large number. We also use a system where the operator arranges the products into groups of 5 and 25 (or 10 & 14 on the chips), but the LED count is a nice double check. It's also surprising how the bright incrementing LED digits make an otherwise boring repetitive task quite a bit more enjoyable. I guess there's a reason the treadmills at gyms have 7 segment LEDs.


If so that might isolate the PC from recording the 500 unique devices. Maybe that is a false memory - I didn't come up with a source for that rumor.

Yup, you remembered correctly! ;)

In the very earliest days of Teensy (like version 1.0 and early days of 2.0) they were all programmed by me, using my desktop Linux system. When we hired someone to do that task, we briefly tried to use a "netbook" laptop with Windows (the days when netbooks were in style, before Apple made any iPads). Back then we programmed a no-USB blink. Even without the new serial device detection issue, using Windows was terribly unreliable. The machine would crash at least daily. It may have been the underpowered hardware. I believe it had Windows XP (at the time Vista was the latest) and as we all know now, Windows 10 is the version where Microsoft finally made USB work pretty well.

We quickly replaced the netbook with a Macbook Air, which works fairly well. In fact, we still use the Mac as a backup and for some tasks like programming the hex file onto the audio tutorial boards. There is a known issue where Teensy Loader runs slightly slower on Mac after you've programmed hundreds of boards. Restarting the application cures the issue. MacOS works quite well. It also builds up a huge accumulation of auto-detected modem devices in the network control panel, but that doesn't seem to cause any noticeable issues. MacOS doesn't show anything about this to the user (unless they have that control panel open), so it's quite usable.

Eventually we replaced the Macbook Air with a Linux machine. I believe it was an older model of the SheevaPlug. That was before Raspberry Pi existed. Linux is by far the most reliable system, but still comes with the downside of possibly filesystem corruption if powered off unexpectedly. We had a little Teensy 2.0 based board hanging off that SheevaPlug with red & green LEDs, and hardware for sensing the other USB port's current draw. It was a messy & somewhat fragile contraption, but worked quite well.

For years we used a combination of the SheevaPlug Linux and the Macbook Air. Both were big and bulky and still had some issues. I also wanted to "eat my own dog food" with USBHost_t36, and indeed I did find and fix a bug in the library while programming that board. But as you can see by the fact I just made a new version that's not yet back from OSH Park, we're still refining the process even now.
 
Cool. Is all that built up board (beyond the power supply part) just to make it long term serviceable? Would a cable to onboard host pins work as well - maybe put a powered HUB in the way to control the device power?
 
Is all that built up board (beyond the power supply part) just to make it long term serviceable?

Yes, much of that design is to withstand daily use & handling. The red & green LEDs are meant to make it simple to use. It also gives the operator the freedom to position the LEDs where they want on the workbench. This may sound trivial, but being able to have the LEDs in their direct line of sight while handling the board and USB cable is a huge usability improvement over having to look away to a laptop screen. The LEDs also retain the pass/fail state, unlike Teensy Loader where "reboot ok" vanishes after about 1.5 seconds.

The circuit board has a TPS2055A current limit chip, which gives a lower limit than the chip on Teensy 3.6 if there's a problem. The power supply has much more capacitance than Teensy 3.6, which is more robust for hot plugging. The board also has a 0.5 ohm resistor (two 1.0 resistor in parallel) that all the device's current goes through, and a current sense amplifier. The Teensy 3.6 uses analogRead() to read how much current the USB device is actually drawing. It uses this information to check whether the orange LED results in an increase of 2-3 mA.

It also uses the USB current to "know" when you plug in new hardware, even if that hardware fails to communicate at all. The LEDs turn off the moment you plug in a new board. Again, it's a minor feature than seems trivial, but it's actually pretty important to make the testing process intuitive for an operator without technical knowledge. When programming hundreds of boards, highly reliable gear that's simple with good usability lets them focus on the work.


Would a cable to onboard host pins work as well - maybe put a powered HUB in the way to control the device power?

This tester doesn't turn the device's power on/off. It uses analogRead() to check how much power the device is drawing. So no, that hardware wouldn't work for running this code.

But also yes, with some edits (mostly deleting stuff) the code probably could be adapted.

For only 500 boards, building this sort of hardware might be overkill. Linux running on a PC is probably fine to just run the normal Teensy Loader program. Macs work well too. But I would not bother messing with a slow Raspberry Pi. Use a regular modern PC or Mac.
 
Hey All
Thanks for all the replies!
A lot of good information in this!
Been dealing with metical assembly issues.
Paul
I like the idea of a Linux PC.
I have a PC with Ubuntu 16.04 LTS on it. Do i need to update Ubuntu?
How would I get the Teensy Loader on it?
I'm think I would need to install the full Arduino and Teensyduino on it?

Tom
 
Status
Not open for further replies.
Back
Top