New Part Day: Espressif Announces ESP32-S2 With USB

Espressif, the company behind the extremely popular ESP8266 and ESP32 microcontrollers has just announced their latest chip. It’s the ESP32-S2. It’s a powerful WiFi-enabled microcontroller, and this one has support for USB OTG.

Compared to the ESP32 we know and love, there are a few differences. The ESP32-S2 uses a single core Xtensa LX7 core running at up to 240 MHz, where the current ESP32 uses either a single or dual core LX6. The differences between these cores is hidden away in marketing speak and press releases, but it appears the LX7 core is capable of many more floating point operations per cycle: apparently 2 FLOPS / cycle for the LX6, but 64 FLOPS / cycle for the LX7. This is fantastic for DSP and other computationally heavy applications. Other features on the chip include 320 kB SRAM, 128 kB ROM, and 16 kB of RTC memory.

Connectivity for the ESP32-S2 is plain WiFi; Bluetooth is not supported. I/O includes 42 GPIOs, 14 capacitive touch sensing IOs, the regular SPI, I2C, I2S, UART, and PWM compliment, support for parallel LCDs, a camera interface, and interestingly full-speed USB OTG support. Yes, the ESP32-S2 is getting USB, let us all rejoice.

Other features include an automatic power-down of the RF circuitry when it isn’t needed, support for RSA and AES256, and plenty of support for additional Flash and SRAMs should you need more memory. The packaging is a 7 mm x 7 mm QFN, so get out the microscope, enhance your calm, and bust out the flux for this one. Engineering samples will be available in June, and if Espressif’s past performance in supplying chips to the community holds true, we should see some projects using this chip by September or thereabouts.

(Banner image is of a plain-old ESP32, because we don’t have any of the new ones yet, naturally.)

