Here is a small demo application running on a Digi Connect ME JumpStart kit, and an emulator of the kit:
I've started a new open source project for Digi Connect ME sample code, hosted on the TFS servers at CodePlex:
The Pure Robot - Digi Connect ME project demonstrates the basics of interaction with the Digi Connect ME module, as well as emulation of the JumpStart kit hardware.
Emulating Hardware
One of the main features of this project is the Digi Connect ME JumpStart kit emulator. This was an interesting exercise for me since Digi do not supply their own emulator along with the kit and I've never attempted to build an emulator before. I've created one in the solution, in a project named PureRobot.Emulators.Digi.ConnectME.JumpStart. The code is in a beta stage: it's ready to look at with the LightFun sample code being discussed; however the serial emulation UI is not complete so the other sample projects in the solution may not work as expected yet.
The emulation features of the Microsoft .NET Micro Framework (.NET MF) are very easy to work with. Essentially all you need is a few lines of .NET code, an XML configuration file and some kind of UI. You can then execute your .NET MF code against the emulator and (in theory) see the same results as you would on the actual hardware.
I've made a basic attempt at defining the hardware in the emulator XML configuration file:
This file outlines the Input / Output (IO) capability of the Digi Connect ME module, and the memory characteristics as defined in the documentation:
Processor: 55MHz NS7520 (Digi Part no. NS7520B-1-I55)
Memory: 2 MB of Flash, 8 MB of SDRAM
IO: 5 GPIO pins, TTL (CMOS 3.3V) serial
For the user interface I used an image of the JumpStart kit board and added some overlaid bitmaps for the LEDs in the on state.
The emulator framework provides a nice set of objects to listen out for GPIO state changes. The only complexity in the UI code is that IO events will occur on another thread, so you need to synchronize with the UI thread before modifying the Windows Forms components to represent changes. When I first tried this, I used the InvokeRequired/BeginInvoke pattern of Windows Forms controls, but found the performance sucked. Instead I went for a synchronized set of integer variables which are modified by the IO thread using .NET thread synchronisation objects, then read on a timer from the UI thread - this seems to give a more realistic emulation experience.
The code for the UI form is here:
Running the Demo Code
To run the sample code:
- Download the Visual Studio 2005 source and open the solution
- You might have to cancel a few dialogs that attempt to access the source control server, then choose to 'Permanently remove source control association bindings'
- Build the solution
- When you build the solution the emulator will be added to the registry
- Open the Project Properties of PureRobot.Digi.ConnectME.JumpStart.LightFun -> Micro Framework tab, and set the Transport to Emulator and the Device to 'PureRobot.Emulators.Digi.ConnectME.JumpStart'
- Set the PureRobot.Digi.ConnectME.JumpStart.LightFun to the startup project
- Run (hit F5)
- If everything has been successful you should see the lights flashing away on the emulator application as they do in the video above.
Please feel free to play with the code and if you have any bugs, problems or improvements please don't hesitate to contact me through comments to this post or through the CodePlex site.
Labels: Microsoft .NET Micro Framework
A common requirement for powering a microcontroller based circuit is to regulate voltage to a steady level, protecting the sensitive equipment from fluctuations in power.
One of the simplest devices that can be used to achieve this result is a voltage regulator, such as the Sipex SPX1117U shown to the right.
Using the SPX1117U (the 3.3 volt variant of the SPX1117 range), I have hooked up a small circuit on the breadboard to demonstrate the process. The circuit below consists of the following components:
- 9V Battery
- Gator clip wires
- Home made power jack - two strips from a ribbon cable crimped onto a two pin socket
- Assorted jumper wires - mainly borrowed from a spare bit of CAT5 cable
- An SPX1117U voltage regulator
- Three 100 ohm resistors (Brown, Black, Brown)
- A bright blue LED
- A dull three colour LED
- A DIP switch block used to control the colour of to the three colour LED
| You can see the voltage output from the 9 volt battery, 8.13 volts: | And the voltage being output from the SIPEX SPX1117U voltage regulator, a perfect 3.3 volts: | The blue LED has a voltage drop of 0.54 volts from 3.3 volts down to 2.76: |
| The orange state three colour LED has a voltage drop of 1.64 volts, from 3.3 volts down to 1.66: | The green state three colour LED has a voltage drop of 1.43 volts, from 3.3 volts down to 1.87: |
The resistors are required here to protect two components: the LEDs, which have a maximum current consumption of around 30 milliamps, and the voltage regulator itself which can operate with a maximum current draw of 800 milliamps. The brightness of the LEDs will be determined by several factors to do with the quality of the material it was constructed with, and the amount of current passing through it. In this circuit we have a 3.3 volt power supply to the LEDs. To calculate the current drawn by the circuit, the draw from each LED must be added together:
- Blue LED
- Forward voltage drop = 0.54 volts
- Resistor value = 100 ohms
- Supply voltage = 3.3 volts
- Current, according to ohms law, (3.3 - 0.54) / 100 = 0.0276 amps (or 27.6mA)
- Current, according to ohms law, (3.3 - 0.54) / 100 = 0.0276 amps (or 27.6mA)
- Orange LED
- Forward voltage drop = 1.64 volts
- Resistor value = 100 ohms
- Supply voltage = 3.3 volts
- Current, according to ohms law, (3.3 - 1.64) / 100 = 0.0166 amps (or 16.6mA)
- Current, according to ohms law, (3.3 - 1.64) / 100 = 0.0166 amps (or 16.6mA)
- Total circuit current draw (and draw on the voltage regulator) will be 44.2mA, well below the maximum of 800mA.
Improving the Stability
The circuit above is fine for LEDs, but if you want to power something which requires a steadier voltage you'll need some additional components. According to the SPX1117U documentation, an output capacitor with a minimum value of 2.2uF but recommended 100uF will make the output stable.
In order to increase the output voltage stability, I've added a 100uF aluminium capacitor to the circuit. It is placed across the 3.3 volt output power rail:
In simplified circuit diagram form, this is the above circuit, including the stabilizing capacitor:
The use of capacitors as filtering and decoupling agents is especially important when one power source will be used for both sensitive components like microcontrollers and for rough components like motors. In the circuit above the capacitor is purely used for stabilizing the power output from the voltage regulator, however a more robust design to protect a sensitive circuit could be implemented like this:
 |   |
