NuttX on a Netduino Plus 2; trial 2, on a Teensy++

OK, this has nothing to do with Netduino Plus 2, but it is a step I took to further validate my build process, so I am logging it nonetheless in the interest of completeness.

I wanted to verify that my build product (firmware image) is sane, and ideally had no modifications of my own that would ambiguate the origin of any failure, so I rummaged for a board that is already supported, that I had on-hand.  I do have an STM32F4Discovery, but for some reason I didn’t want to use that, and I found that I had a Teensy++, so why no?

This uses a different processor, one of the very popular Atmel lineage, so I needed a different toolchain:

sudo apt-get install gcc-avr gdb-avr avr-libc

then configure:

make distclean
cd tools
./ teensy/nsh
cd ..
. ./

then ‘make menuconfig’, and change ‘system type, toolchain’ to ‘linux gcc’

Then you need a firmware installer from the Teensy site; I use the command line one.  Goodbye blinky, hello Nuttx.  I use my handy FTDI serial adapter configured to 38400,N81, and connect to the board’s PD2(RXD1) and PD3(TXD1), oh and GND, and open Putty on the com port, and then apply power to the board:

NuttShell (NSH) NuttX-6.27

yay.  I run ‘help’ but the output looks weird.  At length, I find an option in menuconfig:

‘application configuration, examples, nuttshell, library routines’, and I DEselect ‘disable sprintf field width’, rebuild, redeploy, reboot, rerun ‘help’:

NuttShell (NSH) NuttX-6.27
nsh> help
help usage:  help [-v] [<cmd>]

  ?           dd          free        ls          ps          unset
  cat         echo        help        mb          pwd         usleep
  cd          exec        hexdump     mh          set         xd
  cp          exit        kill        mw          sleep

Now that looks sane.  But this is the end of Teensy++ and me for the time being, now to get on with Netduino Plus 2 porting in earnest….

NuttX on a Netduino Plus 2; build/dev machine setup

as per usual for me these days, I create self-contained build/dev environments in VMWare images.  This is a habit I got into years ago from some OpenWRT work, and its wonderful to be able to archive, transport, and snapshot a purpose-specific computer in a hardware-independent way.  Anyway, for me the first step in a project is setting up that build machine.

Also, I typically use Ubuntu for my Linuxian things.  So I created a new machine, and installed Ubuntu 12.10 64-bit, thinking it is modern, and stable.  OK, I guess I’m not up with the times, but they have changed to a faux OSX window manager, called ‘Unity’ I think.  It’s obscenely slow for some reason, and anyway all my cheese has been moved.  So after wasting some time figuring that out:

sudo apt-get install gnome-session-fallback
sudo apt-get install synaptic

and the world is sane again.  I also need to have vmware tools and basic connectivity, so

sudo apt-get install build-essential linux-headers-$(uname -r)
(for building vmware tools)
sudo apt-get install aptitude
sudo apt-get install openssh-server

Now, chain chain chain.  Chain of tools.  I decided to use CodeSourcery since it is tested.  Upon looking back, I might have used something different, but this is what I did.  It’s free; you have to register your email with Mentor, though, to get the super secret link to the free download.

You need to fiddle with stuff to make it install, though:

sudo dpkg-reconfigure -plow dash
Install as /bin/sh? No
sudo apt-get install ia32-libs

then you can install:

/bin/sh ./arm-2013.05-23-arm-none-eabi.bin
(click through with the defaults)

Now your build environment should be setup, and you can get the source.  I usually shut my machine down and snapshot here as ‘clean machine’.  I usually try stuff out, adding missing components I discover along the way, revert, and update the ‘clean machine’ snapshot until it is complete.  But I’m pretty sure what I described above is complete for your build system.

