ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
51–60 of 119 posts
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#52I wonder how power consumption is? Power power use (especially when sleeping) is probably my main complaint with the ESP boards I've used
Hope it went for the better if the core is a hard macro. As far as I heard, they didn't change the process.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#53I wonder how power consumption is? Power power use (especially when sleeping) is probably my main complaint with the ESP boards I've used
There are plenty of esp32 boards with 10-20uA deep sleep current, how low do you want it?
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#54Earlier quoted context omitted.
It's a pretty uncharitable description, but yeah. There are only two types of companies that do this though: companies where they're working at such a scale that spending a few extra months to years of developer time doesn't make a dent compared to the BOM savings. You're more likely to get vendor support by name recognition at these kinds of companies, so it's not as bad as the hobbyist experience. The second kind i…
Is it even possible to make as much as the hype fields (webdev, data science, ML) in embedded? Is there opportunities for startups in HW sector?
> Is there opportunities for startups in HW sector?
Yes, but certainly not in the Western hemisphere.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#55Espressif is no longer alone in the ultra low cost hobby WiFi SoC space. Pine has started working with the Bouffalo BL602 which seems to be a fairly similar RISC-V powered part: https://www.cnx-software.com/2020/10/28/the-quest-for-a-blob... It will be interesting to see which one gains critical mass in community use.
It’s all about the software & documentation. There’s lots of “competitors” to esp32, pretty much none of them except STM have the software for developers, which makes their offerings close to useless. The only way to gain critical mass is relentless deep commitment to developer tools/libraries and documentation. In many cases these competitors actually try to hide their documentation and keep secret how their chips w…
RISC-V so far is a turndown for a design, speaking honestly.
ARM have by faaaaar the best tooling in the industry, which are more open, than not, and the baseline is made on GNU toolchain, only with more fancy debug tools being paid/locked down.
RISC-V did not yet benefit from its openness for as long as tooling go.
However, RISC-V would still be infinitely better than Cadence, and them wanting $100k for a basic (and terrible) debugger with coresight-like functionality.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#56Espressif is no longer alone in the ultra low cost hobby WiFi SoC space. Pine has started working with the Bouffalo BL602 which seems to be a fairly similar RISC-V powered part: https://www.cnx-software.com/2020/10/28/the-quest-for-a-blob... It will be interesting to see which one gains critical mass in community use.
It’s all about the software & documentation. There’s lots of “competitors” to esp32, pretty much none of them except STM have the software for developers, which makes their offerings close to useless. The only way to gain critical mass is relentless deep commitment to developer tools/libraries and documentation. In many cases these competitors actually try to hide their documentation and keep secret how their chips w…
> gain critical mass is relentless deep commitment to developer tools/libraries and documentation
Which seems (IMHO) why the likes of Texas Instruments has failed. They've made a few attempts at jumping on the IoT bandwagon over the last decade and should have been in a perfect position to capitalize on the huge uptake but it just didn't fit their profit margin goals I'm guessing.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#57I wonder how power consumption is? Power power use (especially when sleeping) is probably my main complaint with the ESP boards I've used
There are plenty of esp32 boards with 10-20uA deep sleep current, how low do you want it?
Mind pointing me in the right direction? The ones I have are more like 10-20mA (maybe that's a side-effect of having USB on board? I'm not really an expert, I just want my battery powered stuff to last months instead of days)
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#58Earlier quoted context omitted.
It's a pretty uncharitable description, but yeah. There are only two types of companies that do this though: companies where they're working at such a scale that spending a few extra months to years of developer time doesn't make a dent compared to the BOM savings. You're more likely to get vendor support by name recognition at these kinds of companies, so it's not as bad as the hobbyist experience. The second kind i…
Is it even possible to make as much as the hype fields (webdev, data science, ML) in embedded? Is there opportunities for startups in HW sector?
Starting out no, but there is plenty of demand for experienced people. If you don't have experience then build up a portfolio.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#59I’d love to see a similar hobby-oriented chip that supported Thread as well. It’s a low power IPv6 networking stack that’s designed for connected home automation.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#60Earlier quoted context omitted.
Interrupts and exceptions can happen at any point in a program's execution on a microcontroller, and they are free to modify memory and peripheral registers. >Load >Modify register in memory >>Interrupt happens and changes >Write incorrect value back to . These sorts of bugs can be pernicious to debug, and they are easy for novice developers to create.
That's horrifying. What is the fix/mitigation if you don't have proper atomics? I can't see how to properly avoid that.
You can disable interrupts when modifying locking primitives, and save/restore the CPU context when interrupts are entered/exited. You can also minimize the amount of changes that any interrupt handler can make within the interrupt context.
It's not really that bad, and plenty of microcontrollers lack atomic operations.