EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: alanambrose on December 23, 2015, 03:28:22 pm
-
Hi,
Anyone used the RPi / C# set-up described here:
http://blogs.technet.com/b/uktechnet/archive/2015/10/23/creating-a-simple-windows-10-iot-application-led-dice.aspx?CR_CC=200438481%3FWT.mc_id%3DCRM_DX_FY15_MAAlwaysON_EMAIL_9856153_6330_8148471 (http://blogs.technet.com/b/uktechnet/archive/2015/10/23/creating-a-simple-windows-10-iot-application-led-dice.aspx?CR_CC=200438481%3FWT.mc_id%3DCRM_DX_FY15_MAAlwaysON_EMAIL_9856153_6330_8148471)
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.
TIA, Alan
-
So while I haven't used the particular hardware you mention, these types of boards are designed more in line with how a PC works than a typical microcontroller. Interrupts are all handled inside the operating system kernel. This is both good and bad. There will be operating system overhead and you are dependent on drivers to provide you access to anything you need. Unless you are writing a kernel-mode driver, don't expect to be able to handle interrupts directly.
I have done a lot of work with the Intel Galileo which has a similar design (except running Linux). Many people in the forums ran into problems of trying to program in the microcontroller mindset on a computer running a program in user-mode on an OS.
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.
-
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.
Or, especially if your IO requirements have tight time specifications, an FPGA. A Zynq FPGA also contains a dual-core ARM, and you can run a Linux on one core and an RTOS (or bare metal) on the other.
-
I don't think you can compare an GHI board, which uses .net micro framework, intepreted code, compared to windows10 on raspberry, which surely uses proper .net, still it's bytecode based, but shoud be a lot faster.
-
Can't the mono package run C# ?
http://www.raspberry-sharp.org/ (http://www.raspberry-sharp.org/)
/Bingo
-
Why C#? That's one of the worst choices, next to Java and the other interpreted stuff, if you want fast and tiny efficient code.
-
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 would never infest my RasPi with a M$ OS :-- , not even for a test.
Next thing is a RasPi for $50 & All of a sudden a 100$ M$ OS for it.
With FORCED upgrade to Win 11
/Bingo
-
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.
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.
-
I compiled a text based program in c# for windows and it ran unmodified on the rpi. I accidentally launched it and was surprised it worked.
-
And the RPi was running?
Mono is distributed with Jessie, so if you don't use special things, it should run fine. I guess things that doesn't work is winform/wpf etc, and things that can be interresting is filehandling, depending on your code, but other than that, the purpose of Mono is beeing compatible with .net. (same bytecode etc)
-
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.
GHI offer RLP with their some of their boards which would have allowed you to do the code in C/C++ with more exact timing considerations. Did you ever try this?
With a fast enough processor I've found C# interrupts are fine. I have a control system running on a 1.7Ghz PC under Windows XP Embedded that handles around 1400 interrupts per second and all of the code is done in C# with only the kernel code to handle the interrupt being in C but passes this off to my C# code to do the processing. I do a lot of bit banging in the interrupt handler and we only see very slight jitter on the transmitter between channels.
-
>>> I compiled a text based program in c# for windows and it ran unmodified on the rpi. I accidentally launched it and was surprised it worked.
Yes I would think that it would unless it needs some services / drivers that are not common to both platforms. In this case I'm trying to figure out whether Agilent visa64.dll has any chance of working.
>>> GHI offer RLP
Yes I was vaguely aware of that. I'm guessing it is a bit more trouble that writing straight Atmel arm code though.
Thinking about this, I guess what I would like is:
+ something that I can access reasonably low level stuff with (i2C, SPI, ADC, encoders, digital io etc) in a fairly easy way and effective way. Atmel arm, for instance, does that but it's slow to write / debug / find your way around the library code.
+ a platform that I also can churn out quantities of fairly sophisticated c# code on and maybe port from win c#. I'm thinking reflection / maths etc.
Some time ago, I was hoping the GHI stuff would do that easily - no dice. Now I'm thinking maybe the Win10 / RPi layer? Maybe it's not really feasible.
Alan
-
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"?
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.
My opinion is that the very fact that facets like security and performance are termed "non-functional requirements" in itself means that they're the first things to get de-scoped in a developer's and some project managers' minds. For many developers, correctly applying security is on the too-hard pile, it gets in the way of doing 2+2. To be fair, it does need proper direction from the right people, but equally the security models in many enterprise systems are crazy in their complexity, and need to be fleshed out earlier rather than later. At least _most_ performance problems can often be fixed relatively easily, unlike security related issues that typically need to be a fundamental part of the design.
-
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.
-
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.
It still doesn't excuse lack of care over resources at the outset. Regrettably the increase in abstraction nowadays hardly helps. My point is that while your code might run "fine" in unit test, once it's in there with everything else if it steals all the memory/CPU because of lazy programming, as a system it'll be useless.
Playing wack-a-mole with performance and indeterminism was a lucrative part of my career, maybe I shouldn't complain! That doesn't stop me being frustrated at carelessness though. How many times have you experienced random slow downs, slow program loading, or being on the phone to a call centre while they say "the system's a bit slow today"? The symptoms are the same as they were twenty years ago, but we now have, say, 20 times the hardware resources. So we're now writing software and systems that are 20 times slower than it was then, I don't call that much progress :-(
-
...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.
Sounds like a Windoze programmer. There is nothing wrong with writing efficient code for ANY microcontroller. It is simply good practice, and the mark of a "good craftsman". Secondly, "fast enough" is sometimes a recipe for problems later on if you need to add additional functionality in the area of interest. I have seen some dreadful embedded code written by Windows programmers, with getters and setters all over the shop, and little thought about clock speeds, or readibility, creating one big mess that is barely functional.
Code should not be written as fast as possible, UNLESS it is planned up front. Slap-dash fast coding is often false economy, especially for larger projects. The software should be planned and documented before any code is cut, with planning about resources, clock speed etc. With good planning, the coding time is reduced and the chances of a rewrite is diminished.
I agree in that the code should be easy and clean as possible. That means smart and consistent naming convention, well structured file names, intelligent function calls and interrupt handling, and smart commenting. Most importantly, in any company there should be company coding standards published.
At the end of the day, inheriting someone else's well written code is a blessing. But inheriting crap code can be absolutely soul destroying. Better off in jail than having to refactor some idiot's software.
-
Technically you could write the fastest code possible and it may end up being completely unmaintainable.
-
Technically you could write the fastest code possible and it may end up being completely unmaintainable.
Indeed, and sometimes, very occasionally, it's necessary to drop into assembly for hot spots which for maintenance is becoming more and more difficult as fewer and fewer people have the skills nowadays.
This does not, to my mind, excuse unnecessary use of limited resources, particularly in (but not limited to) multitasking or multithreaded environments where it's not just your code that's running.
I'd say it actually works both ways. 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!
The key is getting to a sweet spot between reasonable resource use and maintainability.
As an example, a tight polling loop waiting for a button to press is a lot easier to understand and maintain than an interrupt driven one that wakes the board up. The former method will need to be tied to a mains outlet, whereas the second method will work off a button cell.
-
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!
Over the past 10 years it has become fashionable to have development practices that enshrine "just good enough" as standard practice. See XP and agile.
While there can be good solid motivations for XP/agile, I use the word "enshrine" deliberately. Youngsters catch the religion and apply it everywhere, even where it really shouldn't be applied.