Netduino Enters the Grove

Note: The source code for the temperature LCD program described in this article can be downloaded here.

I recently received one of Seeed Studio’s new Grove Starter Bundles. Since many others will put GROVE through its paces using an Arduino — and Seeed recently posted a series of projects that do just that — I thought it would be interesting to try it out with a Netduino instead.

For those unfamiliar with these two products, Grove is a set of plug-and-use electronics components, like sensors and controls, intended to be used with an Arduino-compatible shield. The Netduino is a .Net Micro Framework-based system that uses the same form factor and pinout as the Arduino.

Why Grove?

The Grove system (and Seeed’s previous generation Electronic Bricks) are great for prototyping. Wiring components to a breadboard-based Arduino system can be rather frustrating, since you have to be sure that all the wires and components stay firmly plugged in. Buttons and potentiometers are particularly tricky. With the Grove system, wiring a component to an Arduino is a snap, literally. Each component connects using a latched cable, ensuring that things stay put.

The closest competitor to Grove that I know of is the Phidgets systems. Seeed’s product is considerably less expensive and, in my experience, the quality is just as good. The Phidgets system, on the other hand, has top quality documentation, and can be directly interfaced with PCs without using an *duino go-between.

The advantages of GROVE over Seeed’s Electronic Bricks are, frankly, yet to be revealed. The GROVE components can use 2 pins, not just 1. In some cases this allows one component (they’re called twigs, actually) to include 2 separate items, such as 2 pushbuttons or 2 LEDs.

However, I think the real reason for the double-pin support is that the “twigs” contain edge connectors which would allow them to be directly connected to one another. You can see what I mean by looking at the photos of the various components on this page. Those markings on the edges of each twig’s circuit board (VCC, GND, D1, D2 etc.) are pads that align with those on other twig’s boards. I’m honestly not sure where that is leading, since the Grove was just released and the documentation is a work in progress, but I assume that the goal isn’t just to reduce cable usage. Stay tuned.

Why Netduino?

If you are a programmer, or learning to become one, then the advantages of Secret Lab’s Netduino over the Arduino are clear.

The Netduino’s IDE is Microsoft’s venerable Visual Studio 2010, which absolutely bristles with features when compared to the Arduino’s IDE. The free Visual Studio C# 2010 Express is well suited to Netduino development, since the extra features found in the other Visual Studio versions generally don’t apply to microcontroller programming.

And, even more importantly, the Netduino supports In Circuit Debugging, using nothing more than a USB cable. No more trial-and-error debugging and testing! As Joe Biden would say, that is a Big F’ing Deal!

If you aren’t a Windows user,the the disadvantages of the Netduino over the Arduino are also clear. ‘Nuff said. The Arduino also has a larger and more established hobbyist community, and is probably a better choice for somebody new to coding.

The Netduino has a close competitor, the FEZ Panda from GHI. GHI has actually been in the .Net Micro Framework game a lot longer than Secret Labs, and their firmware and documentation are therefore much, much better. When Netduino first came along this summer, it had a clear price advantage over GHI’s first Arduino-compatible board, the Domino. GHI quickly responded with a budget board called the Panda, Secret Labs responded with a feature-rich board, the Netduino Plus, and the fight is on!

But, back to the point of this article: Netduino’s adventures in the Grove.

Digital Components

The first things I tried were some basic digital components, and they worked pretty much seamlessly.

As shown in the photo, the basic GROVE shield fits on top of the Netduino. In keeping with the botanological theme, the shield is called a “stem”, actually, but since I can’t quite wrap my mind around a stem with twigs sticking out of it, I’ll call it a shield. (I’ll use the term twig for the component boards, though, since I don’t know what else to call them).

I tried connecting a button twig and LED twig (2 per twig in each case), and programmed them so that the buttons triggered the lights to glow and dim, using PWM. Initially, the button event (yes, the .Net Micro Framework fully supports raised events, just like Bill Gates invented ) didn’t fire. A bit of trial and error revealed that the pulldown resistor had to be disabled, which is easily done in the source code.

The Netduino has relatively limited PWM support when compared to the Arduino (you can set the period, but frequency is fixed at 10Khz), but it worked fine with the LEDs. GHI’s firmware allows the frequency to be set, which might come in handy with the Grove’s piezo buzzer.

I’m using a serial LCD connected to digital pin 3 and the 5V and Ground pins. That setup works as expected. The Grove Starter Bundle includes a parallel LCD,  However, since the Netduino has 2 serial ports, neither of which are used to program or debug the board, and its support for parallel LCDs is less well established than the Arduino’s a Serial LCD might be the best way to go with the Netduino any way.

I’m using an elderly Matrix Orbital serial LCD, but the Sparkfun Serial LCD Backpack is a relatively inexpensive way to convert a parallel LCD to serial, including 4×20 LCDs. I’ve included support for it in the attached source code — just comment out the corresponding #define at the top of Program.cs. I took advantage of the .Net Compact Framework’s support for Interfaces to create compatible classes for the 2 serial LCD APIs.

Incidentally, both the analog and digital pins of the Netduino supply 5V, even though the processor uses 3.3V, which improves compatibility with Arduino shields. However, while the digital pins can accept 5V input, the analog pins (or, more accurately, the analog-to-digital converter) cannot go beyond 3.3V. That presents a problem when using 5V sensors and controls like the Grove’s.

Analog Components

For example, the potentiometer twig would, when turned all the way up, flood the ADC and cause all of the analog pins to read weird values. The proper solution for this is to connect the pot (and any other analog twig you use) through a circuit that converts the 5V signal to 3.3V or lower.

A voltage divider works well for something like a pot, since accuracy isn’t all that important. However, I tried a more accurate (though more cumbersome) approach using Sparkfun’s Logic Level Converter.

