This looks awesome, I'd love to get one. Question, what's the advantage over something like the ESP32C3 and the like? Just even smaller?
This looks awesome, I'd love to get one. Question, what's the advantage over something like the ESP32C3 and the like? Just even smaller?
If it helps, I've used earlier Atmel AVR chips, as well as the ESP32-S3.
8-bit AVR is an extremely clean, relatively simple instruction set that can be viably hand-coded. It's fairly straightforward to calculate the exact number of cycles your code will use, which is handy for applications requiring deterministic timing and for knowing worst-case execution time of interrupt handlers.
If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Atmel also tends to do a better job of their documentation. I've lost count of how many confirmed errata I've reported to Espressif, and the time (and steam) I lost troubleshooting them in the first place.
I like the S3, and it's heaps powerful, but for small projects that don't need advanced peripherals like Wifi, DMA, etc. I can envision that AVR as being a fine choice.
> If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Its not, not really anyway. The Xtensa LX7 in the S3 is very weird, though also quite fun to play with. The C3 is RISC-V
Thanks for correcting me. Are there any good, small "Hello World" examples of RISC-V programming with the C3 you can point me to? I'd love to get a sense of how it compares in practice.
I'll second this.
Doing asm on the AVR is beautiful, you can count clock cycles easily and then observe them on the scope.
I wrote a bit banging serial interface for an AVR once and had a mystery when I was testing it from a PC just with a basic echo. Every Nth character would be wrong. Was able to figure out a timing problem by counting clock cycles and found the bug in my code.
Was cool to see it align with what I was seeing on my oscilloscope.
If it had a female usb c connector at the other end, we could daisy chain those or connect other device on the same port (like mcu in the middle).
It isn't necessarily smaller. See https://github.com/PegorK/f32
It's a much less fancy cpu that's very small. No wireless. Lower powered I would expect. But it's an MCU with something like 16KB of flash and 2KB of ram if I remember right. The analog stuff on it is supposed to be pretty good. The Anduril flashlight firmware (toykeeper.net/anduril) is a somewhat popular application that can run on it.
> Lower powered I would expect
With the right software, ESP32 can be incredibly low power. Like "months on 3xAA batteries" for watching a pin with the ultra low power subsystem and then occasionally waking up and making a HTTPS call over WiFi.
This is just kind-of low-power. Some microcontrollers (e.g. PICs) can have sleep consumptions measured in nanoamperes. Months to years on a coin cell... just, they would need an external wifi module, which is highly inconvenient.
That's not lower power, is it? E.g. RuuviTags can run 3 years or longer while sending sensor data 2.5 times per second, with a single CR2477 (3V 1000mAh). A single AA alkaline battery has 1.5V and 2100-2700 mAh (https://batteryskills.com/aa-battery-comparison-chart/ , somehow this data was difficult to find so I'll add this link :)).
Bluetooth is lower energy than WiFi, but in your scenario the energy used for the radio is quite low anyway.
nRF52832 are famous for their low energy usage, it's hard to compete with them. However, ESP32 is much more universal.
Do you have an example of such a setup handy?
[dead]