Polish your crystal ball: best mcu/radio successor chips?

[NeverDie]

As for me, I think 100na (or less) for MCU current consumption during deep sleep with full memory and register retention is a reasonable expectation these days. As a point of comparison, the RFM69 also has 100na current consumption in its deepest sleep. So, add a TPL5010 or equivalent, and that brings the total current drain to around 235na for a radio+atmega328p_mcu+full_memory_retention+periodic_wakeup as something that's been possible for the last 4 or 5 years or so. I guess these numbers are just hard to beat, because I still don't see much serious competition to Microchip/PIC. I thought I would by now, but I'm just not seeing much. Most ARM CPU's seem to be a minimum of around 2ua, or an order of magnitude more. For instance, the nRF52840, IIRC, has around that much current drain.

That said, I'd like to move beyond the atmega328p, which feels a bit cramped to me, and yet nothing as well supported as the atmega328p seems to stand out as an obvious choice in the competitive landscape. The atmegax32 series offers the same 100na sleep current, and some of them do offer a bit more breathing room. Maybe I'll look into those. Not sure. I thought that by now Arduino would have added newer mcu platforms, but I guess their hands are full with what they have. TI's MSP430 is approaching parity, which is good, but being equal isn't really compelling enough to make a switch. To make a switch, it should be dramatically better.

If I had to guess, the stm32wl series
(https://www.st.com/en/microcontrollers-microprocessors/stm32wl-series.html ) seems like it might be a reasonable candidate for the "next thing", as it's low power and integrates a LoRa radio. According to their presentation:

it consumes just 31na in full shutdown mode, but with a startup time of just 267usec. Alternatively, current consumption is 390na in standby mode with 32KB ram retention and an RTC running, which is then only 29usec startup time. Notably, all off, but with the RTC still running, it's 175na, so in that sense it does appear to beat the best of what can be done with an atmega328p+radio+tlp5010, and all in one neat little SOC package. Furthermore, for comparison, IIRC, the cold startup time on an atmega328p is something like a couple milliseconds, so it wins there as well. Bottom line: more compact, more energy efficient, and a far more capable MCU. What does all this cost? $5.99 for easy to solder modules: https://store.rakwireless.com/products/wisduo-lpwan-module-rak3172?variant=40014759362758 Actually, that one's preconfigured for AT-commands. Not sure whether that can be overwritten (I suspect so), or whether you'd want to buy something different to get full control. But, either way, it's a datapoint on price.
Worthy of note: that's the base model, the stm32wle5. In December 2021, ST released an enhanced version, stm32wl55, with what looks like all kinds of security features, if that's your thing:

The downside? It's not arduino, so it will be yet another tool chain to learn. Also, it's not obviously an easy jump to make: extensive arduino libraries for most devices are a luxury that's hard to part with. That said, I haven't tried stm32 libraries; maybe by now they're fairly complete for most things. Not really sure. Plainly stm32 mcu's are everywhere, so.... how hard can it be?

Well, that's my attempt at prognosticating. I'm no better than you are though, and certainly not better than you all collectively. Therefore, I solicit your opinion, and maybe together we can better chart the future so as to better align with it. In short: What do you all see as the likely hardware future?

[idanronen]

@NeverDie I'm not sure the amount of customization each stm32 version/core requires, but my limited experience with the blue pill wasn't that bad in terms of finding support for basic interfaces.

In the end (IMO), community support is everything, and whether stm, notrdic, or a Chinese clone of one of those takes the main stage is up to how friendly the SDK is, and what gets ported quicker to arduino.

[ejlane]

@NeverDie Using platform.io, you can still use Arduino libraries with the STM chips. In fact, I've done just that and got a system on my workbench right now with it and MySensors. Seems to work just fine. I'm pretty sure that there's support for doing all this same stuff in the Arduino IDE directly, but I haven't done it that way.

One huge benefit of the platform.io IDE is that you can also specify programmers, on top of all kinds of other command-line scripting that should happen every time. I have it set so that it knows to use my ST-Link clone to program the board, so it does everything automatically every time and is absolutely painless. I again suspect that there's a way to set up the Arduino IDE to do this also, but I don't know how.

I don't have the time to go into details right now, but if you're interested in going this route, let me know and maybe over the weekend or next week I can dig up some more details for you. Though I found everything online, of course, so it's out there. If you have questions or get stuck at some point, let me know and I can also share whatever relevant settings I have that have let it work for me.

[NeverDie]

@ejlane said in Polish your crystal ball: best mcu/radio successor chips?:

@NeverDie Using platform.io, you can still use Arduino libraries with the STM chips.

Is that true for any of the STM MCU chips, or just for the STM "blue pill" MCU? The blue pill had a lot of custom software development work done for it by Maple to make it run like an arduino. If, on the other hand, it's true that now any STM MCU can be programmed using arduino libraries using platform.io, then indeed that would be very good to know!

[mfalkvidd]

https://docs.rakwireless.com/Product-Categories/WisDuo/RAK3172-SiP/Overview/#product-description could be a nice package.

[ejlane]

@NeverDie Probably not every chip, but a huge ton of them. STM32 chips and STM8.

You can also set the framework to something other than Arduino, but of course then MySensors won't work.

In fact, I had to add a build option to make Platform.io use the Maple core, because that was the only one that would work with MySensors. (At least that's what I found at the time.) I don't remember what the default was if you don't specify which core to use, but I was getting some weird errors at compile time from MySensors. I might even have posted about them here somewhere.

This was the option, at the end of my platformio.ini file:
board_build.core = maple

And even though platform.io supports building for STM8 with Arduino, I never tried one for MySensors, so I have no idea if it would even work. I just included the list of them to show how much support platform.io has these days. I'm not sure one of the STM8 chips would even have enough flash space for MySensors, nor whether they support all the same instructions.

Anyway, once you get the settings right, it just works and I'm very happy with it. My sensors are a mix of NRF51822, STM32, and Atmega328 and they all are easily programmable with platform.io. (Though I still don't have much beyond the testing stage, as I keep changing large things like whether my gateway will be serial or mqtt...)

[NeverDie]

@ejlane Reporting back: this youtube video at this time index describes a way to determine whether platform.io supports a particular platform on a particular chip:

Here's a link to the youtube video itself:
PlatformIO - A True Alternative to the Arduino, MBED, and STM32 IDEs – 16:10
— Gary Explains

Alternatively, a list of supported boards can be found here: https://docs.platformio.org/en/latest/boards/index.html Fortunately, the Nucleo-WL55JC, which uses the stm32wl55 mcu, is on the list. Even better, it says it supports the Arduino framework for it, so this sounds very promising indeed. https://docs.platformio.org/en/latest/boards/ststm32/nucleo_wl55jc.html In theory, then, that should make it much easier for mysensors to be compatible with it in one manner or another, if it means all libraries that work on an arduino would also work in the platform.io's arduino framework for stm32. Nice find! If nothing else, it sounds as though one is no longer limited to just the bluepill for running the arduino framework on an stm32.

[ejlane]

@NeverDie Yeah, platform.io is more of a 'wrapper' around the same libraries used in any other place. And of course you can create and use your own. But it's not like they have a ton of code that's created in parallel or something. It's all the same code source. I like that platform.io is based on a more full-featured IDE and also that they hide much less that Arduino does. You can easily get down into the weeds and set the settings you want.

However the MySensors code base has no HAL for the stm32w series. I have no idea how much work it would take to add. The HAL for the stm32f1 series doesn't look like there's much going on: https://github.com/mysensors/MySensors/tree/development/hal/architecture/STM32F1

[mfalkvidd]

I don't have experience with stm32 myself, but https://github.com/mysensors/MySensors/pull/1422 might be interesting. The history is a bit complicated but from what I understand this PR might give broad stm32 support in MySensors.

[ejlane]

@mfalkvidd In looking at the files touched, it does look like that pull request is attempting to support all of STM32. I have no idea if it will work, but at least from the people that have replied to the conversation, it at least looks like it should work.

Though I'm a little concerned by a couple of the include orders. Here: https://github.com/mysensors/MySensors/pull/1422/files
In MySensors.h, at line 71 the STM32 arch is checked for first, but at line 450, the STM32F1 arch is checked first. This would only be a problem if they were both #defined, but I could see that being possible, though unlikely to be common. I think the more specific F1 one should be checked first both places, and then only fall back to generic ST32 if that fails.

I also see that some of the hardware features are disabled, like the CPU temp, voltage, and the random number generation looks vastly simplified/maybe weakened? However, all of those things might have been necessary to keep from having to write individual code for each chip line. If so, that sounds like a decent trade-off for being able to work with so many more chips.

Also looks like the only transport support is for the RFM69, where once again the STM32 arch is checked before the STM32F1.

Overall, I would say that if this pull really supports a bunch of STM32 chips (and passes tests) then it's a good addition, but it looks like it needs work to really be complete.

[nagelc]

@mfalkvidd

I have a multi-transport gateway running on an STM32F411 black pill using the KooLru code with arduino. It pretty much just worked.
I don't know about sleep however. I've mostly used the blue pills and black pills for powered things like gateways.

There is also this: https://github.com/mysensors-rus/STM32_Mysensors_bootloader

and this: https://www.seeedstudio.com/LoRa-E5-Wireless-Module-p-4745.html?queryID=5241719889282ea5031374c599ebc867&objectID=4745&indexName=bazaar_retailer_products

Which makes me think a MCU/LoRA with potential for OTA updates is not far out of reach.

But it would take a better coder than me : )

