What would you like to see in The Next Chip?

[SomeESPDev]

On the top of my wishlist is first-class LLVM/Rust support.

• Rust helps with catching bugs at compile time (borrow checker) = huge time saver especially for embedded devices
• additive types/enum with additional data! No more the unsafe "function(enum_selecting_function_mode, &pointer_to_mode_dependent_data_structure)" pattern.
• developer-friendly error handling (using the error-chain or failure crate)
• Cargo as a mature package manager (so we can easily integrate existing platform-independent code like codecs, FFT)
• a turing-complete macro language
• module system/no header files
• because of the pay-what-you-use-design and borrow checker/stricter aliasing rules, generated code might even be faster than C/C++
• compiles easily to WASM and JavaScript, so frontend logic and the esp32-backend can share the same code
• ...

[aureoleday]

NB iot.

[squonk11]

These are the suggestions from my side:

• SPI interface without the "design peculiarity" of the existing ESP32; maybe you have a bug-fix version for the ESP32 soon?

• I found out that the filter functionality of the SPI interface is very helpful for more robust EMC behaviour. So, my suggestion would be to have such filter functionality also with other (all?) pins

• better debug interface

• some/small programmable logic (like FPGA)

• more RAM; Especially for embedtls connections much RAM is required. An alternative could be to have a tweaked version of the mbedtls library with less memory requirement (e.g.: there are some patched versions available)

• easier installation on windows (no Msys2)

• C++ API

[kortschak]

LLVM backend support would be an outstanding addition, not just for Rust use, but for the variety of other languages that are now supported by clang. This was mentioned by ESP_Sprite in 2015. Has enything come of that? Is the work somewhere it could be picked up by the community?

[ESP_Sprite]

SPI quirks *should* be gone in the next chip. We also have some other additions to the SPI peripheral that should help with CPU use.

Wrt LLVM: *EDIT* Nixed because it turned out to be not entirely true.

[kortschak]

Thanks for the update. I actually sort of glad that you're planning on getting LLVM for ESP8266 first - it's the target that we are writing for.

It's odd that Cadence are working that way, you'd think that providing incentives for uptake of their processor designs would be a selling point and a good thing. Thank you for putting in the work to make up for their shortsightedness.

[ESP_Sprite]

Oops, seems I posted something that wasn't entirely true and that I shouldn't have posted. We are developing LLVM for Xtensa first, as I mentioned in my edited post, but it will be coming out for the ESP32 first. Still can't give any timeline, unfortunately.

[permal]

Oops, seems I posted something that wasn't entirely true and that I shouldn't have posted. We are developing LLVM for Xtensa first, as I mentioned in my edited post, but it will be coming out for the ESP32 first. Still can't give any timeline, unfortunately.

Does that mean we're eventually moving away from xtensa-gcc all together?

[ESP_igrr]

permal: we don't have such plans, at the moment.

[permal]

permal: we don't have such plans, at the moment.

Ambitious - gcc, clang, make and cmake all at the same time. Though, compiling the same code with both gcc and clang do have its benefits.