I made a short post about this a couple of days ago, but want to revisit it. The STM32MP153 has lots of peripherals and I don’t understand how these can be fully exploited unless we either access the peripheral memory directly or utilize a rich set of abstractions that fully abstract each peripheral.
It would make sense I think to optionally allow managed code to access peripheral memory unsafely or expose a set of value type structs that map to the many peripheral registers.
It seems (to me) that an abstraction of the STM32 itself would be a sensible thing to have here.
Someone mentioned that there’s a variant of Linux running on the board that hosts the CLR, so it wil be the OS that regulates access to physical memory, and if the OS denies access to the peripheral region then there’s nothing .Net can do about that.
Thoughts…
I did some digging/hacking and found that the abstractions rely on a native API accessed through interop - “libgpiod”. The Microsoft GPIO classes use that library and that library is able to access the device memory.
The library is what does the “real” work and I see no reason why people developing managed code need to be restricted to that library, .Net doesn’t care what such code does.
In principle anyone could write a native library and write managed code that uses that, what I mean is, managed code is managed code and the provided MS IOT class libraries are just an option.
I wonder how the transition is handled that lets the native library access peripheral memory…