Jeroen Swart

.NET Architect

NetDuino - Getting Started with RS232

A common communication protocol is RS232. This is a serial protocol, which uses two wires to transmit data in both directions one bit at a time. A port using this protocol is usually simply called a serial port, because it’s one of the most commonly used protocols for serial communication.

Connecting two devices using RS232 can be as simple as connecting 3 wires between them: transmitted data (TxD), received data (RxD) and ground. It is also possible to connect up to 6 more wires, which handle the handshake part of the RS232 protocol. Handshaking is used to synchronize the communication between the devices: e.g. to let the other device know data was sent or it’s ready to receive data. With 3 wires, and no handshaking, both sides must agree upon the details of the communication: the speed and the number of data-, start- and stop-bits.

What makes using the RS232 protocol difficult in standard digital electronics, is that the protocol uses different voltage levels. Instead of using 0V for a low level or ‘0’ and using the supply voltage (3.3V or 5V) for a high level or ‘1’, the RS232 protocol uses +3V to +15V to signal a ‘0’ and -3V to -15V to signal a ‘1’.

The conversion of RS232 signals and voltage levels is such a common task, that special chips (like the MAX232 or MAX3232) are available to handle this. They even make -12V and +12V out of a 5V or 3.3V power supply. Another option is to use a USB to RS232 converter, like the FT232 chip. This chip presents itself (at its USB side) as a USB serial port to your PC, which is recognized by Windows and a driver is automatically installed. You then have a virtual serial port (usually COM3 or higher) which you can use as if it was a regular RS232 serial port. Whatever you send to this virtual serial port will be present on the RS232 side of the FT232 chip, in logical 0’s and 1’s, and vice versa.

When connecting two microcontroller devices (e.g. two Netduino’s or a Netduino with an Arduino), there is no need to translate the signals. The appropriate ports of each microcontroller can simply be connected directly, or through any type of connector.

Another important thing to know is that the protocol was originally designed for computers and device communication. In this configuration the computer transmits over the TxD line and the device listens to the same line. When connecting two computers, or microcontrollers, to communicate with RS232, both are transmitting over the TxD line and listening on the RxD line. Therefore the lines must be connected across: TxD to RxD and RxD to TxD. When using the ‘real’ RS232 protocol, you can use a special null modem cable, where the TxD and RxD lines are crossed inside. When connecting without such a cable, e.g. between microcontrollers, just remember to connect TxD on one to RxD on the other.

If you want to know more about RS232, check out this Wikipedia article.

The microcontroller on the Netduino has 2 serial ports and both are available through the Netduino headers. Because my laptop has no serial port, I’m using a ‘USB BUB’ board. It’s nothing more than a simple board with a RL232 chip and some supporting components. It’s made by Modern Device, but I ordered mine from JeeLabs, together with some JeeNodes (an Arduino-compatible board).

To setup the hardware part of the example, connect the USB BUB to a PC with a USB cable. It will automatically install the necessary driver and show up as a USB Serial Port in the device manager as shown below.

The ‘LOGIC LVL’ jumper on the USB BUB should be in the 3.3V position, since that’s what the Netduino is working with, but 5V will also work. Connecting the Netduino to the USB BUB takes 3 wires as shown in the picture below. The black wire connects the ground of both boards. The green wire connects the RxD of the Netduino (D0) to the TxD of the USB BUB. The white wire connects the TxD of the Netduino (D1) to the RxD of the USB BUB.

The D0 (RxD) & D1 (TxD) pins of the Netduino headers are connected to the first serial port of the microcontroller, or COM1 for Micro .NET as we will see in code. The second serial port, or COM2, is connected to D2 (RxD) and D3 (TxD) of the Netduino. The first serial port doesn’t provide handshaking. The second serial port does provides handshaking (using CTS & RTS only), but you’re not required to use it.

