Wifi options on ARM (STM32 maybe)  MCU? - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: September 28, 2022, 01:57:51 pm
content: I wanted something different to Adruino. So went STM32. I've got the initial hurdles out of the way using 3 different STM32 board.I kinda like them.However, the projects that I have which do not require some form of Wifi communications are limited.For that I still have the ESP32, which is awesome, but I just feel that, as a 'learning' MCU it doesn't offer what the STM's offer, in that they, at least give you an MCU entry into ARM architecture.So far I've found the PI Pico W and PI Pico W2, the later being hard to get. The former is IIRC a Cortex-M0 and is a bit rubbish on the grand scheme of things.Obviously ARM still I could go all the way to the RPI. However at that kind of level, of board, with an MMU involved, a general purpose OS becomes the normal and I'm back in comfortable user CPU space. I want to be closer to the metal, I enjoy it, it contrasts me to Enterprise Java day job!ARM is obvioulsy worth learning it's one of, if not the most common architecture in volume. STM32's are popular so lots of community and eco-system, same for the PI.The other thing that attracts me is the range of horse power you can get, from $1.20 8 bit MCUs to $5 Arduino killers, to $100 64bit multi-core compute chips. Which, with quite a few caveats are all the same architecture (MCU <> CPU quite a bit obviously).It's just Wifi that's an issue. I think there are Wifi enabled Cortex MCUs, but they are proving hard to find. I also realise that all I really need to do is use a canned Wifi interface chip and find a Wifi stack library for it, for the STM32 or whatever micro I'm using. That will go one of two ways, the first tutrial I find will cover it or I'll spend months researching experimenting and get lost.

author: paulca
author_rank: Super Contributor
timestamp: September 28, 2022, 02:11:16 pm
content: I found this blog post. Has good news and bad news.https://pcbartists.com/design/embedded/stm32-wifi-options/Seems the good news is the best option is already available to me, it seems a little OTT and that is to use an ESP8266 or an ESP32 as a Wifi Module alone for the STM32 or Arm MCU.I suppose it still allows you to focus on one architecture and pick other support modules when needed.The STM...WB series does currently support 2.4Ghz Zigbee which opens up ideas of battery operated sensors/modules, which Wifi is sh1t at.

author: paulca
author_rank: Super Contributor
timestamp: September 30, 2022, 09:46:22 am
content: So investigating this idea of using an ESP8266 as a Wifi module has opened my eyes to a little bit of the history of said ESP8266 and just how lucky they got with the Arduino maker conmmunity catching on to how much "spare horse power" their little Wifi module actually had when you added some flash RAM.So it seems that long before we had an ESP8266 dev board and Arduino framework core for it, it was treated as a lowly little AT command set, Wifi UART module! It literally behaves like a modem. You even ask it to open TCP/IP connections for you and get the data segment streams over UART at 10Mbit/s or higher.I believe to make it function you needed flash RAM and firmware of course. So modules were sold like the ESP01 which was just the chip + 512k of FLASH, because why not, makers are rich. Then someone obviously figured out that the core, when given half a meg of program RAM could actually do some seriously cool stuff.The Lua dev board which originally launched had custom firmware and presented an LUA interrupter via an IDE. This didn't really take off with LUA ending up being a script language for gamers, but the Arduino community had ported the Adruino framework to the Extensa arch. It was only then that all the clones started to appear. Then the upgraded chips started. The RF can modules with flash contained within, the full dev boards etc. etc. etc. Then the ESP32.The downside is, the eco system outside of the Arduino space is pretty limited. Sure you can learn all about the chip and the Extensa arch, but my understanding is that limits you to a very small subset of chinese MCUs from that company.Some of the peripherals and just, well, non-wow-factor. Compared with the cores, the ADC is pathetic. There are a huge number of GPIOs and some hardware serial, but I believe even I2c is software bit banging.The ESP32 makes up for that a lot and if you want a faster dual core with that much SRAM, you'll need to head pretty high up the MCU world.The only hurdle now is in my head. I considered, for example, using the STM32 to drive the new TFT mini-screen I got and then either use an ESP8266 in "AT modem mode" and do the application protocol (MQTT) on the STM. This at least feels better that I'm using the 8266 just as a Wifi module. However I'm not stupid and I also know the ESP8266 alone will probably handle the Wifi, TCP, MQTT and run the TFT at a high enough framerate, so why don't I just do that? The only answer is I don't learn ARM/STM32 eco-system.I could make it all a more pointless learning excercise and forget "over kill" components, just enjoy trying to get it to work. If it turns out too easy, try and do it with DMA channels instead! So how good you can get your buffer handling to not drop a byte!

