New GHI blog is up

There is an official GHI blog now so I will stop posting here and use the official GHI one instead. You can see the GHI blog here http://ghielectronics.blogspot.com/

Have fun and will see you at new blog!

Debug and deploy over serial

All GHI's NETMF devices use USB for deploying/debugging by default. Optionally, a developer may want to use the USB client (not the host) for something other than debugging. This is actually supported by NETMF and GHI adds much functionality making it very easy to setup.

Let me give you an example, you are making a device that that reads temperature and humidity...etc. and logs all this data on an SD card. This device can be configured, like to set the time or give file names...etc. You want the device to be configured over USB. So when your device plugs into a USB port, you want it to show as a virtual serial port. This way, anyone can open a terminal software (like TeraTerm) to connect to your device to configure it.

Sounds good so far, but what device to use? This is an extremely simple application and it will fit very well on our smallest device, that is USBizi. Since FEZ boards use USBizi chipset, then I will use them for my project. FEZ Domino or FEZ Mini will do just fine.

http://www.tinyclr.com/hardware/1/fez-domino/

http://www.tinyclr.com/hardware/2/fez-mini/

The first thing we need to do is change the debugging interface to serial instead of USB. Again, that is because we want to use USB as a virtual serial port to set the configuration our project. USBizi has a pin that is called MODE pin. If this pin is high or unconnected then USBizi (FEZ) will use USB fro deploying/debugging (and for boot loader) but if the pin is low (connected to ground) then USBizi will be using its COM1 for everything.

FEZ Domino has MODE jumper (by the LED) , close this jumper to use serial. FEZ Mini, has MODE pin available on the SD header. The pin is next to ground pin so you only need to short MODE to ground.

Ok, now we have USBizi(FEZ) ready and it is using serial. Now, we have all setup but we still need to connect USBizi(FEZ) to the PC's serial port. The PC serial port is RS232 but the serial connection on USBizi(FEZ) is TTL.

To use FEZ Domino serial COM1 with a PC, you can use the RS232 shield.

FEZ Mini already have RS232 circuit on-board. To connect its RS232 pins to a PC, you will need to make some cable or an easier option is by using the RS232 cable we offer+the starter kit. We also offer a USB<->serial cable. Through this USB<->serial cable, you can debug using a virtual USB-serial connection. Which means, USBizi (FEZ) will be debugging over serial but you actually have a USB connection to the PC!! This is similar to connecting FED Domino RS232 shield to a serial <->USB cable.

When the setup is complete, try to "ping" the device using MFDeploy. Note that this time you will not select USB but you will select Serial. You also need to select the appropriate COM port.

Can BASIC run through C#? This is crazy!

Do you remember BASIC on DOS? Maybe you are too young to know BASIC or DOS. Eitherway, you probably know what is BASIC because of the popular Visual Basic.

So GHI's .NET Micro Framework devices run C# code and can actually run Visual Basic as well. As of now Visual Basic support is not directly supported.
So, I was thinking...what if I can run a BASIC interpreter in C# to run BASIC programs? This will be interesting to see but in reality, this is absolutely pointless!
Think about it, you write program in BASIC then this get interpreted through C# which it turn is also interpreted through the CLR.

Even thought this is useless, I want to see if it can be done (was bored on the weekend!). So, I did some googleing and found a very simple interpreter written in C. I took that code and started converting it slowly to C#. I was able to get the commands PRINT and GOTO implemented along with support for labels. Adding the rest should be simple but I am stopping here since I have proven that my crazy idea can be done.

The project file includes my C# project and includes the original C files if you want to complete the port.

The project is available at http://www.microframeworkprojects.com/project/50

Using XBOX controller with .NET Micro Framework

If you are asking yourself, how do I use the XBOX 360 controller in my project? If you are using Arduino then this requires so much circuitry and programming to do...actually, I am not sure myself how this can be done. If you are using BS2 then just forget about the idea! To use XBOX controller you will need a windows CE device with few month to learn how to write USB drivers. Out of curiosity, I did search the web for drivers for XBOX, linux winCE, windows or MAC drivers. I did find few and I can tell you this, looking the the driver source code was scary. Try to google then and take a look yourself.

XBOX controller has many digital inputs but unfortunately it is not a standard HID device and so it will not work with the standard drivers. This example implements an XBOX controller driver using raw USB services.

Thank god GHI offers a raw USB services that is available on all GHI's NETMF devices, including USBizi(FEZ), EMX, ChipworkX...

The example driver is available at http://www.microframeworkprojects.com/project/49

This is a simple driver that is meant to be as a starting point to show you how you can access almost any USB device, even the ones that are not directly supported.

// create a driver instance
XBOXController XBOX = new XBOXController();

// read the analog hat switch
Debug.Print("LH " + XBOX.GetAnalogHat(XBOXController.AnalogHat.LeftHatX) + " " + XBOX.GetAnalogHat(XBOXController.AnalogHat.LeftHatY));

// read digital switch
if( XBOX.GetButton(XBOXController.Button.X)) Debug.Print("X");

Note that writing USB drivers on GHI's devices is very easy but still requires some knowledge of the internals of USB. If you are using standard devices liek mouse, keyboard, storage then these have built in drivers, so you do not need to know anything about USB.

.NET Micro Framework SDK 4.0 is in beta stage

The all new SDK for Embedded Master and USBizi is available for immediate download! ChipworkX come next and very soon.

