[unbalancedevh]

I have years of experience in asm programming with PIC processors, and my job is embedded software development. I got an STM32 development board a couple years ago to get my feet wet in ARM embedded development. I got completely bogged-down in setting up the development environment. It took me forever to get a blinking LED, and I spent an ungodly amount of time unsuccessfully trying to figure out how to change the rate based on a potentiometer input.

It was a very frustrating experience, but articles like this make me want to dive in and try again!

[thebruce87m]

Do you mean in assembly? If you just mean C, then if you’re already in embedded then I’d say a few years ago it was easy. These days it’s super easy - tools like STM32CubeMX will allow you to get even custom hardware up and running in no time.

It will even spit out multiple project types - everything from ARM Keil/MDK/uVision to just a simple makefile.

[jbott]

I disagree that GUI tools like STM32CubeMX are useful. They end up being a crutch that end up adding increasingly complex wizard driven autogeneration, rather than just exposing the configuration in easy to consume ways. Sure, you can get something running fast, but it’s incredibly difficult to move from “blink a led via this template project” to “build a useful project integrating multiple peripherals”.

I think there’s some actually interesting work being done with standardization like SVD files, but too many vendors treat them like second class citizens compared to their bulky code gen solutions.

[thebruce87m]

I think it’s decent - configuring a clock tree and initialising the peripherals by hand might be a good way to learn the chip but in terms of rapid prototyping I’ll take the GUI driven leg up any day.