I started using the current NuttX source, 6.27.  It took me a while (quite a while!) to figure out what I really needed to do, but here is a summary:

  • get stuff form sourceforge
  • get ‘nuttx’ the os, and ‘apps’ the auxilliary, but required, application source code
  • also get the kconfig-frontend, which is how you are going to setup your source.  This was somewhere else on sourceforge, the package I got at the time of this writing was named kconfig-frontends-3.3.0-0.tar.bz2, so you should be able to search and find.
  • create a directory structure in your home laid out this way:
  • untar all the stuff (the three files) where I showed them
  • rename the resulting ‘apps-6.27’ dir to ‘apps’ and the ‘nuttx-6.27’ dir to ‘nuttx’

First, build and install the kconfig-frontend, so you can do configuration of your source:

sudo apt-get install gperf libncurses5-dev
cd nuttx-dev/misc/kconfig-frontends-3.3.0-0
./configure –enable-mconf –disable-nconf –disable-gconf –disable-qconf –program-prefix=kconfig-
sudo install
sudo ldconfig
cd ../..

(that little sudo ldconfig step is vital.  took me a while to figure it out.)

OK, now your source tree is setup.  I like to do a trial build of something as a sanity check.  Never mind if its not for my board, but just to prove I’ve got all the stuff in the right places.  I chose to build the stm32f4discovery as my proving point since I planned on using that as the basis for my project.

cd nuttx-dev/nuttx/tools
./ stm32f4discovery/nsh
cd ..
. ./

OK, the next steps are to configure the source, and then do the build.  The source as-configured out-of-box will not work, you need to make some mods. First, we will just modify the toolchain.  Out-of-box it comes for Windows, and the Windows Code Sourcery.

so ‘make menuconfig’, and go to ‘build setup, build host platform’ and change to ‘Linux’.  Then go back up the tree to ‘system type’ and down to ‘toolchain selection’ and pick ‘CodeSourcery’.  Use Exit until you get out and save the change.

NOW you can do ‘make’.  It should all finish up eventually, with the last output being CP of the nuttx.hex and nuttx.bin.  These are your firmware.  In particular you will need the nuttx.hex so you can burn it onto your board.  The nuttx.bin is presumably elf, and I suspect it can be used with gdb for debugging, but I haven’t done that.

Anyway, regardless, this was just a trial build — you can’t actually put this on the Netduino Plus 2 board.  So clean it all up squeaky-clean this way:

make distclean

The regular ‘make clean’ will remove all the build artifacts, but leave the system configured for your board.  the ‘make distclean’ will blitz the board configuration also, and take you to as you were when you untarred your source.

Next, as my next sanity check, I want to try to build something I can deploy to a board without actually modifying any source.  I have a small ocean of dev boards (well a pond at least, perhaps), so maybe I can do that to one of them….

Building and Interop Assembly for the Netduino Plus 2


This document provides a walkthrough of producing an ‘interop assembly’ for the Netduino Plus 2, which facilitates bridging managed to native code implementation.


NetMF provides a mechansim whereby managed code can invoke implementation realised through native means (typically in C/C++, etc.), called an ‘interop assembly’.  The use of this mechanism has been described elsewhere, including:
Porting SDK Documentation:

RCLPort.chm > The .NET Micro Framework Porting Kit > Porting Kit Overviews > Adding Features to Your Port > Adding Features to the .NET Micro Framework by Interoperating with Unmanaged Code


as well as others.

This document is intended not to repeat these, but rather to provide a brief step-by-step guide for implementing a simple interop assembly for the Netduino Plus 2 as quickly as possible, and to convey caveats particular to that activity.  It is still worthwhile to consult other sources for details on more sophisticated interop capabilities.


Creating an interop assembly for NetMF consists of these tasks:

  1. Building Firmware
    The Interop has a ‘native’ component, which must be built into the firmware image.  It is not possible to ‘dynamically load’ (or otherwise later deploy) the managed component outside of the monolithic firmware image.
  2. Creating a ‘Class Library’ project
    This project will be modified to also emit stubs of skeleton C code to be modified by adding your code.
  3. Integrating the Generate Stubs into the Firmware
    The generated/modifed code will be placed in the firmware build hierarchy, and some project files will be modified to include these added files.

