Although I am a veteran .NET developer with .NET 4.x using Visual Studio Ultimate 2012 I am a newbie to the .NET Micro Framework. I am running Windows 7 Ultimate x64.

A few days ago I successfully installed the .NET Microframework v4.3 as well as the corresponding Netduino SDK v4.3. When I start Visual Studio I can see the new project templates.

As a starter I created a Device Emulator project but when I try to compile it I get this error:

Warning 1 The reference assemblies for framework ".NETFramework,Version=v4.3" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. MyDeviceEmulator

I am new to NetDuino... Since it is obvious the RAM and ROM on an embedded system such as the netduino is limited, I believe some 384KB maximum on the Plus 2, I would like to know how can I determine what are the actual memory requirements of my application.

I have not bought the netduino board yet because I don't want to buy one and then find out it doesn't have enough  memory to run my application. I don't know how effective the .Net MF is at squeezing stuff up. Back in my embedded days I developed (with my team) a multihandset cordless phone with only 512 bytes of RAM using C but for that I had to really know my compiler's output very well to adjust the coding accordingly.

Currently I have my eyes set on the Netduino Plus 2 but I will first have to see how big my application is.

I am using Visual Studio 2012 Ultimate on a Windows 7 Ultimate x64 OS. I am new to Netduino. I downloaded and installed the .NET MF 4.3 as well as the Netduino 4.3 SDK (couldn't find the link to the x64 version).

I opened VS 2012 and created a Device Emulator project but every time I compiled it it gave a warning about missing references to the 4.3 libraries or so, but it would compile. In the project properlies I did see that the Target Framework was EMPTY but clicking on it would list the standard .NET frameworks but NOT the 4.3 Microframework, why?

I also created a sample MF console application. I was able to build the solution and run it. On ocassions and without any reason or interaction the whole thing would crash with an exception on the emulator but it wouldn't let me see well (the exception data disappears after the emulator window disappears, it disappears by itself after a little while). And then just the same without change it would work well and I am not doing anything fancy.

However, the problem now being that I used it until past midnight multiple times. This morning I started VS.2012 and opened my MF solution and now (no changes) the Device Emulator project would not load. It said I didn't have the Targeting Pack. It simply doesn't load anymore.

The same happens with some sample projects I downloaded, they don't load into VS.2012

There is a problem with the installer too. Like all security conscious people, I use my Administrator account for just that and have been developing under a restricted user account for years. I noticed that I could not find the samples on my restricted account. As it turned out, the installer placed the Samples files in the Documents folder of the Administrator user (where the install was made for ALL users). I would suggest those files be put in the Public user Documents folder or let the user where to install them.

Well as I mention it is spurious, it may fail several times in a row and then the next one it doesn't crash. I have been developing .NET web & desktop apps for years under a restricted account and haven't encountered any real issues.

I tried putting a try/catch on the Main of the Emulator project but even with that it simply crashes back to VS and leaves absolutely no information (log, output) about what went wrong. Even the output window is empty.

BTW the Device Emulator project wouldn't load today anymore (didn't have that yesterday because I never existed VS). I had to change the target framework of the Emulator (no the MF application) to .NET 4.5. The target framework drop down would only show standard (not micro) framework versions. The MF application project however DOES show only the Microframework versions in that Target Framework dropdown. So is that okay? should I target my emulator at any of the std. frameworks (4.0, 4.5) ?

By trying multiple times and attempting to being extremely fast to do Select All & Copy in the Output window when the crash ocurrs I managed to get this. When it happens this information is left only for a second or two in the output window before it is cleared and replaced by "Found debugger!". I think that needs some attention.

Looking for a device on transport 'Emulator'Launching emulator with command line: '"N:CodeMicroFrameworkMyAppMyDeviceEmulatorbinDebugMyDeviceEmulator.exe" "/waitfordebugger" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Native.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3Assemblieslemscorlib.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Graphics.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Hardware.pe" "/load:N:CodeMicroFrameworkMyAppMyDeviceEmulatorbinDebugleMyApp.pe"'Restarting interpreter...Attaching to device...Deployment error: failed to (re)connect debugger engine to debugging target.The debugging target and the debugger engine failed to initialize because of unspecified device errors.The debugger engine thread has terminated unexpectedly with error 'Debugger engine could not attach to debugging target.'.

