What low power MCU ecosystem to use? - Page 1
Forum section: electronics / projects

author: kuon
author_rank: Regular Contributor
timestamp: January 06, 2024, 02:45:00 pm
content: Hello.I realize this might be a very broad question, and that you'll be missing some details, but I am more looking for general experience and feeling about vendors that actual technical details.I am currently working with STM32 chips and they are working fine. But the software "ecosystem" is not great. Most of the work I do uses the reference manual directly and I write to registers manually. I tried the SDK but it's a behemoth and in the end I couldn't make it work the way I wanted. It also took ST two years to actually send me the latest SVD file for a chip.We work on linux and we want the most open solution, the ideal workflow would be to add a few .c/.h file in a folder, add out main.c call gcc and have an open source program to upload it. We do that with STM32 now except that all the HAL is written by me. We use openocd to flash/debug the chips.I know there is ST, TI, Microchip and surely others. Are they better/worse than ST regarding using their product without the usual windows based GUI and SDK?For the architecture we use ARM, but we don't care as long as our tooling works. The most important thing is low power consumption. Most of our firmwares wake up, talk on I2C and SPI for a few ms and go back to sleep for a few minutes.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 07, 2024, 12:30:35 pm
content: Every ARM is pretty much the same: some sort of bullshit SDK/whatever, which you have even more reason to ignore. I have had no issue surfing with different manufacturers: all tools are reusable, linker scripts only need address ranges updated, everything related to the ARM cores and interrupts work exactly the same, which is great. All you need to do is to write new wrappers for peripherals but even those tend to be quite similar. Some of the more complex ones (USB, Ethernet, CAN) are often out-sourced so there is non-zero chance the peripheral itself is exactly the same. Simple peripherals OTOH are quick to write again and again from scratch.

author: PartialDischarge
author_rank: Super Contributor
timestamp: January 07, 2024, 01:10:18 pm
content: You should try cypress psoc , the software works great, no more looking for registers in the manuals, unless you’re doing advanced stuff.You can configure the modules, pins, ports, etc , via windows panes

author: kuon
author_rank: Regular Contributor
timestamp: January 07, 2024, 02:13:15 pm
content: Quote from: Siwastaja on January 07, 2024, 12:30:35 pmWell that is close to my experience. But there are a few things that required way too much effort IMO. For example, I wanted to use the I2C slave wake on address on an SMT32 chip, and it took me 2 weeks to finally understand all the subtleties, which in the end is like 10 lines of code.I'll check cypress as I didn't think of them.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 07, 2024, 05:46:16 pm
content: Quote from: kuon on January 07, 2024, 02:13:15 pmYeah, stuff like this causes most trouble. And it's always device-specific code. But the same functionality might not even be available on some other microcontrollers, so you can't abstract it, either; it affects the whole design of your project.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 07, 2024, 10:15:33 pm
content: Quote from: kuon on January 07, 2024, 02:13:15 pmYeah. I have rarely seen much better anywhere though.Usually the less "painful" chips are the ones that are simpler. The more complex they are (well, their peripherals, since the cores are all the same if you're using ARM stuff), and usually the worse documented they are.I wouldn't focus on this issue though, as it's pervasive as I said.Just pick whatever fits your requirements and is actually available and try to set up your toolchain and design your source code to make it as easy as possible to port to another target. Ultimately all you need is base header files with register definitions, which all vendors do provide (often burried inside their SDKs, but still easy to find.) You can also create them from a SVD file if it's available.Don't try to write a complete support library for a given MCU (when you don't want to use the vendor ones) if you're only gonna use a couple peripherals. It's a waste of time.

author: kuon
author_rank: Regular Contributor
timestamp: January 07, 2024, 11:22:09 pm
content: Quote from: SiliconWizard on January 07, 2024, 10:15:33 pmYeah, that's what I do, it works, even if it feels sub optimal.But it's a bit sad. I mean, electronic components usually have great datasheet, documentation and support. Last time I asked ST about NFC reader, one engineer replicated my setup and wrote 10 pages of notes just for me on how to design the antenna for my particular device and how to tune it.But as soon as the MCU becomes a bit complex, I feel like I am navigating in the fog. The reference manual with the list of registers is usually good, but as soon as you enter the "software world", everything becomes blurry.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: January 08, 2024, 12:16:06 am
content: Quote from: kuon on January 07, 2024, 11:22:09 pmSome vendors have peripheral configuration tools, which can generate code blocks for init, and pin mapping etc, complete with comments.These are simpler and less opaque than code blobs, so are useful, tho I've not seen one yet that works both ways. (ie can take source code and 'reconfigure' by adding lines or changing values, then save)Some debuggers, have better registers views, that are smarter with a value lookup, so you can see what is enabled/disabled - ie they are data sheet aware.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 08, 2024, 12:28:55 am
content: Quote from: kuon on January 07, 2024, 11:22:09 pmThe "software world" is a bit sad in general anyway.As to technical documentation, it's hard stuff to write properly and engineers rarely are given enough time to do so unfortunately.If you're specifically looking for "low power" MCUs - which I'll be assuming are what vendors tend to call "ultra-low power" these days - that limits your choices obviously.You have the STM32L4/L5 series of course. Documentation is so-so.If you're really after a very good performance/power ratio, the OnSemi RSL10/15 are fantastic - pretty much unrivaled in this cateogory - and the tech support tends to be very good (but probably good only if you're a good customer...)One alternative I sometimes recommend at least looking at is the Ambiq MCUs. Extremely low power, relatively easy to use and well documented overall. Not overly expensive either. They have variants with or without RF.

author: PartialDischarge
author_rank: Super Contributor
timestamp: January 08, 2024, 07:26:49 am
content: This is why I use Psoc, don’t want to spend time on software when hardware is what matters to me. You can set up a i2c, spi or uart in 2 minutes with no previous experience.Even a pwm with dead times is easy to setup and documentation is good.The ability to have some extra glue analog modules is a plus for some projects, where having an internal comparator or opamp can save the day

author: kuon
author_rank: Regular Contributor
timestamp: January 11, 2024, 10:52:31 pm
content: I'm already using the STM32L serie, I guess I'll continue with it. It works, just frustrating sometimes.I will definitely look at Psoc.Thanks