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.

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.

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

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!

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.

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.

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?

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.

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

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.

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.

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

Anybody knows whether these issues are really resolved in 4.3?

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

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.

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"

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 suppose the current 4.3 fits well in the Netduino Plus 2, right? Is that the lowest platform the 4.3 NETMF fits?

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

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();                }            }        }

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.

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.

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

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