It is the easiest way to power your Netduino Go! projects away from a computer once you’re done building it. The module will fit nicely on the top-left corner of our Large Plate or of our Stackable Plate. This module is equipped with a standard center-positive 2.0mm barrel jack and will take any power supply, such as a wall-wart, a 9 volt battery or a cigarette-lighter adapter, between 7 and 20 volts and will output a nicely regulated 5 volts at up to 800 mA. Just connect the micro USB cable that you’re using today with your Netduino Go! to the power supply module and you’re good to go. The module also features a large switch to let you turn your project ON / OFF smoothly and easily.
Power Specifications
It’s tiny but packs a nice punch:
Voltage Input: 7v (min) to 20v (max)
Voltage Output: 5v regulated
Current Output: 800 mA (max)
1.0v Dropout
Barrel Jack: 2.0mm diameter with the positive voltage at the center
Dimensions
The hole-to-hole dimensions of the module are 30mm x 25mm
The total size of the board is 40mm x 35mm
Hacking the Netduino Go! for power-hungry projects
We will follow up soon with a post showing how to take advantage of the 800 mA provided by the [nwazet Power Supply Module going beyond the 500mA imposed by the USB power circuit on the Netduino Go!
It’s been a while since I’ve last posted here… We have been busy over the past few weeks getting our new little startup company off the ground and setting up a marketplace for the PIX-6T4, our very first product 🙂
The PIX-6T4 is a complete, yet simple, game console designed to teach budding Hackers and Makers about digital electronics and programming in a fun way. Head over to the PIX-6T4 site to check out the schematics, the source code, the docs, and of course, the step-by-step video tutorial on assembling the kit:
The PIX-6T4 is an entirely Open Source and Open Hardware kit, so you’re free to hack it to your heart’s content or use it as a base for your projects. Be sure to show us what you build with it and we’ll feature your creations and contributions.
So, you’ve decided to build your own PIX-6T4 game console and you’re excited about learning C#?
Awesome! Buckle up, you’re in for a wild ride 🙂
The first step of your journey starts with gathering a few parts, which you can find listed in this spreadsheet along with their current retail price and links to the suppliers. In a nutshell, you’ll need about $95 to get all the required parts.
In an effort to keep the number of suppliers down to a minimum for your convenience, most of the parts for the PIX-6T4 prototype come from Sparkfun Electronics.
However, there are many alternative suppliers out there and with some research in Octopart, you will be able to reduce the cost of building this prototype.
Next time, we’ll cover the first step of the build, laying out the IC sockets, the analog joysticks, and some headers on the prototyping board, just like this:
 Earlier this month, AdaFruit released a nice little TTL camera, perfect for security and remote monitoring applications. The camera supports three resolutions (640×480, 320×240 and 160×120), has a built-in motion detection circuit and can output an NTSC signal, all in a fairly compact form factor. The communication with the camera is done over a TTL UART @ up to 115200 bauds. In many respects, this device is very similar to the LinkSprite camera, which has been out there for some time now.
As I’m working on a security-related project involving the Netduino, it was the perfect opportunity to put this camera to the test, starting with writing a C# driver. While interfacing with the camera over the TTL UART of the Netduino is straight forward, the datasheet describing the protocol and commands required to control the camera functions is painfully sketchy and sometime inaccurate. In some instances, some camera functions such as OSD (text overlay) are not supported in the firmware even though the datasheet documents them or only behave properly if called in a particular sequence, which of course, is not documented…
Connecting the camera to the Netduino
Limor’s tutorial on how to interface the camera with the Arduino outlines the required steps rather well, so I won’t re-iterate them here. The only difference worth mentioning is that the voltage divider configuration shown in the adafruit tutorial is not necessary on the Netduino, since its GPIO pins are 5 volt tolerant. So, you can simply connect the TX pin of the camera to PIN 0 (RX) on the Netduino and the RX pin of the camera to PIN 1 (TX) on the Netduino. To make things a bit easier while testing the camera with a breadboard, I built a connector using a standard 0.1″ pitch right-angle header and a small section of prototyping board: unfortunately, the breakout board of the camera uses a different pitch. In addition, you’ll want to connect an SD card reader to your Netduino so that you can store snapshots. Please refer to my earlier post on how to connect an SD card reader to the Netduino if you aren’t familiar with the procedure. If you’re using a Netduino Plus, don’t worry about that part 🙂
Using the Netduino driver
The Netduino driver currently implements 4 major functions.
Initializing communication and the camera’s resolution
Initialize(string port, PortSpeed baudRate, ImageSize imageSize): This call must be the first call in the application. It takes care of initializing the UART and the resolution of the camera at the same time. The reason for keeping these two functions together is that changing resolution requires a reset of the camera, which also resets the camera’s baud rate to the factory default of 38400 bauds. In addition, if the baud rate is set to something other than the default and the program is interrupted while debugging, the next time the program runs, it will have to remember what the last baud rate was (unless the camera is hardware-reset). To avoid all this trouble, the initialization function automatically figures out the proper baud rate needed to communicate with the camera before applying new settings.
Controlling TV output
TvOutput(bool enable): Passing ‘true’ will tell the camera to output a composite video signal showing whatever the camera is looking at. Passing ‘false’ turns it off.
Taking pictures
TakePicture(string path): This function will tell the camera to take and store a snapshot, in JPEG format, to the location specified by the path argument. You need to have an SD card reader connected to the Netduino for this to work. You can control the quality of the image using the SetCompression(byte compression) function where the compression is a value between 0 and 100, with the default being 53.
Detecting motion
StartAutoMotionDetection(int imageSequenceNumber, string storagePath, MotionDetectedHandler motionDetectionHandler): This function will activate the motion detection circuit of the camera and will return immediately. Whenever motion is detected by the camera, the driver will callback the application through the motionDetectionHandler delegate. If the handler returns ‘true’, a snapshot will be automatically taken and stored to the location indicated by the storagePath parameter. The filename is sequentially incremented, starting with the number provided by the imageSequenceNumber argument. The motion detection can be stopped using a call to StopAutoMotionDetection(). Click on the image below to see a sample on how this can be used.
Testing the camera
To put the camera to the test, I wrote a sample taking a set of 100 pictures using each of the resolutions supported by the camera. The sample also tests motion detection and the camera’s composite output. During the test, the camera was set outside on a tripod, pointed at a neighbor’s house about 200 feet away around 8PM on August 11th. The goal of the test was to gauge the overall video quality of the camera in lower light conditions as well as evaluating the error-rate when taking snapshots.
The results
The composite video quality, shown here on a small CRT TV, is generally quite good and stable.
NTSC output
The snapshots, on the other hand, often show compression artifacts like this:
Artifacts
Out of 100 pictures taken at the higher resolution, only one did not have any artifacts. Please note that I did not tweak the color saturation of the camera before using it: colors can be greatly improved with some tuning with the tool coming with the camera. Limor covers this in her tutorial as well but I’ll post updated snapshots with tuned color saturation when I get the chance.
No artifact
In the large and medium resolutions, 1 picture out of 100 is generally corrupt and cannot be viewed. There could be several root causes for these artifacts and data corruptions:
The connection I’m using between the camera and the Netduino is not shielded or twisted to minimize radio and electromagnetic interference. I haven’t had the chance to validate this yet.
The serial buffer size vs. the baud rate is critical in minimizing errors:Â I was able to read a maximum of 120 bytes at a time @ 115200 baud without losing data with the current connection to the camera. Larger buffers only seem to increase the error rate to unacceptable levels which makes reading large images a slow process. Again, a shielded and twisted cable would likely help using larger buffers.
Conclusion
The VC0706 camera, with proper tuning, is a nice addition to any project where remote monitoring, motion detection and security are needed and it will pretty much work ‘out of the box’. It would be great to see future versions of this camera offering access to the SPI and High Speed UART interfaces: while it is possible to force the camera to use ‘out of spec’ UART speeds above 115200 bauds, it is unlikely to be very reliable.
As always, you can find the camera driver and the test code as part of the Netduino Helpers library.
Over the past few months, my friend Bertrand and I have been working on a game console, the PIX-6T4, which is powered by a Netduino mini.
The console is designed as platform for learning digital electronics and C#: we’re in the process of writing a book covering all aspects of building the console, how its components work and how to write games for it with our framework.
Here’s a video of the prototype of the console below:
and here, as we presented it during the Ask An Engineer Show-And-Tell run by AdaFruit on Google+ last weekend: http://vimeo.com/26943990
As always, it’s entirely open source / open hardware and we hope that you’ll have as much fun building your own and making games as we did, which we will cover in a series of upcoming posts, often referring to past articles on this blog.
AdaFruit recently released a sweet little TFT display that I was dying to hook up to a netduino: the display features a resolution of 128*160 pixels, is capable of showing 18-bit colors and has a microSD card reader on the back of the breakout board. As usual, Limor wrote a nicely detailed Arduino tutorial showing how to connect the display and how to write sketches to drive it.
The Arduino driver relies on the ability of the Atmega168/368 to toggle digital lines extremely fast, which does not work well on the netduino due to the latency introduced by the .Net Micro Framework: even when configured to use hardware SPI, the Arduino driver constantly toggles a data/command output line, rspin below, which would be unbearably slow on the netduino if the same method were applied.
You can see an example of this in the drawPixel function:
Â
void ST7735::drawPixel(uint8_t x, uint8_t y,uint16_t color) {
  if ((x >= width) || (y >= height)) return;
  setAddrWindow(x,y,x+1,y+1);
  // setup for data
  *portOutputRegister(rsport) |= rspin;
  *portOutputRegister(csport) &= ~ cspin;
  spiwrite(color >> 8);
  spiwrite(color);
  *portOutputRegister(csport) |= cspin;
}
Driving the ST7735 on the netduino
The  netduino has one advantage over the Arduino: it has plenty of RAM. So, instead of toggling I/O lines slowly all the time and using next to zero RAM, the netduino driver allocates a 40K buffer corresponding to the resolution of the display in 12-bit depth colors (16 bits per pixel) and leaves the ST7735 in ‘data’ mode upon initialization.
Drawing always happens on the internal buffer first. Then, whenever the actual display needs refreshing, the display I/O operations are performed using hardware SPI, blasting the entire 40K buffer. It may sound crazy but using this method on the netduino is faster than refreshing a single pixel while toggling an I/O line!
Take a look at the following netduino code to see how this works, compared to the Arduino driver drawPixel funtion above:
private void Initialize() {
<...>
DataCommand.Write(Command);
Write((byte)LcdCommand.DISPON);
Thread.Sleep(50);
DataCommand.Write(Command);
Write((byte)LcdCommand.NORON); // normal display on
Thread.Sleep(10);
SetAddressWindow(0, 0, Width - 1, Height - 1);
DataCommand.Write(Data);}
private void SetPixel(int x, int y, ushort color) {
if ((x < 0) || (x >= Width) || (y < 0) || (y >= Height)) return;
var index = ((y * Width) + x) * sizeof(ushort);
SpiBuffer[index] = (byte) (color >> 8);
SpiBuffer[++index] = (byte)(color);
}
Â
public void Refresh() {
Spi.Write(SpiBuffer);
}
The caveat is that allocating a 40K buffer on the netduino does not leave room for much object allocation afterwards. In fact, memory is so tight that OutOfMemory exceptions will be common if not careful and planning your application accordingly.
Before going any further, let’s look at the display in action on the netduino. Please forgive the quality of the video as the camera on my phone doesn’t do justice to the display.
Pretty zippy, huh?
Some hacking required…
As I was trying to get the ST7735 display to work with the netduino, I discovered that the display would stop communicating when configuring SPI to run @ 10 MHz or above.
This is a huge issue for a couple reasons: the speed of the SPI bus determines the display frame rate on the netduino and secondly, mounting a microSD card on the netduino configures SPI to run @ 10 MHz minimum. No matter what. This meant that I could either use the display or the microSD card but never together, preventing scenarios such as loading pictures from the microSD card for display for instance.
Based on previous experience, I began suspecting that the CD4050B logic level-shifter on the ST7735 breakout board was the root cause of the issue and decided to take it out of the equation altogether by shorting out its pins so that it would no longer convert signals. Since the netduino works at a 3.3v logic level, there was no risk of damaging the display driver.
CD4050B – Before hack
CD4050B – After hack
Sure enough, eliminating the logic-level shifter allowed me to initialize SPI @ 40MHz on the netduino as well as using the the microSD card reader without any issues.
Connecting the AdaFruit ST7735 display to the netduino
netduino GND -> ST7735 GND
netduino Vcc (3.3v or 5.0v) -> ST7735 Vcc
netduino D8 (or other Dx pin) ->Â ST7735 RESET
netduino D7 (or other Dx pin) ->Â ST7735 D/C
netduino D10 -> ST7735 CARD_CS
netduino D9 (or other Dx pin) ->ST7735 TFT_CS
netduino D11 ->Â ST7735 MOSI
netduino D13 ->Â ST7735 SCK
netduino D12 -> ST7735 MISO
Note that the ST7735 LITE pin can be connected to netduino Vcc (3.3v or 5.0v) or any of the netduino’s PWM pins if you’d like to control the intensity of the display’s back light.
The AdaFruit ST7735 TFT is a fast, bright and convenient all-in-one display and microSD reader:
Using it on the netduino is sub-optimal for the time being due to the memory requirements involved in making the display work at a decent frame rate but, if used carefully, it is possible to achieve very cool results with it right now. Keep in mind that the memory requirement will eventually go away once the netduino starts supporting native ARM code with .Net Micro Framework 4.2, letting applications toggle I/O lines super fast.
Finally, my only wish is for AdaFruit Industries to consider producing versions of their products without built-in logic level-shifters as they can negatively impact some micro controllers such as the netduino.
Update on 08/23/2011: here’s the same hack applied to the stand-alone version on the adafruit microSD card reader, this time with a 10K resistor between Vcc and Gnd to ensure that the electrical behavior of the chip remains stable.
This is where a chip like the MAX7219/MAX7221 LED display driver comes in handy: all you need to do is to send it the data that you want to display over SPI and it will drive LEDs without further involvement from the micro controller.
The chip offers 2 display modes: ‘Decode Mode’Â is intended to manage 7 segment displays (plus a dot) and another which displays raw bitmaps instead, perfect for controlling an 8×8 LED matrix.
Multiple MAX72xx chips can be daisy-chained together to form larger displays as well.
1 Logic-level shifter (DigiKey) (optional: see note below)
1 10K resistor minimum
1 100 uF capacitor
1 0.1 uF ceramic capacitor
many hookup wires (as short as possible)
Note: The MAX72xx requires 3.5 volt logic levels minimum and because the netduino uses 3.3 volt logic level on its digital output pins, you may need to place a logic-level shifter between the netduino SPI interface and the Max72xx SPI interface. Check out this article if you’re not sure how this works.
While the Max72xx SPI clock can go up to 10 MHz based,  I was unable to get stable communications above 2 MHz when using the MAX7219 with a logic-level shifter. Without the shifter, SPI @ 10 MHz works flawlessly but because this is out of the chip’s specifications, so your mileage may vary.
The following summarizes the connections. It doesn’t matter which pins you choose on the logic-level shifter provided that they’re matching low-level input/high-level output pins.
Note: the MAX72xx is extremely sensitive to EMI and power fluctuations. So, be sure to:
Place the capacitors as close as possible to the V+ and GND pins of the chip
Connect both GND pins to ground
Use the shortest possible hookup wires
If EMI is an issue, reducing the speed for the SPI bus and/or using shorter hookup wires may help. If you still have EMI issues, the MAX7221 is likely the right alternative.
Connecting the Max72xx to the LED matrix
The LED matrix that I’m using is wired like this:
LED matrix
Connecting it to the MAX72xx is straight forward:
The MAX72xx’s SEG pins correspond to the columns of the LED matrix
The MAX72xx’s DIG pins correspond to the rows on the LED matrix
I wanted to figure out the kind of throughput achievable through bit-banging on GPIO pins on the netduino.
The basic idea for the test was to flip a bit as fast as possible on a single output pin connected to an LED with a ~215 ohm resistor, Â measuring the frequency of the changes on an oscilloscope.
The little code snippet below is about as simple as it gets for this test.
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;
namespace GPIOSpeedTest
{
public class Program
{
public static void Main()
{
var d0 = new OutputPort(Pins.GPIO_PIN_D0, false);
while (true)
{
d0.Write(true);
d0.Write(false);
}
}
}
}
The result turned out to be surprisingly low, clocking in @ 8.4 kHz!
Fortunately, extremely fast serial protocols, such SPI and I2C, are built into the ARM 7 hardware powering the netduino and are easily accessible from the .Net Micro Framework.
A while ago, I bought a LCD117 serial LCD backpack from Modern Device to save a few pins on my Arduino board. Everything worked great because the micro-controller, the serial backpack and the LCD display all required 5 volts for power and logic levels.
But when I tried connecting the serial LCD backpack to a netduino micro-controller, nothing worked: the netduino uses 3.3 volt logic levels while the LCD117 serial backpack expects 5 volt logic levels.
That’s annoying.
Fortunately, there’s a simple and inexpensive solution called a ‘Hex non-inverting buffer’ which can translate between logic levels. I happened to have such a chip, in this case, a  NXP HEF4050 which can be found for less than 50 cents a piece from DigiKey.
I wanted to use the TX pin (digital pin 1) of COM1 of the netduino to print out text messages, so I wired the 4050 like this:
Here’s a code snippet sending a “Hello World!” message to the LCD screen:
using System;
using System.IO.Ports;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;
namespace SerialLCD
{
public class Program
{
public static void Main()
{
using (var port = new SerialPort(Serial.COM1, 9600, Parity.None, 8, StopBits.One))
{
port.Open();
string Msg = "Hello World!";
var buffer = new byte[1];
foreach (Char c in Msg){
buffer[0] = (byte)c;
port.Write(buffer, 0, 1);
}
port.Flush();
port.Close();
}
}
}
}
Fabien's Bit Bucket 