STM32F4-HD44780 | An interrupt driven library for HD44780-based LCD displays

So a very broad question. first and formost what exactly was your avr experience, clearly if you started at main.c then someone else built your sandbox/tool environment for you including the bootstrap. The avr is more harvard-ish than arm so actually it is more of a PITA to truly build for without someone doing the work for you.

There is no reason why the experience cannot be exactly the same. You can take an avr document read about the registers for some peripheral poke at the registers for that peripheral in your program and make it work. You can take the st document, read about the registers fro some peripheral, poke at the registers for that peripheral in your program and make it work.

You can take some library like arduino for your avr, read about the api calls, write a program that makes some calls, program the device. Can take some library for your st chip and do the same thing, api calls wont be the same. arduino libraries are not the same api calls as other avr libraries made by atmel or some other party. You could jump on mbed.org and start writing api calls for your or some st chips and poof a working binary.

All mcu chip vendors need to provide libraries as not everyone is willing or (so they think) able to bare metal their way through (not that the libraries are not bare metal but are just api calls so system like). they wouldnt survive in this day and age. Likewise you have to have newer better with some new name so the libraries change. ARM is wonderful but at the same time a royal PITA. Because they make cores not chips, and their cores are surrounded by different stuff. there are a ton of cortex-m4 solutions that use the same cortex-m4 core, but you cant write one cortex-m4 program that works on all of them as the chip vendor specific stuff is all different (sure a massive if-then-else program would work if you could get it to fit). ARM is trying to make a magic layer that looks the same ish and the vendors are being dragged along so this CMSIS and MBED are ARM driven notions to solve this problem. AVR doesnt have this problem, the core and the chip vendor are one in the same. Now there are a number of different AVR cores and even if you had the same peripheral you might not be able to write one binary that works across all of them and or there might be binaries for one (xmega) that dont work on another (tiny) because of differences in the avr core implementation even if the peripherals were the same. the avr problem is much smaller than the arm problem though, but all contained within one company. so the peripherals if they vary are not going to vary nearly as much as atmel vs nxp vs st vs ti vs others using the same arm cores (or at least same named, there are items in the arm source that are easy to modify, with or without floating point with 16 bit fetches or 32 bit fetches, etc, documented in the trm for that core, creating more pain).

within a company like ST across just the cortex-ms they have created different peripherals a number of timers, gpio, uart, pll/clock, etc. If you take the bare metal, talk to the registers no other libraries approach, you will see that the transition from the cortex-m3 to the cortex-m0 they started using a different gpio peripheral, but maybe some of the others were the same. Fast forward to today we have cortex-m3, cortex-m0, cortex-m0+, cortex-m4 and cortex-m7 based devices just from ST, and there are peripherals that mix and match one product line may have a timer similar to an early cortex-m3 product but the gpio that is more like the first cortex-m0 product. And they seem to mix and match each new family they create from a pool of peripherals. So I might have code for a specific chip that works great on some other specific chip, same family or maybe even a little different. But move that to another st stm32 family and maybe the uart code works but the gpio doesnt, take that first program and move it to yet another family and maybe the gpio works and the uart doesnt. Once you have a library of your own for each of the different peripherals you can mix and match that and their libraries attempt to do that, and use a common-ish ideally call such that the code ports a little better but you have to build for the different chip to get the different stuff linked in. Not perfect.

Also look at how old say the very popular thanks to arduino and perhaps avr-freaks before that atmega328p that thing is relatively ancient. In the time since that came out all the stm32s were created, and for various reasons size/speed/internal politics/etc different peripheral choices were created. All the above mentioned cortex-m variations were created with different target use cases within the mcu world in the time that the atmega328p didnt change.

So if you take one avr document and one avr, and have a somewhat working toolchain, you can write programs straight from the avr docs. If you take one stm32 document for one stm32 chip, take just about any of the gcc cross compilers for arm (arm-none-eabi, arm-linux-gnueabi, etc), do your own boostrap and linker script which are pretty trivial for the cortex-m, you can write programs straight from the stm32 docs and the arm docs, no problems both are somewhat well written. repeat for a different stm32 chip, repeat for a cortex-m based nxp chip, repeat for a cortex-m based ti chip.

As a programmer though you want to write one program for two chips you need to look at the two chips and see what is common and different and design your program to either avoid the differences or if-then-else or use a link time if-then-else solution.

I find the libraries from the chip vendors harder to use than just reading the docs and programming registers. YMMV. I recommend you continue to attempt to use their old and their new libraries and try going directly to the registers and find what fits you best. the arms will run circles around the avrs at similar prices, power, etc. so there is value in attempting to use these other parts. avr, msp430, etc have become also-rans to cortex-m based products so professionally you should dig into one or more.

so for example a simple led blinker for the stm32f411 with an led on pa5

flash.s