I’m just curious at this stage in my studies, but how - in general - are MCU interrupts exposed to managed code on Endpoint? I imagine we must have a native handler or interface, that can forward calls to managed events or something, but if there’s anything to explore here please share!
I expect the existing IoT libraries and stuff handle this opaquely but if one was interacting directly with hardware, hos is this exposed to managed code?
But when using a managed high-level language, are you really interacting directly with hardware? This is a bad thing as the code becomes hardware dependant.
.Net MF->Gadgeteer->TinyClr->Endpoint…
Maybe Endpoint will live up to it’s name… 
And nothing else matters 
Peter Pan!
Well there’s always device dependent code. I’ve also been underwhelmed by Linux for years and the less I see of the better!
As long as we’re talking about app code, I have to disagree there. See also : Zephyr RTOS and Device Trees in general.
In Zephyr, as in Linux, device definitions, bus mappings, pinmux de-confliction, bus addressing, device enumeration, etc. are all determined by the declarative statements in .dts and .dtsi (device tree and device-tree-include files). Board support packages are defined in dts file hierarchies starting with a SOC .dts and working down toward a particular board configuration (like a dev kit or production board).
Using this, I’ve been able to keep all of the device-dependent code out of the app source. For instance, my app can say “blink the green_led” without knowing how that LED is attached, where it is attached, or how that relates to other bus commitments, or even whether any led is attached. This has hugely improved the flow from fly-wired dev kits to production boards.
This is also how I think app development should feel (and currently does feel) on Endpoint. When you are in Endpoint code, you should be thinking about app flow and user experience and not fiddly hardware details.
Everybody gets an opinion to call their very own, but mine is that drivers and hardware config belong close to the metal and in the fastest available code layer, and separate from app logic; and application code should be hw-portable and relatively immune to changes at the hardware and driver levels.
I don’t think I disagree at all with anything you say here. I certainly do not advocate that application level code should be bothering with registers and all the other stuff.
Being able to write some of this though in C# rather than C or assembler, is what interests me and with the Linux OS overseeing this we are limited in how that OS has abstracted all this.
Consider GPIO, perhaps the simples of IO we can do with an MCU. The peformance of the GpioController approach is poor compared to what can be achieved with C#.
I just don’t feel like the way many peripherals are abstracted is a good as it could be, it just seems a bit rushed a bit contrived overall.
I’d love to see detailed documentation on how the various MS IOT abstractions fit together and relate to the actual hardware, this vague abstraction issue has been around since .Net MF too.
So that’s really all I’m saying, it comes across a a bit rushed, bolt ons etc.
On Endpoint today I simply cannot really do much with DMA (it seems anyway) this is locked away and I have no control over the implementation. I think that the idea of a device driver model for MCU’s is a very good one of course, but it comes across as if the devices are to be too abstracted away, in ways that are not truly representative.
A peripheral (like a SPI peripheral) is not actually a device, devices might be attached to an SPI bus but there are really two abstractions, the SPI peripheral itself and the hardware we might interface to the MCU over SPI, this suggest that at a minimum we should have peripheral drivers and device drivers, the latter being written by leveraging the former.
Then Endpoint is not the environment for you.
GHI has a vision, which has been consistent over the years, to keep the complex guts of the system away from the user. If you need more, there are realtime systems which are better suited for your requirements.
I never suggested that a user should be exposed to “complex guts” nowhere have I suggested that Mike, you’ve misunderstood my posts I think.
I’m interested in Endpoint because I’m interested in C# running on STM32 boards, my opinions and personal interests are what they are and I’m simply discussing them that’s all.
Also, it seems the code is already hardware dependent because the class LibGpiodDriver is (or so it seems) specific to the Linux platform(s), it derives from UnixDriver so right there we don’t have portability.