Note: This article is an installment in a series about building a plant light controller (and beyond) on the Netduino microcontroller platform.  For previous articles in the series, click here.

If you’ve made the switch to programming with .Net Micro Framework devices like the Netduino and GHI Panda, you inevitably find yourself asking the question: “What the heck do I do with all my Arduinos?”  They have a minimalistic IDE and no debugger to speak of.  They make lousy cat toys and anniversary gifts. (Unless you’re receiving one, that is.)  Who needs them?

Well, actually, you do. You might think that .Net’s “managed code” runtime environment is there to usher your program past the hardware, but it’s more like a bouncer protecting the hardware from your crummy code.   It’s great that your code can’t mess with the hardware, unless you intentionally want to mess with the hardware.

I ran into this problem when trying to upgrade the Light Controller’s analog temperature sensor with a digital “one-wire” sensor.  These types of temperature sensors have become quite common, and are generally much more accurate than analog sensors. While the Netduino’s firmware doesn’t officially support the one-wire standard yet (as of Version 4.1.0 Update 6), it is available in the GHI firmware, and I was planning to incorporate it into a Panda version of the Light Controller.

Unfortunately, not all “one wire” temperature sensors are created equally, and the one I have doesn’t follow the Dallas Semicondutors / Maxim 1-wire standard. It’s a Seeed Studios Temperature and Humidity Brick (now replaced by a Twig version) , both based on the DHT11/AM2302 chipset.

The interface to this standard is well documented (quite enthusiastically documented, in fact).  As demonstrated in the Arduino sample code, communicating with the chipset requires toggling a pin high-and-low at specific sequence of microseconds.

That’s microseconds, not milliseconds.  .Net MF doesn’t let you send signals at the microsecond level.  That’s dangerous, son.  Might shoot your eye out.

Wouldn’t it be nice if we could combine the productivity of managed C# code with the versatility of the Arduino’s AVR-C code library? Mush them together somehow, with solder and duct tape.  Hmmm…

Sadly, I happened to be out of duct tape, so I turned my attention to a Serial Enabled LCD Kit that I had recently bought from Sparkfun.  I was looking to replace the parallel LCD that comes with the Seeed Grove Starter Bundle with a serial LCD to free up some pins.

I hadn’t considered the upgradable firmware on this model as a big benefit – there isn’t much that you can do with an LCD beyond the basic set of commands that all serial LCDs support.  The kit actually incorporates an ATMega328 with the Arduino bootloader — a full Arduino, essentially.  The Arduino code reads the occasional LCD update command and passes it along to the LCD.  Between LCD updates, it sits about, twiddling its thumbs, waiting for something to do.  Hmmm…

Maybe we could use the Kit’s ATMega328 as an interface to the temperature sensor?  That’s so crazy, it might just work.

The Sparkfun Serial Enabled LCD Kit

And it does work.  (Most of the time, as I explain below.)

The Sparkfun Kit’s design makes it quite easy to implement this type of project.  It breaks out the standard 5 pins used by the FTDI cable (the serial-to-USB cable I previously used with the Light Sensor’s dearly departed UART interface), and also breaks out all of the Arduino pins not used by the LCD.

The LCD interface “firmware” is just a standard Arduino program, nothing weird, so it’s easy to merge in the sample code for reading the DHT11 sensor – mostly just copy and paste.

While I was at it, I also added some code to interface to the Arduino’s built-in EEPROM memory.

So, the end result is that the Plant Light Controller can now display the humidity, a more accurate temperature, and save the settings from the menu too.

Actually, the “more accurate” temperature is debatable.  The DHT11 chip always returns temperature as an integer, and always in Celcius.  It appears to truncate the actual temperature, rather than rounding it.  So, the temperature can be off by .9C, or 1.6F.  Humidity is similarly truncated to an integer.  But, hey, I’m not complaining – at $5, Seeed’s sensor is still a steal.

Pin Assignments

From the Netduino’s standpoint, not much changes from the previous installments of this project.  All communication with the Arduino goes through the same serial pins used by the LCD interface.  However, since the LCD now talks back, we need to connect a Netduino Serial Rx pin to the Serial LCD’s Kit TX pin, which is part of the FTDI breakout on the end of the backpack’s circuit board (the right end of the photo below).  My code uses Netduino’s COM2 (pins D2 and D3) for this.

Sparkfun Serial LCD and Seeed Temperature/Humidity Sensor

From the Serial Kit’s standpoint, the following pins are used:

-          The white JST plug contains the 5V, ground and RX pins, which we connect to the 5V, ground and TX (D3) pins of the Netduino

-          The TX pin at the end of the board is connected to the RX pin (D2) of the Netduino

-          The breakout pins at the bottom of the Serial Kit are used to connect to the Temperature/Humidity Sensor: specifically, the 5V, Ground and Analog 0 pins.

User Interface

Not much has changed here from the last installment of the project, either.  As shown in the photo below, I’ve used the leftover space on the Temperature row of the LCD to display the humidity instead of the Sunset time.

The number in parentheses is the temperature value from the sensor – the other temperature value is from the analog sensor, as added to the project in an earlier installment.  Which one is more accurate depends on how well your analog sensor is behaving – as mentioned, the digital sensor’s temperature can be off by 0.9C, while my analog sensor is apparently a little high.

Demonic LCD displaying strangely moderate temperature and humidity

I’ve also added a couple of new items to the “Timers” section of the menu, allowing you to disable the plant light timer.  This became necessary once I started saving the menu settings to EEPROM, since that ruined the handy Disable-the-timer-by-turning-the-gadget-off-and-on ™ feature.

Programmer Show And Tell

The Serial LCD Kit is now the 4^th LCD interface supported by the code, joining the parallel LCD, the Matrix Orbital Serial LCD, and the Sparkfun Serial Backpack.  I considered making the LCD Kit fully compatible with the Sparkfun Backpack’s command set by changing the Arduino “firmware” code.  The 2 command sets are quite similar, differing only when in the cursor positioning and backlight control commands.

However, I like the Serial LCD Kit’s API better, so I subclassed the Backpack’s clsLCD_SF class and overrode the commands that differed.

Subclassing is supported the same way in .Net Micro Framework as in the full blown .Net:

public class clsLCD_SFKit : clsLCD_SF

Overriding a class method is also done the standard C#, using the “new” keyword.  So, to replace the cursor positioning method with code that works with the LCD Kit’s firmware:

new public void SelectLine(byte intLine, bool blnClearLine)

I added some new commands to the LCD class, used to receive data from the Serial Kit’s Arduino.  Since its unlikely that the other LCDs are going to do much talking, I didn’t add these  methods to the common ILCD Interface.  Instead, when the main program wants to check to see if the LCD is of the Serial Kit variety, it uses the “is” keyword, again just like in the full .Net Framework:

