Electronics > Microcontrollers

Wifi options on ARM (STM32 maybe) MCU?

(1/4) > >>

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.

I found this blog post.  Has good news and bad news.

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.

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!

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"]}}

--- End code ---

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"}

--- End code ---

What makes this good:
1. A network processor becomes a reusable stand-alone component, suitable for many other projects
2. If the interface is UART, it is extremely easy to debug and test both main MCU side, and a network side
3. main MCU does not need to know anything about network
4. MCU <-> network API is human-readable, extendable JSON messages
5. Same approach can be extended to other media - Ethernet, Cellular, Bluetooth, and no changes would be required on the main MCU side


--- Quote from: tellurium on September 30, 2022, 10:55:32 am ---A neat solution would be to turn ESP8266 / ESP32 into a smart network processor with JSON-RPC API over UART.

--- End quote ---

I 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)
Wait.... on status.
Send SUBSCRIBE home/sensors/temperature/office
Wait.... on the interrupt for the receive channel.
Consume the buffer until it ends, parse the JSON, update the display.

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.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version