There is nothing that prevents you from combining a board like this with a microcontroller to handle the real-time IO needs. Or even a discrete logic chip might get you what you need.
C# has matured a lot. In UWP (Windows 10) it is compiled to binaries and isn't interpreted anymore (.Net native). Except graphics Windows is relatively fast on the RPi 2 (There is no graphics driver yet). I didn't use interrupt handlers but I did use I2C and SPI and they are really fast and use ISR afaik.
And second you don't want fast and tiny efficient code on a quad core cpu with 1GB ram. You want fast enough code and you want to write the code as fast, easy and clean as possible.
I'm wondering whether it handles interrupts OK? I did a project with a GHI board and C#a while back and it fell down on not being able to handle encoder input OK as the event / interrupt processing was at odds with .Net's garbage processing etc. It would be cool (at least for me) if it does actually work.
I2C is hardly demanding though, I wonder what you mean by "really fast"?
where the programmers and project managers treat non functional requirements (in paricular efficient use of resources) as an afterthought at best.
I2C is hardly demanding though, I wonder what you mean by "really fast"?Yeah doing I2C on something high-level is much different than trying to handle interrupts or bit-banging. That is a combination of actual hardware resources as well as kernel drivers. As long as the data is buffered, it should be really fast. That is also why USB works well. But as soon as you try to respond to individual IO pins quickly, all goes to hell.where the programmers and project managers treat non functional requirements (in paricular efficient use of resources) as an afterthought at best.
Yeah that is a common problem. In my field it isn't so much performance and use of resources but things like security, reliability and the ability to support the system that gets lost. It is a combination of both lack of knowledge and experience as well as giving in to pressures and expectations not rooted in reality.
I2C is hardly demanding though, I wonder what you mean by "really fast"?
As for not wanting fast and tiny efficient code, and being just "enough" I guess you'll be largely tied to a mains outlet for some time!
I spent a large part of my career troubleshooting and analysing performance on enterprise systems due to what I call diarrhea programming, where the programmers and project managers treat non functional requirements (in paricular efficient use of resources) as an afterthought at best. Lack of concern for those resources throughout the development cycle generally means you'll end up with a shitty system and you certainly won't get a Christmas kiss from your users.
I2C is hardly demanding though, I wonder what you mean by "really fast"?
As for not wanting fast and tiny efficient code, and being just "enough" I guess you'll be largely tied to a mains outlet for some time!
I spent a large part of my career troubleshooting and analysing performance on enterprise systems due to what I call diarrhea programming, where the programmers and project managers treat non functional requirements (in paricular efficient use of resources) as an afterthought at best. Lack of concern for those resources throughout the development cycle generally means you'll end up with a shitty system and you certainly won't get a Christmas kiss from your users.
So, you dealt with the downstream technical consequences of bad organizational design/implementation. Who was responsible for fixing the root cause?
Actually, given how many IT projects fail before they even get to production, ending up playing wack-a-mole on performance once the system is in production might be a lesser sin.
...And second you don't want fast and tiny efficient code on a quad core cpu with 1GB ram. You want fast enough code and you want to write the code as fast, easy and clean as possible.
Technically you could write the fastest code possible and it may end up being completely unmaintainable.
Someone who's written code that was "just good enough" to work probably wouldn't care much about how maintainable it was going to be either, or how it would scale at the edge, or how well that database query is going to work after a few weeks of data has been entered, at which point it'll probably need a rewrite: so much for "just good enough" and maintainability!