In theory, this converter takes 5V signals and steps them down to a 3.3V signal. In practice, things are a little more complicated. You need to connect the converter to the 5V line, and to the 3.3V line, and to ground (actually to ground twice, once on the 5V side and once on the 3.3V side). And, of course, you need to connect the signal from the twig to the converter, and the output from the converter to the analog in pin on the shield. All of which makes for a very messy setup, as you can see from the photo.

Lastly, to make things interesting, Sparkfun decided to step the signal down to 2.5V, not 3.3V as the product description suggests. The step up, on the other hand, always goes to 5V. Presumably, this decision was made to allow compatibility with microprocessors that use other voltage levels, but it means an extra step (pun intended) when what you want is a 3.3V signal.

Generally, you would correct the reading in code (by multiplying it by 3.3/2.5). Another option is to use the Netduino’s AREF connector to feed in the actual analog voltage you want to use. So, I connected it to AREF to a 2.5V signal from the Sparkfun converter, requiring yet another pair of wires – a connection to the 5V bus on the input side, and a connection from the output side to AREF.

Messy, but effective. The pot twig’s signal now moves smoothly from 0 to 1023 while staying well within the Netduino’s tolerance.

Next up, the temperature sensor twig. I tried the same connection approach as with the pot. Actually, since the Sparkfun Logic Level Converter only supports 2 input signals, I setup a second converter on the breadboard for this. While the converter correctly stepped the analog voltage down, the resulting temperature calculation was 34C (93F). This overshot the correct reading by about 12C.

I’m not 100% sure what the cause is, but I think the problem is that the temperature twig’s sensor uses a logarithmic scale, and simple fractional conversions don’t work in that world. (If anyone knows differently, please post a comment with an explanation).

A good solution, which has been described in the Netduino forums, is to use a temperature sensor that connects via I2C rather than an analog pin. However, I went with a hack. The analog signal returned by the Grove system’s temperature sensor (assuming you are using it for room temperature, and aren’t in Hell) is safely below the 3.3V threshold supported by the Netduino’s ADC. So, you can get away with connecting it directly to the shield, and the same temperature calculation formula used with the Arduino then works correctly with the Netduino.

Well, it almost works. The formula in the Grove system’s tutorial makes use of the Arduino’s (technically, AVR Libc‘s) log() function, which calculates a natural logarithm. The .Net Micro Framework doesn’t have a log() function. .Net’s Math function was pared down for size, and log() didn’t make the cut.

I first tried an alternative formula, taken from a forum posting for the older Electronic Brick temperature sensor. This came close, but was about 0.5C too high.

So, I next tried incorporating Elze Kool’s exMath library, which includes a log() function. After waiting, and waiting, for the logarithm calculation to complete, I broke into the debugger (again, in-circuit debugging is a Big Freaking Deal!!) and found it caught in an infinite loop.

while (partial >= double.Epsilon)
{
   if (x >= newBase)
   {
      fractional += partial;
      x = x / newBase;
   }
   partial *= 0.5F;
   x *= x;
}

The comparison of partial to epsilon kept returning true, even though the debugger showed the value of partial to be 0. In fact, entering partial > epsilon in Visual Studio’s Immediate window correctly returned false - only the compiled code was getting it wrong.

I can only assume that this is a bug in the compiler — epsilon is, after all, the mother of all edge cases. Adding (partial == 0) to the while loop’s condition fixed the problem. The temperature calculated by this formula is almost dead-on.

This leaves us with one last problem: the hack of using the “raw” signal from the 5V temperature sensor isn’t compatible with the earlier hack of feeding a 2.5 voltage into the AREF pin. Since the AREF problem is easily fixed in software, I changed the AREF signal to 5V, and doubled the reading from the potentiometer twig.

I really like Seeed Studio’s products, and the Grove looks like a solid, low-cost starter bundle for *duino experimentation and prototyping. I’m not entirely convinced of the advantages of the Grove over the older Electronic Brick system. The new connector cables are quite stiff, and since the twigs don’t have mounting holes they tend to stick up in the air like, um, branches of a tree. However, the twigs’ edge connectors are innovative, and it will be interesting to see what uses they are put to.

Source Code Notes

A few notes on the hardware setup used by my code:

1. The button twig is connected to D7/D8, and the LED twig to D9/D10.
2. The temperature sensor twig is connected to A2/A3,
3. The potentiometer twig is connected to A0. As explained this connection is via the Sparkfun Logic Level Converter. The “D1″ (why D?) pin of the pot is actually connected by a jumper cable to the RI pin of the Converter, and the corresponding RO pin of the Converter to the A0 pin of the shield. If you want to skip the hassle of the analog voltage conversion, you can omit the potentiometer. It is used only to set the backlight level of the LCD. Just comment out the call to setLCDBrightness in Program.cs.
4. The Serial LCD is connected to D3. You can run the code without a serial LCD by commenting out both #define statements at the top of Program.cs. You can see the temperature value in the Visual Studio Debug output window, and the buttons and LEDs will still work as normal.

The MathEx library is included in its entire, original form, except for the one change I made as explained above.  The change is commented with date 12/12/10.

And one final note: if you are thinking that a temperature display is a horrible waste of the Netduino’s capabilities, I agree entirely. This is just a starting point for a series of refinements that I’ll blog about in the future. I currently have various Arduinos scattered about my house, controlling plant lights, displaying Twitter feeds and weather forecasts, and logging temperature data. The code required a lot of trial-and-error debugging, and relies on the use of a Beagleboard as a go-between to the Internet. I’m looking forward to seeing how much more (or less?) the Netduino can achieve.

The source code for the temperature LCD program described in this article can be downloaded here.