That is the basics of creating the interop assembly.  Beyond that, you must:

  1. Compile the firmware and generate the flash image
  2. Flash it to your board
  3. Create your project that uses your new assembly, adding a reference to it
  4. Run your project, invoking your interop’ed methods
  5. Rejoice


1 — Building Firmware

Setup for this is a biggie.  I have covered it elsewhere, e.g.

Building Netduino Plus 2 Firmware with Yagarto GCC 4.6

but you can use whatever build system you like.  Regardless of what route you choose, this is the first thing you need to get working.  Interops, at least in the present (4.2) release of NetMF, are required to have their native side linked into the firmware image.

2 — Creating the Interop Class Library Project

[this is from the perspective of VS2010 Ultimate, but you can figure out the variation for whatever you’re using, I’m sure]

a — First, we will create a C# class library project like any other:

From the File, New > New Project… choose

New Project, Other Languages, Visual C#, Micro Framework, Class Library

Choose a name, I’m going to call it DemoPeekPoke.

b — Next, we will modify the project to produce our native stubs:

Get to the project’s properties; you can use View, Solution Explorer, and right click on the DemoPeekPoke, and select ‘Properties’

The last tab on the left will be ‘.NET Micro Framework’.  Select it.  The configuration pane presented will have a checkbox ‘Generate native stubs for internal methods’.  Select it.  Personally, I leave the defaults as they are.

The ‘root name for stub files’ is interesting if you want to change the filenames the tool emits (ostensibly to avoid some conflicts if your toolchain has troubles with same-named files in different directories).

‘Create stub files in this directory’ might be interesting in some case, but I conscientiously don’t change it.  Each time your build the project, the files here will be overwritten.  It should be preset to a directory ‘Stubs’ within your project directory.

c — Make your class interface

Obviously what you put here is specific to your application, but for this demo we are going to do this:

Rename the class file from ‘Class1.cs’ to ‘HardwareInterface.cs’.  (You will be prompted to fix things up, and I say ‘yes’.  This should also fixup the class name within the file to be ‘HardwareInterface’)

d — add a ‘using’ to ‘System.Runtime.CompilerServices’

This will allow you to decorate your methods as needed to cause stubs to be generated.

using System.Runtime.CompilerServices;

e — add your methods of interest

Again, this will be whatever your application demands, but in my case, I’m going to make two methods that will allow you to ‘Peek’ at an arbitrary memory address, and ‘Poke’ a value as well.  Sounds basic, but actually it is pretty powerful since most of the hardware is memory mapped.

//note, these addresses are meant to be dword-aligned
public extern UInt32 PeekDWord(UInt32 addr);
public extern void PokeDWord(UInt32 addr, UInt32 word );

The decoration [MethodImpl(MethodImplOptions.InternalCall)] is required, and the method must by public extern.  Must.  This will cause the stubs to be emitted.

f — build the project

OK, now stuff is happening.

As per usual, a ‘bin’ directory now contains ‘Debug’ and ‘Release’  (depending on what configuration you built, if you have configurations (Express edition doesn’t)), and those in turn have ‘be’ and ‘le’, ostensibly for a ‘bigendian’ and ‘littleendian’ machine (but really they are both the same).  This is our managed side stuff, and what your applications would ‘add reference’ to.  We’ll also be copying that into our firmware build tree soon.

Also created are things in ‘Stubs’.  You should have these 7 items

DemoPeekPoke.cpp — we won’t mess with it

DemoPeekPoke.featureproj — we WILL mess with it

DemoPeekPoke.h — we won’t mess with it

DemoPeekPoke_DemoPeekPoke_HardwareInterface.cpp — we WILL mess with it

DemoPeekPoke_DemoPeekPoke_HardwareInterface.h — we won’t mess with it

DemoPeekPoke_DemoPeekPoke_HardwareInterface_mshl.cpp — we won’t mess with it

dotNetMF.proj — we won’t mess with it

3 – Create Firmware Project

Your Porting Kit, along with all the Netduino software is located in some directory often referred to as $(SPOCLIENT).  We need to make a place to put our code (both  managed and C) for the build system.  It’s not critical where, and for this example I will use:


a — A Place for your Stuff

