Qualcomm’s New QCC74x Appears To Target The ESP32 MCUs

These days wireless microcontrollers featuring built-in WiFi and Bluetooth are all the rage, with Espressif’s range of ESP32 MCUs being the default option for commercial and hobbyist projects alike. This makes Qualcomm’s recently released QCC74x MCU rather interesting, as specification-wise it would seem to be placed firmly in ESP32 territory.

On the radio side you get 1×1 WiFi 6, Bluetooth 5.4, and IEEE 802.15.4 (e.g. Thread and Zigbee), coupled with a single-core 352 MHz RISC-V CPU with FPU and DSP features and 484 kB of SRAM. The SDK for this MCU is hosted on Codelinaro, featuring the typical FreeRTOS-based stack, though confusingly Bluetooth and Zigbee support are currently marked as ‘not supported’. This might still be in progress.

Where the competition with Espressif feels clear is in the pricing, with the highest-performance evaluation board (QCC748M EVK, pictured above) listed for $13 (before taxes/tariffs). This gets you 8 MB of PSRAM built-in with unspecified link speed, but likely the same QSPI as used for the NOR Flash. USB support is available on this higher-end tier, while absent on the QCC743. Development documentation is also available, and looks fairly complete based on first glance.

Overall the QCC74x looks to be an upgrade to the older and significantly less powerful QCC730 MCU. Depending on software support and final pricing it could make for an interesting competitor to some of Espressif’s modules like its ESP32-C series or ESP32-S2, though the upcoming ESP32-S31 would seem to have it matched or beat on all metrics.

38 thoughts on “Qualcomm’s New QCC74x Appears To Target The ESP32 MCUs

    1. It all depends on how good the SDK is. The ESP one is not great, but it gets the job done. There is an opportunity for something better, but I’m not sure Qualcomm can deliver.

      It would be nice to have some better microcontroller features too, e.g. the timers on ESP32 are rather basic and limited.

      1. For [simple] home automation, you could basically consider ESPHome to be “the SDK”. The HA integration is practically automatic (just a handful of lines to get online and linked to HA), and though customizing behavior by writing lambdas and scripts inside YAML doesn’t have the best ergonomics, you do in fact have access to basically the entirety of the core SDK if needed.

        If the devices are going to be plugged in and don’t require major customization to the predefined behaviors, I think ESPHome is just too easy to be ignored. For battery-powered or custom things, yeah, ESP-IDF might be the choice to wring out minimum power draw or approriate behavior, but for the vast majority of home automation, ESPHome will probably do what you want.

        Of course, the need to know that everything is ultra-optimized also cannot be ignored, so absolutely no shade to anyone that skips ESPHome for a full-fat SDK. E.G.: I have an LED project that could be done in ESPHome or even WLED, but I’d rather trade the work to integrate it with the home (MQTT FTW!) for ease of coding the behavior in real C++ instead of lambdas or other scripts.

    1. Compared to ESP, I guess QCOM is pretty good in code sync to compilation/build and debug. May need initial struggle to setup toolchain and environment. However, the experience is pretty solid with QCC74X

  1. Qualcomm had already promised that its processors would work well with Linux, that there would be tablets, and that everything would be wonderful. Unfortunately, those promises didn’t pan out.

      1. That is not the meaning of that status thing (it is in fact, very maintained, the board is just not assigned an area, as is the case for most boards, and the general board area is unmaintained).

        Regardless, not relevant here as the point of the link is it’s bouffalolab hw and supported on zephyr.

    1. No Mac tool chain and stuck on GCC 10? So not for professional grade developers that need modern language support. Sure, it’s probably just RISC-V and we could probably use the generic chain by working through linker scripts and finding chicken bits in startup code, and putting that under their libraries, but that’s not an investment that directly moves our own projects forward when alternatives do thay integration already.

      If that’s their commitment to devex and modern tooling, they remain dead to me.

    2. Weeeeelll… I use esp chips regularly, but I don’t know much about user goodwill. Perhaps Espressif has a reputation of having user goodwill, but have you ever searched the web for information about a bug you’ve run into with an esp? If the link returned is on the Espressif forums, there is usually a question with no replies in over 3 years. If the problem is RF related, you will never find an official answer. ESPs are cheap, and mostly easy to use once you figure out the quirks, but support is abysmal, and the ESP-IDF is similar to Zephyr in its verbosity and abstraction (both of which I hate for embedded work). It’s ridiculous.

      1. While it’s true their official forum is mostly dead, they are quite good fixing bugs if you open an issue on their esp-idf Github. I have done it several times, and even made some feature requests (some quite obscure, like for example being able to get packets in monitor mode with failed FCS) and they did them all. This level of support is awesome. On the other hand, I would not expect something like that from Qualcomm, even after signing the usual pile of NDAs.

      2. That reminds me that I’m still waiting for an answer why Bluetooth SPP (Serial Port Profile) is not properly handshaking and I get data overruns when the SDK’s buffers are full.

        Quite a big problem if you are bridging between a PC with an SPP connection to the ESP32 (baud rate means nothing here), and an old computer that communicates at 2400 baud with no handshake signals, and we need to insert a pause after every byte sent.

    3. Qualcomm has negative goodwill from years of treating developer documentation as a profit centre. Them buying Arduino is just the mouse poop on top of the elephant crap cake.

  2. espressif locking their documentation behind oauth for mcp servers really makes it hard to do modern automation against their chips. hope qualcomm opens their datasheets in a machine-readable format to anyone

    1. Modern Automation… oh you mean Vibe-coding and agents.

      I honestly expect locking data via oAuth to become more common. Those bots can be absolute murder on servers and have only gotten more demanding.

  3. I can’t find any products – no development boards and no prices either.

    Once a year, a new chip comes along that’s supposed to dethrone the ESP. A Raspberry Pi Zero 2W currently costs 12 euros here, an ESP32 S3 board is available for less than 6 euros, and at Mouser, the Espressiv chip alone costs 1.59 euros. Both systems have an extremely broad documentation and support base.

    So where does this chip fit in, price-wise and technically – no matter how technically outstanding it is? As a product that meets industry standards? Or as a niche product for quality-conscious users?

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.