author: tellurium
author_rank: Frequent Contributor
timestamp: September 30, 2022, 10:55:32 am
content: A neat solution would be to turn ESP8266 / ESP32 into a smart network processor with JSON-RPC API over UART.E.g. your main MCU can command it to connect to MQTT:Code:{"id":1, "method": "mqtt.connect", "params": {"subscribe": ["myID/control"]}}Then when a network processor receives an MQTT control command to a "myID/control" topic, it can send a notification to the main MCU:Code:{"method": "mqtt.data", "params": "some arbitrary command"}What makes this good:1. A network processor becomes a reusable stand-alone component, suitable for many other projects2. If the interface is UART, it is extremely easy to debug and test both main MCU side, and a network side3. main MCU does not need to know anything about network4. MCU <-> network API is human-readable, extendable JSON messages5. Same approach can be extended to other media - Ethernet, Cellular, Bluetooth, and no changes would be required on the main MCU side

author: paulca
author_rank: Super Contributor
timestamp: September 30, 2022, 12:00:05 pm
content: Quote from: tellurium on September 30, 2022, 10:55:32 amI suppose it comes down to where you put that line. Putting it as "Network / Non-Network" makes sense.The network stack on the ESP8266 via the AT modem mode over UART is very basic. I need to research more, but it seems as though to open a TCP connection, you send the AT commands to open a TCP connection in text. As to how it then connects the IO streams I don't know yet. I know there are AT command to "send n bytes" and probably "recv n bytes", but how then do you deal with multiple TCP connections? A lot to learn.Anyway. I didn't like the example code people were showing/using. Their approach was to use that AT mode UART to treat the ESP solely as a "dumb" Wifi module. This meant the STM32 code contained all those horrible AT strings being transmitted over UART2. Of course the examples most show are a Request/Response like HTTP GET. That's such as easy state machine I expect if you want to consume bidirectional data such as for MQTT over a TCP socket and respond to events, not under run your buffers.... it's going to be a LOT harder to manage that, at that level.So. As you suggest I move that line further and put ALL network related functionality on the ESP. In my case it can start with just Wifi+TCP connection+MQTT. All the STM32 doesn't even need to know the Wifi or MQTT network credentials, the ESP can be "self initied" as an AP and allow it to be configured over the web browser, like Tasmota. Once configured. It will reboot in "slave mode", establish a UART connection with the STM32 and construct IO buffers and DMA channels with interupts, such that a JSON messages can appear in the buffer and "commands" and "outbound messages" be placed in the outbound buffer.Just need to devise that command set and figure out all the buffer/channels/intertupts.A use case might be:Connect Serial - handshake (versions)Send CONNECT.Wait.... on status.Send SUBSCRIBE home/sensors/temperature/officeWait.... on the interrupt for the receive channel.Consume the buffer until it ends, parse the JSON, update the display.Repeat.So the only information the STM32 needs are the topics and the JSON message format, which is application specific and thus in the right place away from the network.Other commands and services can be added later. Maybe for BLE.And yes, you are right the ESP part becomes a "fungible part" resued in many similar projects out-of-the-box.

author: redkitedesign
author_rank: Regular Contributor
timestamp: September 30, 2022, 01:26:42 pm
content: Quote from: paulca on September 28, 2022, 01:57:51 pmI think you're mixing up the Pi Zero W2 (a board with quad core, 1GHz 64-bit ARM Cortex-A53 and wifi) with the Pico series, which are all based on the same RP2040 chip; a dual core 133MHz Cortex-M0+. And indeed, the Pico W has a wifi module.What makes me wonder is why you would consider a dual core 133MHz Cortex-M0+ "a bit rubbish"? What do you want to do that isn't easily handled by this RP2040 device, yet where it is totally unreasonable to just use an Pi Zero, with a full-blown OS? (apart from the lousy availability of any raspberry except the Pico and actual fruit versions.)

