Polish your crystal ball: best mcu/radio successor chips?
-
@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.
@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!
-
@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!
@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 = mapleAnd 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 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 = mapleAnd 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...)
@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:
https://www.youtube.com/watch?v=QMYhVqjBhKQAlternatively, 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 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:
https://www.youtube.com/watch?v=QMYhVqjBhKQAlternatively, 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.
@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
-
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.
-
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.
@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.
-
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.
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
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 : )
-
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
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 : )
@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 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.
@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.