[ejlane]

@nagelc Multi-transport gateway? So the single chip uses multiple transports? Which ones? I guess do you just have to define the pins to use yourself? (Since that's the only thing his code does for RFM69.) Or maybe I just really missed something...

As far as sleep, it doesn't look like any MySensors code supports it on the STM32. See here: https://github.com/mysensors/MySensors/blob/4afa7a644360c3abcb39d61df7c750c8f0ee19cb/hal/architecture/STM32F1/MyHwSTM32F1.cpp#L95

I've done projects using different STM32 chips in the past (the 'L' variants, usually) that were battery powered and we set up the sleep code. It wasn't too terribly tricky, but I do remember some issue on wake-up that took a bit of troubleshooting. Details are fuzzy, but could have been something to do with clock re-initialization, maybe? But this was with ST's STM32Cube software directly, not through an Arduino core, so I don't know if it's supported. We had to fiddle with registers directly sometimes. (Though the IDE was a lot of help, of course.)

I just went and looked for a core that supported sleep, and this isn't exactly it, but since it's a library, perhaps it would work with any core, with some modification? It does say that it's written for this core specifically. I'm not sure if that core works with MySensors. I'm using the Maple core with STM32. I had an issue with whatever the default was.

At any rate, not something that I have time to go play with right now, but maybe someday. For now, Atmega328 and NRF51 chips are what I'm using for my low-power nodes. I do plan to use some STM32F1 chips (from Blue pills) for plugged-in nodes that are also going to be relays outside, but I figured they might need the extra speed/power.

[nagelc]

@ejlane
Yeah. I did this a while ago and I will have to dig into my notes to figure it out. I don't recall how I combined the STM code with tekka's multiple transport (which i think was in the development branch already), but it was not much more than cut and paste. I have an NRF24 and an RFM69 running on one and an RFM95 on another. I can figure out the details when I get back home in May.