52 thoughts on “New Part Day: Espressif Announces ESP32-S2 With USB

  1. Sounds great, just have to wait for the boards to be available via the inevitable ‘bay so we dont have to bust out the flux and no doubt produce a few pieces of scrap!!

  2. Whole some of those features are great, loosing bluetooth and the 2nd core is a show stopper for a lot of things..

    If you are doing wifi stuff the 2nd core is great – as the wifi runs on that core and you can get your program running doing pretty close to real time stuff on the other core.. If you try and do real time stuff on a 8266, at the same time as wifi, it doesn’t work very well..

    This this is more a esp32 lite, or a 8266 pro, as it sits somewhere between the esp8266 and the esp32. SO I thik their naming choice isn’t a good one…

    1. However, this is a sweet bit of cost saved for applications that don’t require constant WiFi like that, as (for example) I would still currently rather put a Wemos D1 Mini into a product before an ESP12-F module due to the extra cost in sourcing and placing parts for the Serial->USB bridge circuit. Having direct USB sounds absolutely fantastic!

      1. agreed – but in that case I think it will be more a 8266 replacement.. evening ignoring wifi, it’s much easier running into hardware limits on the 8266 that the 32 – which has made me go to the 32 instead for everything..

        of course, it’s all better than a atmeg328 or all those new ardunio boards that came out the other day…

        The interesting thing will be when the esp32 PRO (or whatever) comes out – it the one that is a step up. This would have been it if it had 2 cores and bluetooth. Or even better, 3 cores :-).

    2. The reasoning is probably that the new core is so fast that everything will be done with interrupts. You’ve got hardware support for the stuff that really requires fast accurate timing, and just as in a PC everything else will be handled by interrupts which are now fast enough to be responsive even if they jitter a bit.

        1. Ian 42, there are people who do real-time sensitive applications and there are people that think you can achieve guaranteed latency while processing wifi on a single core.

        2. Agreed – at some point when you delve enough into Bluetooth or Wifi, you realize that a modern PC relies entirely on many dedicated secondary MCUs/ASICs with real-time availability for one specific application. Most high speed interfaces need extremely low jitter to function at all, and each controller chipset is essentially designed to allow the primary CPU to not need any real-time guarantees on availability whatsoever.

          BLE is particularly bad. To reduce power consumption, all communications must occur within a small window when all receivers are on at the same time. I think the maximum latency is on the order of 50 microseconds, but you probably want much less to improve reception in marginal cases. If you can’t do that, or mess it up, you can lose connections (I suspect this is why some poorly designed BLE devices lose sync). This is why on most single-core BLE devices, your application is always secondary to the BLE protocol handlers. I’m can imagine Wifi has a similar issue. Two cores makes life easier, but of course it increases expense.

          Modern CPUs haven’t gotten a whole lot faster (in terms of clock speed) – they do more in parallel, have gotten more efficient, and are better at dealing with memory/cache management. All of these happen to make jitter more and more difficult to predict. In fact, it might even be easier to write a Bluetooth/Wifi controller on a 486 than it is on an i7.

          1. True, but the new ESP is abandoning Bluetooth entirely, much less BLE. WIFI isn’t THAT timing sensitive; the specs for releasing control to the firmware on the good ol’ “what interrupts” ESP8266 are pretty lenient. But this new chip seems to be abandoning the idea that procedural code can do precise timing for the business logic, which is probably not a bad call.

          2. I have had to abandon projects on the 8266 as it is too difficult to get much done if you are also doing wifi.
            Sure, a ‘blink’ program will run, but start trying anything time senstive and it just won’t work..
            Doing wifi on the same core on the 8266 is like doing real time on windows – you can do it sometimes, but it is a shit load of work..

    3. You’re not wrong. However, the device fits more on the ESP32 side of things: fairly peripheral-rich, compatible with external SPI RAM, pretty advanced memory systems etc, so it’s placed in the ESP32 family. Also, don’t worry too much about loosing BT and the 2nd core; this is not going to be the last chip Espressif will produce, and we certainly haven’t dropped multicore/BT as features we want in the future.

    4. It sounds like the core is much faster than the old one unless I’m misunderstanding something. There are a lot of other benefits but losing Bluetooth hurts. Looks like there are 200KB less ram on this one as well. This must be the Chip 7.2 thing they were teasing on the twitter feed a few months ago.

      I believe this is the new chip unless they used a picture of an old one too:

      1. The RAM is worrying. One of the coolest uses for these chips is running interpreters so you can code remotely(Yeah I know, it’s awful), and that just eats RAM.

        Time for an even tinier language (that isn’t forth or lisp)!

        1. I was thinking about it more last night and I think I judged it mostly based on the name. It’s much better if you consider this as an upgrade to the esp8266 chip. It’s faster, it has more ram and like that chip it only has wifi and one core.

    1. Hmm, yeah, I always thought that FLOPS is Floating Point Operations Per Second. Yes, it does have slow floating point, but that seems really slow!

      I’m thinking maybe 2 floating operations per cycle?

  3. The floating point on the original ESP-32 was so slow that it might have been emulated. Hopefully we can run some versions of Codec2 on this one. I have plans…

      1. K210 is more likely, and the neural network processor in the K210 may work for the really compute-intensive neural network code in the LPCnet versions of Codec2, including Codec2 2020. Those would probably overwhelm the main CPU. But I am the wrong person to program that.

  4. I think the PR has been misinterpreted.

    From the Cadence PR: -2-to-64-FLOPS-Cycle

    “the Xtensa LX7 architecture makes new technologies available for customization by Xtensa customers and increases floating-point choices from 2 to 64” (keyword: customization).

    In the PR Espressif:

    There are no mentions to the FPU.

  5. Aww Expressif, don’t do this. Please. Don’t name it ESP32-S2. Especially if it removes features the other ESP32s have been come to be known for. Call it the ESP26 or the ESP33. ANYTHING but a postfix on the ESP32 name because all that will do is breed confusion.

      1. Octoprint is expensive (energy wise, HW wise, setup time wise). I used it, than I gave up when getting a new 3D printer. It works just by itself, no problem and it is next to where I am so no need for the remote part. (On the other hand, Klipper is something I did not try yet, looks interesting)
        On the other hand, multiple models of 3D printers have a nice color LCD controlled by ESP and a regular ATMEGA2560 controlling the motors, but still using SD cards. If the LCD controller handles the USB stuff, it would be a nicer solution compared to SD cards (not to mention compared to microSD cards).

      1. this is what the ESP32 technical reference manual says about the memory:

        “The Embedded Memory consists of four segments: internal ROM (448 KB), internal SRAM (520 KB), RTC FAST
        memory (8 KB) and RTC SLOW memory (8 KB).”

        The ESP-chips usually do not have any flash inside. The Flash is a separate Chip connected using SPI. The ROM contains the code to upload the firmware, various other Flash-related routines and a BASIC interpreter.

        (i guess, the new chip does not have the basic interpreter, because the ROM is only 128KB.)

        1. 448kB is a *lot* for just a flash loader and ota.
          Guess they have ROMed a lot of their wifi controller code as it’s probably mature now, same with peripheral code like AES, secure key store etc…

  6. I think having multiple variants of the ESP32 is wise. Having just one variant that has everything rarely works. For example even though the older ESP32 IC can do BLE and WiFi, its power dissipation is probably not low enough for the most optimized BLE applications.

    Espressif should have:
    – a low power variant of the ESP32 with BLE and USB (USB Device would be good, OTG even better)
    – a variant with WiFi, Ethernet and USB
    – a variant with LTE Modem and USB

    Notice how all three variants have USB :)

    1. I’d like one with 3 cores – one for bluetooth, one for wifi, and one for my program.. And enough ram to be able to run all three at once.. :-)

      Though I can guess why they have dropped bluetooth – it is a nightmare… So maybe they chould do that as a ‘sister’ chip with i2c and an interupt back to the esp31…

    2. Espressif is a wifi company, BLE is a side kick only usefull for WiFi provisioning.
      There is no point in doing BLE only, they don’t have very low power architecture, ie running on single cell lithium battery for years.
      Btw their BLE IP wasn’t their, they license it from CEVA (who is also selling wifi IP btw).

    3. I don’t think BLE was meant to really be low power on the ESP because the rest of the chip is not. It’s merely reusing part of the same RF hardware you ready have on chip to add functionality that is low cost. BLE makes the ESP as an in teresting IoT gateway.

  7. features are always nice… but I want to know the important stuff like the bottom line for cost… it doesn’t mean a thing, if its expensive; there is a plethora of cheap microprocessors and modules and new tech always seems to come with a myriad of issues when it debuts

  8. Nice package and great way to get experience with that core type by tensilica/cadence.

    So would it be viewed as an ‘easy imperative’ and then practically more viable to use this module as a development tool to gain experience in the core generalities as well as a stepping stone to a reduced hardware implementation for installing into an esp 8266 format for a final product
    IOW if you wanted to produce a cost effective final product with an esp 8266 then could the convenience of this module ease that process enough to procure it ?

Leave a Reply

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