thanks for the link! I have some never used esp8266 laying around! I might try to use it for my stm32 tinkering! (I have a couple of discovery boards around as well)
The ESP32 datasheet is 62 pages. The STM32F4 datasheet is 1729 pages, and that's not counting the reference manuals.
The ESP32 datasheet contains about 3 paragraphs about the ADC, which basically say that it has an accuracy of +/-6%, see example code for ways to calibrate it (which probably amounts to a linear interpolation between two sample counts with the pin pulled to ground and AVDD). In the STM32 manual, the section on the ADCs is much longer than the entire ESP32 datasheet, and goes into gory details about every possible nonlinearity/ missing counts/ slope/ offset/ noise/ reference voltage and other various potential sources of error you might encounter. If you wanted to build, for example, a wireless machine that included a precision scale, you can see why you'd want to use the STM32F4 ADC instead of the ESP32 ADC because a thorough understanding of that peripheral is critical to your application.
If you want to drop in someone else's ESP32 code and use it to push bytes over the air, it's a great tool. If you want to actually develop some application for it that doesn't exist yet, you're on your own.
Yes, people don't realize how inadequate ESP32 is for commercial use. There are literally no commercial products that use ESP32 (or its older brother ESP8266) besides some chinese cheap toys on Amazon.
There are packages out there that use ESP32 as a "augmentation" chip to do OTA with a main processor being STM32 or NXP. There are also major security flaws and silicon revisions made by ESP32 that makes the whole thing reek of inadequacy beyond anything a hobbyist would do.
ESP32 -> Hobby use only. Don't spin up $500k of tooling and HVM batch relying on a weak CPU that will give you some chance of a complete recall or losing your customer base that took many years to build.
Hobbyists on Youtube and EE Stackoverflow are oblivious to the professional world. Let me know if you would like sources, I don't have time to dig into it but esp32.net is a good place.
And due to popularity of ESP in hobby circles, there are many good open-source firmwares for those devices, such as ESPurna with its very impressive feature set: https://github.com/xoseperez/espurna
The final product is better than almost any "professional" IoT device. I'd rather risk with higher odds of system failures (the Atom bug showed that not even Intel is safe) than suffer daily with slow, buggy, expensive, restricted and privacy-hostile cloud-connected trash from the likes of Logitech.
I'm not certain I would consider this a 'feature'.
I have been forced to use F042 and F767 for work, and I must say, I have never seen such convoluted peripheral implementations in my life. There is complexity for complexity's sake, it seems to me. I could write a booklet about this, with each bloated, twisted peripheral as a chapter.
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 has several 16bit hardware timers and other peripherals.
Kinda hard to compare, since the external ADC doesn't do much without speaking to a microcontroller...
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.
It's $1 for an STM32F0 or $2.65 for an STM32F4 with a quantity of ten 12-bit 2.4 MSPS ADCs included, but a single-channel SOT23-5 ADC chip is also $1, and if you wanted 10 single-ended channels at 2 MSPS you're looking at $8 per device.
You typically don't use an off-chip ADC peripheral when most every MCU has a few channels of ADC on-board unless you've got special requirements (like sigma-delta high-resolution, simultaneous sampling, very high sample rate, etc), and those requirements cost money.
To be clear, there is a quantity of one ADC in the STM32F4, with a multiplexer in front. You could emulate this with an analog switch like 74HC4051, which costs pennies in quantity.
To the extra clear, there can be either one or three ADCs in the STM32F4, depending on model. The STM32F405/F415 models for example have three.
STM32 models with more than one ADC, they can typically be interleaved to increase effective sampling speed. In the case of the STM32F405/F415, the three 2.4 MSPS ADCs can be interleaved for up to 7.2 MSPS.
The STM32 ADCs are also quite accurate with proper board layout in my experience, so you actually get close to the 12 bits. Some newer STM32 models also support hardware oversampling to effectively get close to 16 bits.
STM32 is available with more, and better peripherals and interfaces than the ESP32. Embedded microcontrollers perform a wide variety of tasks, aside from simple digital communication.
[0] I am an embedded engineer who works with STM32 and bluetooth modules
So this is totally off-topic and a bit you are going to think I am very rude for intruding:
I was just looking around whether it is possible to create custom apps (on phones) to sync with smart watches (generic ones from places like aliexpress). I have no experience with bluetooth, but is there anything that would prevent you from making something like that? Even if it is just for myself, I don't need to release or anything.
Do you happen to know if it is possible and where I can look?
There are no hardware obstacles to doing that, and BLE (BT4 and 5) support custom protocols. That said, I think you will find that working with the proprietary operating systems and architectures on watches and phones is much more difficult than you anticipate.
I figured it is most likely too difficult. For the amount of work it would take I could just buy an Apple watch and be done with the privacy concerns I have with cheaper trackers, but once the seed of an idea is planted it starts having a life of its own.
I think this is an idea I shouldn't water though ;).
Wow this is amazing! It is exactly what I was looking for except for it being on Android only, but at least I now have a whole code base to learn from. Thanks!
I would describe the ESP32 as having a basic peripheral set. The ADCs and DACs are not great, and there are basically no other analog peripherals. The timers are meager, and low-power functionality is lacking.
The documentation is horrible, which is very important when you compare it to NXP and STM which both put out fantastic 2k-3k page reference manuals.
Yes it's a shame.
The hardware is quite capable for the price but the documentation is lacking, so one has to resort to reverse-engineering - which is totally ridiculous.
Traditional MCU vendors have set quite a high standard to the quality and availability of documentation.
I know good documentation takes effort, but the lack thereof is hampering the product.
One can only hope that with Espressif trying to become more mainstream, they will improve in that department.
A datasheet is a contract, not just documentation. If they put something on the datasheet, they need to write the document, then test the parameter, and guarantee that performance.
If I receive 10k of a part that does not satisfy specified performance parameters, I will return the reels, and never design that manufacturer's parts into any future product.
Oh, surely they're not contracts. They're full of disclaimers like: "MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND [..], RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE."
And then they publish 50 pages errata including: "Ethernet functionality in 64-pin packages is not available."
Well the Errata Sheet should be considered part of the data sheet ;)
Working with same54 has taught me to always also read the Errata Sheet when checking out a feature, I can only guess that there was a bit of a shake-up with the acquisition by Microchip that so many errors slipped in.
Not that STM32 is any different. Recently I designed around STM32F105 specifically due to it's ROM USB bootloader. Too bad I didn't read the errata which says no USB bootloader for 64 pin package.
Well, I can tell you that if 5% of the parts on a reel are out of spec, that reel is being returned for a full refund. Everyone treats the datasheet as a contract, whatever the small print may say.
This is also why parts can often perform well above their specified performance levels, and often have undocumented functionality; the manufacturers are happy to design in this performance, but they refuse to test and guarantee it.
I generally recommend going for the highest-spec board that suits your requirements. The STM32L4+, STM32L5, and STM32H7 are all amazing microcontrollers.
I'm playing with STM32 Cube IDE right now. I got surprised that it works well on Linux (ok, I did only basic stuff, but did not have any trouble setting it up).
However I was wondering what would be totally open source toolchain and development setup? That might be too advanced for me now (and I'm happy with graphical peripheral selection in ST tools), but would like to try it in the future
Also there are plenty of Open Source RTOS projects that come with a HAL, so you can write code that is vendor independent.
Zephyr is probably the largest full-featured RTOS, it's backed by the Linux Foundation and several hardware vendors (NXP, Nordic, Intel, Ti and SiFive), but the community provides support for other vendor's chips too.
RIOT-OS is more popular in the academic sector, targeting sensor networks.
NuttX tries to bring a POSIX environment to your MCU and of course STM32 is supported there too.
there is of course ARM Mbed, but that feels more like a framework than an integrated OS.
Heck you can even run Linux on the larger STM32s (M4, M7) if you attach some external RAM - kernel support was provided by ST themselves.
Are any of those available multi-core? It's one thing that's pretty nice on the ESP32, especially for the cost and lack of complexity for simple cases. I couldn't find a similar STM32 part that was relatively cheap, low pin count (eg 48 pin with ethernet Mac support), and had dual core.
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.)
I’m not an Arduino fan either but I primarily work on the opposite end of the spectrum working with the bare metal directly. ESP32’s documentation is nonexistent compared to STM32 and the ARM Cortex core in the STM32 chips has infinitely better tooling than anything with an Xtensa (this more than anything else was the deciding factor in my book).
On RIOT we’ve put quite some work into implementing the peripheral APIs on the esp8266/esp32 just like on any other supported platform.
So no matter if you are on stm32, esp* or ATmega, you can run the same code.
Concerning the contribution of code for adding Bluetooth support - if a company would want to allocate some time and a person for this cause, would there be someone who can guide them in the process? Perhaps the challenge could be broken down into smaller components?
Assume that you get a rational human being at the input, they know various programming languages (including C and C++), but have no experience with RIOT whatsoever - would this work out?
> if a company would want to allocate some time and a person for this cause, would there be someone who can guide them in the process?
A good first step would probably be to create an issue on the issue tracker, so the relevant people can be informed and you can get some information about what was already tried / what needs to be done.
I'd also recommend the IRC/Matrix channel, but the main esp* maintainer (@gschorcht) doesn't hang out there.
> Assume that you get a rational human being at the input, they know various programming languages (including C and C++), but have no experience with RIOT whatsoever - would this work out?
RIOT is a rather simple system IMHO, I found it easy to get into it and the community is pretty helpful.
With Bluetooth and esp32 you have picked a pretty hard project to start. The esp32 is notoriously bad documented and Bluetooth is a complex beast on it's own.
Currently Bluetooth is only implemented on nrf51/nrf52 using the NimBLE stack.
To get to know RIOT a bit it's probably good to play around a bit and fix small things that you find are broken / need improving if you notice any.
- flash the networking example: make BOARD=esp32-wroom-32 -C examples/gnrc_networking flash term
This will default to esp_now, you'll get a shell can can ping other esps.
- flash the border router example: make BOARD=esp32-wroom-32 -C examples/gnrc_border_router UPLINK=wifi WIFI_SSID=your_ssid WIFI_PASS=secret_password flash term
This should connect to your WiFi and act as a border router to the esp_now network. All your esp_now esps should now be online, given that your WiFi provides an IPv6 connection and DHCPv6.
If you enable the sock_dns module, you should be able to ping hosts on the internet directly by name
Configuration is done through the application Makefile, there is an ongoing effort to move to Kconfig but this is not finished yet.
Sorry, for going a little off topic here but the same implementation was also done for AVR MCUs (include the famous Arduino UNO & MEGA). Feel free to check it out here -
This project is a part of a commercial usage, where the entire product was located remotely, thus it was not possible to manually flash the STM everytime.
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.
https://github.com/markrages/blackmagic/blob/esp8266/src/pla...