author: paulca
author_rank: Super Contributor
timestamp: September 30, 2022, 03:13:41 pm
content: Yea I was confusing the Pico and the Zeros. I think when I watched the various comparison videos on the release of the first Pico MCU board... it was pitted against the 8266 and ESP32 and in that light, it is a bit "meh". Although it does come with the Raspberry PI community and documentation.At the end of the day it comes down to "hobby".If I had a business or commercial requirement to develop a system like this, and it worked financially the a RP Zero a cut down ubuntu made readonly and an afteroon's python code and I'm done. It would depend on the distribution. A small distribution that would work out cheaper as software engineer rates are scandalous and hardware is cheap.Doing it via general OS and high level langauges using mega bytes of RAM is what I do in my day job. Although in that I'm actually a lot further from the metal and it's gigabytes and terrabytes.I just want to have fun and learn with the least, rather than the most. I find it refreshing and helps keep me sane.Also. If I am intending on making a small household dashboard display which might be on 16 hours a day, I would like to keep it's power requirements as low as possible. I know a full RPI 2b pulls 1 Watt ideal and more like 10W flat out. In comparison an STM32 pull about 100th or less than that to do the same job.

author: rstofer
author_rank: Super Contributor
timestamp: September 30, 2022, 03:27:09 pm
content: If you just want an easy way to do WiFi from a reasonably capable processor, look at MicroPython on the Pico W. The networking library does all the work and it implements the Berkeley Sockets protocol. It is also programmable in C++ and it has a nice scheme for saving multiple programs on the device. If one is named main.py, it will always be executed at startup. Not a bad gadget for $6

author: paulca
author_rank: Super Contributor
timestamp: September 30, 2022, 03:33:39 pm
content: Quote from: rstofer on September 30, 2022, 03:27:09 pmYea, I know, I know. I debated the PI for a while. It was a toss up between STM32 and RPI. The small amount of research I did basically suggested for "high level frameworks", like MicroPhyton the RPI is probably the best bet, has the eco system to support it. However, when you move to the lower levels, the community is nowhere near as strong. For that reason I decided to go with the STM32. I want to be neck deep in registers and interrupt handlers. Not downloading a Python framework and writing 5 lines of code and calling it done.

author: hubi
author_rank: Regular Contributor
timestamp: September 30, 2022, 05:09:03 pm
content: I just did a couple projects with the Pico and I really like it. The C/C++ support is great, it has a cmake build system and does not have some silly IDE so you can just use vi or emacs instead. If you want the silly IDE, I think arduino supports it. The programmable I/O (PIO) system is fantastic, talk about being close to the metal, none of this interrupt handler rubbish.The only issue with it is the horrible ADC, but for $6 for the wifi version ($5 without) I'm not complaining.

author: paulca
author_rank: Super Contributor
timestamp: October 01, 2022, 09:50:36 am
content: Quote from: hubi on September 30, 2022, 05:09:03 pmIf by silly IDE you mean the Arduino IDE. Yea. No thanks.However, I've been doing this a long time and even the people in work who write C/C++ engines for low latency trading systems either use a full C/C++ IDE or, in the case of the Linux die hards, the FULL Vim setup. That includes C_tags, indexes, mouse support and in some cases IntelliSense/Auto complete.I mean, yea, it's nice to have projects small enough to not need an IDE, but to be honest they do increase your development speed massively. More so in some languages. Java for example. The speed of development without an IDE and build system is orders of magnitude slower.Back in the stock exchange days myself I used to use "vi and grep" for coding. Eventually however I installed Eclipse C/C++. I could never get it to full index and build the project, but I find the indexes enough for CTRL+Clicking through libraries, which was much, much faster than grepping header files.

author: paulca
author_rank: Super Contributor
timestamp: October 01, 2022, 10:02:58 am
content: Interestingly, this popped up in my feed: RP2040 + ESP32. Maybe next toy.https://youtu.be/eNjvjc0sMNE

author: brucehoult
author_rank: Super Contributor
timestamp: October 01, 2022, 10:52:26 am
content: Quote from: paulca on September 28, 2022, 01:57:51 pmI can certainly understand a reluctance to get too much into the Xtensa-based ESP32s and ESP8266. While Xtensa is fairly widely used in deeply embeded CPUs, the ESP chips are the only places (as far as I know) that the ISA is exposed to end users in a way that they can examine and replace code. Xtensa knowledge acquired by doing things with ESP WIFI chips isn't very useful elsewhere.On the other hand, the newest ESP chips use RISC-V and Espressif have said that all future products will be RISC-V based instead of Xtensa.There is also the similar Bouffalo lab WIFI/Bluetooth chips that also use RISC-V: the BL602 and BL702 ranges.RISC-V obviously isn't as popular as ARM at the moment, but the momentum is huge and learning about it would not be wasted.QuoteWhaaaat? "8 bit MCUs" ... the same  architecture?Nooooo. There is no 8 bit ARM. Never has been. ARM started as 32 bit in 1985 and got a new and vaguely similar 64 bit ISA in 2015 or so (spec published in 2011).RISC-V is also 32 and 64 bit only at present, with opcodes reserved for a future 128 bit version. One of the biggest differences to ARM is that the 32 and 64 bit ISAs use the same mnemonics and binary opcodes, but operating on 32 bit registers and values in one case and 64 bit registers and values in the other. The 64 bit ISA also adds a few instructions (10 in RV64I) for directly doing 32 bit operations on a 64 bit CPU.This being the Microcontrollers topic, I'll also point out that there are no 64 bit ARM microcontrollers, only applications processors. RISC-V doesn't make the same distinction, and you can buy or make a 64 bit RISC-V equivalent to a Cortex-M0 if you want. The dual core 400 MHz 64 bit K210 microcontroller chip (8 MB of on-chip SRAM) has been quite popular for a few years now.