Make two directories under that for your managed and native code



b — Put Stuff in its Place

from your compiled DemoPeekPoke project, copy all the stuff in

/bin/Debug (or /bin/Release if you prefer)



from your stubs directory, copy all the stuff into


so, ManagedCode should have a built assembly and a be and le directory containing processed assemblies.  NativeCode should have some project and source files.

c — Fixup Interop Project Files

Fixup some paths in NativeCode\DemoPeekPoke.featureproj.  There is a tag MMP_DAT_CreateDatabase which I comment out altogether.  This will cause the managed assembly to be built into the firmware (don’t need it).  If you want to fix it up proper, though, change the Include attribute to be


Fixup the path of RequiredProjects  to refer to your location in the porting kit:
<RequiredProjects Include=”$(SPOCLIENT)\MyInterops\DemoPeekPoke\NativeCode\dotnetmf.proj” />

CAVEAT:  It is handy that we are copying this stuff, because every time you build your DemoPeekPoke project (e.g. you add/remove/change some methods), all the stubs will be re-generated, and any work you might have added there will be overwritten.  If you need to do this, carefully merge the changes into this directory.

CAVEAT2:  the managed and native code must be in sync.  A checksum is computed when the project was built and embedded in the code.  If you do rebuild your project, be sure to copy over both the native code and the managed code into these working directories in the porting kit.  You’ll gert runtime errors otherwise.

d — Fixup Netduino Firmware Project File

This is perhaps the trickiest bit.  In:


You will need to add an Import tag, and an ItemGroup tag.

Hunt for the Import tag containing ‘Microsoft.SPOT.System.Interop.Settings’ (around line 61 on my system) and place your Import tag just before it:

<Import Project=”$(SPOCLIENT)\MyInterops\DemoPeekPoke\NativeCode\DemoPeekPoke.featureproj” />

Also, add your ItemGroup tag; I just put it at the end:

<DriverLibs Include=”DemoPeekPoke.$(LIB_EXT)”/>
<RequiredProjects Include=”$(SPOCLIENT)\MyInterops\DemoPeekPoke\NativeCode\dotNetMF.proj”/>

CAVEAT:  I found the hard way that the Import tag really needs to come before the one for Microsoft.SPOT.System.Interop.Settings.  If you don’t, the firmware will build but you’ll get runtime errors when you try to use your interop.

4 — Implement your Functionality

This is what it’s all about.  In your NativeCode directory, the file:


has the stubs you must implement.  This test is simple; for PeekDWord(), use

UINT32 retVal = *(UINT32*)param0;
return retVal;

and for PokeDWord(), use:

*(UINT32*)param0 = param1;

So, Peek will read a machine word from an arbitrary address, and Poke will write a machine word to an arbitrary address.  You could do tons more, of course, but this is enough for the demo.

5 – Build and Flash

Do your firmware build as usual, make your flash image, and flash it to your board.

6 — Build Test App

Make a Netduino Plus 2 app for testing.  Add a reference to your interop using the Add Reference… Browse, and find your DemoPeekPoke.dll in the bin/Debug directory of the DemoPeekPoke project you first created and built.

Now you can do some peeking and poking.  For instance, address 0x1fff7a22 contains a constant indicating how much Flash is on the chip.

UInt16 nFlashSize = (UInt16)hwif.PeekDWord(0x1fff7a22);
Debug.Print(“flash size = ” + nFlashSize + “k”);

Also, addresses 0x1fff7a10-1b contain a unique serial number.

UInt32 nDevId0 = hwif.PeekDWord(0x1fff7a10);
UInt32 nDevId1 = hwif.PeekDWord(0x1fff7a14);
UInt32 nDevId2 = hwif.PeekDWord(0x1fff7a18);
Debug.Print(“device id = ” + nDevId2.ToString(“x8”) + nDevId1.ToString(“x8”) + nDevId0.ToString(“x8”));

The device has a hardware random number generator (for true random numbers, useful for crypto).

Here’s some sample output from my board:

