[CNLohr], ESP8266, USB…

“Round up the usual suspects…”

[CNLohr] just can’t get enough of the ESP8266 these days — now he’s working on getting a version of V-USB software low-speed USB device emulation working on the thing. (GitHub link here, video also embedded below.) That’s not likely to be an afternoon project, and we should warn you that it’s still a project in progress, but he’s made some in-progress material available, and if you’re interested either in USB or the way the mind of [CNLohr] works, it’s worth a watch.

In this video, he leans heavily on the logic analyzer. He’s not a USB expert, and couldn’t find the right resources online to implement a USB driver, so he taught himself by looking at the signals coming across as he wiggled a mouse on his desk. Using the ever-popular Wireshark helped him out a lot with this task as well. Then it was time to dig into Xtensa assembly language, because timing was critical.

Speaking of timing, one of the first things that he did was write some profiling routines so that he could figure out how long everything was taking. And did we mention that [CNLohr] didn’t know Xtensa assembly? So he wrote routines in C, compiled them using the Xtensa GCC compiler, and backed out the assembly. The end result is a mix of the two: assembly when speed counts, and C when it’s more comfortable.

All in all, it’s a very iterative, experimental approach to coding, learning, and hacking. The video is a bit long and winding, but it gives you a great peek into the skull of [CNLohr]. You also can’t argue with his results. This is the guy who bit-banged Ethernet in an ESP8266, after all.

Thanks [Lucas] and [Uriel] for the nearly-simultaneous tips!

30 thoughts on “[CNLohr], ESP8266, USB…

    1. Your comments were sent to pending because you’re either a new user, have a new IP, or wordpress is dumb. Take your pick.

      I trashed your earlier comments (because they were all pretty much the same), and approved this one. You *should* be good now.

  1. Now that is cool.

    That would be one tool that I would tose into each esp8266 I have and I have a lot of them.
    I cant wait to start getting into them. so much to do. I wonder if he would be thinking of making a esp8266 WiFi hub.
    Yea I now it would be slow but there are some things that I would think of doing with something like that like a wifi key board on the cheap side.. ( has anyone ever thought of finding one of them, and if you do they are megga $$$.)

    Keep up the good work I’ll be following you.

  2. 1. First question for any software USB device is where from will you get the USB VID/PID.

    2. There is an example of a USB stack for 8-bit AVR MCU’s, with source code and some key explanations. It is available online at the author’s website:
    as an application note from Atmel (Atmel published the obdev’s work, with his permission, as an application note). For whatever reason, the AVR309 application note is not available any more, but can still be found online:

    1. @RoGeorge:

      1) USB VID/PID: Use whatever you want as long as you don’t need USB-foundation certification. The “don’t step on other VIDs” is a feature that makes commercial devices interoperable, and for which you have to pay a ton of money. There’s no reason a hobby project should worry about it.

      And if you need some for a significant Open project: go here: http://wiki.openmoko.org/wiki/USB_Product_IDs

      I use the VID/PID pair from Microsoft’s Natural Keyboard for all my HID keyboard devices. Bypasses driver installation on many Windows machines. :) Just avoid collisions and all’s well.

      2) V-USB is awesome, but limited to low-speed devices. That’s [CNLohr]’s inspiration here, although he didn’t like the codebase and went the long way around, re-inventing the wheel. Which is probably faster for him than re-fitting the existing wheel to a different vehicle — to fully murder the metaphor.

      1. It is also kind of rough since the AVR code is sooooooooo specific to the AVR. There’s no good analog for trying to compare the asm’s. But yeah… That vid/pid pair thing is really only a serious issue for commercial projects.

    1. It’s not the horsepower that counts, it’s the latency.
      The Attiny USB stack only works as a foreground process during the boot process, where nothing else is running.
      the ESP8266 has Wifi as a background process and so you can’t block the processor for too long.
      Given that USB also has hard timing limits, it remains to be seen if these 2 conflicting requirements can be met.
      The ESP32 makes this much easier because it has 2 independent cores.

      1. I was really surprised, though. I could slam the USB bus to 60% saturation and it really wasn’t that big of an issue. I was still able to get 200Hz on my websockets test! USB Also auto-retries, so that’s good!

  3. Very informative vid… and great undertaking.
    Am I mistaken to be gathering the impression that the ESP8266 doesn’t do crazy things like caching, branch-prediction, et-al that would otherwise cause a processor’s instructions to take seemingly random cycle-counts…?

    1. It does do some razy-ish things but mostly having to do with the memory addresses of the instructions and jump targets. After a couple hours I was able to find everything I cared about, you can see it in usb-notes.txt in the repo.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.