With this SDK, all GHI NETMF products share the same SDK and same libraries, allowing seamless switching between all products, same code same project runs on any GHI NETMF device.

The forum includes some steps and details on how to install 4.0

Embedded Master: http://www.ghielectronics.com/forum/index.php/topic,2866.0.html

USBizi: http://www.ghielectronics.com/forum/index.php/topic,2865.0.html

This month will be exciting will all new updates...so stay tuned ;-)

Using TFT displays and standard VGA monitor with EMX or Embedded Master

GHI Electronics offers many hardware modules running .NET Micro Framework, like EMX and ChipworkX. They all support TFT displays with 16-bit 5:6:5 RGB color depth.

With this interface, users can use about any TFT display. Some applications, like handheld devices, may require a 320x240 3.4" display. Others, like vending machines, may need a 640x480 7" displays. What about airport informational center? Those will probably need a 12" 800x600 displays. What is important is that GHI NETMF modules can work with all these options. Through a simple call to the GHI managed libraries, a user can set the default settings for display, including resolution, HSYNC, VSYNC and clock.

What if an application require to work with external VGA monitors? While TFT displays are rather flexible when it comes to timing and clock rates, VGA monitors must have a very precise clock. Since the image beam is controlled directly by the VGA signals, a high clock rate is required. A 640x480 @60hz refresh needs about 25Mhz clock! Stepping up to 800x600 @60hz will need 40Mhz! Having 40Mhz clock at 2bytes per pixel will require 80MegaBytes/second.

In computers, generation the clock is handled by the graphics card. All the processor have to do is transfer the frame buffer (image) to the graphics card then the card will take care of generation the clocks. On small embedded system, generation such high clocks/bandwidth is not an option.

Fortunately, there are small chips that does what graphics card do. Chrontel at www.chrontel.com offers a chip called CH7025 that has an internal 2MB for frame buffer. An embedded system, like ChipworkX, can send its buffer at any clock rate to CH7025 and then the chip will take care of generating the appropriate clocks. It even take care of converting the 16bit digital signals to the VGA analog colors Red, Green and Blue.

Here is the datasheet http://www.chrontel.com/pdf/7025_7026ad.pdf

The good news is that EMX and Embedded Master can generate VGA timings with some limitation. They support 640x480 resolution with actual 480x480 pixels. This means that the monitor will see a 640x480 clock timings but you will have actually 480x480 pixels to draw on. With this configuration, EMX and Embedded Master can generate the VGA signals without the need for any extra components. (Remember that you can use any resolution you like if you add a frame generator circuit.) Keep in mind that this requires these devices to transfer about 50MBytes/sec in which will slow down the system. This option is ideal for vending machines and informational centers.

OK, we are all set as far as timings. Now, we need to convert the 16-bit digital to analog signal. If perfect colors are not important in your device then this can be accomplished using simple resistor circuit. Here is an example schematics

http://www.ghielectronics.com/downloads/EmbeddedMaster/EM-VGAEXP_sch.pdf

With this simple circuit, you will still have perfect image quality but the colors will be slightly off. If you are displaying text or solid colors then images will look perfect. But, if you are displaying full color photographs, then images will look okay but not perfect. To prefect colors, we need to use a DAC chip.

Here is a video of a customer talking about generating VGA signals.

This is a fun time-laps video of the same customer assembling a circuit that host Embedded Master. Time-laps starts about in the middle of the video.

Where is NETMF 4.0? What is new?

The new release of .NET Micro Framework 4.0 is very compatible with 3.0 so updating the firmware is somewhat an easy task. GHI Electronics took this opportunity to rewrite and optimize the whole driver set for USBizi, EMX (Embedded Master) and ChipworkX.

What does that mean to you?

• All managed libraries are now uniform among all products. If you have code for EMX then it will simply work on ChipworkX with no changes.
  http://ghielectronics.com/downloads/NETMF/Library%20Documentation/Index.html
• Optimizing allowed us to *double* the free memory on USBizi chipset, was about 20K and now about 40K. This means NETMF C# projects can run smoother and users have higher flexibility.
• USB Host now supports unlimited USB devices! This new support works on all our devices even USBizi. You can now connect hubs/devices anyway you like and they will all work simultaneously.
• All GHI NETMF SDKs are now combined into one download. This make sense since all are now sharing the same managed libraries.
• The same EMX firmware will also run on Embedded Master. Loading 3.0 on EMX will not work and will damage EMX but the new 4.0 firmware works fine on Embedded Master and EMX.

Keep in mind that if you are using one of our modules/chipsets then these updates come free to you! You only need to download the firmware from GHI website and load it on your device.

The schedule:

• USBizi 4.0 has been out for months where it was used on FEZ. If you didn't know FEZ actually has USBizi chip on it so FEZ=USBizi (see www.TinyCLR.com). We didn't announce the firmware for USBizi because we wanted to modify few things first. By the time you read this post, USBizi 4.0 release should be online. We are done but still doing some extensive testing
• The new EMX is online (and in stock!) but can't be ordered till March 1, 2010. By then, the 4.0 firmware for EMX and Embedded Master will be online.
• ChipworkX comes last to join in the 4.0
• In short, a production release firmware will be available for all our NETMF products by end of March 2010 but beta will be available in beginning of March.

We very much value your feedback so please let us know what you like/dislike and help us out in testing the all new 4.0 firmware.