flash size = 1024k
device id = 363430373131471000190036
rand = 0x4BE4D446
rand = 0xF089656A
rand = 0x13C1798F
rand = 0x313FF4CA
rand = 0x60B2F729

OK, I had hoped this would be a shorter doc, but I think I pared it down to the bare minimum.  Here is a checklist style summary that will make sense after you’ve gone through the expository part once.


Checklist of to-do to make Interop:

  1. Make a Class Library Project, name and define your interop’s interface class
  2. Declare the methods
    public extern
    with the
    attribute, and be
    using System.Runtime.CompilerServices;
  3. Fixup the project properties for .NetMF to generate native stubs
  4. build the project, generating the native code and the stubs
  5. Make a spot in the firmware heirarchy; copy the managed code and native (stubs) code into place.
  6. Fixup the .featureproj file
  7. Fixup netduino tinyCLR.proj to include your stuff
  8. Implement the stub methods
  9. Build the firmware
  10. If you modify the interface to add/remove/change the methods, carefully merge the changes in the regenerated files into your firmware copies.  Bear in mind that the managed and native are coupled by way of a computed checksum; the managed assembly your app uses must be the one that was generated with the stubs that the firmware incorporates.

NuttX on a Netduino Plus 2

I am going to try to port NuttX onto a Netduino Plus 2, and this is a journal of that experience.

Why am I going to do this?  Well, why not?  Haha, but seriously, this project is largely motivated from the desire to have RTOS and native-code capabilities on this board/platform.

The Netduino Plus 2 ships with dotNet Micro Framework (“NETMF”).  While this is lovely and fun in its own right — and I was a skeptic coming into it — it is as slow as you might expect from an interpreted framework.  Many if not most embedded developers are accustomed to C/asm and are taken aback by the inability to manipulate the hardware directly, or run at one machine cycle per instruction.  Or have real-time capabilities whereby they can services interrupts or read or feed datastreams with minimal latency and maximal speed.  Scripting and p-code execution environments certainly have a place in speeding development, but so does having the power to access your machine’s native capability, and so many environments provide some facility for integrating these approaches.  For example, Java has the the Java Native Interface (“JNI”).  In NETMF, there is a similar facility called ‘interop assemblies’.

I did an interop assembly on a lark (separate project, q.v.), but there are at least two problems:

  1. This requires a firmware build change.  The firmware contains the native component.  the application contains the managed component.  There is not an official way for the application to provide all that, and deploy it onto unmodified firmware.
  2. This works for creating objects in the NETMF type system, but can be awkward to integrate more deeply, and the interface between native and managed is weaker than JNI.

So, initially I thought about making an interop to proxy dynamically loaded native code (like providing a ‘dll’ capability), but then I thought about instead doing a port of NETMF onto an RTOS, and letting the RTOS handle those parts.  I did some research and found that this was not a new idea, but no one to wit had actually done it.  The NETMF apparently can run on another OS (the emulator apparently works this way), and there was a project to put it on top of Linux.  So, I thought this might be a useful approach — and maybe much richer than the ‘dll emulation’ approach.

My first though was FreeRTOS, which is well-respected, has existing ports for this processor (STM32F405), and is, well, free.  It’s also friendly on the memory footprint, and I’ve used it before.  However, I ultimately decided to give NuttX a try.  NuttX’s philosophy is to present a Linuxian system model that should be more accessible to programmers.  It’s less friendly on the memory footprint, but still within a couple 10s of K for something replete with file systems and networking.  Also, there is an existing port for the STM32F4Discovery, which I could cannibalize, and an existing driver for the ENC28J60 Ethernet controller that I will be needed.  Also, why not?

So I decided to do this project in two phases:

  1. Port NuttX to Netduino Plus 2
    As a goal, just the OS and its execution environment.  This will result in something of value in its own right, and you could happily develop applications within this framework.
  2. Port NETMF onto NuttX
    Make a ‘solution’ that runs on NuttX.  My thinking is the Linuxian programming environment might make this more natural.  I could be wrong but that is my present thinking.

So, today, I am off to downloading codebases and setting up build environments….