When your starting off with a new embedded system, particularly the Arduino and Netduino the usual thing to do is make the LED flash, when you see the light you know you've gone from source code on the PC to a running micro controller.

Naturally I did exactly that, but I wanted to take it a little further, so the PowerLED project was born.

The idea of the PowerLED project is a home automation unit, controlled over a wired ethernet connection, hopefully drawing power from a POE switch via the same ethernet cable and powering a number (3+) of high power (1+ Watt) LEDs.

Hardware:

So, a simple start, get an LED to light up.  Then extend that to power a serious LED.

I tried two variations for driving the LED.  The initial design was to use a power MOSFET switched from an IO line.  This didn't go as simply as I had hoped.  My choice of FET was dictated by what I had to hand and that was dictated by what Maplin had in stock many months ago when I thought of the project.

The FET I used was a IRF540A, that beast can switch something in the region of 28 Amps, whilst that would be useful for halogen lamp switching, it wasn't exactly what I needed for a LED drawing about 300mA.  The big problem with the device was that the 3v3 voltage drive from the micro controller was not enough to get the FET fully conducting, so I needed to drive a simple NPN transistor from the micro which then connected the gate of the FET to ground (it was held high with a 10k resistor).

After getting the FET solution working I decided to try another way, a ULN2803A octal driver, this is a chip that will switch up to 500mA per channel (and you can parallel up the channels), it was very simple to use, connect the ground pin to ground, the common pin to the drive voltage for the LED (not really needed but should the LED be replaced with a relay then this will prevent any reverse EMF from destroying the chip), then connect the input to one of the micro GPIO pins and the output to the ground of the LED.  Nice and simple.

For good measure I also paralleled up a low power LED on the gate output so I didn't have to use the high power LED.

I also wanted a way to measure the light levels in the room so the lights didn't need to be switched on if the room was already bright enough.  Fortunately I had to hand a TEMT6000 breakout board from Sparkfun to hand.  This gives out a voltage based on the light level.  To make this work that voltage just needs to be fed into one of the Analog In connections.

One Gotcha worth noting here is that on the Netduino the Analog Reference isn't connected, so you need to supply a reference voltage, otherwise all your analog reads will be 1023 (Analog max for a 10bit ADC). In this case the Aref pin is connected to the 3v3 connector, and the TEMT6000 is also powered from the 3v3.

So here are our first important lessons.

• Use prototype block board for initial prototyping, not an expensive (£5-10) prototype shield that doesn't take well to having lots of change happing on it.
• The Arm processor at the heart of the Micro Framework uses 3v3, not 5v like the Arduino. Now the chip is 5v tolerant, so you can stuff 5v down the GPIO line without killing it, however not all hardware works with 3v3 logic, in this case a simple FET, so that needs to be taken care of.
• To use the Analog ports a Aref needs to be supplied.

Software:

This project is going to be more than just a simple LED driver so I wanted to make a good start to the code.  A critical part of this project is going to be the ethernet connection and the Netduino doesn't currently support that (the Netduino Plus should do and that's in Beta) I wanted to use my Meridian/P board, however that doesn't have an analog input for the light sensor, so I also want to use the Netduino and in the future move the project to the Netduino Plus.

The project references both the Netduino and Meridian/P SDK's and I have introduced hardware provider and controller base classes that are subclassed for the specific board implementation.  At startup some logic is used to tell which board the code is running on and select the appropriate controller.  This controller is then used to control the hardware, by using Liskov substitution principle and only calling the methods and properties on the abstract base controller we can switch the hardware without having to change any code or recompile.

I've set up a public repository on GitHub where the code will live.  Don't worry if you don't do git you should be able to use GitHub to download a zip of the latest code from the website.

Github Repository:

http://github.com/BookSwapSteve/PowerLED

git://github.com/BookSwapSteve/PowerLED.git – Readonly access

The software is over complicated for a simple flashing LED example, but it's a good start for encapsulating away various aspects of the hardware.

The controller class defined some outputs which LEDs will be connected to, some inputs for a switch and the light sensor and some code to handle configuration so the light levels for dark and light can be defined.

The main program defines a timer which on each tick reads the current light level and if it's too dard switches on the LED.  Fairly simple at this stage.

If your are use to app development one thing to watch out for is to not allow the Main() method to exit.  If it does thats it, program finished.  So here the Thread.Sleep(Timeout.Infinite) is used to keep the app running whilst events are used from the controller and timer to fire off some work.

