Updating STM32 Over-The-Air using ESP32(github.com) |
Updating STM32 Over-The-Air using ESP32(github.com) |
https://github.com/markrages/blackmagic/blob/esp8266/src/pla...
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.
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.
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.
[0] I am an embedded engineer who works with STM32 and bluetooth modules
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?
(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.)
https://github.com/RIOT-OS/RIOT/tree/master/examples/suit_up...
There are lots of commerical IoT devices that use the ESP chips (Shelly, Sonoff, Tuya e.g.).
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 think this is an idea I shouldn't water though ;).
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.
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.
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.
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://api.riot-os.org/group__cpu__esp32.html#esp32_feature...
You could do a mesh with ESP-Now and RPL though.
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?
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.
You probably want to
- install the esp32 toolchain for RIOT: https://doc.riot-os.org/group__cpu__esp32.html#esp32_manual_...
- 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.
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
There are plenty of open source projects for STM32
There is https://www.openstm32.org
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.
And then they publish 50 pages errata including: "Ethernet functionality in 64-pin packages is not available."
...
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.
But those are at least consistent across chips.
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.
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.
[1]: https://www.digikey.com/product-detail/en/stmicroelectronics...
[2]: https://www.digikey.com/products/en/integrated-circuits-ics/...
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.
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.
[1]: https://www.st.com/en/microcontrollers-microprocessors/stm32...