The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I've been playing with Netduino for a couple of hours over the last month or so. As part of that I started a bit of a helper library to abstract some of the hardware for me, allowing me to write things like (to control a single RGB LED via three potentiometers):
int minValue = 0, maxValue = 100;var potRed = new Potentiometer(Pins.GPIO_PIN_A0, minValue, maxValue);var potGreen = new Potentiometer(Pins.GPIO_PIN_A1, minValue, maxValue);var potBlue = new Potentiometer(Pins.GPIO_PIN_A2, minValue, maxValue);var rgbLed = new RgbLed(Pins.GPIO_PIN_D9, Pins.GPIO_PIN_D6, Pins.GPIO_PIN_D5);rgbLed.SetColor(Colors.Fuchsia);while (true){ rgbLed.SetColor( potRed.CurrentValue, potGreen.CurrentValue, potBlue.CurrentValue );}
Am I reinventing the wheel here - is there already a library that does all this and more?
Or ( do I not yet 'get' why structuring your code like this would not be useful?
First, let me say, you're not the first one inventing this. There are some libraries available which have this kind of stuff.
But it's good you built it, since it's also a leaning experience. I hope you'll (re)discover a lot of stuff in the future and learn from it
Getting your OOP skills tuned is not bad at all, it might seem stupid to make a "driver" class for a RGB diode, but on the other hand seems very right to make one for a SPI controlled LCD display.
For example a simple button can turn out to be hard to do for many people.
Sharing your code is also a good thing, you will get feedback, and others will get idears or save time.
The "hard button" i'm talking about is debounced in software, and can be used in threads and with events, not something you will want to fiddle with when are concentrating on other stuff.
I'm a professional developer with 15+ years of coding experience, so I can do OOP in my sleep, but I am very new to the hardware side of things.
I'll do a little more cleanup of my library and publish it in the hopes of getting some feedback. I've done a couple of things which I think some people might find useful - or at least that I haven't come across in the code that I have seen so far!
@Stefan Do you have any examples of good code that has been published? I'd like to read through that to learn a bit more.
@Ulrik I agree it may seem silly to have a 'driver' for an RGB diode, but it is really about abstraction - if you want to understand a complex circuit it is better to read code that talks about turning an rgb diode blue rather than a PWM's duty cycle to an integer.
Like you I'm also a developer on the PC side, and getting my feet wet in NetMF. I would definitely advocate an OOP approach to programming on the Netduino.
But sometimes you have to cut corners and go "old school", making your code look more like C++, due to the devices smaller size and smaller feature set. I love having advanced features like generics, IOC Containers, lambdas, linq-to-entities, etc, but all of that adds to your memory footprint.
On the full version of .Net, I tend to have zillions of extremely simple classes with lots of inheritance, so I can put them together like a puzzle depending on the needs of the project. But each class adds a bit of overhead. So in NetMF my classes tend to be a bit fatter, and there are fewer of them. You have to balance that, of course, against modularity: you get the same benefit from breaking up tasks into different assemblies on NetMF as in full .NET.
@Ulrik I agree it may seem silly to have a 'driver' for an RGB diode, but it is really about abstraction - if you want to understand a complex circuit it is better to read code that talks about turning an rgb diode blue rather than a PWM's duty cycle to an integer.
I'm all aware of this, but in this resource constrained world and compared to programming something running on a modern PC, it's not always that simple, or should i say it actually is.
A very simple task could be to register input from a mechanical switch, and updating a display with a lap time, something you will find trivial on the PC, because most of the job is already done for you, you just don't know.
You will be amazed what input a simple press on a button can give you on an IO pin, and you will be amazed how hard it is to update a display while at the same time sampling data from that "simple" switch.
Now writing code that's readable and gives you the wanted level of abstraction is not so easy anymore.
This is not to dis encourage you at all, the process is fun, and gives most people a whole new perspective on programming.
But try working with the on board button and on board LED for a while, start by making a program that toggles the state of the LED for every press on the button, when you are done, try fading the LED in stead of just turning it on and off, whey you are done with that, do anything else at the same time...
You will be amazed what input a simple press on a button can give you on an IO pin, and you will be amazed how hard it is to update a display while at the same time sampling data from that "simple" switch.
With multi-threading this is trivial. That's why a chose a Netduino.
With multi-threading this is trivial. That's why a chose a Netduino.
Until you figure out that the NETMF is not multitasking, but doing "a simple form" of task switching every 20ms.
And like i told you, you will be amazed what a press on a simple button will give you on an input pin, you will probably also be amazed that 20 ms is like a lifetime for sensors, even simple ones like a mechanical button.
But do connect that switch to an input pin, and see how many interrupts you get while pressing it just once.
Until you figure out that the NETMF is not multitasking, but doing "a simple form" of task switching every 20ms.
And like i told you, you will be amazed what a press on a simple button will give you on an input pin,
You were telling KevinT, actually. And I was referring to multi-threading not multitasking. As far as I know, NetMF does not support multitasking of any kind.
If you're saying that Netduino's simplified form of multi-threading (as compared to the PC) somehow makes it more difficult to monitor multiple sensors/buttons than the complete lack of multi-threading on the default Ardiuno, then I'm sorry I just don't follow the logic on that one.
If you're saying that Netduino's simplified form of multi-threading (as compared to the PC) somehow makes it more difficult to monitor multiple sensors/buttons than the complete lack of multi-threading on the default Ardiuno, then I'm sorry I just don't follow the logic on that one.
I will rest my case then, but it seems that you have not tried to debounce a switch in a standalone thread, while doing something else in another.
But try fading a led up and down in one thread and use another thread to get input from a button to toggle the led on and off, now try the same without a thread, and while you brought the arduino into play, try the same on that platform, even though i mean they are not to be compared, they serve different purposes.
I will rest my case then, but it seems that you have not tried to debounce a switch in a standalone thread, while doing something else in another.
But try fading a led up and down in one thread and use another thread to get input from a button to toggle the led on and off, now try the same without a thread, and while you brought the arduino into play, try the same on that platform, even though i mean they are not to be compared, they serve different purposes.
So far, I've had to do debounce code in 80x86 & 6502 assembly, straight C/C++, and now on the Netduino.
So far, I've had to do debounce code in 80x86 & 6502 assembly, straight C/C++, and now on the Netduino.
Then you should be able to do the code in your sleep, and you can focus on explaining how exactly it it less difficult in two separate threads.
I'm to novice to get it, so i would really appreciate if you would mind the time to explain me, however just the code would be nice, in that case i can sit down and analyse and learn myself, because you have really made me think that i have totally missed something.
do I not yet 'get' why structuring your code like this would not be useful?