Below is the code for the Netduino. It sets up a serial port to use COM1 and adds an event handler for when data is received. When data is received, a single byte is read and send back as long as there is data in the buffer to read. You need to add a using statement for the System.IO.Ports namespace. If you want to use COM2 instead, connect the USB BUB to D2 & D3 instead of D0 & D1 and change SerialPorts.COM1 in the code below to SerialPorts.COM2.

public class Program
{
    static SerialPort serial;

    public static void Main()
    {
        // initialize the serial port for COM1 (using D0 & D1)
        serial = new SerialPort(SerialPorts.COM1, 9600, Parity.None, 8, StopBits.One);
        // open the serial-port, so we can send & receive data
        serial.Open();
        // add an event-handler for handling incoming data
        serial.DataReceived += new SerialDataReceivedEventHandler(serial_DataReceived);

        // wait forever...
        Thread.Sleep(Timeout.Infinite);
    }

    static void serial_DataReceived(object sender, SerialDataReceivedEventArgs e)
    {
        // create a single byte array
        byte[] bytes = new byte[1];

        // as long as there is data waiting to be read
        while (serial.BytesToRead > 0)
        {
            // read a single byte
            serial.Read(bytes, 0, bytes.Length);
            // send the same byte back
            serial.Write(bytes, 0, bytes.Length);
        }
    }
}

Next is the code for a simple console application. It uses COM3 which you might need to change depending on what your USB BUB is connected as; check your device manager. The application lets you type a string and sends it out. When data is received, it is shown. As with the Netduino code, you need to add a using statement for the System.IO.Ports namespace.

class Program
{
    static SerialPort serial;

    static void Main(string[] args)
    {
        // provide some usage information
        System.Console.WriteLine("enter some text and hit ENTER.");
        System.Console.WriteLine("enter 'x' and hit ENTER to exit.");
        System.Console.WriteLine();

        // initialize the serial port for COM3 (could be other port, depends on system)
        serial = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
        // open the serial-port, so we can send & receive data
        serial.Open();
        // add an event-handler for handling incoming data
        serial.DataReceived += new SerialDataReceivedEventHandler(serial_DataReceived);

        // this will hold each line entered
        string line = string.Empty;

        // as long as an x is not entered
        while (line.ToLowerInvariant() != "x")
        {
            // read a single line from the console
            line = System.Console.ReadLine();

            // convert the line to bytes
            byte[] utf8Bytes = System.Text.Encoding.UTF8.GetBytes(line);

            // send the bytes over the serial-port
            serial.Write(utf8Bytes, 0, utf8Bytes.Length);
        }
    }

    static void serial_DataReceived(object sender, SerialDataReceivedEventArgs e)
    {
        // wait a little for the buffer to fill
        System.Threading.Thread.Sleep(100);

        // create an array for the incoming bytes
        byte[] bytes = new byte[serial.BytesToRead];
        // read the bytes
        serial.Read(bytes, 0, bytes.Length);
        // convert the bytes into a string
        string line = System.Text.Encoding.UTF8.GetString(bytes);

        // write the received bytes, as a string, to the console
        System.Console.WriteLine("echo: " + line);
        System.Console.WriteLine();
    }
}

Notice how the code for initializing the serial port, sending & receiving data and even for converting of bytes to a string and back, is exactly the same for both platforms! How cool is that.

Next: working with I2C.

NetDuino - Getting Started with SD

The Netduino Plus has an on-board SD-card slot. It is connected to one of the SPI ports of the microcontroller. Fortunately, you don't need to write code to control the SPI port yourself. The firmware handles this for you, so all you need to do is work with the classes from the System.IO namespace. Do remember that this is the Micro .NET framework and it is not as rich as the full .NET framework, but it does provide enough implementation for working with the SD card.

The root of the file system on the SD card is '\SD'. So, to get all the files in the root directory, you could do the following:

string[] fileNames = Directory.GetFiles(@"\SD");

And anything else is just as simple as that. Below is an example that shows all folders and files on the card. You'll need to add a using statement for the System.IO namespace to your code and a reference to the System.IO.dll to your project.