I am planning a design based on the Netduino Plus 2 (tentative) and I created a custom emulator (nothing fancy really) project in VS.2013 Ultimate on Windows 7 Ultimate x64. As pointed out in a previous question this is targetted to a desktop framework (.NET 4.5) and it seems to work well.

I also created the Microframework application (SDK 4.3). Basically the application sends commands to the device (as emulated) via the SPI bus, It sends 16 bit commands to control a MAXIM 7219 chip.

I seem to have gotten the communication between emulator an app right from the examples. So, I can click on a button on the emulator which causes an interrupt to be processed on the app (Emulator to App comms). Also the application sends commands via SPI to the emulator (no actual device yet). My emulator receives the SPI commands and acts accordingly to update the custom UI. I also have a form that shows the registers of the device which has SPI (slave) and see that the commands are received.

The problem is... If I add initialization code in the app that sends initialization commands via SPI then the whole thing crashes. If I omit the initialization code (sent by SPI) and simply assume everything is initialized then I can interact with the emulator.

So to my question, how can one debug these things? when I enabled the initialization code sent to my device the emulator UI appears, I see in the Output Windows "found emulator!..."  and then I briefly see a bunch of messages, the thing crashes and the whole output window is ERASED leaving me with absolutely no clue as to what went wrong. 

I put a breakpoint on the call to the initialization code which is invoked in Program.cs then it doesn't even break, it craps out erases all output and no clue.... If I remove that call to the initialization then 99% of the times it starts and works. But usually the 1st time it crashes (same modus operandi of erasing all useable output) and the next time it runs fine.

How can I debug this???? I am not even using an actual hardware device. Why are the breakpoints ignored in DEbug mode?

I found the following messages on the "Microframework Device Deployment" category of the Output Window in VS.2013:

Looking for a device on transport 'Emulator'Launching emulator with command line: '"N:CodeMicroFrameworkDisplayMyDeviceEmulatorbinDebugMyDeviceEmulator.exe" "/waitfordebugger" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Native.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3Assemblieslemscorlib.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Graphics.pe" "/load:C:Program Files (x86)Microsoft .NET Micro Frameworkv4.3AssembliesleMicrosoft.SPOT.Hardware.pe" "/load:N:CodeMicroFrameworkDisplayMyDeviceEmulatorbinDebugleMyDeviceEmulator.pe"'Restarting interpreter...Attaching to device...Deployment error: failed to (re)connect debugger engine to debugging target.The debugging target and the debugger engine failed to initialize because of unspecified device errors.The debugger engine thread has terminated unexpectedly with error 'Debugger engine could not attach to debugging target.'.

But that "unknown device errors" isn't really much of a help, isn't it? shouldn't it give a stack trace or something to work with?

Since I don't have a device yet and it is good for early prototyping, I am using a custom emulator for my project for the time being. As we all know (I recently only...) the Device Emulator project is targeted to the standard .NET framework (v4.5).

My actual application is a .NET Microframework v4.3 project with ".NET Microframework 4.3" as the target. So far so good...

Now, since for the configuration of both applications I need things like pin numbers and perhaps a few interface definitions, rather than duplicating them in both the uF console app and the .NET device emulator project, I thought a common library project would be more suitable to share those things I mentioned.

My question is... such "common library" project to be used with both the Device Emulator project AND the uF Console Application should be targetted at the uF (the lowest denominator) or is this approach just not possible?

OK, I am new to Netduino, let's say I spent quite some time developing a project using the .NET uF based on the Netduino hardware and I am ready to create boards... Obviously I wouldn't want to just have a true netduinon inside.

