It lists `USB Device` as well. This could be a really accessible device for building hybrid usb/bt devices, like wireless keyboards.
2$ wifi bad usb anyone?
ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
31–40 of 119 posts
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#32It lists `USB Device` as well. This could be a really accessible device for building hybrid usb/bt devices, like wireless keyboards.
It seems it only supports CDC and some JTAG mode. For keyboards and such, the USB stack should support HID which doesn't seem to be the case here. In other words, they've implemented a USB 1.1 FS stack just so far to make intermediary USB2UART chips like FTDI and CP2102 redundant.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#33> Pricing will also be similar to ESP8266. How can they possibly sell these chips at these prices? This is impossibly cheap. You can’t even accuse them of trying to flood and control the market because they already own the market!
You are seeing economies of scale (and cheap labour) in action.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#34Espressif 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…
>stm
gd32v is a stm32 (peripherals, memory map) clone, except using risc-v rather than arm.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#35Earlier quoted context omitted.
"embedded code monkey" Is this really the case? :(
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?
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#36Earlier quoted context omitted.
Why do you need atomics on a single core device?
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.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#37Earlier 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.
Obviously interrupt code can't clobber registers like that, any shared register the ISR needs to share with ordinary code must be saved/restored on entry/exit somehow.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#38Earlier 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 implement higher-level abstractions like mutexes. On a single core device this could be as simple as masking interrupts. You can use the mutexes to avoid the described race.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#39Earlier quoted context omitted.
That's horrifying. What is the fix/mitigation if you don't have proper atomics? I can't see how to properly avoid that.
Obviously interrupt code can't clobber registers like that, any shared register the ISR needs to share with ordinary code must be saved/restored on entry/exit somehow.
I think GP is talking about MMIO or some device register rather than the CPU’s register file.
Re: ESP32-C3 WiFi and BLE RISC-V processor is pin-to-pin compatible with ESP8266
#40Earlier 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?
Sadly no - apart from a very tiny number of silicon valley companies, everyone else in embedded tech seems to pay the people who write verilog and assembly the same as the people who make the schematics and the mechanical designs. That's sometimes only 40% of what people who write python and nodejs get in the same city...