public class Program
{
    public static void Main()
    {
        DirectoryInfo rootDirectory = new DirectoryInfo(@"\SD\");
        RecurseFolders(rootDirectory);
    }

    private static void RecurseFolders(DirectoryInfo directory)
    {
        if (directory.Exists)
        {
            Debug.Print(directory.FullName);

            foreach (FileInfo file in directory.GetFiles())
            {
                Debug.Print(file.FullName);
            }

            foreach (DirectoryInfo subDirectory in directory.GetDirectories())
            {
                RecurseFolders(subDirectory);
            }
        }
    }
}

If there is no card in the SD slot, the \'SD' directory will not exist. So check the Exist property before using the rest of the DirectoryInfo object. Using the object (other than the Exist property) if the directory it represents does not exist will throw an expection. If a DirectoryInfo object was already created, for an existing directory, and then the SD card is removed, an exception is thrown when accessing the object. Since removing a card is easy, you should write code that handles that possibility.

Oh, and do remember that the maximum SD card size the Netduino Plus can handle is 2GB. It is clearly mentioned on the Netduino Plus specifications page, but I overlooked it at first myself. When using a larger SD card, it will look as if no card has been inserted at all.

Next: communicate using RS232.

NetDuino - Getting Started with ADC

The Netduino contains several ports (A0 - A5) that are capable of reading an analog signal and changing it into a digital representation of that signal. These ports can be used for digital I/O as well, but can individually be configured to use an internal ADC (Analog to Digital Converter).

The analog signal at the ADC port can come from different sources. It can come from a sensor, e.g. for measuring light or temperature, or it is simply taken from a variable resistor, that is changed by a user to select some value (e.g. the desired intensity of a dimmed light). The analog signal is a voltage between 0V and 3.3V. The ADC converts this voltage to a number between 0 and 1023, since the Netduino has 10-bits ADC’s. The number 0 represents 0V and 1023 represents Aref. The voltage level at any ADC port can be determined as follows:

float analogValue = (float)digitalValue * (3.3f/ 1023f)

In theory, you should divide by 1024, because there are that many steps. The maximum digital value of 1023 in that case represents a voltage between 3.2967 and 3.3V, but the formula would result in the lower value. In practice it is easier to divide by 1023, so a digital value of 1023 represents the full scale of 3,3V. And with ADC precision-errors and a Vref that's probably not exactly 3.3V, the result is pretty accurate.

The example uses port A0 and continuously reads the digital value and converts it to the actual voltage at the port using the previously mentioned formula. For this example connect a variable resistor to port A0 as shown below.

public class Program
{
    private const int MaximumValue = 1023;
    private const float AnalogReference = 3.3f;

