Earlier quoted context omitted.
It’s notoriously not a friendly or easy perform to develop for and despite its capabilities, the ESP32 has largely been relegated to daughterboard status in most embedded situations.
Okay, as someone who has used the ESP32 before (but not the STM32), I'm genuinely curious as to why you're stating this as an assertion. What exactly is it about the ESP32 that makes it unfriendly or difficult? (FWIW, all my ESP32 development has been in C with FreeRTOS. I'm not one of those people who insists on shoving the Arduino stack onto everything.)
Updating STM32 Over-The-Air using ESP32
61–63 of 63 posts
Re: Updating STM32 Over-The-Air using ESP32
#62Earlier quoted context omitted.
Actually not that clear cut. You can get a small STM32 with multiple multiplexed 12bit ADC channels, with ~2MSPS sampling speed and 256x hardware oversampling (~16bit), for less than half a buck (per 1000)[1]. Cheapest independent 12bit ADC with >500kSPS I could find on DigiKey were all over a buck (per 1000)[2], and they were all single-channel parts. Now keep in mind that the ADC only does ADC, while the STM32G030…
What're the comparative impacts on battery life of those?
The STMG030 running full tilt at 64MHz, with ADC and one timer (4 channels) enabled takes about 6.7mA at 3.3V according to the simulator.
However looking at consumption in the sim with and without the ADC enabled at full speed, the ADC peripheral itself seems to consume a bit over 100uA. In comparison the ADS7042 datasheet says about 200uA at 1MSPS.
I haven't hooked up the STM32G030 (just got some), so I can't verify the simulator. Would be a fun project though.
Of course the STM32 has power-saving sleep modes etc, which reduces the overall chip consumption to a few uA.
Re: Updating STM32 Over-The-Air using ESP32
#63Earlier quoted context omitted.
You can automate that using flipflops or maybe MOSFETs.
Not my point though. Use case for over the air update is when one has no access to the device or its debug interfaces. So, the implementation must provide for a way to remotely handle entering programming mode, etc. IMO, the disclaimer section should be a part of the implementation.
My opinion is that if you read the page, which is only like 10 paragraphs anyway, you can clearly see how it works and decide for yourself if it's useful for you.