by Jan Kučera, last updated: 2/10/2009.
There is an updated version for .NET Micro Framework 3.0 available here. Only minimal changes - just to make it run on the new framework's version and 96dpi - were done. MemoryManager is no longer available (B) and state saving (C) is now automatic, the display (1) is landscape and supports touch. To upgrade from previous version, just replace the original files. Questions and requests welcomed. Thanks to Georgios for the update inducement.
Extensible emulators are one of the fundamentals parts of the .NET Micro Framework. In real world, every device manufacturer can very easily create an emulator for his device. Easily means either by XML configuration of the built-in Microsoft's emulator, or by making a Windows Forms application, which represents the device interface (as you can't add buttons using pure XML) and then connecting it with emulator components.
As for the Microsoft's built-in emulator, it has a 320×240 display and four pre-assigned buttons. This configuration is good enough for testing screen-saver-like applications, but you likely have higher aims. The worst thing on this emulator is, that it does not display any outputs, and it ends up with an error if your application uses any of the serial interfaces.
I've tried to address these issues using this, a little bit universal, emulator:
I was told that any atempt to create an device-independent emulator is a waste of time, so check it yourself, if it helps emulating your applications a little bit more than the built-in emulator - or even the emulator from device vendor - and let me know what do you think about it.
First, a little bit of propagation:
(1) The built-in display has 240×320 resolution. You can't rotate it by means of XML configuration (yet), neither you can change its physical dimensions now. However, any resolution you put into the XML will be stretched on the display surface, so that you can at least see the whole image.
(2) The list of currently used outputs and their actual state. The pin names can be dynamically read from any assembly specified in the XML.
(3) Outputs, in which you are interested during whole application lifetime, can be pinned. In this case, GPIO13 is checked in the Pinned items list, but has not been initialized yet by the application.
(4) Similarly all currently initialized inputs are available for control.
(5) And also outputs buttons can be pinned, as in this case of yet unitialized GPIO12.
(6) Significant amount of devices with UI will have buttons arranged in a similar way, and it's quite uncomfortable to control arrows using buttons in row, so I put few of them under the display in a fixed position. Pins which are they representing can be specified in XML.
(7) Input with glitch filter turned off is indicated by the exclamation mark.
(8) Pull-up and pull-down resistors are also indicated.
(9) As with GPIO ports, list of serial ports is available. By default, all of the ports available (i.e. defined in XML) are shown all the time. In addition, you can turn on automatic creation of new serial ports as requested by the application (COM ports only so far). In the case shown, an application for Meridian CPU is emulated, which uses some virtual ports.
(A) If you are developing an application which chats with several peripherals, but you don't have the peripherals available, or if you need to simulate a situation, which is not easy to set up on the peripherals, you can not only to monitor (and redirect) the communication, but also participate actively on both sides. For the present, only textual representation of the communication is available.
(B) Last, but not least, there is a FLASH memory usage indicator, showing different colors for different sectors usage. However, the current architecture of emulators does not allow to view the actual data stored in memory.
(C) You can save, load or erase the flash memory contents whenever you want. You can also set up an automatical memory save and restore to the disk in the XML configuration, so that your ExtendedWeakReferences are ready the next start.
In the configuration XML (AdvancedEmulator.exe.emulatorconfig) you can change the paths to the FLASH storage files and to the assembly, from which the pin names are being loaded. The default settings are storing the FLASH in the emulator folder and to not generate any pins, yet allow undefined ones. Examples to the Meridian and Microsofts enum are included as comments. Compiled - and not finished yet - emulator (debug configuration) can be downloaded here (ZIP, 332 kB). In order to use the emulator, you have to register it in Visual Studio. Extract the downloaded archive wherever you want and run the RegisterInStudio.exe (it registers the emulator to the framework version v2.0.3036; eventually you can register it yourself by writing to the registry as written in the RegisterInStudio.cs). The last step is to select Advanced Emulator in the your project properties.
I will give source code to anyone who asks by e-mail.
Warning:
Fixes (thanks to Michael Schwarz):