Is this a good breakdown of what you're asking?

• Can you request a health check from the Netduino?
• Can you extend the program memory size by using an SD card?

For 1, you can do a few things in an attempt to determine if your board is GO/NOGO but I don't know of any single or set of commands you can run to get this answer directly. For instance, I know of no way to say: Check analog pins can input and output relative to Aref correctly, check the onboard LED is functioning, etc. You'd have to identify the components critical to your operation and devise a way to do a system check yourself. When you do this you might find some things can't be tested when the board is connected to your circuit(s) and require a dedicated testing station. You might also find not every test can be run and understood by the board - for instance generating PWM might be hard to measure to ensure you're getting the correct frequencies and you'll need to use an external device to do the proper capture and/or analysis.

As for 2, there are a number of discussions on using the SD card as storage space for DLLs but keep in mind, once you load the DLL into memory, you're using the chip memory. You can't execute program space from the SD card directly. The SD card is primarily used to store log or resource files. I wouldn't count on being able to use this when decided on what boards to evaluate for your needs.

Side note: all consumer GPS receivers (sold in the US? made in the US? required by license?) have an arbitrary maximum operating altitude above which they will be unusable. Just something to be aware of when designing your project.

The DOD requiurement for the arbitrary maximum is 60K FT Altitude + 1K FtPS Speed. However most manufactures write the firmware code as 60K FT or 1 ftPS instead of 60KFT and 1 ftPS.

My team and I have posted emails to a few of the larger chip makers with what we are trying to do in an effort to get a properly coded GPS Chip that will meet our needs.

Sounds like you've got it covered then!

I think it depends on your purpose. For instance if you're trying to PWM some LEDs, you could use an LED driver chip. Most can be programmed with SPI from what I've seen. The chip would then handle the PWM work. What specific problem are you trying to solve?

I have been developing my Netduino application on a Windows desktop machine - but my deployment scenario is going to involve powering the board from a Mac Mini USB port (currently a Mac Mini 2012 model).
What I have discovered, is that if I plug my netduino into a Mac Mini USB port, the on-board LED lights up, but stays on - and my program never loads.
If, I plug it into my PC, or a wall-wart USB power supply, the on-board LED lights up for a few seconds, then goes out as my program loads into memory, and everything works.

Why does my Netduino not run correctly when powered by Mac Mini??

Thanks

I noticed a similar issue. All I had to do was tap the reset button and it'd come up just fine. I noticed as soon as my VM running on the Mac Mini was set up to automatically attach the Netduino to the Windows instance, this stopped happening. Before that it was reliable to just reset the board and it'd come straight up.

Everything you need to know was right there in the first error:

#### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (1) ####
#### Message:
#### System.Delegate::Combine [IP: 0000] ####
#### Microsoft.SPOT.Hardware.NativeEventDispatcher::add_OnInterrupt [IP: 0014] ####
#### NetduinoPlusApplication1.Program::Main [IP: 004a] ####

This is saying in your application NetduinoPlusApplication1 has an object Program with a function Main which has some instruction that is, under the hood, calling NativeEventDispatcher object's add_OnInterrupt method. That is in turn calling Delegate object's Combine method. From experience, I know when you do <event> += <handler> this uses Combine to join your new handler into the pool of handlers that want to be called when this event is fired.

That gives us all the information we need to find the problem. Looking at your code, there's only one place you're doing a handler assignment to an event:

while (true)
{
    button.OnInterrupt += new NativeEventHandler(button_OnInterrupt);
    button.ClearInterrupt();
}

We see this is being done in an infinite loop. Basically you're attaching a copy of your event handler again and again and again until the Netduino runs out of memory space.

You can read up on Event Based Programming but in short to fix your issue, just move your event wire-up above the while loop (which I assume you have just to keep the main thread alive; in which case you should consider adding a sleep call to put the main thread to sleep when it's not needed.)

Hope this helps!

-Erik

It depends on your need. If you want to wake up from time to time before going back to sleep:

public static void Main()
{
    //Do your event wireup and any other thread work

    //Then, last thing:
    while(true)
    {
        //Do any periodic work you need executed on the main thread for some reason
        Thread.Sleep(10000); // 10 seconds or whatever
    }
}

If you don't ever need the main thread to wake up to do something then you don't need a loop at all and you can put the thread to sleep forever. Your event threads will continue to process; this is just the main thread which you need to keep active so the whole program doesn't terminate.

public static void Main()
{
    //Do your event wireup and any other thread work

    //Then, last thing:
    Thread.Sleep(Timeout.Infinite);
}

Heh been there done that

You failed to mention whether you acquired the t-shirt.

NETMF uses software threading and from code I've written and what I've seen from others, you can do asynchronous programming. I haven't specifically used Begin- and EndInvoke rather using Thread and ThreadStart.

You could try re-installing the .NET Micro Framework SDK 4.2 and the Netduino SDK 4.2.0.1. Links are on the Downloads page under

netduino go (and all 4.2 upgrades)

.

Following the Wiki instructions exactly worked for me.

I also had to install the driver mentioned in a small snippet in those instructions.

Now (re)connect the Netduino to the PC. A driver for an emulated COM port will be installed. Start the SAM-BA tool. If a driver for an emulated COM port is not installed on a Windows 7 x64-machine, try this wiki page.

I'm running Server 2008 on a VM so it wasn't as straight-forward. I had to use IE to go to the Update site, download the file and install it manually. A little bit more of a pain but it worked. The link to the file is in the second Wiki link.

There are more differences than raw clock speed. The Atmel chip on the Netduino Plus executes code in Thumb mode (for code space optimization). In this way the DMIPS for that chip is 0.9/MHz. I believe the Go can use Thumb2 code which is more efficient for execution while still having a smaller code footprint. I believe the DMIPS rating is 1.25/MHz. If the Go is still running Thumb code then it will have the same DMIPS as the Netduino and in this case it's a simple matter of increased clock speed. If your program is purely computational (CPU bound) then the time to execute should decrease directly proportional to the instruction set efficiency and speed increase. Exceptions would be any situation you're waiting on threads to switch since I believe the time slices in the NETMF are set at 20ms. If you're not using all the time you are given for your time slice, you could be wasting cycles and you won't see as much of a speed increase. Bottom line is it's really hard to figure out performance difference from a pure math perspective. You'll really just need to benchmark your application.

Short notice but I'm down for it. I won't have anything prepared to show though. I could talk about using NuGet though.

I've had pretty good success with running WIndows inside VirtualBox. After you've connected the board you need to go into VirtualBox settings, USB and add a filter for the Netduino device. This should cause the Netduino to automatically (re)connect to the VM instance when it is plugged in / rebooted.

 

Sometimes a deployment will fail or time out. Usually I can just right-click on the VirtualBox USB indicator in the status bar and click the Netduino device to disconnect it and do that again to reconnect it before trying to deploy again.

 

It's not as smooth as just using a native Windows environment but it's not bad either.

I've always just taken a look at the output directory file sizes. For instance, in a default configuration you'll have a BIN folder with 1 or 2 folders underneat: Debug and Release. Whichever configuration you're building, go into that folder. You should see your DLL (and probably other referenced files, build artifacts, etc.) and 2 more folders: LE and BE (for little endian and big endian builds.) These should be about equivalent but you're likely deploying the LE files. Go into that folder and take a look at the .PE file sizes (I'm pulling from memory - maybe it's not PE?).