Didn’t Intel also try to brand the 64bit x86 extensions as ia-32e initially? Seemed like wasting an opportunity to me.

(Disclaimer: I work at Intel but this was way before my tenure.)

Maybe Espressif will notice that there are no RV32 chips with MMU so far (at least to my knowledge); we only have 32 bit MCUs or then only 64 bits for the CPUs. Something like Cortex-A7 is missing.

Does anyone know what CPU this uses? Is it their own first party design?

> I'm more hopeful for single-pair ethernet to gain momentum though!

I keep looking for a reasonably priced 10baseT to 10Base-T1L bridge... everything commercial seems too expensive (for me) and the two hobby designs [1] [2] I've seen are not orderable :(

But I'm seeing more commercial options lately, so that's hopeful.

[1] http://robruark.com/projects/10BASE-T1L/10BASE-T1L.html

[2] https://matthewtran.dev/2024/08/10base-t1l-converter/

Waiting for my ManT1S:

https://www.crowdsupply.com/silicognition/mant1s

SPE with multidrop and PoDL would be awesome ! They are working on that and it will be everywhere.

PoE is not obvious to implement (take it from someone who has done it with a fair share of mistakes), uses more expensive components that normal ethernet, takes up more space on the board, makes passing emissions certification more complex, and is more prone to mistakes that ruin boards in the future, causing support/warranty issues. In other words, a bag of worms: not impossible to handle, but something you would rather avoid if possible.

A full-module add-on in this power class is about $7 at 1,000 unit scale [0]. It would be around $3 with your own custom PCB design in terms of BoM addon at scale. That’s power only. Add another dollar or two for 10/100 PHY.

The trick is as others have said in what adding it to your design does in terms of complicating compliance design.

[0] https://www.digikey.com/en/products/detail/silvertel/AG9705-...

PoE power supplies need to be isolated (except in rare exceptions) and handle much higher voltages than common USB-C or wall wart power supplies.

They have to use a transformer and a more complex control strategy, not a simple buck regulator with an inductor. PoE inputs need to tolerate voltages several times higher than the highest USB-C voltages, so more expensive parts are used everywhere.

Ethernet is already one of the most expensive standards because you need magnetics for isolation. Adding power on top of that is genuinely expensive.

Whenever you combine two things into one, the complexity and cost go up considerably. A regular coffee machine is pretty cheap. Add high pressure so it can make espresso and it gets considerably more expensive. Add milk so it can make cappuccino, again more complex and expensive. The same holds for electronics. Isolating power when it's alone is fairly straightforward. It gets considerably more tricky and hence more expensive the moment you want to place any kind of a meaningful data signal in its vicinity.

I’m sure the other commenters are right, but I’m guessing market segmentation may play a role here too.

> You don't need long cables, just a local power source

Which means batteries that have to be replaced and maintained or cables... So ethernet with PoE or even better SPE (single pair Ethernet) with PoDL (power over data lines which is PoE for SPE) is the best from my point of view

Esp32 's wifi is only 2.4ghz though.

Is what you described a truth for all IoT devices? If I have los of my AP, why do I need 2.4Ghz? Even so, what SNR do you truly need for this low bandwidth application? Where is the engineering here?

I have a unique position of having a data set over 8000 APs with 40k unique devices. If you design properly, there is no need for 2.4 ever. 2.4Ghz congestion (with nearly no actual 802.11 traffic) is very high. To the point where the IoT folks are struggling.

>My 2.4ghz is basically all IOT these days.

Yup. And it's exactly why some of my IoT admins are struggling. There is only so much spectrum to go around.

Yes. And 2.4 lives and dies by that sword. What downsides might there be in areas where dozens of APs hear each other and 100s of clients hear each other?

Yes and in some uses cases it works against you. 2.4 is incredibly crowded without adding 802.11 to the mix. My IoT admins would have less complaints if they could take advantage of my small cell 5Ghz spectrum. This isn't 2005 with widely deployed asymmetrical wireless networks.

Realistically 2.4Ghz is far from "greatest backward compatibility" since there is a real benefit of running 5Ghz and 6Ghz only networks.

2.4Ghz makes sense because this tiny device does not need high speeds Wi-Fi connection, and deployment scenarios benefit from 2.4 GHz penetration more.

There is μClinux [1] although it is not clear to me how much alive is the project

I wish I could run DiscoBSD/RetroBSD [2] on an ESP32, I like the idea of running on a MCU something that was originally meant for a PDP/11 (2.11 BSD)

[1] https://en.wikipedia.org/wiki/%CE%9CClinux

[2] https://github.com/chettrick/discobsd

you can run linux on riscv without an MMU. There is mainline support for Kendryte K210 chip, so it should be possible port to this chip provided you have enough PSRAM.

Just to get an idea of its capabilities.

Imagine installing Claude Code in it with full root access. Just by asking a few things, you can have a semi-broken ESP32 doing stuff.

> there is drama around platform-io

What do you mean ?

For those using PlatformIO, the folks at pioarduino[0] are doing a great job keeping up with Arduino Core 3.x support.

    ```
    # platformio.ini
    platform = https://github.com/pioarduino/platform-espressif32.git#55.03.37
    framework = arduino
    ```

[0]: https://github.com/pioarduino/platform-espressif32

how's Rust on the xtensa cores ?

Well, that depends on what you count as a backdoor, but Espressif has had some questionable flaws:

- Early (ESP8622) MCUs had weak security, implementation flaws, and a host of issues that meant an attacker could hijack and maintain control of devices via OTA updates.

- Their chosen way to implement these systems makes them more vulnerable. They explicitly reduce hardware footprint by moving functionality from hardware to software.

- More recently there was some controversy about hidden commands in the BT chain, which were claimed to be debug functionality. Even if you take them at their word, that speaks volumes about their practices and procedures.

That’s the main problem with these kinds of backdoors, you can never really prove they exist because there’s reasonable alternative explanations since bugs do happen.

What I can tell you is that every single company I’ve worked which took security seriously (medical implants, critical safety industry) not only banned their use on our designs, they banned the presence of ESP32 based devices on our networks.