stm32f103-example VS libopencm3

If you want to do bare-metal programming, you may want to take a look at my stm32f103-example project. It's for a different microcontroller than the one you're using, obviously, but converting it to work with an F4 part should be fairly straightforward. (I use the same framework for all of my STM32 projects.)

Use the CMSIS definitions of registers. They will save you a lot of time. If you're unhappy with having to repeat the names of peripherals, consider using something like the FIELD macros I wrote here.

The VECTOR macro expands to a sequence of assembler directives which uses .org. It'll end up creating gaps as needed.

And with a helper macro, you can rewrite the first bit as:

Some of the vendor IDEs have the option to generate makefiles for a project. Depending on the processor, you could also opt out to a different system. A lot of the popular cortex-m stuff is supported by libopencm3.

You can also look at examples of HALs such as - libopencm3 (Though this is Cortex only) - RIOT OS (though this requires an RTOS)

Yeah by the looks of it I am going to have to expand my project do creating a portable driver interface as well. Abstracting hardware interfaces to create portable code is fairly common in embedded development. For example, libopencm3 does this and has great support for STM32 parts but very limited support for SAM parts.

TinyUSB or Libopencm3 are probably your best options (although check they support the SAME70).

that is fair. SPI isn't very portable across Arm cpu vendors because all peripherals are vendor specific, i.e. the registers will differ a lot and APIs reflect that. Finding common ground is hard unless using specifically designed portable libraries like https://github.com/libopencm3/libopencm3