| Getting started with .NET Micro Framework on the Freescale i.MXS |
by Alden Linn (Apr. 10, 2007)
Foreword: In this technical whitepaper, Microsoft .NET Micro Framework team member Alden Linn offers some practical tips for getting started with .NET MF using the i.MXS Development Kit from Freescale. Among the issues addressed are some differences between the actual hardware and the .NET MF emulator.
According to Microsoft, the .NET Micro Framework (.NET MF) is a natural extension of its embedded software product line, bringing the efficiency and reliability of a managed code environment to very small devices with tight constraints on cost, memory, processing resources, and/or power consumption. Additionally, .NET MF's integration with Visual Studio will optimize software development efficiency, by providing PC emulation capabilities and on-device debugging within the Visual Studio IDE. User interface development is supported with Windows Presentation Foundation.
Getting Started with .NET Micro Framework on the Freescale i.MXS
by Alden Linn
The Freescale i.MXS applications processor is a low-cost ARM-based platform for deploying software solutions developed with the Microsoft .NET Micro Framework. To develop applications for i.MXS, you need the i.MXS Development Kit, which is available from Freescale. In particular, the i.MXS USB device driver included in the i.MXS Development Kit must be installed on your computer before you can deploy applications to your i.MXS device. The Development Kit also includes a wealth of other information, including schematics, sample code, and a hardware emulator.
The i.MXS Development Kit is available as a downloadable ZIP file from the Freescale Web site.
You may want to run the samples included with the .NET Micro Framework on the i.MXS hardware to see how they behave and to better understand how to run your own applications on the platform. To do this, you must make some minor changes to the samples.
There are two key differences between the i.MXS hardware and the .NET Micro Framework emulator: - The i.MXS buttons are mapped to different General Purpose Input/Output (GPIO) pins than the emulator’s buttons. Thus, the i.MXS buttons will not be recognized when the samples are run.
- The i.MXS buttons use a different resistor mode than the emulator’s do. This will cause the samples to throw an exception when you press an i.MXS button.
The following section of this article discusses the simple changes you need to make before you can run the Presentation sample solution on the i.MXS Development Kit hardware. For ease of development and testing, you can use conditional compilation so that your solution can be run either on the .NET Micro Framework emulator or on the i.MXS hardware. You can make similar changes to the other .NET Micro Framework samples and to your own code.
The last part of this article explains how to deploy solutions to the i.MXS device for testing. If you have previously deployed software to other platforms by means of USB, you are already familiar with the steps you’ll be using for your i.XMS deployments.
Changing the Code
Start by opening the Presentation sample solution, following these steps: - On the Start menu, point to All Programs.
- Point to Microsoft .NET Micro Framework, then click Samples.
- Double-click the Presentation folder.
- Double-click the Presentation solution icon.
With the Presentation solution open, you can now edit the GPIOButtInputProvider.cs file.
Button Mapping
The i.MXS hardware uses GPIO pins numbered in the 40s for its button interface, whereas the .NET Micro Framework emulator uses pins 0 through 4. An added wrinkle is that the .NET Micro Framework Cpu.Pin enumeration includes only pins 0 through 15, which means that there is no pin named Cpu.Pin.GPIO_Pin40 (pin 40 is the Select button on the i.MXS hardware). Thus, you must represent the i.MXS pin numbers as integers in your C++ code, using the (Cpu.Pin) type casting syntax. In code, then, you would represent the i.MXS Select button as (Cpu.Pin)40.
To address the issue of the mapping between buttons and GPIO pins, first define a symbol to be used for the conditional code section. At the beginning of the file, add the following two lines of code:
// comment out next line when running on the emulator #define RUN_ON_IMXS_HARDWARE |
Next, update the GPIO mapping for the buttons by editing the ButtonPinMap class. The following lines are the code that needs changing:
// associate the buttons to the pins as setup in the emulator/hardware m_buttonToPin[(Int32)Button.Select] = Cpu.Pin.GPIO_Pin3; m_buttonToPin[(Int32)Button.Up] = Cpu.Pin.GPIO_Pin2; m_buttonToPin[(Int32)Button.Down] = Cpu.Pin.GPIO_Pin4; m_buttonToPin[(Int32)Button.Left] = Cpu.Pin.GPIO_Pin0; m_buttonToPin[(Int32)Button.Right] = Cpu.Pin.GPIO_Pin1; |
Change this section of code to read as follows (the italic lines are the added code):
// associate the buttons to the pins as setup in the emulator/hardware
#if RUN_ON_IMXS_HARDWARE m_buttonToPin[(Int32)Button.Select] = (Cpu.Pin)40; m_buttonToPin[(Int32)Button.Up] = (Cpu.Pin)43; m_buttonToPin[(Int32)Button.Down] = (Cpu.Pin)42; m_buttonToPin[(Int32)Button.Left] = (Cpu.Pin)48; m_buttonToPin[(Int32)Button.Right] = (Cpu.Pin)44; #else m_buttonToPin[(Int32)Button.Select] = Cpu.Pin.GPIO_Pin3; m_buttonToPin[(Int32)Button.Up] = Cpu.Pin.GPIO_Pin2; m_buttonToPin[(Int32)Button.Down] = Cpu.Pin.GPIO_Pin4; m_buttonToPin[(Int32)Button.Left] = Cpu.Pin.GPIO_Pin0; m_buttonToPin[(Int32)Button.Right] = Cpu.Pin.GPIO_Pin1; #endif |
Resistor Mode
The sample code uses the PullDown resistor mode. However, the i.MXS reference platform requires the PullUp mode because the hardware does not have pull-down resistors. If you try to use the PullDown mode, an exception occurs when you press any of the i.MXS buttons.
Conveniently, the .NET Micro Framework emulator works correctly with either resistor mode, so you can just change the mode to PullUp. Conditional code is not needed in this case.
In the sample solution, locate the GpioButtonInputProvider constructor, and then change PullDown to PullUp, as shown in the following examples.
Before editing:
InterruptPort port = new InterruptPort(pin, true, Port.ResistorMode.PullDown, Port.InterruptMode.InterruptEdgeBoth); |
After editing:
InterruptPort port = new InterruptPort(pin, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeBoth); |
These are the only code changes required for the Presentation solution.
Deploying a Solution
Deploying a software solution to the i.MXS hardware is even simpler than making the code changes. First, click Configuration Manager on the Build menu. Then make sure that the check box under Deploy is selected in the Configuration Manager dialog box, as shown in the following illustration.
 Now edit the solution’s properties to run it on the i.MXS hardware, following these steps: - On the Build menu, click Presentation Properties.
- Click the Micro Framework tab.
- Under Deployment, select USB in the Transport box.
- In the Device box, select the connected i.MXS device, as shown in the following screen shot.
 If there are no i.MXS devices displayed in the Device box after you select USB in the Transport box, this usually means that the USB device driver is not installed on your computer. If you are sure that it is installed, check your USB connections.
Finally, click Deploy Solution on the Build menu to download your code to the i.MXS device.
Conclusion
Developing .NET Micro Framework solutions for the i.MXS platform is much like developing applications for other supported platforms. While some code changes are needed, they are few and minor. Using conditional compilation, you can make one version of the solution that works with both the i.MXS hardware and the .NET Micro Framework emulator. Why not download the i.MXS Development Kit today and try this for yourself?
Copyright (c) 2007 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the author's MSDN blog, here.
About the author: Alden Linn is an engineer on the .NET Micro Framework team at Microsoft and has been involved with the product for over 3 years.
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|