Yeah, there's two parts to it. The first is "Can you build your code, for the correct target with the right cross compiler. Is your linker script set up correc

Yeah, there's two parts to it. The first is "Can you build your code, for the correct target with the right cross compiler. Is your linker script set up correctly etc.". This isn't too bad once you've done it once, as long as your toolchain isn't proprietary and the target is sane. But the second part is painful every time which is "what code do I need to run at startup so that my hardware is correctly configured". This is before you even write a driver. This is so specific to the particular chip, and even what you're particularly doing with it that it always takes time to get right. I'll tell you that as a "pro" in this field, any time I can skip the second part I will do. STM32 chips for instance need a lot of clock config and selecting the right muxes because their chips are very flexible as to which peripherals can come out of which pins. They have a graphical tool called "STM Cube" where you can select your chip, configure the function for each pin and then it'll generate you a full project with startup code. We threw away the project and just used the startup code, regenerating it occasionally when we changed something. It saved so much time and suffering and is a big reason why I'll always choose an STM32 if I can.