Take The Minimal Pain Out Of ESP32 Programming

Perhaps without many of us realising it, our single board computers perform the task of making programming their processor or SoC a lot easier. They take care of setting the right lines or commands to put the chip in programming mode, they deal with timings, such that we simply fire our code from our dev environment without having to expend much thought. It’s not as though it’s difficult to program most microcontrollers, but there is usually a procedure to set the chip in programming mode. Tired of pressing buttons to achieve this with the ESP32, [DoganM95] took the time to create an all-in-one USB ESP32 programming board.

It’s a straightforward enough CH340C design that also has a USBC-PD chip on-board allowing powering of an attached ESP32 from PD sources. It’s all the stuff you’d find incorporated on a little dev board, without the ESP32, so while it’s nothing earth-shattering it’s also a neat and useful little addition to your arsenal. Unsurprisingly it’s not the first time someone’s created a similar board for a commercially available ESP32 module.

29 thoughts on “Take The Minimal Pain Out Of ESP32 Programming

  1. Didn’t the Arduino IDE support this board?
    If so, then there’s no awkward programming tools needed. ^^
    Because I’m confident ESP32 could be a almost a replacement for an Arduino Uno.

    1. Yes, the Arduino IDE does support most ESP32 dev modules via add-on libraries.

      The ESP32 is clocked much higher than an ATMEGA328 (Uno) and many ESP32 chips also have both WiFi and Bluetooth. The power consumption is vastly different, with a typical ATMEGA328 consuming as much power in active mode as an ESP32 does in sleep mode.

      Their target applications are different, but you are right that an ESP32 can functionally replace an ATMEGA328. That said, if an ATMEGA328 is sufficient, an ESP32 is overkill.

    2. This is the root of the problem, and it’s why I don’t use chips like the ESP32 series. Any chip can become “legitimate” just by virtue of somebody (usually NOT the manufacturer and NOT Arduino) developing an Arduino board manager package for it. And then what happens? That board manager breaks in the next version of Arduino IDE, and you have to wait for someone to fix it, because you can’t find the actual development platform for the chip, and the manufacturer’s programmer is ridiculously priced anyway, and the tools only run in Windows. Yeah, I’m looking at YOU, Atmel, or Microchip, or whatever you call yourself.

      The Arduino platform is what gives everybody the impression that microcontrollers are easy, but as soon as you try to apply this to a new chip, you’re back in try-to-find-the-development-tools-and-make-them-work hell. The original chips used on Arduino were released back in the late 2000s, and Atmel released the follow-on architecture in 2016, which if my math is right, was SEVEN YEARS AGO. I recently bought some ATtiny402 chips for a project, because the older Atmel chips were 2-3x as expensive, and power hogs as well, but Atmel has always had good support, only to find out that Atmel’s “new” (again, seven years old) UPDI programming method isn’t supported by Arduino, and only by several individual efforts by hobbyists are just now working well enough to even be worth trying out.

      And if you DON’T go with Arduino, then you’re stuck with whatever the manufacturer provides. Which, thankfully, is usually free these days, but the IDEs will generally automatically produce code to do chip-level initialization stuff like setting up the clock PLLs and/or dividers, pin multiplexing, and power management (even if the required programming hardware is always overpriced). Which is great unless you’re using chips from four different manufacturers, each with a different toolchain, each with its own learning curve.

      So please don’t tell us that thanks to Arduino, microcontrollers are easy.

      1. I get that this is more of a generalized rant rather than one at the ESP32 ecosystem, but just to correct a few things here. Note I’m an Espressif employee, with all the biases that come with that. First of all, the ESP32 (and its descendents) are supported in Arduino by board support packages we build and maintain ourselves, all the way back to the original ESP32. Secondly, we make it a point to make our devtools usable in whatever way you want: the ‘lowest common denominator’ is to run it command-line under Linux, Windows, OSX, whatever, and you can add your flavour of IDE on top of that: we have extensions for Eclipse and VS Code, but since the SDK mostly consists of CMake and some Python tools, it’s easy to hook up to whatever workflow you want.

        I get your frustration with support for chips in general, I’ve been there and done that, but we made an effort to not be like the others in that aspect, and I’m kinda proud of what we achieved (even if it’s certainly not entirely wart-free), hence the reply.

        1. You are right, this was a much more general rant, and I apologize if Espressif DID make the effort to make it easy to develop for the ESP32 in Arduino IDE, for implying that they didn’t. This article just came out at a time when I was fighting with issues with the “new” AVR chips, and I’m still having to fight with beta-level tools for programming them over UPDI. Also, I was not aware that Espressif made ESP32 bare-metal development possible on Linux platforms, so I may have been misguided in avoiding the ESP32, because I just saw everybody using Arduino IDE to program it.

      2. I’ve started tinkering with modern microcontrollers with the 16C84.
        And it was a fine chip for what it was.
        It was the spiritual predecessor to the ATmega 168/328p, so to say.

        The downside was however, that many projects used hex files and non-portable assembly code.

        But that’s not the worst. The tricky part was the assembly language was different among all microcontrollers by microchip (the company). An 18xxx chip had different ports and assembly code, for example.

        So if had a project made for a certain µC, you couldn’t just substitute another one.
        In worst case, the whole application had to be rewritten.

        That’s were the Arduino IDE was such a big relief, I think.
        You could write human-readable code and modify things, if needed.

        Likewise, the ancient 8052 microcontroller series was equally flexible.
        That microcontroller series all had same machine language and mature development tools.
        The famous AH BASIC interpreter allowed even more flexibility, too.

        1. What? Why would it matter if the assembly is different, you have written your code in a higher language so you can just run it through the compilation specifying the different chip either way?

          1. It wasn’t until Atmel introduced the AVR series that I saw a free C compiler for a microcontroller. Not that I have seen every microcontroller’s development tools; it’s just my experience over the years, and what kept me out of microcontrollers until the AVR series. Well, except for that one time with an 8048.

  2. Literally all ESP dev boards dont need the boot button pressing. And a pile of the newer boards also run of USB-C.
    Newer ESPs also have native USB and a USB serial bootloader built in, so don’t even need the USB to serial chip.

    1. Cheaper clones require the button press but better ones have onboard transistors to use one of the control lines (iirc rts signal) over uart to automatically reset and hold the esp32 in programming mode when necessary.

  3. The last link in the article goes to aWordpress / Hackaday admin page rather than to the Reddit comment page I believe was intended. A username or email address, and a password, are required to access that page.

  4. There is little wrong with using the Arduino IDE, it’s quick and easy and it works.
    My only gripe would be that it generally updates and uses the latest version of a library, so returning to an old project can mean far more than a quick change and recompile. I have one library that I can’t update because the latest version fails to compile because Expressif have changed something.
    I’m sure that someone would like to tell me to use PlatformIO, which keeps the libraries from the original compile, but, frankly, I have never got it to compile anything more complicated than blink. And as for Vscode, with its exciting nostalgic excursions into DOS, no, I haven’t got that to work, either.

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.