Because of the different electrical characteristics and capacities that different materials allow for, a 100uF aluminium capacitor is used here as a filter and two 2.2uF tantalum capacitors for decoupling.
The circuit can be simplified into the diagram below:
This power supply circuitry can provide a stable platform for a simple robot, allowing the microcontroller to enjoy a steady voltage level whilst the other components of the robot introduce spikes and drains on the supply as they grind their way across the deserts of Mars or are picked up and hurled by a toddler.
Labels: Electronics
Since I began researching the Microsoft .Net Micro Framework (.NET MF) I've come across some very handy white papers and resources. Here's a reading list:
- Introducing the .NET Micro Framework (Word Doc)
A Microsoft 'Product Positioning and Technology' white paper written by Donald Thompson and Colin Miller. This white paper includes a nice discussion of the background of and business case for the .NET MF. It sells the idea that the lower development costs of using a managed environment and great tools like Visual Studio can offset the slightly higher per unit cost of using a 32-bit processor and licensing the .NET MF.
- Official .NET MF Site
- Porting the .NET Micro Framework (PDF or HTML)
A Microsoft technical white paper for device manufacturers about porting the .NET MF to their hardware platform. Includes interesting insights into the underlying framework.
- Embedded Development Kit for the Microsoft .NET Micro Framework Step by Step Guide (PDF)
A tutorial for the SJJ Embedded Micro Solutions EDK module, which includes a great introduction to the .NET MF.
- Introducing Devices Profile for Web Services (DPWS) (PDF)
Great introduction to DPWS, including an overview of the libraries, namespaces and important classes. Includes sample code for getting started with DPWS.
- .NET Micro Framework on miloush.net
A great site, full of straight forward information, sample code and discussion of the .NET MF. Particularly useful is the list of available modules including approximate prices and the product comparison page, which appear to be kept up to date as new modules are released.
- The .NET MF News Group (newsreader, HTML, ATOM or RSS)
The official newsgroup for .NET MF questions. The forum is very active, with knowledgeable people contributing to help with practical problems.
- The .NET MF Team Blog (HTML, ATOM or RSS)
From the horses mouth, news and announcements on the .NET MF.
Labels: Microsoft .NET Micro Framework
The Microsoft .NET Micro Framework (.NET MF) is licensed differently according to the volume you will be selling. There are three basic scenarios:
Pre-licensed Modules
Several original equipment manufacturers (OEMs) have ported the .NET MF to a 'module' which can be bought prepackaged with a number of connectivity and peripheral options. When you buy a module from an OEM, the license fee has already been paid to Microsoft, and there are no licensing fees for you to consider. Just buy the module, include it in your design and you're done.
An example of a pre-licensed module is the Digi Connect ME (DC-ME-01T-MF), which can be bought for approx. USD $50, and includes the .NET MF license. For a full list of available pre-licensed modules, see the comparison chart on miloush.net.
Discrete Custom Designs for Existing Ports
If you are building a device for mass distribution, a prepackaged module from an OEM may not exactly meet your connectivity, peripheral or pricing requirements. In this case you can use one of the processors that an OEM has already ported to the .NET MF in your design. If you choose this approach, you first contact Microsoft at netmfbiz@microsoft.com and send them information about your company, project, and potential volume. They will put you in contact with processor manufacturers from whom you can buy a CPU at volume, and then Microsoft will agree a per-unit license fee for the .NET MF in your particular case. For example, in a high-volume device project you may create a discrete design around an ARM processor supported in the porting kit or using a public board support package (BSP). You could buy processors from Arrow, Digi-Key or some other distributor, and since those processors could be used with any platform, they won't have the license built in.
New Platform Port
If you have a processor architecture which the .NET MF has not yet been ported to and you want to use the .NET MF on this platform, you can sign a 'porting agreement' with Microsoft. The porting process involves working closely with Microsoft developers to incorporate your platform into the .NET MF. Processor and microcontroller manufacturers such as ARM and NXP have been through this process, sometimes directly and sometimes through specialists in porting new architectures to the .NET MF such as Adeneo. OEMs such as Digi use these processors and microcontrollers as part of the design of their prepackaged modules. To create such an agreement contact Microsoft at netmfbiz@microsoft.com. A Microsoft technical white paper for device manufacturers about porting the .NET MF to a new hardware platform can be found here: PDF or HTML.
Labels: Microsoft .NET Micro Framework
Let's start out with what the Microsoft .NET Micro Framework (.NET MF) is. In a nutshell, it's the future of embedded development. Programming microcontrollers for embedded devices has suffered through a litany of poor man's compilers, custom languages, non-standard development environments and until the arrival of the .NET MF was the province of the specialist low-level programmer. The .NET MF brings the finest development environment on Earth, Visual Studio, and managed C# to the embedded world. No other integrated development environment (IDE) even comes close to Visual Studio, and the debugging experience using C# and .NET MF directly on the device leaves other embedded IDEs for dead and buried. Using the increasingly standard ARM CPU as a platform, the .NET MF enables low-powered, high performance computing in micro sized packages.
The .NET MF is a complete re-write of the .Net common language runtime (CLR), and does not run on a host operating system. It is a 'bootable runtime', meaning that the CLR runs directly on the processor and includes a memory manager. This is a major departure for Microsoft from the existing .Net implementations in the embedded space, such as XPe and Windows CE running the .Net Compact Framework, and removes the massively bloated environment that those systems required - think 12MB->300KB, not to mention the reduced power consumption during operation.
The .NET MF includes these components:
- Drivers for standard peripherals such as
- XML and Web Services support
- Parallelism with threaded applications
- Simple persistent storage architecture
- XML based user interface GUI framework for working with LCD screens and touch screens
Best of all, the platform is free with a licensed copy of Visual Studio and there are no runtime licensing fees: these are covered for you by most manufacturers of .NET MF modules.
Labels: Microsoft .NET Micro Framework
Ethics is defined in Miriam Webster's dictionary as:
"the discipline dealing with what is good and bad and with moral duty and obligation"
Robots all over the world are engaged in activities from killing people with live ammunition on the Korean border to playing with children in kindergarten. Are these activities good or bad?
In 2005 the US military engaged in a $161 billion dollar robotics project that will develop combat robots, from their website:
"Protecting our soldiers now and in the future is nothing less than a national moral imperative."
An interesting ethical standpoint. It is certainly moral to protect 'our' soldiers; but not, it seems, moral to protect anyone elses.
Clearly Asimov's three laws are firmly entrenched in the world of fiction. Perhaps robotics technology will only be limited by an ethos when its darker side is brought to public focus. How will you feel when the first robot army takes out a human one?
I believe that robots should take us beyond the boundaries of what we can do; rather than replace us. People are great at killing one another; we don't need any robotic assistance for that, so why not use robotics for extending our capabilities. There are robots right now exploring the deep sea floor where humans could not go, from figuring out what causes Tsunamis to seeking out the next great undersea oilfield. There are robots in space exploring other planets where people would freeze or boil in a heartbeat.
Military robotics is the biggest part of the industry, but I would much rather pursue the areas of robot development that:
a) don't harm people
and b) do things that people can't
Call it an ethos; a set of ethics. There are medical ethics, political ethics and social ethics; so why not a set of ethics for robotics?
Labels: Robotics
If you're looking for an introduction to the Microsoft .Net Micro Framework (netmf), the first three chapters of Rob Miles and Donald Thompson's book 'Embedded Programming with the Microsoft .Net Micro Framework' have been made available on the book's website.
The first chapter runs through the origins, features and benefits of the netmf. It has a nice breakdown of the architecture stack, including the CLR and hardware abstraction layers. It is 15 pages long, and gives a nice concise overview of the netmf platform.
Rob Miles is an MVP in Microsoft embedded development. He has a small space in his site for the netmf, including an interesting but slightly out of date FAQ and a forum in which you can ask netmf questions.
Donald Thompson is an architect for Microsoft Research, and was responsible for overseeing the design and management of the software, protocols, and technology strategy for SPOT which was launched back in 2002. As such he was well qualified to write this book about the netmf, which developed out of the SPOT project.
Labels: Microsoft .NET Micro Framework
Subscribe to Posts [Atom]