Here's a couple of video's showing the unit working.  I set the timer to a fast interval, then by pointing the light at the sensor it toggles the LED on each tick of the timer.  This demonstrates one of the great advantages of the LED light, it can be switched really quickly (actually you can switch LEDs at MHz but I'll save why that's interesting for another blog post, but not the type of light used here as it has a constant current driver built in and that doesn't handle the switching all that well). 

I wouldn't dare to try and switch a halogen lamp as quickly as I was doing with the LED, and had I use a relay for switching it would have been making a terrible noise.

This first video shows the LED being switched on as I block the light to the sensor and then switching off again as the light level is restored:

The second video shows the rapid switching of the LED as the light is reflected off my hand onto the sensor switching off the LED:

Things have moved on big time in the .Net Micro Framework world since I started this blog, significantly most recently with the introduction of the Netduino and the announcement last weekend from the Microsoft MSR team here in Cambridge (UK) of the Gadgeteer.

Development boards have been available for a long time for the Micro Framework but they have been in the £300 range, this was more than I was willing to spend hence the purchase of the Meridian/P and the Ethernet module, which still came to around £100, a fairly high level to pay to tinker.

Meridian/P with Ethernet module attached:

Sadly I found that I wasn't using the Meridian/P as I would have liked to as it wasn't really easy to hook up to (not difficult, but not easy like the Arduino) and so instead I tinkered with the Arduino, and kept wondering about one of the proper dev boards.

That's changed recently, in the post about a month ago I received two Netduino boards (after handing over $70 + postage to MakerShed!), the cool thing is that they are the same form factor as the Arduino so my prototyping shields fit, but now I get to code in C# using Visual Studio 2010 and Resharper and take advantage of the cool stuff already written in  the Micro Framework.

Netdunio board:

Netdunio board with a Prototype shield mounted:

If like me you want to develop some internet connected devices using the Netduino then hold on, the Netduino Plus is in beta, it features an on-board network adaptor, (I'm sure their will be some network shields that work with the Micro Framework for the standard Netduino kicking around soon). I'm still hoping to see some Power Over Ethernet (POE/802.3af PD) powered devices so I can connect up one cable to a remote sensor system and have power and networking delivered remotely.

On top of all this Microsoft have also released the Gadgeteer, theirs a few interesting blog posts about it and I managed to get my hands of the bits the other night when attending a NxtGenUG meeting in Cambridge, although that's as far as I got as they were only out for display and not functional.

So, if you like developing in C#, you want to tinker around with hardware, go checkout the Gadgeteer and the Netduino.

Also check out the Arduino, it's not C# or .Net based but it's still an awesome platform to hack hardware on.

The Arduino and an Ethernet Shield:

Arduino next to a Netduino, what a lovely couple they make!

You can see from the photo above how well matched the boards are for form factor and connectivity, the Arduino already has a massive community involvement behind it with many shields and projects, lets hope the Netduino follows as it should be able to make use of a lot of the shields already developed.

The .NET Micro Framework at Microsoft have been hard at work and released an update for the V4 framework which supports Visual Studio 2010. Read more about it on the .NET Micro Framework Team Blog

The actual version supporting VS2010 is V4.1 and can be downloaded from http://download.microsoft.com/download/0/9/5/0958CB08-E209-4DFD-A945-9DA0FE64B3A4/SDK.zip

You will need updated versions of the SDK from the manufacturers of the hardware.  Checkout Device Solutions Download page for the SDK and Firmware updates.

In summary, it doesn't work.

The problems I've seen are with the RC version of VS2010, hopefully some of these might be fixed in the RTM version, otherwise I guess a patch for .NET MF will be required.

The Setup:

• Install VS2010

• Install Device Solutions SDK for the Meridian/P

• Try to install .NET Micro Framework v4 – this fails as it requires Document Explorer 2008.

• Install VS2008

• Install .NET Micro Framework v4

 

Once you've got that lot installed you can happily build and debug Micro Framework projects in VS2008:

 

 

However whilst creating a new MF Console application in VS2010 appears to work initially you get a load of broken references and the framework is missing:

When you try and build the project MSBuild crashes.

The missing references and MSBuild crash are because of a missing target in the .csproj file. If you add in <Target Name=”SplitProjectReferencesByType” /> and reload the project then the references appear correctly:

 

However the framework is still missing and the project wont compile:

 

Unfortunately as yet I have no idea how to get a v4 Micro Framework project working in VS2010, so for now stick to VS2008 folks.

 

 

I'm a long term C# developer, from .net 1.0 to working day to day in .Net 3.5, so the thought of being able to write code for embedded devices in C# with the Dot Net Micro Framework is to good to be true.

However, it didn't take long before the Micro part of the Micro Framework took hold and the penny dropped that it really was micro and the CLR was different, so I thought I would share my initial findings as if you are coming into Micro Framework development like me with a history of WinForms and ASP.NET it can feel like a big leap back in time.

A quick look at the Add Reference Dialog Box tells the story.

A V3 Micro Framework Class library project Add Reference dialog box:

 

Compare that the C# 3.5 WinForms project Add Reference dialog box:

Somewhat of a difference! I have intentionally put the WinForms project at the NUnit references to highlight that they are not available for the micro framework whilst being in the GAC. Actually at present I have not found any unit testing framework for the micro framework, even the MS Test framework is missing from the references.

Another major loss is the lack of Generics. No <T> in Micro Framework projects. Apparently this would have made the underlying image to big, which is a real shame as generics adds a huge amount of value and cuts down on a lot of repeated code. And yes, this means no List<T> and it's back to ArrayList of object - ouch!

Many of the day to day tools that existing C# developers may be use to using also don't function with micro framework projects. Reg-Gate's popular Ants performance and Ants memory profilers don't work (as of V5.1) which is a huge shame as memory usage and performance are especially important for embedded systems. NUnit doesn't care much for the micro framework either, although I've only tried V2.4.8 which complained about Generics. I could go on – in short don't assume your favourite tool/component will work with the micro framework!

The good news is that it's not all bad news!

Reflector works a treat (is their nothing that program can't do!).

 

 

Resharper still does it's thing, I'd be lost with out it!

The .csproj is still a MSBuild file.

Many of the great C# 3.0 features work (e.g. Auto-Properties, var)

You can still write separate class library projects as with regular .net so component reuse is really easy and this should help the unit testing story (if only I could find a framework!).

It's still one of the best IDE's I've tried for embedded development and C# is a great language!.

I've started tinkering around with the .NET micro framework and wanted to share my experiences with it as well as other general .Net code whilst not littering my other blog with .Net specific as that blog is supposed to be more about my products. I had IImplement.Net laying around not doing anything so I decided to put it to good use.

About Me:

One of my interests is the hardware and software combination so I was really excited to see Microsoft release the .NET micro framework and that I can build a peripheral for the PC and write the code for it in C# using Visual Studio then push it down to a embedded device as well as writing the application running on the PC in C# as well.

 

My background is Chemistry and a particular interest is lab automation and instrumentation, I'm also into home automation as a result some of the postings will reflect this.

 

.Net Micro Framework Hardware:

It's mid 2009 and these times are hard, I don't have £300+ to spend on a development kit and I guess many of you don't either, so I wanted to start with something that was well priced, easy to upgrade, had good features and more over that would be usable in a standalone product.

 

Introducing the Meridian/P:

 

This is a tiny (2”x2”) prototype board (the Meridian is even smaller!) available from device solutions.net which looked perfect for what I wanted. It's a heavily cut down version of the Tahoe-II with connectors for the IO and TFT screen, a single user switch & led plus a mini-Usb B socket, 8MB SDRAM, 4MB flash and that's basically it, the rest is down to your electronics and programming skills to use the 27 GPIO pins with RS232, SPI, I2C and PWM functions.

 

The thing I also really liked about the Meridian/P is that it's something I could easily use in a final working product (perhaps not a commercial one) as it really has little extra on it and the price is good (with shipping and tax it cost me £82 for a single board), the Meridian CPU looks like it would be more than happy going into a commercial product and is even cheaper.

 

Typical current consumption for the device is 5mA/2.6mA for 5V/3V which also makes it ideal for small projects, even battery powered ones.

 

There are a number of other prototype systems available, one of the reasons it's taken me till V3 of the framework is finding a decent development kit at a price I was willing to pay, now there are a couple of basic solutions and some really good ones for a bit more, the options are becoming better all the time.

 

Here's some photo's of the Meridian/P and Schmart Board(tm)'s that I hope to build up some fun bits on.

 

 

Packaging for the Meridian/P

 

Meridian/P with 2 AA Batteries to give an idea of it's size.

 

A SchmartBoard(tm) physically (not electrically) connected.

 

SchmartBoards(tm) and Meridian/P.