The "Microsoft Extensible Emulator" is part of the Visual Studio IDE AFAIK. But it is great in allowing you to mimick your end device when you still don't have hardware (I have a design but I am testing some concepts).

The MAX7219 emulator code I wrote myself because I wanted to see the state of the chip during debugging (just as if I had a real emulator pOD on a real device) but I have to fix it based on your comments (the NoOp). However, it goes only as far as keeping track of the register values, state and notifying the UI to update the UI accordingly. It does not include a real 7-segment emulator that would ideally read the status of the A-G,DP segment output pins and display accordingly. Perhaps some day I add it, in the meantimeI have to fix the emulator code and find some suppliers for my 7-segment displays

Thanks for the clarification, I will change my firmware, I guess you recommed doing the Chip Select (SS) manually rather than letting the .NET Microframework's SPI software do it, right?

By emulation I meant the .NET Extensible Emulator where you create a user interface to mimick your device. That's what I did, created a winform to mimick the faceplate of my device where I could interact with buttons (pushbuttons and a dual concentric encoder) as well as a separate winform that would show me in real time the current state of all registers of the "emulated" MAX7219.

I am also using a 7219 but since I don't have hardware yet (waiting for the official 4.3) I have worked with emulation by using the Extensible Emulator. Now I read this so to save me some suffering could you clarify this for me to make sure I got it right?