    public static void Main()
    {
        // initialize one of the analog pins
        AnalogInput adcPort = new AnalogInput(Pins.GPIO_PIN_A0);

        // do forever...
        while (true)
        {
            // read a digital value from the ADC
            int digitalValue = adcPort.Read();

            // convert digital value to analog voltage value
            float analogValue = (float)digitalValue / MaximumValue * AnalogReference;

            // show the analog value in the output-window
            Debug.Print(analogValue.ToString());
        }
    }
}

If the default Aref value of 3.3V is not convenient, you can provide your own Aref at the corresponding pin of the Netduino headers. It must however be between 2.6V and 3.3V. To let the Netduino actually use the external Aref, you need to switch port 56 (on the board, but not available on the headers) to low:

OutputPort arefSelect = new OutputPort((Cpu.Pin)56, false);

To use the 3.3V again, switch port 56 to high:

OutputPort arefSelect = new OutputPort((Cpu.Pin)56, true);

Another way to convert the digital value of the ADC port to some meaningful value in code, is by using the SetRange method of the AnalogInput class. It allows you to set the minimum and maximum value returned by the Read method of the AnalogInput class. The conversion of the actual value to the range you have set is then done for you. In the example above we could have added the following line after the declaration of adcPort:

adcPort.SetRange(0, 3300);

The digitalValue can then be used as is, or divided by 100 to get the exact analog value:

float analogValue = (float)digitaValue / 100;

Since Aref can’t be higher than 3.3V, no analog signal higher than 3.3V can be measured by a port directly. Any signal above Aref is read as 1023 and, if considerably higher, may damage the port. To solve this, use a voltage divider using two resistors as shown below. The voltage at the port is Ain x R6 / (R5 + R6). The values of the resistors in the schematic allow for a 5V input to be measured as 3V by the port (5V * 18k / 30k = 3V). You can change the resistor values to accommodate any input voltage, e.g. change R2 to 120k to measure up to 23V. Note however that, when the input value is increased in this way, the accuracy of the value read from the ADC does decrease accordingly. Instead of 1024 steps of roughly 0.003V to reach 3.3V full scale, the ADC will do 1024 steps of roughly 0.022V to reach 23V full scale.

Another trick shown here is the use of a zener diode to protect a port. A zener diode will not allow a higher voltage to pass then the voltage that it was designed for. I won't go into the detailed workings of a zener diode, but effectively it protects the port from any voltage higher than the zener voltage.

Next: using the SD card.

NetDuino - Getting Started with PWM

PWM (or Pulse Width Modulation) is a technique that basically allows digital circuits to control analog circuits. One of the applications for this is to control the speed of a motor or, as I will show you in a second, the brightness of a LED.

A digital port is either on or off. This is very logical, but not very helpful when controlling an analog device like a motor. The speed of a motor is usually controlled by varying the voltage: if you set the voltage higher, more current will flow and the speed of the motor will increase.

With PWM, the digital port is switched on and off really fast. The effective voltage for analog (DC) use is the average of the on and off levels and depends on how fast the port is switched. The time the port has been switched both on and off is called the period, the time the port is on is called the pulse and the time the port is on, relative to the period, is called the duty-cycle and is expressed in percentage. By controlling the width of the pulse, you control the effective voltage on the output. Luckily, most microcontrollers have one or more PWM ports. You only need to set the period, pulse and/or duty-cycle, and the microcontroller takes care of the rest.


This image shows a PWM signal with a 50% duty-cycle. With a supply voltage of 3.3V, like on the Netduino, this will result in an average output of 1.65V.


This image shows a PWM signal with a 25% duty-cycle. This will result in an average output of 0.825V when using a supply voltage of 3.3V.

The Netduino has 4 ports that are capable of producing PWM signals: D5, D6, D9 and D10. The PWM class is used to control one of these ports. It provides two methods to configure the port. With the SetDutyCycle method, the duty-cycle is simply set as a percentage. Passing 0 sets the port off all the time, resulting in an effective 0V output. Passing 100 sets the port on all the time, resulting in an effective 3.3V output. Passing 50 results in an pulse that’s on during 50% of the period, resulting in a 1.65V output. The SetPulse method allows a little more control. The first argument is the length of the period and the second argument is the duration of the pulse, both in microseconds. So calling SetPulse(1000, 250), results in a pulse that starts every 1ms and lasts 0.25ms; the duty-cycle in this case is 25%.

In the simple example below, the LED is dimmed to a specific level. Since the on-board LED is not connected to a port that allows PWM, we need to connect a LED ourselves. This example will work with a LED & resistor connected directly as shown here, or using a transistor as shown here. The only difference is that you need to use one of the PWM ports. The code below is using port D5. Please note that for controlling anything other than a LED, you will need a transistor to provide a decent amount of current.

public class Program
{
    public static void Main()
    {
        // initialize one of the digital pins (that support PWM!) for PWM
        PWM pwm = new PWM(Pins.GPIO_PIN_D5);

        // set the duty-cycle to a specific value
        pwm.SetDutyCycle(50);

        // wait forever...
        Thread.Sleep(Timeout.Infinite);
    }
}

In the example below, the LED is dimmed repeatedly from totally off to totally on and back again. It uses the same port and components as in the previous example.

public class Program
{
    public static void Main()
    {
        // initialize one of the digital pins (that support PWM!) for PWM
        PWM pwm = new PWM(Pins.GPIO_PIN_D5);

        // we start with the LED off
        int dutyCycle = 0;
        // we start with making the LED brighter
        bool up = true;

        // do forever...
        while (true)
        {
            // if making the LED more bright
            if (up)
            {
                // increase duty-cycle
                dutyCycle++;

                // if we're at 100%, start making the LED less bright
                if (dutyCycle >= 100)
                {
                    up = false;
                }
            }
            else
            {
                // decrease duty-cycle
                dutyCycle--;

                // if we're at 0%, start making the LED more bright
                if (dutyCycle

Another application for PWM is controlling servos, as are used in remote controlled cars and small robots. In this case the duration of the pulse controls the angle of the servo. The period is 20ms and a pulse of 1.5ms (duty-cycle 7.5%) puts the servo in the center or zero position. A pulse of 1ms (duty-cycle 5%) turns the servo completely to one side and a pulse of 2ms (duty-cycle 10%) turns the servo completely to the other side.

Next: using the ADC.

NetDuino - Getting Started with transistors

Controlling a LED directly using a port is fine in most cases, because a LED only requires a small current that can be supplied by the Netduino. But when controlling components that require more current (like high-power LED’s, motors, relays, etc.) a transistor is needed. The transistor is controlled by a small current from the MCU and the transistor controls the heavy load. While transistors actually work as amplifiers, they can also be used as switches.

Transistors exist in a few main types, like bipolar (either NPN or PNP) or FET. For our purpose almost any popular bipolar transistor will work. For each main type, there are many different types to select from. Examples for NPN types are: BC547, BC548 or 2N222. Examples for PNP are: BC557, BC558 or 2N2907. I picked the BC547, a NPN type, and will use it in my example which will simply control a LED. You can use the source code from the blink example in the Netduino Getting Started document.

The schematic shows a LED, again with a resistor to restrict the current through the LED. They are connected to the collector of the transistor, while the emitter is connected to ground (or common or 0V). When the transistor is switched on, current will flow through the transistor from the collector to the emitter. This current will also flow through the resistor and LED, so the LED lights up. When the transistor is switched off, no current will flow and the LED remains off. Switching the transistor is controlled by a current through the base. The base is connected to a NetDuino port through a resistor. And yes, the resistor is there to restrict the current. Since the current is only needed to switch the transistor and not to light up the LED a small current will suffice. A high level (true) on the NetDuino port will cause a current at the base, which will switch the transistor on and the LED will light up.

The above is of course a simple (but working) example. Each specific transistor type (BC547, BC548, etc.) has its own specifications, although many can be used in a similar way or even as a replacement in a situation as simple as this.

Since the Netduino ports are at 3.3V, when set high and the base-emitter voltage is 0.7V (which is the case for most transistors), the voltage-span over the resistor is 2.6V. This gives a 0.5 mA current (I = V/R => 2.6V / 5.6KΩ = 0.46 mA) through the resistor and at the base.

A PNP transistor, like the BC557 below, can replace the BC547 in the schematic above. Although, because of the different behavior of the PNP transistor, the LED will be off when the port is high and the LED will be on when the port is low.

On a PNP transistor the collector is drawn with an arrow inwards. On a NPN transistor the arrow is outwards on the emitter.

Connecting the transistor

A transistor is almost always part of a larger circuit, as it is not much use by itself. The easiest way of putting such a circuit together with the Netduino is using a breadboard or a breadboard shield. If you want to know more about using a breadboard, there are lots of online breadboard tutorials.

To connect any transistor in the right way, you'll need to know which pin is which. The datasheet for the transistor of your choice will help you out. Just google/bing the type and 'datasheet'. Below is a part from the datasheet of the BC547.

 

Next: dimming a LED.

Netduino - Getting Started with switches

After getting the blinking LED, the next thing to do is experiment with a switch. Besides an on-board LED, the Netduino also comes with an on-board switch, so we can work without extra components.

There are two ways to use a digital input-port. As an InputPort, which requires us to constantly check for an input-value ourselves, or as an InterruptPort, which will provide an event when the value changes. I will show code for each.

For this example, the program will turn the LED on when the button is pressed. When using the on-board switch, the program may look like this:

public class Program
{
    public static void Main()
    {
        // initialize the onboard LED
        OutputPort ledPort = new OutputPort(Pins.ONBOARD_LED, false);
        // initialize the onboard switch
        InputPort switchPort = new InputPort(Pins.ONBOARD_SW1, false,
                                             Port.ResistorMode.Disabled);

        // do forever...
        while (true)
        {
            // turn the LED on
            //, if the switch is pressed (== false, because switch is inverted)
            ledPort.Write(switchPort.Read() == false);
        }
    }
}

After the output port for the LED is created as in the blink example, the input port is created for the on-board switch. In this case the glitch-filter is turned off, since bouncing of the switch contacts is not an issue here. The pull-up resistor inside the port of the MCU is disabled, since the on-board switch already has a pull-up resistor. More on this later. Important note: since the switch has a pull-up resistor, the value on the port is low/false when the switch is pressed; the value is high/true when it is released.

Using an InputPort, as shown above, the code is required to regularly read the input port to check if the switch has been pressed and act accordingly. An easier way is to use an InterruptPort, as shown below.

public class Program
{
    // initialize the onboard LED
    private static OutputPort ledPort = new OutputPort(Pins.ONBOARD_LED, false);
 
    public static void Main()
    {
        // initialize the onboard switch
        InterruptPort switchPort = new InterruptPort(Pins.ONBOARD_SW1, false,
                                                     Port.ResistorMode.Disabled,
                                                     Port.InterruptMode.InterruptEdgeBoth);
        // add an event-handler for the switch
        switchPort.OnInterrupt += new NativeEventHandler(switchPort_OnInterrupt);
 
        // wait forever...
        Thread.Sleep(Timeout.Infinite);
    }
 
    ///
    /// Event handler for the onboard switch.
    ///
    ///The port for which the event occurs.
    ///The state of the switch.
    ///Time of the event.
    private static void switchPort_OnInterrupt(uint port, uint data, DateTime time)
    {
        // turn the LED on, if the button is pressed (== 0, because switch is inverted)
        ledPort.Write(data == 0);
    }
}

In this version, an InterruptPort is created for the on-board switch, again with the glitch filter and the internal resistor disabled. The interrupt mode is set to both edges, meaning that an event is raised when the value on the port changes from low to high and when it changes from high to low. This allows us to respond when the switch is pressed and when it is released. In both cases, the OnInterrupt event is raised, for which a handler is registered. The handler turns the LED on or off depending on whether the switch is pressed or released.

In this example, the program enters sleep-mode as soon as the initialization of the ports is done. When an event is raised, the program wakes up, the handler is called and goes back to sleep again.

If you want to use your own switch, there are several ways to connect a switch to the Netduino (or a MCU in general), but a common way is shown in the schematic below.

As with the LED, you need to combine the switch with a resistor. Not only to restrict the current, but also to prevent a shortcut when the button is pressed. As with the on-board switch, because a pull-up resistor is used, the value at the port is high when the button is not pressed, and the value is low while the button is pressed.

You can connect the switch & resistor to any of the available ports A0-5 or D0-D13 , as long as you change the first argument of the InputPort or InterruptPort constructor to correspond with the selected port. E.g. when connected to the D0 port, the port should be constructed as follows:

InterruptPort switchPort = new InterruptPort(Pins.GPIO_PIN_D0, false,
                                             Port.ResistorMode.Disabled,
                                             Port.InterruptMode.InterruptEdgeBoth); 

Next: getting started with transistors.

Netduino - Getting Started

Last week I finally received my Netduino, after it had spent almost a week at customs :-(. I didn’t have much time last weekend, but luckily it doesn’t take much time to get started with the Netduino.

I also ordered a breadboard shield and a motor shield. The breadboard shield is very handy for experimenting small projects, but a separate breadboard is even better. And with some wiring you can use them together, of course.

How to install, connect, start coding, deploy and debug your Netduino projects is very well described in this document on the Netduino website. So there is no point in repeating that here. One tip though: use a separate solution for each project. You can add libraries to the solution of course. I started with a single solution with several projects, each representing a different hardware project. Even though I set a specific project as the ‘Startup Project’, Visual Studio still started the first project I added to the solution when I hit F5. A workaround is to select the correct project in the Solution Explorer, open it’s context-menu and select ‘Debug’, then ‘Start new instance’.

Blink a LED

The first program to run is of course the mandatory blinking of a LED. It is the ‘Hello World’ of the microcontrollers. Since the NetDuino has an on-board LED, this program can be run without any extra components. You can use the code from the Getting Started document mentioned before.

If you want to try to blink your own LED, don’t forget to combine it with a resistor (of about 1K) to restrict the current that will flow through the LED. Forgetting the resistor could ruin the LED, or worse, the port on your Netduino. Also, mind the polarity of the LED. The longest wire is the positive one. There are several ways you can connect the LED and resistor to any microcontroller, but usually it is done as shown below. This way the LED will be on when the port is high (true).

You can connect the LED & resistor to any of the available ports A0-5 or D0-D13 (the analog ports can be used for digital I/O as well), as long as you change the first argument of the OutputPort constructor to correspond with the selected port. E.g. when connected to the D0 port, the OutputPort should be constructed as follows:

OutputPort led = new OutputPort(Pins.GPIO_PIN_D0, false);

Next: getting started with switches.

TFS Scrumboard

One of the things I'm missing in Team Foundation, is an easy way to prioritize and plan workitems (user stories, tasks, bugs, etc.). The easiest way right now, is to open a workitem query in excel and edit the priority of each workitem. But that's not really easy. You need to change the priority field, making sure to provide a correct value that will put the workitem in the right position priority-wise. If you managed to pick the correct values, you need to sort the workitems; which is a manual action.

I would like to be able to drag & drop workitems in the correct position in the list. I don't care about the exact value of the priority field. I only care about the order in which the workitems show when they are sorted by priority. I would also like to be able to easily plan workitems, by moving workitems into (or out of) a specific iteration path. In my case that would be the product backlog and several sprint backlogs, but the functionality should be applicable to all process templates. Finally, I would like to have some sort of status- or scrumboard. Each possible status for workitems is a column on the board and each workitem is represented by some form of card. By moving a workitem card into a specific column, the status of that workitems changes accordingly. We use physical (white)boards, with a recent print-out of the sprint burndown in some corner, but they are of course not connected to TFS.

I did some research on how to build such functionality and, especially, on how to integrate it into TFS Web Access and/or Sharepoint. I quickly found that TFS Web Access would be the easiest way, for me at least :-P. Last month I started a project on codeplex: TFS Scrumboard. Below is a short description and a screenshot.

Project Description
TFS Scrumboard is an extension to TFS 2010 Web Access, providing easy planning and managing of workitem progress.

TFS Scrumboard is build (in C#) as an extension to TFS 2010 Web Access. It is designed to be used in scrum projects, using one of the many scrum process templates available. I use my own custom scrum process template, to support the way we do scrum projects, but no dependency on any kind of process template is assumed.

When installed, TFS Scrumboard provides two extra tabs in TFS Web Access: Planning and Tasks.

The Planning tab is meant for planning and prioritizing workitems. It shows the product backlog and each sprint backlog on the left side, and the workitems in a selected (product/sprint) backlog on the right side. A workitem can be planned by moving it to (dropping it on) a specific sprint backlog or removed from planning by moving it to the product backlog. A workitem can be prioritized by dragging-and-dropping it in the desired position inside a (product/sprint) backlog.

The Tasks tab is meant for managing the progress of workitems during a sprint. It shows vertical swimminglanes which represents one or more statusses of the workitems in a specific sprint. The status of a workitem can be changed by dragging-and-dropping it in the desired swimminglane. A workitem can be prioritized by dragging-and-dropping it in the desired position (vertically).

Goals

  • Planning work items, by dragging-and-dropping them into a specific (product or sprint) backlog
  • Prioritizing work items, by dragging-and-dropping them into the desired order
  • Manage sprint progress, by dragging-and-dropping them into the corresponding swimminglane
  • Print workitem cards, to be used on a RL scrumboard (if possible with a link back to TFS, using a camera, some form of (RFID?) tags or (2D?) barcodes)

 

TFS 2010 - Moving Sharepoint to another server

The last few months, we used a single server for our first TFS installation to host both TFS 2010 and Sharepoint 2010. We started with the single server because of lack of resources on the virtual hosts, and I couldn't wait for the new hardware to arrive :-P.

Today I moved the Sharepoint server to a new dedicated virtual machine. Only a few team projects with a team portal exist yet and since most portals don't have any content except the dashboards, I decided to simply recreate the team portals on the new machine and copy any content manually.

The installation and configuration of the new Sharepoint 2010 server was quick and without problems. We also changed the NAT of the firewall to point our external IP & domainname to the new server, again without any problems.

Then it was time to install & configure the Sharepoint extensions as well as reconfigure the integration with Sharepoint for TFS 2010. I encountered some errors during this part that we quickly fixed, but learned a few lessons that might be usefull for others.

TF250049 & TF25006

The first error happened during the configuration of the TFS Sharepoint extensions on the new Sharepoint machine. Error TF250049 (the URL for Team Foundation Server could not be verified), which in turn was caused by error TF250067 (No connection could be made). This error was solved by first changing the 'Sharepoint Web Applications' configuration on the TFS machine. By adding the new Sharepoint web application (or changing the existing one) the service accounts used by Sharepoint are granted access to TFS.

TF250067 and not associated project portals

Before (re)creating the site collection and project portal sites, you need to add the TFS service account to the farm administrators group in Sharepoint. This will prevent TF250067 errors during the creation of the project portals. The project portal will be created, but without a working association with TFS.

If this happened to you, delete the project portal site before recreating it, again.

Team Project Site collection

To recreate the site collection, navigate to the team project collection in the 'Team Project Collections' node in the TFS admin console and select the SharePoint Site tab. Select 'Edit Default Site Location' (, make any changes to the Default Site Location if you want) and click OK. Since the Sharepoint is a fresh install, you will be prompted to create a new site. This is the site(-collection) for the team project collection, that will contain all the project portals within the team project collection.

Project Portals

The easiest way to recreate the project portals, is to use the tfpt command-line tool that is part of the Team Foundation Power Tools (which can be downloaded from the Visual Studio Gallery). You can easily see what arguments must and can be provided by executing: tfpt addprojectportal /?, but here is some extra information.

The collection argument is the uri of the TFS server, as you configured them e.g. in the Team Explorer. Examples:
/collection:http://tfs.domain.local:8080/tfs
/collection:https://tfs.domain.com/tfs

The teamproject argument specifies the name of the team project. Of course, you need to put the name between quotes if it contains spaces. Examples:
/teamproject:MyProject
/teamproject:"My Other Project"

The processtemplate argument specifies the name of the process template. Again, use quotes if it contains spaces. Examples:
/processtemplate:"MSF for Agile Software Development v5.0"
/
processtemplate:"Quintor Scrum 0.8"

If you want to create the portal on a different url, e.g. team project name contains spaces and you do not want those in the url of the project portal, provide both the webapplication and the relativepath arguments.

The webapplication argument specifies the url of the web application (and not the name as the usage help says). Examples:
/webapplication:http://sharepoint.domain.local
/webapplication:https://projects.domain.com

The relativepath specifies the path to the project portal. Examples:
/relativepath:/sites/DefaultCollection/MyProject
/relativepath:/sites/Quintor/MyOtherProject