MSPM0 vs STM32G0: Peripherals, SDK & Dev Tools Comparison - Page 1
Forum section: electronics / general

author: Louis-92
author_rank: Newbie
timestamp: May 22, 2025, 01:14:48 pm
content: Hi all,I'm evaluating microcontroller families for a line of industrial electronic products (motor drivers, sensor interfaces, etc.) and would like your feedback comparing TI's MSPM0 series and ST's STM32G0 series.I’m not concerned with price, power consumption, or raw core performance — both seem good enough for my use case.What I am interested in is a comparison of the following:Peripheral capabilities (clock, timers, ADCs, UART/SPI/I2C, PWM, etc.)→ Which family offers more flexibility or smarter peripheral design?Ease of peripheral configuration and use→ How intuitive are things like timer/PWM setup, DMA use, UART with DMA, etc.?SDK and development tools→ Which provides better productivity, less boilerplate, or better debugger experience?Documentation and learning curve→ Which vendor offers more beginner-friendly or industrial-grade docs and examples?Community and ecosystem maturity→ Third-party libraries, middleware, RTOS support, community help?Thanks in advance for any practical insights or gotchas from those who’ve worked with both!

author: peter-h
author_rank: Super Contributor
timestamp: May 22, 2025, 02:35:14 pm
content: Start herehttps://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/If this is some big company, ST will support it directly anyway. TI, I have no idea.

author: neil555
author_rank: Contributor
timestamp: May 22, 2025, 04:46:32 pm
content: I would recommend looking at embedded studio by Segger, it supports pretty much every Arm microcontroller and supports the jlink debugger.

author: __george__
author_rank: Contributor
timestamp: May 22, 2025, 07:30:15 pm
content: Quote from: neil555 on May 22, 2025, 04:46:32 pmI would politely propose for the opposite. At least from my experience the Segger Embedded Studio is pretty tough to use and I haven't seem many people using it but maybe on that side I might have a small sample. The trend that I see right now is for companies to adapt VScode basically (with custom addons of course).I don't have experience with the specific microcontrollers so I cannot talk about their peripherals capabilities. But here are some thoughts on the rest.At the debugging experience since they are both Cortex-M0 you should get very good support for both.One thing that you can consider is to use the Zephyr RTOS:QuoteZephyr is a full RTOS with it's own drivers for peripherals which use the companies MDK underneath. Both of the boards that you said here are supported but of course you need to check if the level of support matches your requirement. Zephyr has a bit of a steep learning curve because of devicetree, Kconfig and Cmake but it can help you to build portable applications which can work in many MCUs.If you are a small customer I will claim that you will get better technical support in Zephyr compared to contacting the company directly. On the other hard if you are a big company this might not be accurate anymore.

author: uer166
author_rank: Super Contributor
timestamp: May 22, 2025, 10:42:13 pm
content: Quote from: peter-h on May 22, 2025, 02:35:14 pm55 page thread that itself is useless crap with not a super amazing SNR.All vendor IDEs are bad, however you can always setup your own development environment using GCC + CMSIS headers if you wish. I personally use Cube + the generated code for personal projects without major issues: it saves time and $$. I don't know much about STM32G0, but have experience with G4, H5, H7, and U5. All are very decent regarding their peripherals (quirky but powerful).

author: uer166
author_rank: Super Contributor
timestamp: May 22, 2025, 10:43:30 pm
content: Quote from: Louis-92 on May 22, 2025, 01:14:48 pmFreeRTOS support is pretty good for STM32, it sees a lot of use and therefore there's a lot of content/questions/answers regarding its' usage on STM32.

author: nctnico
author_rank: Super Contributor
timestamp: May 22, 2025, 10:54:26 pm
content: I'd consider the LPC range of ARM microcontrollers from NXP as well. Very consistent pheripheral design, very good documentation. All in all very easy to get going with and due to the consistency across devices, you can hop between smaller and larger devices without needing to rewrite a whole bunch of stuff. The STM32 range is very low on my list to use for a project.

author: Louis-92
author_rank: Newbie
timestamp: May 23, 2025, 06:43:09 am
content: Thank you for your insights!You're absolutely right — for large companies, vendor support usually isn’t an issue, as they often receive direct assistance. But for smaller companies or hobbyists working with low volumes, the per-unit price isn’t the main concern — it's the design time that becomes critical.That’s why it’s so important to have good tools, clear documentation, and an efficient development ecosystem. Unfortunately, it’s hard to find a definitive answer about which platform is "best." As some of you have pointed out, it may ultimately come down to personal preference and the specific needs of the project — rather than a clear winner.Thanks again for the discussion — it’s really helpful to hear from people with hands-on experience.

author: peter-h
author_rank: Super Contributor
timestamp: May 24, 2025, 04:51:33 pm
content: QuoteIt is useless crap only if you post a question which sounds like you are doing a MSc thesis, and expect lots of people to write dissertations for youThere is some noise there but also a lot of good posts about development tools etc.

author: BadeBhaiya
author_rank: Regular Contributor
timestamp: May 24, 2025, 09:45:26 pm
content: I would suggest against any particular vendor IDE or debug tool. Using a Makefile (or at most, a CMake) should be good enough no matter what you have.Visual Studio Code is a great editor, very flexible, customisable, has a lot of extensions. The cortex debug extension is especially powerful, and can interface with a lot of different debuggers (OpenOCD, st-util, etc etc).A word of advice, unless your project requires an RTOS, do not use it. It adds no value. And if your project does require an RTOS, use something very simple and lightweight like FreeRTOS.As for the MCUs themselves, I only have experience with STM32 family. They are quite good, they do the job well, and peripherals are quite powerful with many options for whatever you need to do. Although you should be ready to read up a lot. The configuration register level design of peripherals is not the most intuitive, but thankfully the documentation is extensive, so you should be able to find more application notes, and reference manual pages than you can read.DMA design is intuitive, but its the more complex features (example, like chaining timer compare signal->ADC sampling) which can get a bit confusing. Application notes will help you.Their STM32CubeIDE is garbage, do not use it. Instead use their STM32CubeMX GUI code generator to generate a Makefile compile-able project with boilerplate code that sets up all the peripherals. This saves a lot of time during board bringup, its very worth it, I haven't seen another microcontroller vendor have a tool like this. It works well, I have not encountered any big issues with it.Bonus rantDo not use Zephyr RTOS. Its a massive pain to work with, the learning curve is extremely steep, driver library may appear impressive at a glance, but they are all very basic with many features missing. Devicetree is a pain to work with, compile errors make no sense. Half the time is spent fighting with configuration flags. Do not be misled by the claims of cross platform portability, it mostly never works out that way despite best intentions.If you are using multiple networking stacks for BLE or LWIP or whatever...you have less choices. Use Zephyr then.

author: uer166
author_rank: Super Contributor
timestamp: May 24, 2025, 10:00:04 pm
content: I would like to +1 what is said above about NOT using a RTOS in any form unless you actually REQUIRE it for good reasons. Literally anything else (superloop, nested NVIC ISR event driven, co-operative scheduler, in order of complexity), will cause less headache and weird once-in-a-blue-moon issues.The size of codebase is also so much smaller that you'll actually know what the hell is going on on all levels.

author: peter-h
author_rank: Super Contributor
timestamp: May 24, 2025, 10:31:32 pm
content: I find FreeRTOS really brilliant. It makes coding anything nontrivial dramatically easier.And I know the other ways - that's how we did stuff on the Z80 in 1980But even then I wrote a simple task switcher for the Z180/280, c. 1987.Cube IDE is a makefile generator with an editor and a debugger interfaceNot much more. It does work, too.