How does NETMF fit together?


I have been reading for a few days now about NETMF - but a lot of the talk has been about buying already made development boards with… BSP? Or ‘the ported driver SDK’?

So, how does this all work? Is there a nice block diagram of the required ‘parts’ to the process?

The bits I am stuck on;

  • Assuming I use a board that has a supported processor/RAM - how would I go about using a particular LCD display (the ILI9328) for instance? I already have a C++ driver for it (initialisation, write/read commands) - so how to port this to something the NETMF could use?
  • Are there any simple boards that have just a processor and breakout pins?
  • How would/How does external RAM work? Say I had a processor that had 1MB flash/128kB SRAM - how would I add 8MB SRAM for use in double buffering the LCD display?

Basically I want to get a new Atmel ARM processor, soldered on a board with pin headers for prototyping. Add extra RAM. And use my existing ILI9328 TFT/Touchscreen.


GHI offers generally 3 categories of boards:

  1. Gadgeteer:
    These are Plug&Play boards where you simply can connect some existing modules for USB, Ethernet, SD, …
    Spider or Hydra are 2 of these

  2. SOM:
    This is the other extreme, Small modules with processor, RAM and GPIO’s
    EMX or G120 are SOM’s

  3. The middle way:
    The Cobra (II) board for example is in the middle of both. It has onboard USB, SD, Network, but olse offers plain GPIO’s without connector.

In fact the higher level boards also use the same SOM’s like G120 or EMX.

Drivers are in the NETMF-Kernel (SPI for example) or in the GHI OSHW or Premium library.
GHI boards also support RLP, so you can code performant drivers in C as well.

You application is developed in C#

Hope this helps a bit.

I would recommend taking a look at porting netmf ebook we have under support. a quick look in there will explain how it all fits.

From there you have the

  1. “on your own route” (start from zero)
  2. OSHW route (start with working product. Take it and do whatever you wish it it)
  3. Premium route (the typical route for commercial users) See this

The G120HDR is attractive. I see it uses it’s own LCD Controller (R, G, B, T Plugs).

Can you use your own LCD with a controller already built in? Mine has the ILI9328 controller. What would be the process of making this display native? Or even useable at all?


You can either write your own Bitmap.Flush equivalent driver in RLP and use that with the G120HDR, or you will have to build the firmware with native support for your LCD. To do that you either need to port the whole NETMF to the chip of your choice, or you need to look at the Hydra, for which the source code is available, and build your driver into that. This is the OSHW that Gus mentioned.

Looking at the features if the G120HDR, I’m thinking it will be easier/worthwhile to get a TFT I can integrate directly to the LCD control lines of the G120HDR.

How would the touch screen work? The one I am looking at is I2C and capacitive. Is this driver run in the managed/application code?

You should be able to build one in c# easily, just like we have for our CP7 display.