Hello,
Was not sure whether to post here or Begginers section, so sorry in advance, I am well well behind most people on this forum on most things 
My current understanding:
The MCU manufacture takes a CPU core (or several) and bundles it together with useful peripherals. the peripheral's controls and own registers are "mapped to memory" by the manufacturer and recorded in the device datasheet, they can be controlled by register access made easier with C code register access libraries, routine tasks are implemented in Hal libraries for further abstraction. the registers appear all the same to the CPU which does not "Know" about the peripherals but these registers are not a physical extension of the memory that the peripherals also read, they are registers and states built into each peripheral, the CPU directly communicates with the peripherals over the Bus/Bridge (acting as a translation layer) obeying wait and confirmation commands (important for slow peripherals). their are placeholder error handling routines for these transactions and error flags that might get raised in the HAL libraries but generally they don’t do much or anything so for long term stability the application code should address error handling and recovery of the peripherals; the CPU core language is defined by the ISA by the CPU designer (A revelation to me that assembly is an umbrella term for all the different instruction sets (or languages) from 8051 to X86, and not a standard its self) and the CPU does not need to know about the peripherals, so the Compiler is mostly the concern of the CPU IP holder such as ARM and not the MCU manufacturer. Because the compiler, like the CPU, does not know about the peripherals and and the FLASH, RAM ect.. are also peripherals, the compiler needs a "linker file" so it knows where to put stuff; the language that the compiler understands is defined by the C programming language standard. So a very determined person who knows C could write the code and program an MCU without any of the IDEs or libraries, as long as they had the compiler and the device datasheet. It would just be slow inefficient
There is also the start up code that the IDE config GUIs help generate to create boot up routines and initialise clocks/ peripherals correctly depending on use case.
Is that an accurate picture of how these different bits fit together? This is obviously very zoomed out and there are a million and one rabbit holes within view but does it catch the lay of the land?
My angle if you are interested: I am machanical/mechatronics engineer so my formal knowledge of this stuff is thin on the ground but have tinkered a fair amount, plenty of projects using the arduino IDE. Finally making the move out of that sheltered garden for DPS reasons, namely to use TMS320F280034 after discovering one needs HRPWM for battery charging control loops, but that is not the topic of this post 
. Anyway I started trying to understand the full picture of whats going on after floundering on the extra complexity when opening TI's CCS, namely the file structure that was previously obscured. I personally find it hard to work on something when I don't know how the bigger pieces fit together and why things are as they are. So Being short on time and a slow reader I have not picked up a tome and started ploughing through, for better or worse I started searching online, and don't shoot me, chatting to GPT because a lot of this information is in an odd space that the average tinkerer does not come across it, or the information is for a specific MCU and the formally trained know it well enough they dont talk about it SO. I was hoping I could attempt to paint the bigger picture as I think I understand it and someone on here could tear it to shreads and tell me to go read a book. Or not, just leave me to my AI Hallucinations. Also a kind of interesting test for the state of AI
Thanks for anyone who takes the time to read this
Doug