1.  How do I go about creating my own board that would integrate the Netduino (minus a few things I don't need from the board) and my own "add-on" module all in one board?

2. Who can produce those boards in small quantities?

3. Would I need to re-port the uF or something? 

4. How do I get to permanently download my custom firmware (the app developed in vs.2013) into the board?

I don't know if somebody has already gone through that process or what. I would like to do it with Netduino but if that is not possible then I would opt for a PIC based design that is perhaps easier to produce. Anyway, just need some feedback for my "custom appliance"

Just found out it is not possible. If you reference a uF common library from the emulator you get this error:

Warning	1	The project 'CommonLibrary' cannot be referenced. The referenced project is targeted to a different framework family (.NETMicroFramework)	MyDeviceEmulator

so the problem remains how to share certain data types (interfaces, classes, structs) that are common to both the emulator and the uF application taking into consideration that the common library should behave the same (some methods such as ToString are implemented differently in the frameworks) and compile under both frameworks. Pity...

OK the target is okay. What I have consistently noted is that the emulator tends to crash many times on startup with the same error, that it found the emulator but failed to (re)connect to the emulator.

I observe that my custom emulator UI pops up and the Output Window shows "Emulator found..." and many times it crashes a few seconds after that. If I try several times (without any change) then at some point it does connect to the emulator and I see a bunch of messages on the Output Window indicating the progress of loading assemblies and data from the PE file (memory usage, etc.).

Even in the cases it crashes I see that before it crashes I can FULLY interact with the WinForms custom emulator UI I created. Operating it does not cause the exception. Why the uF Emulator backend fails to (re)connect on initial loading puzzles me. Sometimes doing a "Clean Project" followed by "Rebuild Solution" does it, but other times it doesn't. Sometimes I have to try like 5-6 times to get it to run.

BTW... is there a flag or something in my emulator UI (WinForms) that I can use to wait for the Microsoft Emulator to be READY? I see a message on the Output Window that says "Hello World!" and that's how I know it is ready but I want to disable the UI until that phase is reached.

I am planning to use the Netduino Plus 2 (don't know if it is an overkill yet, have to see my memory requirements). I was wondering if there is some Netduino BSP (Board Support Package) that contains the definitions that map Netduino-specific stuff to NETMF ? 

For example, I read that in an SDK I should map my own pin definitions (board specific) to the NETMF Cpu.Pin.GPIO_* enumeration. Is there such a thing for Netduino?

Also, how do I go about specifying GPIO 16 ??? if that is possible.

In addition to the NETMF 4.3 SDK I also installed the Netduino SDK. Isn't there some "using netduino;" kind of using directive that can/should be used to have access to Netduino-specific things?

In my custom emulator how do I set the available RAM/ROM and perhaps speed of the Netduino's core processor? I ask because there must be a way (I think) that the development environment warns me if my code or data segments are too large for the hardware I am targetting.

In my NETMF application I make use of two types of Timers from System.Threading (is there a better one?).

One timer actually times the period of time a button is depressed, if it is less than 2 seconds X happens but if it is pressed for more than 2 seconds then Y happens. This is common in embedded devices.The timer is started when the NETMF application detects that the GPIO pin has gone low (active low) and it also detects when the button is released when the GPIO pin goes high. I am using I/O interrupts on both edges to detect the press/release.

The other timer is a loop processing timer which is used to periodically do the processing of signals and state transitions of my state machine. When a button is pressed for example a Pressed signal is put into the queue and at the next processing loop the signal is picked up from the queue and processed according to the state.

Now, I also found out that in NETMF Timers aren't what we are used to in the standard framework, namely that you can't start/stop them the usual way, they start as soon as they are created (unless a delay is specified) and they keep on running forever. The only way to stop it is by Disposing the timer instance and setting it to null so that it is garbage collected. I use 2000 (milliseconds) for the button press/release and originally used 200 ms for the loop processing.

Now, I am testing my "virtual device" and see that even if I click quickly on the button (much less than 2 seconds) the timeout signal is raised as if I had pressed the button for more than 2 seconds!!!

Am I missing something here? is there perhaps some NETMF setting that controls the time base of the timers? it appears to me that they are running at the speed of light and therefore what is supposed to be 2 seconds turns out to be more like 100 milliseconds!

Doesn't one of the arguments in the button event/interrupt give you the time an even occurred?

 

You are right about Timers running forever.  I found that out earlier this year and ended up writing a post about it.

 

Regards,

Mark

Perhaps it does in the emulator application but that information is AFAIK not available on the NETMF application because it doesn't receive a button event.

Chris, here are some code snippets relevant to the problem at hand...

class AnyController {private mTimerTransfer;private mTransferTimedOut = false;private void StopTimer(TimerID id){    switch (id)    {        case TimerID.TransferTimer:            if (this.mTimerTransfer != null) {                mTimerTransfer.Dispose();                mTimerTransfer = null;           }           break;              :    }}private void StartTimer(TimerID id, int msDelay, int msPeriod){    switch (id) {       case TimerID.TransferTimer:           mTimerTransfer = new Timer(new TimerCallback(ActionTimers_Tick), TimerID.TransferTimer, msDelay, msPeriod);           mTransferTimedOut = false;           break;            :    }}} // class

Then my Timer event handler on the above class looks like this. It handles several timers but they have the same mechanism so I show only one for brevity.

private void ActionTimers_Tick(object sender){    StopTimer((TimerID)sender);    Signals timeoutSignal = Signals.NoOp;    // an enumeration of all signals in the S.M.    switch ((TimerID)sender) {       case TimerID.TransferTimer:          timeoutSignal = Signals.TimeoutTransfer;          mTransferTimedOut = true;    // used to discard the signal if necessary          break;           :    }    if (timeoutSignal != Signals.NoOp) {        mSignalQueue.Enqueue(timeoutSignal);    // of type Queue    }}

Now the Program.cs class in my NETMF I have rigged it so that the TRANSFER button generates a GPIO interrupt on the leading (going low, pressed) and trailing (going high, released) edge. That works well. So there when the interrupt occurs on the leading edge I call the TransferPressed() method on the above class, and TransferReleased() when it is released. These methods are implemented like this in the above class:

class AnyController {  :  public void TransferPressed() {     lock (this.mLock) {         mSignalQueue.Enqueue(Signals.TransferPressed);     }  }  public void TransferReleased() {      lock (this.mLock) {           StopTimer(TimerID.TransferTimer);  // asap           if (!this.mTransferTimedOut)               mSignalQueue.Enqueue(Signals.TransferReleased);           else               this.mTransferTimedOut = false;   // signal is discarded      }  }

And here is the processing of the main timer loop (not seen in the definitions) which executed every 200ms (even tried 75ms) and is in charge of processing the events and state transitions, a state machine... Here shown to the bare minimum for the purpose of clarity showing the mechanism I am using.

private void ControllerTimer_Tick(object sender){     Signals rxsignal = Signals.NoOp;     if (mSignalQueue.Count > 0)         rxsignal = (Signals)mSignalQueue.Dequeue();     switch (this.mState)     {         case States.SomeStateA:              if (rxsignal == Signals.TransferPressed) {                   StartTimer(TimerID.TransferTimer, 0, 2000);  // no delay, 2000ms period              }              else if (rxsignal == Signals.TransferReleased) {                   StopTimer(TimerID.TransferTimer);                   Swap();   // does action related to pressing less than 2 secs              }              else if (rxsignal == Signals.TimeoutReleased) {                   mState = States.OtherState;              }              break;     } // switch state}

That may deserve some extra explanation. The Program NETMF class rigged the GPIO to cauase an interrupt on the leading (going low, pressed) and trailing (going high, released) edges of the GPIO and that is detected properly. When that detects a button pressed associated to that GPIO (The TRANSFER button) it invokes the TransferPressed() public method in the AnyController class. That in turn ALWAYS queues the TransferPressed signal into the signal queue.

Now, as I indicated in the OP, if the button is pressed less than 2 seconds it does the standard action, in this case Swap() and remains on the same state. If on the other hand the button is pressed more than 2 seconds the ActionTimers_Tick() event handler would STOP the one shot timer that times the button press AND raises the timeout by putting the TimeoutTransfer signal on the signal queue. It also flags that it has timed out on the mTimedoutTransfer.

So, why is that you may ask? well, when the button is pressed more than two seconds the TransferTimeout signal is on the queue, since the button was pressed for more than 2 seconds, the next time in the main processing loop (ControllerTimer_Tick()) it will initiate a state transition. That means that in that particular case the release of the Transfer button would happen AFTER the timeout, and I don't want that release event (related to the timeout) to be passed to the signal queue because it would cause the new state to pop back to the original state (not show) because it also processes the Transfer button. So, what I do in AnyController.TransferReleased() is that IF the mTimedoutTransfer boolean is set then the signal is discarded (note, there might be another press/release pair on the new state), if it is not set (not timed out) then the TransferRelased signal is put on the queue.

So, that is the scheme but the problem as I mentioned is that these timers seem to  be working at a frequency of Terahertz or something like that because even if I set the timer to expire at a period of 2000 ms (2,000 ms == 2 secs) and have a time between press/release of MUCH LESS than 2 seconds (not even close, even less than a second) the timer times out first than the release and TransferTimeout signal is processed.

BTW I added a few Debug.Print() statements to the timer code, first with the standard date format and got that the Start, Stop AND Timeout occurred on the same second (34). 

Then I went on to be more accurate and instead print the Milliseconds property of DateTime.Now and this is what I got:

ID_PORT_XFR pressed> TransferPressedXFER TMR Start 663XFER TMR Stop 665XFER TMR TimedOut 665> TimeoutTransfer

The ID_PORT_XFR pressed output was produced by the Program class on its GPIO Interrupt method. The > TransferPressed/TimeoutTransfer output was produced by the main processing loop (ControllerTimer_Tick()) when it gets the signal from the queue.

So that confirms that the base frequency of the timer is running at the speed of light where a millisecond is much much much shorter. Where do I set those base timing things as applicable to the Netduino Plus 2 board?

I am convinced it has to do with the base timer time cycle. As you can see from the debug output that while the timer has been programmed for a time period of 2,000 ms (2 secs) it is expiring (timed out) in three (3) milliseconds, that is quite a difference.

ID_PORT_XFR pressed 582TransferPressed 586> TransferPressedXFER TMR Start 591XFER TMR Stop 593XFER TMR TimedOut 593> TimeoutTransfer 596

From this latest timing, we have the following with the time given in milliseconds:

@ 582ms the Program class receives a GPIO Interrupt signaling the TRANSFER button was pressed

@ 586ms the Controller class' TransferPressed() method is called, it puts TransferPressed signal into the queue

@ 591ms the Controller class' main loop (state machine) receives the TransferPressed signal and starts the timer for 2,000 milliseconds

@ 593ms the Controller class' ActionTimers_Tick() handler receives the timeout and stops the 2,000 ms timer and the

                TransferTimeout signal is put out on the queue

@ 596ms the Controller class' main loop (state machine) receives the TransferTimeout signal and processes it.

Also tried by adding this in my emulator.config of the custom emulator project (the code shown above is all in the .NET MF project, not the emulator).

<Emulator>  <Types>    <TimingServices>Microsoft.SPOT.Emulator.Time.TimingServices</TimingServices>  </Types>  <EmulatorComponents>     <TimingServices id="NetduinoPlus2_TimingSvcs">        <SystemClockFrequency>168000000</SystemClockFrequency>     </TimingServices>  </EmulatorComponents></Emulator>

did that in hope that the emulator that runs my project would adjust its timing to 168MHz (Netduino Plus 2) but the result is the same...

I can follow what NakChak suggests, using the timestamp (in ticks since powerup) provided on the interrupt callback and pass that down the chain and then compare the initial timestamp with the last (release) timestamp to check if it was more than 2000 ms but that would simply be a workaround, the underlying System.Timer should provide realistic, reliable timing services.

Though I could not measure very accurately it appears to me (using a chronometer) that a press/release period of about 2 seconds translates to a NETMF "millisecond" difference of 331 against the expected 2,000.

Changing my SystemClockFrequency to 1.000.000 resulted in the timestamps (passed in the interrupt) to be more realistic though with it a 3./ second push is seen as 2 seconds but the Timer keeps on expiring right away...

I suppose the current 4.3 fits well in the Netduino Plus 2, right? Is that the lowest platform the 4.3 NETMF fits?

How do I know if my application is within the RAM/Code limits of Netduino Plus 2?

Use the intellisense help to see the arguments expected by your method.

I had to dump the entire solution and create a new one from scratch to get rid of this error...

You need to be more specific as to what you want to learn from it. There are tons of things you can have in the LCD library and a lot of it also depends on the LCD hardware capabilities (pixel depth, color/b&w, dimensions, character set, etc.)

I recently read that the Netduino Plus 2 (the device I have in mind and am developing for) has a certain amount of Flash Memory available for use by the application.

Since my application needs to persist in memory (across boot cycles) several values, I would like to know IF I can really use that flash memory and how I can access it from my NETMF application.