if (lcd is clsLCD_SFKit)
{
// get the humidity
((clsLCD_SFKit)lcd).RequestHumidityAndTemp();

Data from the Serial Kit comes in through the Netduino’s serial RX pin, just like we used to read terminal commands through the UART interface.  So much like it, in fact, that I used the same event handler.  When a humidity reading or EEPROM setting comes back from the Serial Kit, the code raises a uart_Command event, as described  back in the Time and Weather article.

There is actually one big difference between the Serial Kit’s behaviour and the UART Telnet terminal, though.  The Telnet terminal could send us a command at any time, so an asynchronous interface using an event was necessary.  The LCD, on the other hand, sends data only when we ask for it.  It would have been possible, therefore, to read the data synchronously after we send the request, using code like the following:

public void RequestHumidityAndTemp()
{
byte[] command = new byte[2];
command[0] = CMD_SPECIAL;
command[1] = 71;
lcd.Write(command, 0, command.Length);
// give the LCD time to retrieve the data
Thread.Sleep(1000);
intBytesRead = lcd.Read(readBuffer, intBufferOffset, lcd.BytesToRead);
. . .
}

This has the advantage of making the context of the data we are reading obvious, but the disadvantage of introducing timing problems.  What if the LCD doesn’t respond fast enough, or the response isn’t received at all?  How long should we wait for the LCD to respond, and at what point does the Netduino decide that a response isn’t going to be received, and carries on?

Asynchronous communication does away with that problem.  In fact, you can unplug the LCD altogether, and the Netduino will faithfully carry on with its other duties, turning on and off the plant light.  It won’t receive any humidity readings, and its request to save menu settings won’t be performed (good luck using the menu without an LCD, by the way), but the Netduino doesn’t notice.

The downside of asynchronous communication is that data doesn’t necessarily come back when you want it.  You’ll see this when you first plug in the Netduino – although it requests the humidity from the Arduinio during startup, the response may not be received before the first “display the temperature” timer fires.  As a result, it may take another 30 seconds (the interval of the temperature timer) before the humidity is displayed.

The code I added to the Arduino to save settings to EEPROM takes advantage of the Arduino EEPROM library – the library makes it simple.  One minor twist is how to handle the very first interaction between Netduino and Arduino.  The Arduino has no idea whether it has any settings saved – it just returns whatever happens to be in the address you’ve requested.  The first time, this will be 0s.  So, all settings are saved as non-zero values: I add 1 to the values where necessary.

One other design decision worth mentioning is the issue of which settings to save, and when to save them.  I decided to save the date, but not the time, since it’s likely that the date will be unchanged, or very slightly changed, when you power the Netduino back on, but the time will almost certainly have changed, perhaps by hours.

The other downside of saving the time is that you’d have to do it every minute, putting wear and tear on the EEPROM.  It is best to write to EEPROM as little as possible: in this case, only when the user changes a setting in the menu.

Fortunately, I already had a callback method for responding to the user’s menu selections (as described in the Ordering Off the Menu article), so I added code like the following to that method.

static void setValueFromMenu(string menuCode, Int16 intValue)
{
. . .
if (menuCode == "_CELCIUS")
{
. . .
SaveSettingToEEPROM(ADDR_TEMP_FORMAT, 2); // 2 means Celcius

With Friends Like That…

This configuration actually did a good job of proving the point about unmanaged code: it’s awfully easy to crash the microcontroller when running it.

When I got things up and running, I found that the LCD would freeze at some point, generally a few hours after powering it on.  The Netduino soldiered on, faithfully turning the plant light off and on, so clearly it was the Arduino that dropped the ball.

Commenting out the code that requests the temperature and humidity reading caused the problem to go away, so whatever was going wrong involved the DHT11 interface.

The right thing to do would be to debug the Arduino’s DHT11 code, but the easy thing to do was to just “reboot” the Arduino on a regular basis.

Crude, but effective.  I’ve had this configuration running for over a month now, and it works like a charm.

The “rebooting” is done by using a transistor to turn the Arduino’s power off and on.  This requires a hardware change: instead of connecting the Sparkfun LCD Kit’s ground pin directly to the Netduino, I used a small breadboard to route the connection through a transistor.  The transistor is controlled using the D12 pin.

Specifically, the configuration I used (shown in the photo) is:

-          Collector pin of 2N2222 transistor to LCD Kit’s ground

-          Emitter pin of 2N2222 to Netduino ground

-          Base pin of 2N2222 to D12 pin of Netduino

-         Base pin of 2N2222 to ground through pushbutton – this can be used to manually boot the LCD Kit Arduino if necessary

Arduino Reset Circuit

The Arduino is powered up during the Netduino code’s startup:

arduino = new OutputPort(SecretLabs.NETMF.Hardware.Netduino.Pins.GPIO_PIN_D12, false);
arduino.Write(true); // turn on Arduino
Thread.Sleep(2000); // give Arduino a chance to do its initialization
lcd = new clsLCD_SFKit(SerialPorts.COM2, 9600, 2, 16);

I added a new method to reset the power to the LCD Kit’s Arduino by temporarily setting D12 low:

static void ToggleArduino()
{
arduino.Write(false);
Thread.Sleep(1000);
arduino.Write(true);
// let Arduino do its initialization
Thread.Sleep(2000);
// restore the brightness setting
lcd.SetBrightness(bytBrightness);

The new method is called when the Netduino hasn’t received a response from the Arduino for over an hour.  It asks for the temperature and humidity every 30 seconds, so an hour is obviously lenient.  If you need the temperature/humidity readings to be more reliable, you should shorten this interval:

// if we haven't received any data from the Arduino for over an hour, reboot it
if (datlastArduinoRead != DateTime.MinValue)
if (DateTime.Now.Subtract(datlastArduinoRead).Hours > 0
datlastArduinoRead = DateTime.MinValue; // prevent another reboot
ToggleArduino();

The voltage out of the Netduino’s digital pins is 5 volts, so why bother with the transistor – why not power the Arduino directly from D12?  The problem is current: the Netduino (and pretty much every microcontroller under the sun) only allows a trickle of current to flow through its pins.  You can power an LED with it, but anything more power hungry needs to get its voltage another way.

Wrapping Up

This installment of the Light Controller project is admittedly off on somewhat of a tangent: connecting a temperature sensor to a Netduino via a Serial LCD interface is not a common configuration.

However, offloading some of the Netduino’s responsibilities onto another processor is actually quite a handy technique.  There are a lot of microcontrollers out there, each with its own libraries of code capable of doing some things that a Netduino can’t (yet), so when looking to add a new feature it’s smart to think “outside the box”.

One other improvement I’ve made to the project is to put the source code into a proper repository, rather than just linking each article to a .zip file.  I’ve created a Google Code project named gigamega-micro.

You can get the code for each of my Netduino articles (starting with Let There Be Light) in 2 ways:

-          If you are familiar with Subversion use SVN to get the latest code.  If you want the older version of the code to match one of the past articles, get the corresponding revision (see the revision list here http://code.google.com/p/gigamega-micro/source/list)

-          Or, download the good old .zip file from the Downloads section of the Google Code project. Here is a direct link to the code for this article.

The modified Arduino code for the Sparkfun LCD Kit can also be found in the Downloads section of the Google Code page (direct link to .zip file).  90% of that code is copied from the original Sparkfun firmware or from Sheepdog Software’s DHT11 page.  I’ve left the original authors’ headers in the code.

Don’t worry, I haven’t forgotten the “road map” of hooking the Netduino up to an XBee.  We’ll get back on track in a future article.

The source code for this article can be downloaded here: LightControllerWithMenu.zip.

This is the 5th in a series of projects for the Netduino and Seeed Studio’s Grove Starter Bundle.

The first four articles in the series were:

1. Netduino Enters the Grove
2. Netduino: Time and Weather
3. Netduino: Let There Be Light
4. Netduino: Here Comes The Night

Today, my friends, the voice of the people has been heard, and the reign of an oppressive dictator shall finally end.

For too long (about a month-and-a-half, to be specific, since my Netduino: Time and Weather post), we’ve had only one way to enter the date and time and other settings: the user-hostile serial connection. It forced us to drag our notebooks over to the Netduino, open serial terminals, enter obscure commands, and other things too loathsome to mention. Is this any way to live?

The people want freedom. The freedom to just walk up to a Netduino and set the date and time at the click of a button. The freedom to choose Celcius or Fahrenheit, at the click of a button.  (Though only imperialists use Fahrenheit, you know.) The freedom to turn off the LCD backlight – well, you get the idea.

In short, the people want a menu system.

This new menu system will follow the orders of one person only: you the user. Well, technically, also me, the programmer. And if you choose to fix my bugs customize my code, then also you (again), the programmer. Oh, and the reviled serial connection is going to remain in, um, a strictly unofficial capacity to ensure an orderly transition.

Pin Assignments

The pin assignments are unchanged from the previous blog post, Netduino: Here Comes The Night. The changes in this installment of the project are purely software.

User Interface

To invoke the snazzy new menu system, take the Red pill — I mean, press the Red button. (For those who aren’t using the Seeed Grove hardware system, the red button is connected to D7, and the green to D8. In Grove terminology, this is a button “twig” connected to the D7/D8 plug on the Grove stem).

Throughout the menu system, the buttons are used as follows (aaah – a user manual!):

• Red button click – scroll down
• Green button click – scroll up
• Red button double-click – select a menu item
• Green button double-click – exit the current menu

Some of the menus allow you to change a numeric value, like the hour of the day. In these menus:

• Red button click – increase the value by 1
• Green button click- decrease the value by 1
• Red or Green button press and hold – repeatedly increase or decrease the value of the number
• Red button double-click – save the current value of the number and exit the current menu
• Green button double-click – exit the current menu without saving

Programmer Show And Tell

The heart of this update to the project, and the part you are most likely to want to change, is the menu configuration. I didn’t want to reinvent the wheel, so I carefully looked through the work that had already been done on creating a menu system for .Net Micro Framework devices.  When I couldn’t find what I wanted on the first page of the Google results, I got annoyed and reinvented the wheel.

Near the top of Program.cs, you’ll find the following array definition:

static string[] strMenuItems = new string[] {
"1", "Date `yy`-`MM`-`dd`", "1-1",
"1", "Time `HH`:`mm`", "2-1",
"1", "Timers", "3-1",
"1", "Settings", "4-1",
"1-1", "Year `yy`", "_UD-`yy`",
"1-1", "Month `MM`", "_UD-`MM`",
"1-1", "Day `dd`", "_UD-`dd`",
"2-1", "Hour `HH`", "_UD-`HH`",
"2-1", "Min `mm`", "_UD-`mm`",
"3-1", "Light On `HH:mm+`", "3-2",
"3-1", "Light Off `HH:mm-`", "3-3",
"3-2", "Manual `HH:mm+`", "3-2-1",
"3-2", "Sunset `HH:mm_`", "_SUNSET",
"3-3", "Manual `HH:mm-`", "3-3-1",
"3-3", "Sunrise `HH:mm*`", "_SUNRISE",
"3-2-1", "Hour `HH+`", "_UD-`HH+`",
"3-2-1", "Min `mm+`", "_UD-`mm+`",
"3-3-1", "Hour `HH-`", "_UD-`HH-`",
"3-3-1", "Min `mm-`", "_UD-`mm-`",
"4-1", "Temp Fmt `TD`", "4-1-1",
"4-1", "Backlight `LB`", "_BACKLITE",
"4-1", "Brightness `BR`", "_UD-`BR`",
"4-1-1", "Celcius", "_CELCIUS",
"4-1-1", "Fahrenheit", "_FAHR"
};

One thing you’ll notice right away is that this should be a 2 dimensional array (i.e. string[,]), but isn’t. Oddly, there is no such thing as a 2-dimensional array in the .Net Micro Framework. Instead, you can have arrays of arrays (e.g. string[][] strMenuItems = new string[20][], where the 2nd-level array can be of a different size in each element of the main array. This weirded me out, so I went with a 1-dimensional array instead.

Each menu item consists of 3 strings:
- A menu ID – this must be the same for each item in that level of the menu
- A caption, which can contain embedded keywords delimited with the backquote character (`)
- The result of selecting (double-clicking) that menu item, which can be the ID of a submenu to display, or an action (actions are prefixed with an underscore).

So, for example, the first level menu has 4 items that appear on the LCD like this:

Date 11-02-14
Time 18:05
Timers
Tools

The first 2 items contain keywords that are replaced at run-time with the current date and time.
Selecting the first item in this menu displays sub-menu “1-1”, which looks like

Year 11
Month 02
Day 14

Selecting any of these menus selects an action, such as “_UD-`yy`” — this displays an “Up/Down” menu for setting the year. More on that below.

I’ve added a new class to the project, clsLCDMenu, and given it sole responsibility for displaying the menu and handling all button input. This class is intended to be a generalized menu handler: it knows  how to display lines of a menu and allow the user to navigate through the menu using the buttons, but it knows nothing about how to handle the actions selected by the user.

This design results in a fairly extendable and reusable menu. There are no hard-coded limits on the # of elements in a menu of the # of levels of submenus. To add new menu items, or create an entirely different menu system, I won’t have to change any of the code in clsLCDMenu. Instead, I just change the strMenuItems array, above, and add some “action handler” logic to some callback methods in Program.cs, described below.

Since clsLCDMenu “owns” the LCD and buttons when the menu is up, I have to make sure that the existing code never tries to write to the LCD or respond to a button click when the menu is up. I do this by turning off the timers and “unhooking” the button event handlers, as follows:

static void launchMenu()
{
  // turn off the timers that update the display
  timerTemperature.Dispose();
 timerTime.Dispose();

  //unhook the button event handlers
  buttonRed.OnInterrupt -= buttonRed_OnInterrupt;
  buttonGreen.OnInterrupt -= buttonGreen_OnInterrupt;

  // buttonGreen = up, buttonRed = down
  menu = new clsLCDMenu(strMenuItems, lcd, buttonGreen, buttonRed, getStringForMenu, getValuesForMenu,     setValueFromMenu);
}

The “-=” statement that unhooks the event handlers will look freaky to anyone who hasn’t encountered it in .Net before, since neither side of the “-=” is a numeric value. This syntax removes the main class’s button event handlers from a virtual “list” of handlers for the event. It isn’t all that commonly used in .Net, since event handlers are automatically “unhooked” when the class that contains the event handlers is destroyed, such as when a form is closed.

The constructor for the clsLCDMenu class looks like this:

public clsLCDMenu(string[] strItems, ILCD lcd, InterruptPort buttonUp, InterruptPort buttonDown,
MenuCallback getCaption, MenuGetValue getValue, MenuSetValue setValue)

The caller passes a reference to the LCD and “up” (green) and “down” (red) buttons, along with 3 callback methods. The callback methods add the “business logic” to the menu system, if you will: they fill in the keywords in the menu captions, and handle the menu actions. Specifically, there are 3 types of callbacks:

• MenuCallback – gets passed a menu caption containing keywords (e.g. “Light On `HH:mm+`”), and passes back the caption to be displayed to the user (e.g. Light On 20:30”.
• MenuGetValue – gets passed an “up/down” menu definition (e.g. “_UD-`MM`”) and passes back the current value, minimum value and maximum value to be used for the up/down menu.
• MenuSetValue – gets passed an action that needs to be taken: either the changed value from an up/down menu (e.g. the user has changed the hour setting on the clock), or some other action such as “_SUNSET” (the user has set the “Light On” timer to sunset.)

Callback methods in .Net require 2 things:
1) A “delegate” definition. For example, the definitions of the 3 callback methods used by clsLCDMenu are:

public delegate string MenuCallback(string s);
public delegate bool MenuGetValue(string menuType, out Int16 start, out Int16 min, out Int16 max, out byte increment);
public delegate void MenuSetValue(string menuType, Int16 value);

2) The actual method to be executed when the callback is invoked. References to these 3 methods are passed to the clsLCDMenu constructor by the launchMenu() method, shown earlier. The constructor saves these references in variables of the “delegate” type. For example, the MenuCallback is saved by clsLCDMenu as:

private MenuCallback menuGetCaption;

…

public clsLCDMenu(string[] strItems, ILCD lcd, InterruptPort buttonUp, InterruptPort buttonDown,
MenuCallback getCaption, MenuGetValue getValue, MenuSetValue setValue)

…

this.menuGetCaption = getCaption;

When clsLCDMenu needs to call one of the callback methods, it uses its reference variable, calling it as if it was a method. For example:

string strMenuText = menuGetCaption(((menuItem)lstMenu[intMenu]).StrCaption);

I won’t give an explanation of what the callback methods do. They are actually quite straightforward: just a bunch of “if” and “switch” statements that examine the parms to figure out what kind of data they are dealing with, then returning the corresponding settings or taking the corresponding action.

Two other features that are worth explaining, though, are the buttons’ double-click and auto-repeat handlers. These both rely on timers, which are a pleasure to work with in .Net compared to the alternatives that you need to hack together in other microcontroller platforms.

The double-click is a click followed by another click (duh). As every new (or elderly) PC user learns the hard way, the difference between a double-click and 2 single clicks is the amount of time in between.

So, the code which handles the first click sets a timer. If the timer goes off before another click occurs, then that was a single click, and the code handles it accordingly. If a second click occurs before the timer expires, that’s a double click.

The code which sets the double-click timer is:

timerButtonDown = new Timer(new TimerCallback(buttonClick), "Down", DOUBLECLICK_DELAY, -1);

The DOUBLECLICK_DELAY is a constant, in milliseconds, which determines how fast Granny has to move to pull off a double-click. I ended up setting it to 400 ms, which was short enough that I didn’t accidentally double-click when I wanted to make 2 separate clicks.

The “buttonClick” timer event handler now contains the logic that was previously in the button interrupt event: a click isn’t a click until the timer goes off:

private void buttonClick(object data)
{
  if ((string)data == "Down")
  {
    // cancel the button click timer
    if (timerButtonDown == null)
    {
      // oops, someone already cancelled it, so we should ignore it
      return;
    }
    timerButtonDown.Dispose();
    timerButtonDown = null;
    blnButtonDownClicked = false; // no longer waiting for double-click
    goDown();

You’ll notice some seemingly unnecessary null handling.  Here’s the thing…

If the user clicks the button a second time, then we want to cancel this timer event: it’s a double-click action, not a single-click. In theory, disposing a timer should cancel the timer event. However, when testing that code I found that double-clicking would often result in both the double-click and single-click action being performed, since the timer event wasn’t cancelled by disposing the timer object. Setting the timer to null didn’t cancel the event either.

So, I ended up adding code to the timer event to see if the timer had been set to null, and aborting the event if it had. Crude, but effective, and a lot more reliable than polling the button a la Arduino.

To implement button auto-repeat, I used the button “push-and-hold” timer (as described in the Netduino: Let There Be Light article), and had it re-invoke the timer if the button was still being held down:

private void buttonHold(object data)
{
  if ((string)data == "Down")
  {
  …
  if (!buttonDown.Read())
  {
    // not being held down anymore
    return;
  }
  intDownRepeatCount += 1;
  int delay = BUTTONREPEAT_DELAY;
  if (intDownRepeatCount >= 4)
    delay = TURBOREPEAT_DELAY;
    timerButtonDown = new Timer(new TimerCallback(buttonHold), "Down", delay, -1);

As you can see, I implemented auto-repeat the same way as most alarm clocks: the number advances relatively slowly at first (BUTTONREPEAT_DELAY is 500 ms), then more quickly after a couple of seconds (TURBOREPEAT_DELAY) is 200 ms.

Next Steps

At this point in the project, we have a reasonably functional plant light controller (and clock and temperature display).

Although using the new menu to set the date and time is definitely a lot more user friendly than the deposed serial port system (boo, hiss), it’s still a pain to have to re-enter each menu setting after a power outage. So, a battery backup and/or saving the menu settings to flash memory would be a nice feature, and I’ll definitely be adding that at some point.

However, the more exciting enhancement is to give the Netduino something to display on its LCD other than the time and temperature. There is a world of data swirling around the Netduino: twitterers tweeting, bloggers blogging, weather forecasters making stuff up forecasting. Wouldn’t it be cool if our Netduinos could dip into that datastream and display some of that info on its LCD?

There are 2 main options for implementing this: using a Netduino-compatible Ethernet shield to connect directly to the Internet, or using a wireless XBee device to connect to a PC. The first option has the very strong advantage of being a standalone solution, but I’ll be going down the second path – it has the even stronger advantage of me having already written most of the code.

So, if you’re interested in following me there, you’ll want to invest in a couple of XBees, and a couple of hardware interfaces for connecting the XBees to your Netduino and your PC.  More on that in my next article.

The source code for this article can be downloaded here: LightControllerWithMenu.zip. As before, it contains a reference to the Micro Liquid Crystal library, so you should download it as well, and place it in a folder that is side-by-side with my LightControllerWithMenu folder (e.g. c:projectsLightControllerWithMenu and c:projectsMicroLiquidCrystal).

This is the 4th in a series of projects for the Netduino and Seeed Studio’s Grove Starter Bundle.

The first three articles in the series were:

1. Netduino Enters the Grove
2. Netduino: Time and Weather
3. Netduino: Let There Be Light

As I hinted at the end of the previous article, there is an easy way to automatically set the plant light to turn on when it starts to get dark. It’s a light-sensing photoresistor (like this), and we’re not going to use it because

1. There isn’t one in the Grove Starter Pack
2. I kinda thought the easiest way would be to calculate the sunset time instead

Using an algorithm to calculate sunset time is actually relatively foolproof, being unaffected by storm clouds, cat attacks, or awestruck bystanders staring at your way-cool plant light controller.

It does however, require 2 additional pieces of information:
- your geographic location
- your timezone, including daylight savings time

The geographic location is, specifically, the longitude and latitude. There are zillions of sources for that on the Internet. One of the handiest is Wolfram Alpha, the Google of calculations. Just type in ” latitude longitude [your city]“, and it will spit out the numbers. Type in “[your city]sunset”, and it will tell you what result the algorithm should be giving you for today.

We all know what timezone we are in, but calculating the start and end date for Daylight Savings Time is too convoluted for most programmers, including me. It becomes pretty easy to determine if your Netduino is Internet connected, but since we aren’t there yet I’ll follow the same approach as the prestigious National Research Council Canada’s Sunrise/Sunset calculator: leave it unimplemented.  (As they put it: “Add one hour to listed times when Daylight Saving Time is in effect.”)

I decided to use the sunset calculation algorithm from this CodeProject article: Solar Calculator.  This API is relatively simple and self-contained. The “LongituteTimeZone” parameter mentioned in the article threw me for a loop – I fruitlessly Googled “Longitute” before realizing that was a typo. This parameter represents your time zone: it is the offset from UTC (aka Greenwich Mean Time) in hours, times 15.    (Turns out each timezone represents 15 degrees of longitude – who knew!)

The algorithm makes extensive use of the trigometry calculations from the .Net Math class, none of which exist in the .Net Micro Framework. Fortunately, all of them do exist, with the exact same parameters, in Elze Kool’s exMath library. This the same library that I used to calculate the temperature in the first article of this series.

So, to change my code to work correctly for your location, you’ll need to change the following 4 values, which are near the beginning of Program.cs in the source code:

// settings for Toronto Canada
const double MY_LONGITUDE = -79.38;
const double MY_LATITUDE = 43.65;
const int UTC_OFFSET = -5;
const bool USE_DAYLIGHT_SAVINGS = false;

Note that the longitude and latitude are in decimal format. If you’ve forgotten your high school geography, negative values are for south of the equator and west of the Prime Meridian, and to convert “minutes” of longitude and latitude to decimals, divide them by 60.

Pin Assignments

If you are using a Parallel LCD, then nothing changes from the list of pin assignments in the Let There Be Light article.

If you are using a Serial LCD, then you probably already changed my pin assignments, since they weren’t at all suitable for a Serial LCD. (As before, you should comment out one of the #define statements at the top of Program.cs to select your LCD type). I changed the code to use:

• UART Serial connection – this changes to COM1 (pins 0 and 1)
• LCD Serial connection – this uses COM2
• Relay twig – this moves from D0 to D13

User Interface

The sunrise calculation is done after the Netduino knows the current date and time. Both of these are still entered using Terminal commands sent over the UART serial connection, as described in the Time and Weather article.

By default, the Light On time is set to 15 minutes before sunset, and the Light Off time is set to 11 pm. You can, of course, override either these using the “+” and “-” Terminal commands described in the Let There Be Light article.

If you have an 16×2 LCD (or larger), it will display the Sunset time on the 2nd row, next to the temperature. This has little practical value other than to confirm that the sunset times are being calculated correctly (and impress friends who are easily impressed).  You can comment it out if you like in the displayTemperature() method.

Speaking of the accuracy of the sunset calculation: it isn’t all that accurate for me (in Toronto Canada). Depending on the day of the year, it is 5-10 minutes earlier than what Wolfram Alpha and other web sites calculate. I get the same result when I run the CodeProject code on a Windows PC, so whatever is responsible isn’t MathEx or the .Net Micro Framework. For the purposes of a plant light, 5-10 minutes is close enough.

Programmer Show and Tell

The most interesting code change this time is something that didn’t work as expected. As described in the Let There Be Light article, I’m using the exotic and mysterious ExtendedTimer class to raise events for turning the light on and off. This class has a Period parm, which is how often you want the timer event to repeat. Since we are now recalculating the “light on” time on a daily basis, I wanted to turn off the period. The MSDN docs for the ExtendedTimer constructor say you do this with Timeout.Infinite

tmrLightOn = new ExtendedTimer(new TimerCallback(SetLightState),
  true, datAlarm,
  new TimeSpan(Timeout.Infinite));

Unfortunately, this doesn’t work, not on a Netduino anyway. It throws an “Argument out of range” exception. The best workaround I could find was to set it to the maximum TimeSpan value.

TimeSpan tsRepeat = TimeSpan.MaxValue;

if (!blnLightOnAtSunset)
{
   // repeat timer at same time every day
   tsRepeat = new TimeSpan(1, 0, 0, 0);
}

tmrLightOn = new ExtendedTimer(
  new TimerCallback(SetLightState),
  true, datAlarm, tsRepeat);

The other piece of code that I’ll point out is the use of a custom event to notify the main class that the user has entered a date and time. The clsUART class has a UART_DataReceived event that fires every time something is entered by the user in a serial terminal. It handles things that it knows how to do (like set the system date and time), then fires off an event to notify the rest of the application that the command was received. This allows you to cleanly separate the serial port logic in clsUART from the “plant light” logic in the main application class.

For example, the code in clsUART that handles the Date command includes the following:

DateTime currentDayTime = new DateTime(intYear,
  Int16.Parse(strDateParts[1]),
  Int16.Parse(strDateParts[2]),
  DateTime.Now.Hour,
  DateTime.Now.Minute, DateTime.Now.Second);

Utility.SetLocalTime(currentDayTime);

// tell rest of application that the date has been set
raiseCommand(strCommand);

if (blnSendResponse)
{
  WriteToUART("OK");
  return true;
}

The raiseCommand method looks like this:

public event CommandEventHandler Command;

private bool raiseCommand(string strCommand)
{
   CommandArgs args = new CommandArgs(strCommand);
   // raise event using Command delegate
   Command(this, args);
   return args.blnHandled;
}

It uses a parm passed to the CommandEventHandlers to determine if some other part of the program recognized the command and handled it. The return code is ignored in the above “date command” logic (since clsUART already handled it), but it is important for commands that clsUART doesn’t know how to handle, like setting turning the plant light on or off. If it gets a false parm back, it displays an error message to the user. (Well, it actually displays a “?” and buzzes a little, but you get the idea.)

Currently, the only CommandEventHandler is in Program.cs. It is created during startup by the following:

uart = new clsUART(strUARTPort, 9600, 50, true);
uart.Command += new CommandEventHandler(uart_Command);

The event handler includes this:

static void uart_Command(object sender, CommandArgs e)
{
   if (command == '-')
   {
      e.blnHandled = setLightTime(e.StrCommand.Substring(2), false);
   }
   else if (command == 'D')
   {
      blnDateSet = true;
       // set default light timer if date and time have been set for the first time
      setDefaultTimers();
  }

So, the code uses the e parm to return a confirmation that it took care of the command (if it did).

That’s it for this installment – a simple change that could have been simpler.  (Clearly George Vernon Hudson wasn’t a programmer.)

Next up, I’ll be adding a menu system for things like setting the date and time.  I notice that the current version (1.0b) of the Grove Starter Kit now includes a 16×2 LCD, rather than the tiny 8×2 model that the beta Starter Kit shipped with, so I’ll use that as the minimum screen size for the menu.

The source code for this article can be downloaded here: LightControllerV2.zip. As before, it contains a reference to the Micro Liquid Crystal library, so you should download it as well, and place it in a folder that is side-by-side with my LightController folder (e.g. c:projectsLightControllerV2 and c:projectsMicroLiquidCrystal).

This is the 3rd in a series of projects for the Netduino and Seeed Studio’s Grove Starter Bundle.

This installment is intended to create a plant light that automatically switches on and off at a pre-set time of the day (well, more usefully, the night).  It is inspired by the “Garduino” project, which was published in Make Magazine and can also be found on Instructables.

This project builds on the foundation set by the earlier two articles. If you want to actually get the project working yourself, you’ll probably need to browse the earlier articles, especially the part about the serial connection to the PC.

The first two articles  in the series were:

Netduino Enters the Grove

and

Netduino: Time and Weather

As the project develops it will soon be necessary to move beyond the Grove’s components (that 8×2 display, in particular, is cramping my style).  First, though, we’re going to bring another Grove component into the act: the Relay twig.

The Relay twig is used to switch the plant light off and on.   To connect the relay to the plant light, we first need to splice open an AC extension cord.

Now, I know that Edison fellow has been spreading the word about AC power being dangerous and what-not.  Sounds scary, don’t it?  Well, it’s true!  Ask Topsy the Elephant.

Seriously, though, various unpleasant things can happen if you hook the relay up incorrectly, but fortunately the risk is mainly to the relay, and your self-esteem.  However, since you don’t want your relay Twig to end up like poor Topsy,  I’ll spend much of this article covering the process of  making that connection.

You actually have a couple of options: build or buy.

Option 1 – Modify an Extension Cord

Here’s the plan: The Relay twig acts as a on/off switch for the extension cord.  The twig has two little green screw connectors.  The “live” wire of the extension cord needs to be cut open, and the 2 exposed ends need to be inserted into those 2 green connectors.  Sounds simple, and it is.

The following photo shows a modified 2-prong extension.  It also shows the connection to the Relay twig, but don’t worry about that for now – it is explained in the “Connecting the Relay Twig” section, below.

Two-pronged extension cord connected to Grove Relay

The process of modifying the extension cord isn’t complicated or dangerous. Anything you do wrong will be evident before you get to the stage where you’ve got the extension cord plugged into the wall. However, it does requires some soldering and some common sense.  If you’re not confident about your abilities at either of these, consider Option 2, below.

The extension cord you use doesn’t need to be anything special – the cheapest one at Wal-Mart is good enough.  If your plant light has a three prong plug then, of course, you need to buy a three prong extension cord.

The best guide to what’s required (and the one I originally followed) is the one in the Make magazine Garduino article. The Instructables version of Garduino refers you to 2 other sites.  Personally, I found the Hobby Robotics article to be confusing (so many wires!) and the Sparkfun article to be downright intimidating (you don’t have to pull a power receptacle out of the wall for this project).  As far as I know the Make Magazine article isn’t available to non-subscribers, but it just so happens that someone (not me) has posted a PDF of this article here.  To modify the extension cord for use with Relay twig, follows steps 7a-7c.

The Make magazine article shows how to modify a two-prong extension cord.  If your plant light requires a 3-prong cord, then the only difference is the process of selecting the right wire to cut and splice.  

It must be the “live” one, which for both 2- and 3-prong cords is the one connected to the narrower blade of the plug.  Generally, the corresponding wire in the cord is aligned with the blade of the plug (i.e. if the blade is on the left, you need to cut the cord on the left).   However, to make sure that you’ve selected the right one before cutting it, nick the cord to expose the copper underneath, then use a multimeter to check connectivity with the narrower blade of the plug.  (If you picked the wrong cord, it’s safe to cover the nick with electrical tape, as I did with the 3-prong extension cord in the photo below.)

Three-pronged extension cord connected to Seeed Relay Brick

Option 2 – Buy a Netduino-Friendly Extension Cord

A product called the “PowerSwitch Tail” recently became available.  It is specifically intended to be hooked up to microcontroller circuits, such as the Arduino and Netduino.  It contains a 5V relay similar to the one in the Grove starter kit – if you go this route, you can ignore the Grove relay.  You’ll have to connect a wire from the Powerswitch to the D0 pin of the Netduino (or modify my code to use whichever pin you’d like).  Then, just skip ahead to the “First Test” section below.  You can read more about the PowerSwitch on the Adafruit product page and in Adafruit’s forums.

I haven’t tried a PowerSwitch, but I’m 99.9% sure it will work fine with the Netduino and this project.

Connecting the Relay Twig

You should have two wires with exposed tips coming from your extension cord.  As you probably figured out, you need to connect each wire into one of the screw connectors on the Relay twig.  Ah, but which goes into which?

Unfortunately, Seeed didn’t put any markings on the v0.9 Relay twig to help you out.  The Datasheet and tutorial on Seeed’s web site don’t offer any guidance on this either.  (“If in doubt contact a professional such as a licensed electrician for help“.  Uh, yeah, good luck with that.)

However, the HLS8L-DC5V relay happens to be the exact same model as used in Seeed’s Electronic Brick relay, and the Brick relay is well documented in this Instructables article and in this Seeed Forum post.

The Grove relay has removed one of the Brick’s 3 screw connectors, meaning that the only way you can hook it up is “normally open”.  This means that the extension cord won’t (yeah, “open” means “off” – go figure) conduct electricity when your Netduino project is powered off.

The 2 screw connectors are, then, are the “Common” and “NO” connectors shown in the Instructables article.  As with its big brother, the Seeed Relay Brick, the twig’s Common connector is on the left (when the screw connectors are facing you) and Normally Open is on the right.  See the photos in this post.

Important Note: this is true for the “0.9″ version of the twig, which is the first version that was sold.  If your twig doesn’t say 0.9 on it, then I’d strongly suggest you double-check this information, either by using a multimeter or by checking the Seeed product page or forum.  Seeed recently posted an article about version 1.0 of the Grove Starter Bundle.  The Relay twig photo on that page looks more like a Relay forest, so if your twig is bristling with relays then all bets are off!

To check continuity with a multimeter, you want to confirm that the “Common” left-hand screw connector is connected to the middle pin at one end of the black relay box, and the other screw connector is connected to one of the 2 pins at the other end of the black relay box. I think the best illustration of the orientation of the pins for this relay is the one in the Seeed forum thread.

Grove Relay Brick - hooked up and ready to rock

OK, so at this point you should have an UNPLUGGED extension cord that is connected to an unplugged relay twig.   This is the time to ensure that you’ve firmly and securely connected the extension cord to the relay.  Tug  hard on the relay twig to make sure that it doesn’t come loose from the extension cord.  

Carefully inspect the points at which the wires from the extension cord are plugged into the screw connectors of the Grove twig.  There must not be any exposed metal from the wire.  If there is, insert the wire further into the screw connector or, if the exposed metal is simply too long, snip it shorter.

That cord-to-relay connection is the only dangerous (to you) part of the setup, and you definitely don’t want to have a wire come loose after you plug it in!

Incidentally, if you Googled for information about the HLS8L-DC5V relay, you may have been unsettled to find that there isn’t much out there, aside from a bunch of pretend-datasheet-sites gaming Googling search engine.  However, I’ve had 2 of the Seeed bricks with this relay in daily service for about 6 months now, and never had a problem with either of them.  So, for what its worth, I’m pretty comfortable with this relay, safety-wise.

Initial Test

I’ve written a small test project, RelayTester, that you can use to test turning the relay off and on.  Pressing the green button (connected to D8) toggles the relay.

Start by unplugging everything from the Grove shield.  Reconnect to the Grove shield just 2 twigs: the one with the red and green buttons (connected to plug D7/D8) and the Relay twig (connected to D0, and to an UNPLUGGED extension cord).  Yes, there, is such a thing as D0 on the Grove shield, off to one end, as shown in the photo in the “Final Configuration” section, below.

Deploy the test project to the Netduino.  For this part of the test, you can leave the Netduino plugged into the USB port of the PC.

The red light on the relay may briefly go on and then off when the Netduino boots up.  Press the green button on the button twig, and the red light should come on and stay on.  Press the green button again to turn it off.

Do you hear a fairly loud clicking noise from the black relay box each time the red light goes on or off?  If not, something is wrong.

If the red light on the relay works, but there is no click, try using a different cable between the Relay twig and the Netduino.  If that doesn’t help, try a different connector than D0 (you’ll have to change the test program code accordingly, of course).

If the red light doesn’t come on at all, check that the connectors are plugged into the Grove shield correctly (buttons in D7/D8, relay in D0, and nothing else connected), and that the project was deployed to the Netduino correctly.  (It will display messages to the Visual Studio Debug window when turning the relay on or off).

If that’s not the problem, then you might have a bad relay twig and should check the Seeed forums or e-mail them.

Live Test

I don’t think there is much risk to the Netduino if things aren’t hooked up correctly.  The Netduino isn’t exposed to the AC current – that’s the whole idea of the relay.  The biggest risk is to the relay itself, and possibly to whatever you have plugged into your extension cord.  However, as an extra precaution, I’d suggest you have as little as possible connected to the Netduino: the Grove shield, the button twig and the relay twig.

Also, I’d suggest you power the Netduino from a DC adapter rather than the PC’s USB port.  The concern isn’t that the relay is power-hungry, but that you want to protect your PC’s USB port if things go wrong.    (If you haven’t run the Netduino with that DC adapter before, rerun the above “Initial Test” with the extension cord still unplugged from the wall.)

OK, so it’s all been fun and games so far, but no fooling around for this test. Remember Topsy!

1. Plug the plant light (or a cheap test light) into the extension cord.
2. Plug the extension cord into the wall.
3. Plug the DC adapter into the Netduino.
4. Press the green button.  Let there be light!
5. Leave the light turned on for awhile, periodically touching the extension cord, the wires leading from the extension cord to the relay, and black relay box to make sure it isn’t getting hot.  The cord and wires shouldn’t get warm at all; the relay box will be very slightly warm.

One last (I promise!) comment about safety: ideally you should never make any adjustment to the relay/extension cord/light setup with the extension cord plugged in.  When hooking things up, and when adjusting the setup, unplug the extension cord first.  Keep an eye on those 2 screw terminals on the Relay twig and the wires inserted into them — that’s the danger zone.  Don’t pile anything on top of them, don’t let those wires get snagged on something.

Final Configuration

OK, let’s bring the rest of the Grove twigs back on stage.  (Not you, Prototype Twig, we aren’t ready for you yet.  Oh, and Tilt Switch twig, um, you can run along home.  We’ll keep you in our files, and we’ll call if we need to do any tilting).

The configuration is the same as in the previous project, Time and Weather, with the addition of the Relay twig:

• D0/D1 – Relay
• D2 – jumper to TX pin of serial header on breadboard
• D3 – jumper to RX pin of serial header on breadboard
• D4/D5 – right side of LCD stem, lower connector
• D6/D7 – piezo buffer twig (only D6 is used)
• D7/D8 – button twig
• D9/D10 – bottom of LCD stem, right connector
• D11/D12 – bottom of LCD stem, left connector
• D13 – right side of LCD stem, upper connector
• A0 – modified potentiometer (unused for Grove LCD, or any other LCD without a software backlight control)
• A2 – temperature twig

Final Configuration of the Netduino and Grove components. Can't see the forest for the trees!

By now, you’ve probably noticed that I have a strange aversion to pin D1.  What’s up with that?

Well, I have 2 Netduinos, one for development and one for testing.  My test Netduino suffered an unfortunate accident, resulting in it being, um, “differently abled” on the D1 pin.

Wait, what?   The guy who’s  giving you safety tips electrocuted his Netduino?

Well, not on this project – honest!  I’m actually not sure at what point it stopped working, but I suspect it occurred while experimenting with the not-particularly-dangerous-but-not-Netduino-friendly Danger Shield.  (See my “Spiderman: The Musical” project for details).

The source code for the LightController project can be downloaded here.

As with the test project, press (and, this time, hold) the green button to manually turn the relay (and light) on and off.  You can also program it to turn off and on at a certain time, using the handy serial port connection from the previous project.  (Stop groaning, we’ll get rid of the serial port in a later project, I promise.)

The 2 new commands are:

+:hh:mm

Sets the time at which the light will come on

-:hh:mm

Sets the time at which the light will go out.

There is no default on and off time – you have to set them manually for now.  (Since you have to set the Netduino’s clock manually, there wouldn’t be much point to having default timer settings).

I’ve also added some new button features, pretty much exhausting the possibilities for the 2-button twig:

• Press the red button: Toggles LCD between the regular time/temperature display, and a display of the  Light On and Light Off times.   If all you see is “+” and “-”, with no times, then you need to set the times using the serial terminal “+” and “-” commands, as described above.
• Press and hold red button: Toggles the serial port off and on, as described in the “Time and Weather” article.
• Press the green button: toggles the first row of the LCD between the current time and a countdown to the next light “event”.  That is, if the light is currently on, it shows a countdown to when the light will go off.  And vice versa.
• Press and hold green button: toggles the light off and on.
• Press and hold red and green button: clears the light on and light off timer.  Also makes your fingers hurt.

Programmer Show And Tell

The new code has a few features worth mentioning.

The light on/off timers are implemented using the ExtendedTimer class.  This is the lesser known of the 2 .Net Framework timers.  It is better suited than the Timer class for time events that occur at specific times of day, rather than at intervals.

For example, the code to set the “light on” timer is:

// set the timer to go off at this date, and every 24 hours after that
tmrLightOn = new ExtendedTimer(new TimerCallback(SetLightState), true, datAlarm, new TimeSpan(1, 0, 0, 0));

Since we want the light to come on at the same time each day, the ExtendedTimer constructor does all the work. There is no need to reset the timer for the next day when the timer event fires.

The countdown timer takes advantage of the fact that, in .Net, subtracting one date from another returns a TimeSpan that gives the difference between them:

// relay is off, display time to next light-off
string strCountdown;
if (datNextOn == DateTime.MinValue)
{
    strCountdown = "Not set";
} else
{
   TimeSpan timeTo = datNextOn.Subtract(DateTime.Now);
   strCountdown = timeTo.ToString();
}
lcd.SelectLine(1, true);
lcd.WriteStringToLCD(strCountdown);

Note that DateTime (and TimeSpan) objects can’t be null – an unset DateTime has a value of DateTime.MinValue.

And lastly, this projects makes extensive use of the 2 pushbuttons. I really like the fact that all the button features can be implemented in the .Net MF without polling.  

Buttons can be configured as InterruptPorts.  The InterruptPort constructor has a parm that lets you specify when the event should be triggered — when you press the button, when you release the button, or both. The following code specifies both:

buttonRed = new InterruptPort(Pins.GPIO_PIN_D7, true,
   SecretLabs.NETMF.Hardware.Netduino.ResistorModes.Disabled,
   SecretLabs.NETMF.Hardware.Netduino.InterruptModes.InterruptEdgeBoth);

The event handler needs to handle 2 cases: a short push and a push-and-hold.  The handler can’t know which it is until the button is released.  On the other hand, the user would like to have some confirmation of the push-and-hold action before letting go.  The answer is to set a timer (the regular kind) on the button press.  If the button is released before the timer goes off, that’s a short push.  If the timer expires first, then that’s a push-and-hold.  I use a 2-second timer.

Here’s the button’s event handler. The same event handler is fired when the button is pressed and when it is released. The state parm tells you which event it is.

static void buttonRed_OnInterrupt(uint port, uint state, DateTime time)
{

  if (state == 1)
  {
     // start the button hold timer
    timerButtonRed = new Timer(new TimerCallback(buttonHold),
       buttonRed, BUTTON_DELAY, BUTTON_DELAY);
  }
  else
  {
     // cancel the button hold timer
     if (timerButtonRed != null)
     {
        timerButtonRed.Dispose();
      }
      if (blnButtonHeld)
      {
         // timer went off, so ignore the release
         blnButtonHeld = false;
         return;
      }

      // normal button press - handle it

      . . .

Note that .Net MF timers are turned off using the .Dispose method – there is no property for setting a timer’s active state.

Last, here’s the timer’s event handler.  I decided to have the red and green button share the same button timer, so a parm is passed to indicate which button it is.  

A boolean variable is used to tell the button’s event handler to ignore the button’s release event when the user eventually lets go.  

Note that, in order to implement the double-button-hold feature for clearing the timers, the code checks the state of the other button using the .Read method, same as you would if you used polling to check the buttons.

private static void buttonHold(object data)
{

  // tell the button release event to ignore it - we're handling it
  blnButtonHeld = true;

  if ((InterruptPort)data == buttonRed)
  {
     // cancel the button hold timer - otherwise, this event will go off again if user keeps button pressed
     timerButtonRed.Dispose();

     // if both buttons are held down, clear the light timers
     if (buttonGreen.Read())
     {
        // cancel the green button's timer
        timerButtonGreen.Dispose();

        clearTimers();
     }
     . . .

So what’s next for this project?  Needless to say, this project is badly in need of an improved user interface, so a menu system can be used to replace (or supplement) the serial port commands.  This will require that we say bye-bye to the tiny 8×2 Grove LCD.