ziggurat29

The loss of red squiggles

oft gives one the giggles,

but the code that does run

is really more fun.

Good luck, have fun debugging!

some things:

*  Is 'Light_State' reachable in Status()?  Because it is a local in Lights().  So it shouldn't compile as you have shown.  You could define Light_State as a (static) member variable, like your did with the serialA and serialB; then it will be reachable.

*  Light_State is not a boolean itself, it's an OutputPort, but you need to call Read().  (much like you don't assign, but you call Write()).  So your line 63 would read something like:

  if ( Light_State.Read() )

*  you initialized LIght_State on D2, but this will presumably conflict with serialB when you get around to implementing that, which uses that line as COM2 RXD.

*  you're creating and opening your serial port in Status().  Normally you wouldn't do this.  Normally you'd do that early in the program, and then just use the open instance later.  As written here, it goes out-of-scope at the end of Status().  But this doesn't mean the hardware is actually released at that time, because you did not close and (more importantly) Dispose().  So the next time you go into Status(), you might find you can't open it.

HTH

It is interesting, I have never had to do this, and I can attest that I use a dns name to reach my server from the netduino (which is on the Internet, not the lan), and I use dhcp to get all my config.  I would think that would mean that I must be using dns to resolve the name, and that since there is no specific configuration of the dns server name, that it must have come in through dhcp, automatically, without explicit programmatic action.  FWIW I am using 4.2.2.1.

Your mention that, at work, that you find that "the DNS entry is my home router, not my work DNS" is interesting.  What do you mean by that?  There's not a power-cycle-to-power-cycle persistent storage of a dynamically assigned dns name.

crypto is a stub in the netduino firmware; you'll need to do it managed (or make your own firmware).

I have had mostly success using the BouncyCastle implementation.  But you cant just build bouncy castle and use, you'll need to find and pull out the particular modules you need.  It can be tedious, but when you're done you're done.

You'll sometimes need to be judicious in what alternative implementation you use, or the build tools will croak (e.g., I had to use AES 'light', because the 'fast' will not compile).  In particular, the 'metadata processor' will croak if you have large constant data.  For example, for me the sboxes of the fast implementations pushed it over the edge.

I should also mention that, in my case, I did not use asymmetric crypto; I used aes, sha, hmac, and dealt with key management the old fashioned way.  So structly I cannot attest that you can successfully integrate the asymmetric stuff from personal experience, but it is worth a try.

yes, reverse the header pins on your board and mount the np2 'upside down' with respect to what you are originally thinking.