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.