author: hubi
author_rank: Regular Contributor
timestamp: October 01, 2022, 11:08:52 am
content: Quote from: paulca on October 01, 2022, 09:50:36 amI'm more of an emacs guy myself, but I do use vi for editing config files and such. Emacs could be called an IDE, I guess, you can build and debug in it, use tags and completion, and even connect to a microcontroller via a serial port. My experience collaborating on large projects does not support a massive increase in development speed from IDEs, particularly Visual Studio. But like you guessed, my comment was really about Arduino.I haven't had any luck finding the pico with wifi, but I noticed yesterday that digikey has over 7,500 in stock for $6 each. I will order a few to play with.

author: paulca
author_rank: Super Contributor
timestamp: October 01, 2022, 06:23:24 pm
content: I spent a lovely frustrating day playing with the STM32s.Spent ages trying to work out why "snprintf" hard faulted the F0. I never did get the bottom of it. However I was running into 80% memory and 80% flash and figured I'd overshot some of the sections, so heap or stack overflow, the exception handler addresses weren't much help either. General Exception.... Nested Exception. Infinite loop.Then I spent ages getting an assembler test project running. Just by declaring a void(void) function pointer to it. Learnt a small amount of just how weird ARM can be and mostly spent the time fumbling at GCC-ASM.Finally after trying to get "blinky" working in ASM. I resorted to one step up, to get the ASM from the compiler.Turbo blinky:GPIOA->BSSR = 32;GPIOA->BSSR = 32<<16U;7.8Mhz apparently. Basically a sine wave on my "100Mhz" scope.

author: fchk
author_rank: Frequent Contributor
timestamp: October 06, 2022, 04:30:58 am
content: Alternative: TIfor examplehttps://www.ti.com/product/CC3235MODASF(they have much more)

author: krho
author_rank: Regular Contributor
timestamp: October 06, 2022, 09:11:45 am
content: Quote from: fchk on October 06, 2022, 04:30:58 amLast time we checked the availability for most of those modules or chips only if you want to do your own modules from TI was 18 months or so.

author: bidrohini
author_rank: Regular Contributor
timestamp: November 07, 2022, 06:56:18 am
content: To use Wi-Fi with STM32, you will need to add some sort of Wi-Fi/BT module or SoC that handles all the wireless networking.https://pcbartists.com/design/embedded/stm32-wifi-options/

author: fchk
author_rank: Frequent Contributor
timestamp: November 08, 2022, 07:31:37 am
content: TI has interesting parts.https://www.ti.com/product/CC3235Sfchk

author: paulca
author_rank: Super Contributor
timestamp: November 08, 2022, 02:21:58 pm
content: I've gone around in circles on this and decided to settle on keeping it simple, generic, but not too generic.So... I'm making up a board with an STM32F411 and an ESP32 hardwired and pre-flashed with the latest AT Command firmware.The latest AT command firmware includes the full TCP and MQTT stacks as well as the full Wifi and BT(LE) stacks. I already posted somewhere on here that I had a functioning (HAL based) STM32 library to drive the ESP32 all the way to producing incoming async MQTT messages in a buffer, while still retaining the synchronous request/response AT command channel open.First board will be for my purposes only. STM+ESP+ILI9341, form-factor to match the ili9241 2.4" screen board+headers. If that is successful I will look at options to provide full break outs from both MCUs. However the focus of the board would be to allow MCU devs focused on STM32 world to jump into highlevel Maker style IoT or NoT.I'm sure it's already been done a dozen times, but not the way I liked itMy use case is for a Home automation dash board and quick control touch screen.