• I understood from the 7219 that the NOOP was used to shift to the slave 7219 but since it was not explicitely mentioned I was sending the NoOP as the first 2 bytes: (a) NOOP(empty_data) and then ( COMMAND(value). However, reading this thread it seems I had it wrong, so you say IF I want to write to the slave 7219 I would send the COMMAND(value) I need and then follow it by NOOP(dummy)  (two 16 byte transactions but with the NOOP in the 2nd transaction), right?
• Commands are always 16 bits, address plus data, right?
• Emulation is not the same as real hardware, according to what I read here, letting the MF SPI s/w do the Loading won't work in this setup right? so you recommend doing the SS (Chip Select/Load) manually making it active before the 2 bytes are sent and inactive AFTER the two bytes are sent.
• A write to the slave 7219 would require only one LOAD activation/deactivation for the 32 bytes (Command[value] + NoOp[dummy]) OR do it for every 16-bit (2 byte) transaction?

Another problem I just noticed in my setup is that each 7219 drove a 4+2 digit setup (better than 6 individual digits) but unfortunately the 4-digit 7Segment uses 35mA and the 2-digit 7Segment uses 25mA which I guess wouldn't work well with a single Iset resistor (one set would look dimmer than the other). So I will have to probably drive the two 4-digit 7Segments by the main (same current limit) and the two 2-digit 7Segments by the slave 7219 (same current) with the complication that writing a value on either set would require two transactions (one for main to fill the first 4 digits and one for slave to fill the remaining decimal digits) :*(

That's the firmware that is on the netduino device or the one that one installs aside VS.2013 (SecretLabs*.dll) ?

Still having problems trying to get my desktop application's Broadcast UDP packets to be received by the emulated netduino on the emulator. Trying to isolate the problem, are there any known issues like "Emulator doesn't have Ethernet connection" ? Is there a way to simulate ethernet cable (un)plugging in the emulator?

In doing my netduino networking code (UDP & TCP) I tried something that was suggested back in 4.2 to detect when the connection is broken due to the inherent limitations of the NETMF.

It was proposed to use the NetworkInformation.NetworkAvailabilityChanged event handler. Basically one defines the delegate method and in there depending on the e.IsAvailable property one would stop or resume network operations (tx/rx).

Microsoft.SPOT.Net.NetworkInformation.NetworkChange.NetworkAvailabilityChanged += new Microsoft.SPOT.Net.NetworkInformation.NetworkAvailabilityChangedEventHandler(NetworkAvailabilityChangedHandler);

I have no hardware yet so I was trying it on the emulator which is supposed to have already a "connection" to the host system. I placed a breakpoint on that event handler method but it never gets called.

private void NetworkAvailabilityChangedHandler(object sender, Microsoft.SPOT.Net.NetworkInformation.NetworkAvailabilityEventArgs e)        {            lock (this.threadLock)            {                if (e.IsAvailable)                {                    StartServices();                }                else                {                    StopServices();                }            }        }

Anybody knows whether these issues are really resolved in 4.3?

Just found out there is no Async Send in the NETMF Socket class :-( anyway, it got me on the way.

Hey thank you so much Chris!!!! somehow my .NETMF project didn't have the System.dll in the list of references and as far as I know I did not remove it. Just added it and finally I have System.Net and the Socket class (plus related gadgets).

One last question though... I have seen some .NETMF examples out there using UdpClient that is what got me into trying to use TcpClient & UdpClient. Will now get on to my Sockets code, thank you very much.

My netduino application *needs* to communicate with the server running on the PC to exchange information. This communication needs to be fast. I was told USB was not "possible" unless I implemented the whole USB stack which I must say is q HUGE task (I have seen some of the sources back in 2001). The usual serial communication is also not desirable because it doesn't fit into my scheme of designs.

So that leaves the ethernet connection. On the server side I already implemented the TCP server that listens for commands as well as the UDP that sends the "who is out there" broadcasts (unless somebody has a better idea).

Now, when I wanted to code my TCP & UDP parts in the .NET Microframework project using TcpClient and UdpClient I found them nowhere. Found some examples on the internet that claims it is present in the mfdpwsextensions.dll appearing under the System.Ext.Net namespace but neither adding a reference to that DLL nor the Microsoft.SPOT.Hardware.Net give me anything of use, not even the plain Socket.

What am I missing, can somebody help me out with this? I need them soon.

Well now that I have been told that USB is not possible without extensive work, Serial is not a possibility either because I don't want to use a legacy system and that the ethernet connection has been suggested as the best....

I got my desktop proxy software developed, I got my custom emulator developed and running and also my .NETMF application to run on the Netduino Plus 2. But as it turns out (?) there is no support for UDP or TCP in the 4.3 SDK ?! can anybody shed some light into the subject?

In my .NETMF application I need an UDP listener that will exclusively listen for UDP broadcasts from the desktop application, this is basically to respond to the "WHO is out there" question because there is no guarantee whether the embedded device would start running before or after the Desktop proxy "server". I am using VS.2012 with .NETMF 4.3.

My .NETMF application then mostly uses a TCP connection to the above named desktop proxy server to send commands and receive a response.

When I try to write ANY net code in the NETMF the network communications classes are missing. I added a reference to Microsoft.SPOT.Net but that doesn't have anything of use. I also tried the MFDWSEXTENSIONS.DLL suggested in the MSDN but also, nothing of use.

I was looking for TcpClient and UdpClient .NET classes but I can't find them. I tried to then make something equivalent based on the Socket class but also, not available anywhere. I am stuck.

I installed the 4.3 SDK and needed to use the UdpClient. According to the MSDN it is in the System.Ext.Net namespace of mfpwsextensions.dll (something like that) but when I add that reference I don't see that namespace. Can't find UdpClient anywhere.

I think my NETMF software is nearly on its last phases of development, I just hope it fits in Netduino Plus 2. Anyway, my NETMF application is supposed to run on the Netduino Plus 2 hardware and it would communicate with a service on the desktop to get some live information.

So that means the Netduino would send a request to the desktop and get some data in return. Since I haven't had the chance to try that on real hardware I would like to know what you can suggest me for this, USB or Ethernet? and what sort of roundtrip communication times I should be expecting.

My .NETMF state machine loop runs every 200ms and the service on the desktop would also be updating information around the same rate perhaps even a bit slower (like 1Hz).

Quite true, the flash is not the best place. Does the Netduino Plus 2 comes with a built-in SD Card? and if so, is there some sample code how I can access it? I simply need to read/write configuration data, nothing else, no big files,etc. The problem there would be that given the sizes of SD cards, most of its space would be wasted.

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.

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 had to dump the entire solution and create a new one from scratch to get rid of this error...

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

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

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

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...

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.

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.

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?

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.