Embedded Developer

In the previous posts a prototype output expander module was put together on breadboard and connected to the Netduino Go!. A small module driver was developed for the Netduino GO! and the STM8S. This video shows the basic module working:

The next stage in the process is to make the final design decisions and produce a prototype PCB.

Design Criteria

The criteria as defined in the first post stated that the hardware should provide at least 16 digital outputs using low cost components. The breadboard prototype produced shows that we can certainly control 16 digital outputs using the common shift register.

One possible extension is to use more shift registers than were used in the breadboard prototype. This will produce a module with more outputs. A quick look at a local suppliers web site shows that these can obtained for a relatively modest cost. Adding a further two shift registers will take the outputs from 16 to 32.

The prototype shows which pin is being activated by a LED. The LED circuit includes a resistor and MOSFET/Transistor to allow the power for the LED to be provided by an external power supply rather than the 74HC595. Doing this allows the use of LEDs which would exceed the maximum power rating of the 74HC595. Although it should be possible to include these components (resistor and MOSFET) in the final design, they will be omitted in order to reduce the production costs.

In summary:

1. Use the STM8S as it is low cost and powerful enough for this task
2. 32 digital output (4 shift registers)
3. Use 0.1" connectors to the board can be used in breadboard prototyping

PCB Design Software

Over the past few years I have spent a fair amount of time looking for the right PCB design software. I have looked at the following:

• Eagle PCB
• KiCad
• DesignSpark

There are also several other packages available but these seem to be the three main packages offering free version of their software. Being a hobbyist price is a critical factor in the choice of software to use.

Eagle PCB is available as a free personal edition. The software and licence are both restricted in some way. I have also found the interface to be exceedingly difficult to use. As a long time user of Windows applications the interface in Eagle PCB is counter-intuitive.

KiCad is free and looks to be well supported but I found the interface difficult to use.

DesignSpark looks to be well supported and has gone through several revisions, one major revision in the time in which I have been using the software.

Of the three packages I have settled on using DesignSpark for the following reasons:

• The interface is the most "standard Windows" like of the three packages
• Free licence with no restrictions
• Eagle parts can be imported into the library
• Additional DesignSpark libraries are also available including one for Sparkfun’s components and boards

DesignSpark is not restricted to producing just the PCB design file but can also render a 3D image of the final PCB. This allows you to visualise how the final board will look. The interface allows the board to be rotated and viewed from an infinite number of points of view.

Schematic

DesignSpark is fairly intuitive to use and there are a number of tutorials and how to guides available and so I will not go into too much detail regarding using the package. There is one tip I would like to give and that is use nets.

Using nets allows the design file to be simplified greatly. You can break the design down into a number of logical components. Consider our design, this breaks down into the following three sections:

1. STM8S and connector for the GoBus
2. Shift registers
3. Connectors for the digital outputs

Now before I discovered how the nets feature works I would have dropped the components for the STM8S and connector on the schematic and then wired them together.

Next I would have dropped the first of the shift registers onto the schematic and started to connect this to the STM8S. I would have then repeated this with the next shift register (connecting it to the first) and so on. The end result would have been a schematic which was difficult to read due to the number of connecting wires.

This can be simplified by the use of nets and input/output connectors/pins. So lets have a look at how this appears for the first of out logical blocks, the STM8S and the GoBus connector:






STM8S Showing Pin Labels

Looking at the above image you should note that the STM8S has two different connections, an un-named wire which goes off to another part of the circuit (i.e. pins PD5, PD6 etc.) and connections which are terminated with a name (i.e. PD3 is connected to something called SRClockOut).

The connections which go off of the image are standard interconnects between the various components on the board. These interconnects have been restricted to connecting components in our logical function block (STM8S and GoBus connector). This includes any components required to support the STM8S such as capacitors etc.

The second group of pins which go to named connections go to either an input or output pin. The names represent the function of the signal; so SRClockOut is the Shift Register Clock Output from the STM8S. If we look at the first shift register you will see that it has an input pin SR1ClockIn (Shift Register 1 Clock Input):



Shift Register Showing Net Names

We have two pins which have two different names but if we were to look at their properties we would find that they have both been connected to the same net, SRClock Shift Register Clock. By doing this the software knows that the two pins are in fact connected.

This process has been repeated and a number of nets have been created, some have only two pins on them (the data output from the STM8S – SRData – is only connected to the input of shift register 1), others have several (the SRClock net connected the STM8S clock output pin to the clock input of all of the shift registers).

Using nets simplifies the schematic and makes it easier to read. Using a standard naming convention for the input and output pins means that you should always be clear on which pins should be connected. It does add a new task to the design process. With a number of the pins named rather than connected you will need to verify that the pins are connected correctly.

For a small schematic like this one the process of checking the connections is relatively simple. The software allows a component (or net) to be selected from a list of all of the components/nets in the circuit. A part/net is then highlighted on the schematic once it has been selected:






Net Selection

The above diagram shows that the net SR4DataOut has been selected; see the blue highlighted name in the list at the right of the image. The green connections on the schematic show which pins are connected to the SR4DataOut net. Checking is then a case of repeating the process for each of the nets and noting which connections are highlighted.

The final schematic for the module looks like this:



Schematic

A PDF version is also available as this may be difficult to read.

Conclusion

Now that we have the schematic we can translate this board into a PCB and from there we can get a 3D view of the board. Here is a sneak preview of the board in 3D:



Output Expander – 3D View

In the next post we shall have a look at taking the schematic and laying out the PCB.

In the previous post a prototype for the multiple digital outputs was developed and implemented on breadboard. The STM8S code was independent and demonstrated that two chained 74HC595 shift registers could be controlled by bit-banging data through GPIO pins on the STM8S.

In this post we will continue the development of the module by merging the code from the previous post with the STM8S module code from the post STM8S SPI Slave (Part 3) – Making a Go Module. We will develop both the STM8S code and the NETMF driver to implement the following functionality:

• Clear the shift registers
• Set the outputs of the two shift registers

These two functions are already in the standalone version of the STM8S code and it should be a relatively simple exercise to merge this functionality with the Netduino Go Bus communication protocol.

STM8S Application

The first task to be completed for the STM8S code is to create a new project and add the code from the post STM8S SPI Slave (Part 3) – Making a Go Module. The two functions should then be removed and the two new ones we are implementing should be added.

Start a New Project

Start a new STM8S project and save the project into a new directory. Now take the source code in main.c from the project STM8S SPI Slave (Part 3) – Making a Go Module and paste over the code in you new project. Ensure that the project is targeting the correct microcontroller and save the project.

Alternatively, copy the project code from STM8S SPI Slave (Part 3) – Making a Go Module into a new directory.

Remove Dummy Functionality

The project code in the STM8S module post contained a couple of dummy functions illustrating the concept of module functionality and communications. This code should be removed and the application stripped down to the basics required for SPI communication with the Netduino Go!.

Add New Functionality

The final task is to add the code which implements the new functionality as defined for the basic module (i.e. clear the shift registers and set the outputs of the shift registers).

The first thing which is required is to add the #define statements to support the bit-banging:

//--------------------------------------------------------------------------------
//
//  Pins which we will be using for output the data to the shift registers.
//
#define SR_CLOCK            PD_ODR_ODR3
#define SR_DATA             PD_ODR_ODR2
#define SR_CLEAR            PC_ODR_ODR3
#define SR_OUTPUT_ENABLE    PC_ODR_ODR4
#define SR_LATCH            PD_ODR_ODR4

The InitialisePorts method will also need to be modified in order to ensure that the ports above are all setup correctly. We need these to be output ports capable of running at up to 10MHz. The code becomes:

//--------------------------------------------------------------------------------
//
//  Initialise the ports.
//
void InitialisePorts()
{
    //
    //  Initialise Port D.
    //
    PD_ODR = 0;             //  All pins are turned off.
    PD_DDR = 0xff;          //  All pins are outputs.
    PD_CR1 = 0xff;          //  Push-Pull outputs.
    PD_CR2 = 0xff;          //  Output speeds up to 10 MHz.
    //
    //  Initialise Port C.
    //
    PC_ODR = 0;             //  Turn port C outputs off.
    PC_DDR = 0x18;          //  PC3 & PC4 initialised for output.
    PC_CR1 = 0x18;          //  PC3 & PC4 Push-Pull outputs
    PC_CR2 = 0x18;          //  PC3 & PC4 can run up to 10MHz.
    //
    //  Initialise the CS port for input and set up the interrupt behaviour.
    //
#if defined(DISCOVERY)
    PB_ODR = 0;             //  Turn the outputs off.
    PB_DDR = 0;             //  All pins are inputs.
    PB_CR1 = 0xff;          //  All inputs have pull-ups enabled.
    PB_CR2 = 0xff;          //  Interrupts enabled on all pins.
    EXTI_CR1_PBIS = 2;      //  Port B interrupt on falling edge (initially).
#else
    PA_ODR = 0;             //  Turn the outputs off.
    PA_DDR = 0;             //  All pins are inputs.
    PA_CR1 = 0xff;          //  All inputs have pull-ups enabled.
    PA_CR2 = 0xff;          //  Interrupts enabled on all pins.
    EXTI_CR1_PAIS = 2;      //  Port A interrupt on falling edge (initially).
#endif
}

The application will also need some storage space for the data in the shift registers:

//--------------------------------------------------------------------------------
//
//  Number of registers in the chain.
//
#define NUMBER_OF_REGISTERS     2
//
//  Data area holding the values in the register.
//
U8 _registers[NUMBER_OF_REGISTERS];             //  Data in the shift registers.

Note that the variable used to store the data in the registers has been converted into a static array instead of a variable sized array using malloc.

The function table needs to be modified to hold the references to the methods which will implement the module functionality:

//
//  Forward function declarations for the function table.
//
void SetShiftRegisters();
void ClearShiftRegisters();
//
//  Table of pointers to functions which implement the specified commands.
//
FunctionTableEntry _functionTable[] = { { 0x01, ClearShiftRegisters }, { 0x02, SetShiftRegisters } };

The next step is to add the methods which will implement the functionality:

//--------------------------------------------------------------------------------
//
//  Clear the shift registers.
//
void ClearRegisters()
{
    for (U8 index = 0; index < NUMBER_OF_REGISTERS; index++)
    {
        _registers[index] = 0;
    }
}

//--------------------------------------------------------------------------------
//
//  GO! Function 1 - Clear the shift registers.
//
void ClearShiftRegisters()
{
    ClearRegisters();
    OutputData();
    NotifyGOBoard();
}

Note that the functionality has been implemented using two methods, the first ClearRegisters is the internal implementation. This is independent of the Netduino Go! communications and allows the functionality to be called in say the initialisation code of the module. The second method, ClearShiftRegisters is the method which is called by the code as determined by the Netduino Go! driver code. This has the additional output and notification methods which actually sets the data in the shift registers and sends a signal back to the Netduino Go! to let the board know that the request has been received and processed. Note that this split is not necessary but is a design decision taken for this particular module.

The code should be ready to compile and deploy to the STM8S.

Netduino Go! Driver

At this point we should have one half of the communications channel ready to test. The second stage is to implement the driver on the Netduino Go!. As our starting point, we will copy the code from the BasicGoModule class in the post STM8S SPI Slave (Part 3) – Making a Go Module into a new class OutputExpander. We will modify this to add create new functionality to clear and set the shift registers.

Command Constants

The first this we need to do is to remove the old command constants and add two new ones:

/// <summary>
/// Command number for the ClearShiftRegister command.
/// </summary>
private const byte CMD_CLEAR_REGISTERS = 1;

/// <summary
/// Command number for the SetRegister command.
/// </summary>
private const byte CMD_SET_REGISTERS = 2;

Modify the Supporting Methods

The existing code in the module can be optimised for this module. To do this rename the WriteDataToModule method to WriteDataToSPIBus. Now add the following code:

/// <summary>
/// Write the data in the _writeFrameBuffer to the module.  Make several
/// attempts to write the data before throwing an exception.
/// </summary>
/// <param name="exceptionMessage">Exception message to the used in the constructor if the write attempt fails.</param>
private void WriteDataToModule(string exceptionMessage)
{
    int retriesLeft = 10;
    bool responseReceived = false;

    WriteDataToSPIBus();
    while (!responseReceived && (retriesLeft > 0))
    {
        //
        //  We have written the data to the module so wait for a maximum 
        //  of 5 milliseconds to see if the module responds with some 
        //  data for us.
        //
        responseReceived = _irqPortInterruptEvent.WaitOne(5, false);
        if ((responseReceived) && (_readFrameBuffer[1] == GO_BUS10_COMMAND_RESPONSE))
        {
            //
            //  Assume good result, it is up to the calling method to determine if
            //  the command has been executed correctly.
            //
            return;
        }
        else
        {
            //
            //  No response within the 5ms so lets make another attempt.
            //
            retriesLeft--;
            if (retriesLeft > 0)
            {
                WriteDataToSPIBus();
            }
        }
    }
    throw new Exception(exceptionMessage);
}

By making this change we are also making the assumption that the signal back from the module (via the interrupt) is always indicating success. This is a decision which is appropriate for this module but may not be appropriate for other applications/modules.

Add New Functionality

Before adding new functionality it is necessary to remove the existing AddFive functionality from the BasicGoModule.

Out OutputExpander module will provide the application with two basic functions:

• Clear – clear the shift registers setting the output to 0
• Set – Set the values in the shift registers to those specified by the parameters

This functionality is provided by the following code:

/// <summary>
/// This method calls the ClearRegister method on the GO! module and then waits for the
/// module to indicate that it has received and executed the command.
/// </summary>
public void Clear()
{
    _writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
    _writeFrameBuffer[1] = CMD_CLEAR_REGISTERS;
    WriteDataToModule("Clear cannot communicate with the Output Expander module");
}

/// <summary>
/// Set the shift registers using the values in the byte array.
/// </summary>
/// <param name="registers">Bytes containing the shift register values.</param>
public void Set(byte[] registers)
{
    if (registers.Length != 2)
    {
        throw new ArgumentException("registers: length should be 2 bytes");
    }
    _writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
    _writeFrameBuffer[1] = CMD_SET_REGISTERS;
    for (int index = 0; index < registers.Length; index++)
    {
        _writeFrameBuffer[2 + index] = registers[index];
    }
    WriteDataToModule("Clear cannot communicate with the Output Expander module");
}

Testing

At this point we should be able to add some code the Main method of the application to test the module. We will perform something similar to the code in the previous post, we will move a single LED but this time we will illuminate the LED starting a position 15 and working down to 0. This should ensure that we have deployed new code to both the module and the Netduino Go! board.

public static void Main()
{
    OutputExpander output = new OutputExpander();
    int cycleCount = 0;
    byte[] registers = new byte[2];
    while (true)
    {
        Debug.Print("Cycle: " + ++cycleCount);
        for (int index = 15; index >= 0; index--)
        {
            output.Clear();
            if (index < 8)
            {
                registers[0] = (byte) (1 << index);
                registers[1] = 0;
            }
            else
            {
                registers[0] = 0;
                registers[1] = (byte) (1 << (index - 8));
            }
            output.Set(registers);
            Thread.Sleep(200);
        }
    }
}

The test breadboard and Netduino Go! were connected through the Komodex GoBus Breakout Module. This allows the Netduino Go! and the ST-Link/2 programmer to be connected to the breadboard:

Output Expander Connected to Netdunio GO!

And here is a video of this working:

You can just see the Netduino Go! in the bottom left corner of the video.

Conclusion

At this point the basic concept has be proven and the application can perform the following:

1. STM8S code can control one or more LEDs
2. STM8S can be controlled using SPI
3. Netduino Go! can pass instructions to the STM8S

One thing that did become apparent during this part of the process was that both the STM8S code and the Netduino code can be improved by improved grouping the functionality. For instance, in order to add the methods to the function table in the STM8S code I had to jump around the source code a little.

The next step in the process is to look at the hardware and start to prepare for prototype PCB manufacture.

So the first stage in the development process (now we have the concept) is to develop a working prototype on breadboard. This will show if we can make the hardware and software work as we want to achieve the desired goals.

Connecting up a Single 74595

For the first stage we will connect up a single 74HC595 shift register to a STM8S chip and write some software for the chip. We are not going to consider connecting the STM8S to other chips/controllers at the moment, we are simply going to output some known data to the shift register and see how it responds.

As this is a simple digital output board we can show the output from the system by using some LEDs. This will also allow us to test one of the secondary objectives, namely the ability to control a reasonable amount of current. The standard 74HC595’s will supply/sink up to 25mA per pin. However, the chip is only rated at 150mW. Turning on all of the pins will over drive the chip. So to get around this we will drive the LEDs through a transistor/MOSFET.

Breadboard Prototype

Looking at the data sheet for the 74HC595 we have 5 control signals to connect to the STM8S:

The serial input lines of the 74HC595 lend themselves to the using the SPI bus in order to send data to the shift registers. We will not be able to use SPI in this case as we will need to reserve this for communication with the Netduino Go!.

Connecting the 74HC595

The second shift register should be connected to the same signals as the first except the serial data in line. This should be connected to the serial data output line of the first shift register. In this way the data is cascaded from the first register to the second and so on. The resultant schematic looks this this:

Shift Register Schematic

The next task is to connect the shift registers to the STM8S. As SPI is already reserved for communicating with the Netduino Go! the data will have to be transferred by bit-banging the data. The following connections should be made between the STM8S and the first 74HC595:

The above schematic becomes:

STM8S and Shift Registers Schematic

Connecting the LEDs

Visual output from the shift registers will be provided by a number of LEDs. In order to reduce the current drawn from the shift registers the LEDs will be driven by a transistor/MOSFET.

Full Circuit

When assembled, the full circuit looks something like this:

Prototype On Breadboard

Software

A small application is required to test the circuit. The first stage is to verify that the STM8S can communicate with the shift registers. The application will simply turn on the various LEDs connected to the shift registers in turn.

Firstly, we need some #define statements to make the code more readable.

#define SR_CLOCK            PD_ODR_ODR3
#define SR_DATA             PD_ODR_ODR2
#define SR_CLEAR            PC_ODR_ODR3
#define SR_OUTPUT_ENABLE    PC_ODR_ODR4
#define SR_LATCH            PD_ODR_ODR4

The application will use a small array of bytes to indicate the status of each pin on the shift register. A small helper function will allow the previous contents of the register to be cleared:

//
//  Clear all of the bytes in the registers to 0.
//
void ClearRegisters(U8 *registers, U8 numberOfBytes)
{
    for (U8 index = 0; index < numberOfBytes; index++)
    {
        registers[index] = 0;
    }
}

The final helper function will output the data to the shift registers:

//
//  BitBang the data through the GPIO ports.
//
void OutputData(U8 *data, int numberOfBytes)
{
    //
    //  Initialise the shift register by turning off the outputs, clearing
    //  the registers and setting the clock and data lines into known states.
    //
    SR_OUTPUT_ENABLE = 1;               //  Turn off the outputs.
    SR_LATCH = 0;                       //  Ready for latching the shift register into the storage register.
    SR_DATA = 0;                        //  Set the data line low.
    SR_CLOCK = 0;                       //  Set the clock low.
    SR_CLEAR = 0;                       //  Clear the shift registers.
    __no_operation();
    SR_CLEAR = 1;
    //
    //  Output the data.
    //
    for (int currentByte = 0; currentByte < numberOfBytes; currentByte++)
    {
        U8 b = data[currentByte];
        for (int index = 7; index >= 0 ; index--)
        {
            SR_DATA = ((b >> index) &amp; 0x01);
            SR_CLOCK = 1;               //  Send a clock pulse.
            __no_operation();
            SR_CLOCK = 0;
        }
    }
    //
    //  Set the clock line into a known state and enable the outputs.
    //
    SR_CLOCK = 0;                       //  Set the clock low.
    SR_LATCH = 1;                       //  Transfer the data from the shift register into the storage register.
    SR_OUTPUT_ENABLE = 0;               //  Turn on the outputs.
}

The final code required is the main program loop which will drive the shift registers:

//
//  Main program loop.
//
void main()
{
    //
    //  Initialise the system.
    //
    __disable_interrupt();
    InitialiseSystemClock();
    //
    //  PD3 and PD2 are used for the serial data going to the registers.
    //  Configure Port D for output.
    //
    PD_ODR = 0;             //  All pins are turned off.
    PD_DDR = 0xff;          //  All pins are outputs.
    PD_CR1 = 0xff;          //  Push-Pull outputs.
    PD_CR2 = 0xff;          //  Output speeds up to 10 MHz.
    //
    //  PB4 and PB5 are used for control of the output and clearing the
    //  registers.  Configure Port B for output.
    //
    PC_ODR = 0;             //  All pins are turned off.
    PC_DDR = 0xff;          //  All pins are outputs.
    PC_CR1 = 0xff;          //  Push-Pull outputs.
    PC_CR2 = 0xff;          //  Output speeds up to 10 MHz.
    __enable_interrupt();
    //
    //  Main loop really starts here.
    //
    numberOfRegisters = 2;
    registers = (U8 *) malloc(numberOfRegisters);
    ClearRegisters(registers, numberOfRegisters);
    OutputData(registers, numberOfRegisters);
    while (1)
    {
        int counter = 0;
        while (counter < 16)
        {
            ClearRegisters(registers, numberOfRegisters);
            if (counter < 8)
            {
                registers[0] = (1 << counter);
            }
            else
            {
                registers[1] = (1 << (counter - 8));
            }
            counter++;
            OutputData(registers, numberOfRegisters);
            for (long index = 0; index < 100000; index++);
        }
    }
}

The code above turns on an LED, pauses and then moves on to the next LED. This is repeated until all of the LEDs have been illuminated. The cycle then repeats from the start. The following video shows this working:

Conclusion

At this point we have proven that the STM8S can be connected to the shift registers and we can turn on one of more LEDs connected to the output of the shift registers.

The next post in this series will connect the STM8S to the Netduino Go! and present a basic driver for the Netduino Go!, enough to illustrate that the Netduino Go! can control the shift registers.

This series of posts will examine the activities required to take the concept of a module for the Netduino GO! through to production.

Project Definition

A simple project will allow the series of posts to concentrate on the principles required for the production of a Netduino GO! module without being too distracted by the functional aspects of the module. The following project definition should meet this brief:

• Provide 16 or more digital outputs
• Work with the Netduino GO!
• Low cost manufacture
• Use simple tried and tested components/techniques

Meeting the Objectives

As you can no doubt see, this is a reasonably simple project and with the exception of cost, we should have no major problems reaching the objectives. The most obvious solution to this problem is to look at using 74HC595 serial to parallel chips. These are cheap components and the techniques needed to solve this type of problem are tried and tested. The project definition looks like the counting example which is discussed in the Counting Using 74HC595 Shift Registers post with the addition of the Netduino Go! functionality.

Project Plan

Initial assessment of the project indicates that the following steps are required in order to take the project from concept to manufacture:

1. Build a hardware prototype using the STM8S103F3 to control two shift registers. This will have some form of visual output to prove that we can control the digital lines (probably some LEDs)
2. Write the software for the STM8S which will control the output of the 74HC595 chips
3. Generate the schematic for the board
4. Layout a prototype board and send to manufacture
5. Write the software for the Netduino GO! while waiting for the manufactured boards to turn up
6. Assemble a prototype on one of the prototype boards
7. Conclusion

The first post in the series will build the breadboard prototype and start to control the LEDs using the STM8S.

A few days ago in the Netduino chat room we were discussing a problem with the Timer class. Should be a simple problem to solve as I had used timers in .NET applications many times. A short while later it became obvious that the Timer class was not as easy to use as I thought. In this post we will look at the NETMF implementation of the Timer class and how it can be used.

In all of the examples below I will be working on a 50% duty cycle. So a 100 Hertz signal should be 10ms between the rising edges of the signal where the signal will be high for 5ms followed by low for 5ms.

All of the following examples will run on the Netduino Plus 2.

Setting up a Simple Timer

The basic timer constructor takes four parameters:

• Callback
• User defined object
• Delay
• Period

Callback

The Callback parameter is a TimerCallback object. This will be called by the Timer at the period defined by the period parameter.

User defined object

This is an object defined by the user and can be used to identify the source of the callback. Initially we will be setting this to null as we will not be using it.

Delay

The number of milliseconds to pause before the callback method is called.

Period

Period (in milliseconds) between invocations of the Callback method.

So now we know how this should work, let’s jump in with a simple example. Here we will generate a 100Hz signal and we will start the timer immediately. The code for this will look like this:

using System;
using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace BasicTimer
{
    public class Program
    {
        private static Timer oneHundredHertzTimer = null;
        private static OutputPort oneHundredHertzPulse = null;
        private static TimerCallback timerCallback = null;
        private static OutputPort trigger = null;

        public static void Main()
        {
            trigger = new OutputPort(Pins.GPIO_PIN_D1, false);
            timerCallback = new TimerCallback(TimerInterrupt);
            oneHundredHertzPulse = new OutputPort(Pins.GPIO_PIN_D7, false);
            trigger.Write(true);
            trigger.Write(false);
            oneHundredHertzTimer = new Timer(timerCallback, null, 0, 5);
            Thread.Sleep(Timeout.Infinite);
        }

        private static void TimerInterrupt(object state)
        {
            oneHundredHertzPulse.Write(!oneHundredHertzPulse.Read());
        }
    }
}

The trigger pin is simply used to indicate the start of the program run. This is used to allow the logic analyser to start data capture.

If we hook up the logic analyser we should get a trace which looks something like the following:

Basic Timer

The top trace shows the trigger pulse whilst the trace below shows the output from the timer callback. If we expand the start of the trace we see the following:

Timer with trigger

As you can see, there is a small pulse (the trigger) at the start followed by the pulses generated by the timer. The timer between the falling edge of the trigger and the rising edge of the first pulse generated by the timer is approximately 16us. This can be put down to the amount of time it takes for the NETMF instructions to complete the construction of the timer. So the first thing the timer does is to invoke the callback method defined in the constructor.

If we modify the construction of the timer slightly we can see the impact of the delay parameter. Let’s change the construction to the following:

oneHundredHertzTimer = new Timer(timerCallback, null, 50, 5);

If we run this application (see the project BasicTimerWithDelay) we will see the following in the logic analyser:

As you can see, the start of the timer has been delayed by 50ms.

Two Timers, One Interrupt

In this example we will look at the role the user defined object has in the TimerCallback parameter. This object can be used to allow the system to use a single callback from multiple timers. The object can be used to determine which timer invoked the callback.

The user defined object is an instance of an object which is passed to the callback method when it is called. In the following we start with an enum:

private enum TimerState { OneHertz, TwoHertz };

Now when we create the timers we create a new object and pass this into the constructor. Our constructors look like the following:

TimerState oneHertzState = TimerState.OneHertz;
oneHertzTimer = new Timer(timerCallback, oneHertzState, 0, 500);

TimerState twoHertzState = TimerState.TwoHertz;
twoHertzTimer = new Timer(timerCallback, twoHertzState, 0, 250);

for the two hertz timer.

As you can see, both timers have the same method being invoked as the callback method. However, each timer will pass in a different object (albeit of the same type) to the callback method. We can then use this parameter to determine the action we should take. The code for the callback method will look like the following:

private static void TimerInterrupt(object state)
{
	switch ((TimerState) state)
	{
		case TimerState.OneHertz:
			oneHertzPulse.Write(!oneHertzPulse.Read());
			break;
		case TimerState.TwoHertz:
			twoHertzPulse.Write(!twoHertzPulse.Read());
			break;
	}
}

The full application is as follows:

using System;
using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace TimerExample
{
    public class Program
    {
        private static Timer oneHertzTimer = null;
        private static OutputPort oneHertzPulse = null;

        private static Timer twoHertzTimer = null;
        private static OutputPort twoHertzPulse = null;
        
        private static TimerCallback timerCallback = null;

        private enum TimerState { OneHertz, TwoHertz };

        private static OutputPort trigger = null;

        public static void Main()
        {
            trigger = new OutputPort(Pins.GPIO_PIN_D1, false);
            timerCallback = new TimerCallback(TimerInterrupt);
            trigger.Write(true);
            trigger.Write(false);
            //
            //  Set up the one hertz timer.
            //
            oneHertzPulse = new OutputPort(Pins.GPIO_PIN_D7, false);
            TimerState oneHertzState = TimerState.OneHertz;
            oneHertzTimer = new Timer(timerCallback, oneHertzState, 0, 500);
            //
            //  Set up the two hertz timer.
            //
            twoHertzPulse = new OutputPort(Pins.GPIO_PIN_D6, false);
            TimerState twoHertzState = TimerState.TwoHertz;
            twoHertzTimer = new Timer(timerCallback, twoHertzState, 0, 250);
            //
            Thread.Sleep(Timeout.Infinite);
        }

        private static void TimerInterrupt(object state)
        {
            switch ((TimerState) state)
            {
                case TimerState.OneHertz:
                    oneHertzPulse.Write(!oneHertzPulse.Read());
                    break;
                case TimerState.TwoHertz:
                    twoHertzPulse.Write(!twoHertzPulse.Read());
                    break;
            }
        }
    }
}

If we run this application we will see the following on the logic analyser:

Two timers with one interrupt.

As you can see, we are generating a one and a two hertz signal using a single callback.

Stopping A Timer

So far we have considered starting a timer and the various options for delaying and callbacks. There will come a point where we will want to stop a timer from executing. A quick glance through the methods provided for the Timer class reveals that there is no method do do this. In this scenario, the first instinct is to simply set the variable referencing to the object to null.

So if we take the first example as out starting point we will add a small amount of code to deal with a button press. The idea is that when the user presses the onboard button on the Netduino Plus 2, the application will terminate the timer by setting to timer object to null. The code becomes:

using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;
using Microsoft.SPOT;

namespace StoppingATimer
{
    public class Program
    {
        private static Timer oneHundredHertzTimer = null;
        private static OutputPort oneHundredHertzPulse = null;
        private static TimerCallback timerCallback = null;
        private static InterruptPort button = null;

        public static void Main()
        {
            timerCallback = new TimerCallback(TimerInterrupt);
            oneHundredHertzPulse = new OutputPort(Pins.GPIO_PIN_D7, false);
            button = new InterruptPort(Pins.ONBOARD_BTN, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeHigh);
            button.OnInterrupt += new NativeEventHandler(button_OnInterrupt);
            oneHundredHertzTimer = new Timer(timerCallback, null, 0, 5);
            Thread.Sleep(Timeout.Infinite);
        }

        private static void button_OnInterrupt(uint data1, uint data2, System.DateTime time)
        {
            oneHundredHertzTimer = null;
            Debug.Print("Timer set to null.");
        }

        private static void TimerInterrupt(object state)
        {
            oneHundredHertzPulse.Write(!oneHundredHertzPulse.Read());
        }
    }
}

If you deploy this application to the Netduino Plus 2 you will see the same output (on the logic analyser) as the first example in this post. Namely, a 100Hz square wave with a 50% duty cycle.

So the next thing to try is pressing the button and see what happens. If everything works as expected then the timer should be set to null and the timer should terminate. So let’s press the button and start the logic analyser.

And the timer keeps on running. In order to kill the timer we must ensure that it is disposed of correctly. We can do this by modifying the button interrupt method as follows:

private static void button_OnInterrupt(uint data1, uint data2, System.DateTime time)
{
	oneHundredHertzTimer.Dispose();
	oneHundredHertzTimer = null;
	Debug.Print("Timer set to null.");
}

Running the application again and pressing the button results in the expected behaviour.

Changing the Frequency

In our final example we will look at changing the frequency of the timer. This example uses the button press interrupt from the previous example but this time it will halve the period (i.e. double the frequency of the output signal) of the timer. The application uses the Change method to change the timer on the fly. So let’s dive straight in with some code:

using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;
using Microsoft.SPOT;

namespace ChangingTheFrequency
{
    public class Program
    {
        private static Timer frequencyGenerator = null;
        private static OutputPort frequencyGeneratorOutput = null;
        private static TimerCallback timerCallback = null;
        private static InterruptPort button = null;
        private static int currentPeriod;

        public static void Main()
        {
            timerCallback = new TimerCallback(TimerInterrupt);
            frequencyGeneratorOutput = new OutputPort(Pins.GPIO_PIN_D7, false);
            button = new InterruptPort(Pins.ONBOARD_BTN, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeHigh);
            button.OnInterrupt += new NativeEventHandler(button_OnInterrupt);
            currentPeriod = 500;
            frequencyGenerator = new Timer(timerCallback, null, 0, currentPeriod);
            Thread.Sleep(Timeout.Infinite);
        }

        private static void button_OnInterrupt(uint data1, uint data2, System.DateTime time)
        {
            if (currentPeriod > 100)
            {
                currentPeriod /= 2;
                frequencyGenerator.Change(0, currentPeriod);
            }
        }

        private static void TimerInterrupt(object state)
        {
            frequencyGeneratorOutput.Write(!frequencyGeneratorOutput.Read());
        }
    }
}

As you can see the code is relatively straight forward. Connecting up the logic analyser and running the application generates a 1 Hz signal (500ms period will result in 1Hz). Pressing the button on the Netduino Plus 2 will cause the period to be halved and hence the frequency to be doubled. You logic analyser will confirm this, I know mine did.

One thing you should note is that the Change method returns a value to indicate if the method has disposed of the old timer. I have never seen this not return true but if you see some odd behaviours with timers still generating interrupts at old frequencies then it may be the result of an old timer still hanging around.

Conclusion

This article was inspired by a posting on the Netduino chatrooms regarding the changing/killing of timers. I must admit I was a little astounded to find that there was no Stop or Start method in the class. As you can see, the techniques for doing this are not complex, they are just not obvious.

There are also some nice feature, like the fact that Timers run in their own threads. Investigation of these features are left as an exercise for the reader.

As always, the Source code is available for download.

In this, the last of the series of posts regarding implementing SPI Slave devices using the STM8S, we will look at building a module for the Netduino Go. This post builds upon the two previous posts:

• STM8S SPI Slave
  A simple SPI implementation using hardware SPI (single byte exchange).
• STM8S SPI Slave (Part 2)
  Software SPI implementation (using buffers to allow the exchange of data packets).

Here we will build upon the buffering and overlay the the Netduino Go 1.0 protocol in order to allow the two devices to communicate. We will also extend the STM8S application to add a simple function table to allow the simple addition of extra functionality to the system.

The makers of the Netduino Go, Secret Labs, have not formally released the GoBus 1.0 specification as a document. They have however release the source code to some of their modules and this can be found in the Wiki. The code found in the Wiki posts along with discussions on various forums has been used in the production of the code presented here. Credit for help is due to Secret Labs for releasing the code and also to the following Netduino forum members:

• Chris Walker
• CW2

These forum members have given assistance in one form or another over the past few months and without their help this post would not have been possible.

GoBus 1.0 Protocol

The early GoBus protocol uses an 18 byte data packet which is exchanged by the Netduino Go and the module. This packet of data contains a one byte header, 16 bytes of data and a one byte checksum with the data packets being exchanged over SPI. With the exception of the header and the checksum it appears that meaning of the data within the 16 byte payload is determined by the module developer.

I would also point the reader to the blog post A Developers Introduction to GoBus by Matt Isenhower on the Komodex System web site.

Enumeration

When the Netduino Go is first powered it will look at each of the Go Sockets in turn and attempt to interrogate the modules which are connected to the main board. It does this by sending out a packet with a single byte header 0xfe followed by 16 data bytes and a checksum. From experience, the data bytes are normally set to 0xff.

The module attached to the socket is then required to respond with a header byte of 0x2a followed by the 16 byte GUID of the module and the checksum byte.

The end result of this exchange is that the Netduino Go will have built up a list of modules attached to the main board along with the corresponding socket numbers.

This process then allows the .NET code to connect to a module using the GUID or the GUID and socket number. Successful connection is indicated by the blue LED by the side of the socket being illuminated. A failed connection normally results in an exception being thrown.

Data Transfer/Module Control

When the code running on the Netduino Go has successfully attached to the module on a socket it can start to control/communicate with the module. At this point it appears that the protocol uses the header 0x80 to indicate transfer between the module and the main board. So our data packets remain 18 bytes with the following format:

• 0x80 – Header
• 16 byte payload
• 1 byte CRC

It appears that the meaning of the 16 byte payload is determined by the module developer.

GPIO Interrupt

The protocol also allows for the use of a single GPIO. This can be used as a signalling line to let either side know that an action is pending. Convention appears to be to use this to allow the module to let the code on the main board know that there is some data/action pending.

A Simple Module

We will be creating a simple module to illustrate how the STM8S and the Netduino code work together. In order to use the least hardware possible the module will perform a simple calculation and return the result. Our module will need to perform the following:

• Enumerate using a GUID allowing the Netduino Go to detect the module
• Receive a number from the Netduino Go
• Perform a simple calculation and notify the Netduino Go that the result is ready.
• Send the result back to the Netduino Go when requested.

This simple module illustrates the key types of communication which may be required of a simple module. It is of course possible to use these to perform other tasks such as controlling a LED or receiving input from a button or keypad.

Netduino Go Module Driver

The Netduino Go code derived from the C# code published by Secret Labs in their Wiki. The major changes which have been made for this post are really concerned with improving clarity (adding comments at each stage to expand on the key points etc.).

Module ID

Modules are identified using a GUID. This ID allows the GoBus to connect to a module by scanning the bus for the specified ID. It also allows the Netduino Go to verify that when connecting to a module on a specific socket that the module is of the correct type. So the first thing we will need to do is obtain a new GUID. There are various ways in which we can do this and the simplest way to do this is to use the Create GUID menu option in Visual Studio. You can find this in the Tools menu.

Once you have your GUID you need to break this down into an array of bytes. You can then enter this in the both the Netduino code and the STM8S code. You will find the appropriate line in the file BasicModule.cs. The code looks something like this:

REMEMBER: It is critical that you generate your own GUID as each module type will need to have distinct ID.

Scanning down the file a little way you will find the two constructors for the class. One takes a socket and attempts to bind to the specified module on the requested socket. The other will attach to the first available module on the GoBus.

Initialise

This method is key to allowing the Netduino Go to connect to the module. The method binds to the module (assuming the IDs match) and retrieves a list of resources which the driver can use to communicate with the module. In this case, the SPI information and the pin used as an interrupt port. The remainder of the method configures the module driver to use these resources.

One key point to note is the use of the AutoResetEvent object. This is used to allow the interrupt handler to communicate the fact that an event has occurred to the methods we will write. This can be done in a manner which is non-blocking.

AddFive Method

This is the first of our methods implementing the functionality which our module will provide. In our case, this method actually implements the simple arithmetic we will be asking the module to perform. We will be sending a byte to the module, the module will add five to the number passed and then make this available to the Netduino Go. The code looks like this:

public byte AddFive(byte value)
{
	int retriesLeft = 10;
	bool responseReceived = false;

	_writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
	_writeFrameBuffer[1] = CMD_ADD_FIVE;
	_writeFrameBuffer[2] = value;
	WriteDataToModule();
	while (!responseReceived && (retriesLeft > 0))
	{
		//
		//  We have written the data to the module so wait for a maximum 
		//  of 5 milliseconds to see if the module responds with some 
		//  data for us.
		//
		responseReceived = _irqPortInterruptEvent.WaitOne(5, false);
		if ((responseReceived) && (_readFrameBuffer[1] == GO_BUS10_COMMAND_RESPONSE))
		{
			//
			//  Module has responded so extract the result.  Note we should really
			//  verify the checksum at this point.
			//
			_writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
			_writeFrameBuffer[1] = CMD_GET_RESULT;
			WriteDataToModule();
			return(_readFrameBuffer[2]);
		}
		else
		{
			//
			//  No response within the 5ms so lets make another attempt.
			//
			retriesLeft--;
			if (retriesLeft > 0)
			{
				WriteDataToModule();
			}
		}
	}
	throw new Exception("AddFive cannot communicate with the Basic GO! module");
}

The first thing this the method does is to set up the _writeFrameBuffer with the header, the command number and the data we will be sending. The data is then written to the module using SPI.

Next we will wait a while for the module to indicate via the GPIO pin that it has processed the data and the result is ready. As we shall see later, the module has already put the result in the transmission buffer ready for retrieval. This will have been performed before the interrupt was generated. The following line performs the non-blocking check to see if the interrupt has been generated:

responseReceived = _irqPortInterruptEvent.WaitOne(5, false);

responseReceived will be true if the interrupt has been generated and the C# module code has received the event.

The final task is to retrieve the result from the module by sending a retrieve command. This is performed by the following code:

_writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
_writeFrameBuffer[1] = CMD_GET_RESULT;
WriteDataToModule();
return(_readFrameBuffer[2]);

STM8S Module

Much of the code required here has already been covered in the previous post, STM8S SPI Slave (Part 2). The protocol uses a small buffer to allow messages to be transferred between the STM8S and the Netduino Go. In order to make this work as a Netduino Go module we need to overlay the GoBus protocol onto the message buffers and provide a mechanism for interpreting these messages. The mechanism we adopted is as follows:

• All messages will be restricted to 18 bytes (one byte header, 16 bytes payload, one byte CRC)
• The request header (from the Netduino to the module) will be 0x80 allowing a 16 byte payload
• The response header (from the module to the Netduino) will be 0x2a followed by 0x80. This restricts the return payload to 15 bytes.
• The final byte will be a CRC calculated on the header and the payload

The way in which the protocol has been implemented here also places a restriction upon on the application. Firstly, the module must receive a request as a full payload. Only then can the module respond. This is where the GPIO interrupt discussed earlier comes into play.

The final part of the problem is to work out how to dispatch the messages received by the module. To do this we will use a function table.

For the remainder of this article we will restrict ourselves to looking at the new functionality we will be adding on top of the previous post in order to allow the creation of a module.

Function Table

A function table in C is a simple list of function pointers. We will add to this by allowing a variable function identifier to be used to associate a byte ID with a particular method within the module. The following code allows the table to be setup:

//
//  Function table structure.
//
typedef struct
{
    unsigned char command;          //  Command number.
    void (*functionPointer)();      //  Pointer to the function to be executed.
} FunctionTableEntry;
//
//  Forward function declarations for the function table.
//
void AddFive();
void GetValue();
//
//  Table of pointers to functions which implement the specified commands.
//
FunctionTableEntry _functionTable[] = { { 0x01, AddFive }, { 0x02, GetValue } };
//
//  Number of functions in the function table.
//
const int _numberOfFunctions = sizeof(_functionTable) / sizeof(FunctionTableEntry);

Here we define a function table entry which has a byte ID and a pointer to a function (taking a void parameter list) associated with the ID. We then declare an array of these objects and associate functions with the IDs.

The final line of code simply determines the number of entries in the function table.

Using the above table we can work out which function to call using the following code:

if (_numberOfFunctions > 0)
{
	for (int index = 0; index < _numberOfFunctions; index++)
	{
		if (_functionTable[index].command == _rxBuffer[1])
		{
			(*(_functionTable[index].functionPointer))();
			break;
		}
	}
}

The function table method presented here allows the functionality of the module to be expanded with relative ease. In order to add a new piece of functionality you simply need to do the following:

• Create a new method in the STM8S code to implement the new functionality
• Determine the ID to be used for the functionality and add a new entry to the function table
• Create a method in the Netduino Go driver to call the method and retrieve any results as necessary

By performing these three simple steps you can add one or more functions with ease. The communication protocol will continue to work as is with no modification. The only exception to this rule will be cases where more than one payload of data needs to be transferred in order to achieve a specified piece of functionality (say a network driver etc.).

Buffers and GUIDs

We will need to make a slight modification to the Rx buffer in order to account for the checksum byte. We will also need to add somewhere to store the GUID which acts as the identifier for this module. This results in the following small change to the global variable code:

//
//  Application global variables.
//
unsigned char _rxBuffer[GO_BUFFER_SIZE + 1];    // Buffer holding the received data plus a CRC.
unsigned char _txBuffer[GO_BUFFER_SIZE];        // Buffer holding the data to send.
unsigned char *_rx;                             // Place to put the next byte received.
unsigned char *_tx;                             // Next byte to send.
int _rxCount;                                   // Number of characters received.
int _txCount;                                   // Number of characters sent.
volatile int _status;                           // Application status code.
//
//  GUID which identifies this module.
//
unsigned char _moduleID[] = { 0x80, 0x39, 0xe8, 0x2b, 0x55, 0x58, 0xeb, 0x48,
                              0xab, 0x9e, 0x48, 0xd3, 0xfd, 0xae, 0x8c, 0xee };

GoBus Interrupt

The discussion of the code on the Netduino Go driver (on the main board) mentioned the fact that the module can raise an interrupt to signal the fact that an operation has completed and that data is ready for retrieval. In order to do this we raise an interrupt on one of the pins when we have processed the data. This code is trivial:

//
//  Raise an interrupt to the GO! main board to indicate that there is some data
//  ready for collection.  The IRQ on the GO! board is configured as follows:
//
//  _irqPort = new InterruptPort((Cpu.Pin) socketGpioPin, false, Port.ResistorMode.PullUp,
//                               Port.InterruptMode.InterruptEdgeLow);
//
void NotifyGOBoard()
{
    PIN_GOBUS_INTERRUPT = 0;
    __no_operation();
    PIN_GOBUS_INTERRUPT = 1;
}

This method is simple and really just toggles which is connected to GPIO pin on the Netduino Go socket.

Adding Functionality to the Module

In our simple case we need to add two pieces of functionality, the ability to add five to a number and then to allow the caller to retrieve the result. This results in the following two methods:

//
//  GO! function 1 - add 5 to byte 2 in the Rx buffer and put the answer into the
//  Tx buffer.
//
void AddFive()
{
    _txBuffer[1] = _rxBuffer[2] + 5;
    NotifyGOBoard();
}

//--------------------------------------------------------------------------------
//
//  GO! Function 2 - return the Tx buffer back to the GO! board.
//
void GetValue()
{
    NotifyGOBoard();
}

SPI Go Frame

The implementation of the SPI processing here is interrupt driven. As such we will need to allow a method of synchronising the payloads we receive. This application will do this using the rising edge of the chip select signal which is generated by the Netduino Go main board. This allows us for cater for the many scenarios (synchronisation, underflow and overflow).

In the case of underflow and synchronisation, the chip select signal will rise before we have enough data. In this case we have either a corrupt packet or we have started to recei8ve data part way through the packet. In this case we cannot sensibly process the data so we should throw away the packet and wait for the next one.

An overflow situation can occur when the Netduino Go sends more than 18 bytes in one packet of data. In this case we should detect this and prevent the buffers from overflowing.

In order to allow for these cases we reset the Go frame pointers when the chip select signal changes from low to high:

//
//  This method resets SPI ready for the next transmission/reception of data
//  on the GO! bus.
//
//  Do not call this method whilst SPI is enabled as it will have no effect.
//
void ResetGoFrame()
{
    if (!SPI_CR1_SPE)
    {
        (void) SPI_DR;                          //  Reset any error conditions.
        (void) SPI_SR;
        SPI_DR = GO_FRAME_PREFIX;               //  First byte of the response.
        _txBuffer[0] = _moduleID[0];            //  Second byte in the response.
        //
        //  Now reset the buffer pointers and counters ready for data transfer.
        //
        _rx = _rxBuffer;
        _tx = _txBuffer;
        _rxCount = 0;
        _txCount = 0;
        //
        //  Note the documentation states this should be SPI_CR2_CRCEN
        //  but the header files have SPI_CR_CECEN defined.
        //
        SPI_CR2_CECEN = 0;                      //  Reset the CRC calculation.
        SPI_CR2_CRCNEXT = 0;
        SPI_CR2_CECEN = 1;
        SPI_SR_CRCERR = 0;
    }
}

As we shall see later, the end of the SPI transmission with result in one of the following cases:

• Too little data received correctly. The rising chip select line will reset the buffer pointers and the data will be discarded.
• The correct amount of data received. In this case the buffer will be processed correctly.
• Too much data is received. The excess data will be discarded to prevent a buffer overflow.

The ResetGoFrame method is key in ensuring that the buffers are reset at the end of the SPI transmission indicated by the rising chip select line.

SPI Tx/Rx Interrupt Handler

This method is responsible for ensuring that the data is transmitted and received correctly. It works in much the same way as the previous buffered SPI example. The main difference between this module and the previous example is what happens when the first byte of the data received is equal to 0xfe. In this case the Tx buffer pointer is moved to point to the module ID. This ensures that the Netduino Go receives the correct response to the enumeration request.

Connecting the Boards

The application code contains a number of #if statements to take into account the differing pin layouts of the microcontrollers used. The following have been tested so far:

• STM8S103F3 TSSOP20 on a breadboard
• STM8S Discovery

The Protomodule has also been wired up for one particular module but at the time of writing the definitions have not been added to the sources.

In order to connect the Netduino Go main board to a module in development you will probably need to purchase some form of breakout such as the Komodex breakout board (Straight connectors or 90-Degree connectors).

Connecting the two boards should be a simple case of ensuring that the SPI pins are connected MOSI to MOSI, MISO to MISO, CS to CS and Clock to Clock. In the case of the Discovery board I used PB0 for the CS line and for the STM8S103 setup I used the standard pin PA3.

Running the Code

Running the code should be a simple case of loading the STM8S code into the IAR development environment first and the deploying the code to the chip. Hot F5 to run the code.

Next, load the visual studio code and deploy this to the Netduino Go main board. Hit F5 to run the code.

The C# code running in Visual Studio should start to print some diagnostic information to the debug window. You should see a series of statements of the form Adding 5 to 6 to give 11. The 6 is the parameter which has been sent to the module for processing and the 11 is the result.

Observations

I have seen differing behaviours to the way in which the debugger in IAR works with the code in the module. Occasionally the debugger will actually prevent the module from enumerating. This will result in an exception in Visual Studio. To date I have only seen this behaviour with the STM8S103 setup. The STM8S Discovery board seems to work correctly. If you have problems with this then the only suggestion is to detach IAR from the board and rely upon diagnostic information being dumped to a logic analyser. You will note that the test application which runs on the Netduino Go has the instantiation of the module wrapped in a while loop and a try block. This allows the test code to make several attempts at creating a new module instance. This should not be necessary in the final production code as this has not yet failed in a none debug environment.

This code has been tested with the simple module example here and also with a temperature and humidity sensor. The application enumerated OK and has been soak tested in two environments over a period of hours. The code seems to be stable and works well with the Netduino Go.

I originally tried to be ambitious with the interrupt service routine dealing with the chip select line. This gave me code which was simpler but lead to a timing issue. As it stands at the moment, dropping the chip select line from high to low starts the SPI processing. The time between this happening and the first clock transition is only 3.25us as measured on my logic analyser. This means that all of the preparation must be completed in 3.25us.

If we look at the diagram below you can see the timings at the start of the SPI communication:



SPI Timing Diagram

The two markers 1 & 2 indicate the time we have between the start of the comms indicated by CS falling to the first clock pulse. The Status Code trace is a debugging signal generated by the application. The rising edge indicates when the first line of the interrupt service routine for the CS line starts and the falling edge indicates the point where we have completed enough processing to allow SPI to be enabled.

Conclusion

This post shows how we to create a Netduino Go module using a standard communication protocol. Additional module functionality can simply be added by adding to the function table.

As noted at the start, this article is the combination of information provided by Netduino community members along with the module code which can be found in the Wiki.

As usual, the source code for this application is available for download (STM8S Go Module and Netduino Go – Basic Module Driver).

Source Code Compatibility

System	Compatible?
STM8S103F3 (Breadboard)
Variable Lab Protomodule
STM8S Discovery

In the previous post we looked at exchanging single bytes using SPI with a Netduino Plus acting as the SPI master device and the STM8S acting as a slave device. The code presented suffered from a few deficiencies:

• We could only exchange one byte and that was mirrored back to the master device
• The mirroring assumed that a byte received meant the STM8S was ready to send a byte back to the Netduino

In this post we will deal with both of these issues and also look at a new problem which can arise, namely synchronisation.

The aim of the code we will be developing is to receive a buffer of data and at the same time send a different buffer of data back to the master device.

Hardware

The hardware we will be using is identical to the initial SPI post. We will be using a few more bits from the registers in order to allow the STM8S application to determine the action we should be taking.

SPR_SR_OVR – Overflow Indicator

This bit will be set when the chip detects an overflow condition. This can happen if the bus speed is too high and the data is arriving at a rate which is faster than the Interrupt Service Routine (ISR) can process it.

SPI_SR_RXNE – Receive Buffer Not Empty

This bit indicates that the receive buffer is not empty and that data is ready to be read.

SPI_SR_TXE – Transmit Buffer Empty

This indicates that the SPI transmit buffer is empty and ready to receive another byte of data.

Netduino Plus Software

The software running on the Netduino Plus requires a small modification to allow it to send a buffer of data rather than a single byte. We will also take the opportunity to increase the SPI bus speed to 500KHz. The code running on the Netduino Plus becomes:

public class Program
{
	/// <summary>
	/// SPI object.
	/// </summary>
	private static SPI spi = null;

	/// <summary>
	/// Configuration of the SPI port.
	/// </summary>
	private static SPI.Configuration config = null;

	public static void Main()
	{
		config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1,        // Which SPI module to use?
									   ChipSelect_Port: Pins.GPIO_PIN_D10,  // Chip select pin.
									   ChipSelect_ActiveState: false,       // Chip select is low when SPI is active.
									   ChipSelect_SetupTime: 0,
									   ChipSelect_HoldTime: 0,
									   Clock_IdleState: false,              // Clock is active low.
									   Clock_Edge: true,                    // Sample on the rising edge.
									   Clock_RateKHz: 500);
		spi = new SPI(config);

		byte[] buffer = new byte[17];
		for (byte index = 0; index < 17; index++)
		{
			buffer[index] = index;
		}
		while (true)
		{
			for (byte counter = 0; counter < 255; counter++)
			{
				buffer[0] = counter;
				spi.Write(buffer);
				Thread.Sleep(200);
			}
		}
	}
}

As you can see, much of the code is the same as that presented in the previous post. This application will now transmit a 17 byte buffer to the SPI slave device. The first byte in the buffer will be a sequence number which will cycle through the values 0 to 254. The remaining bytes in the buffer will remain unchanged.

STM8S SPI Slave

The main changes we will be making are in the application running on the STM8S. In this case we need to deal with the following additional issues:

• Possible overflows due to the increased speed of the SPI bus
• Treating the receive and transmit scenarios as distinct cases
• Buffer overflows

The first thing we are going to need is somewhere to store the data. Looking at the Netduino Code we have defined the buffer size as 17 bytes. The corresponding declaration in the STM8S code look like this:

//--------------------------------------------------------------------------------
//
//  Miscellaneous constants
//
#define BUFFER_SIZE             17

//--------------------------------------------------------------------------------
//
//  Application global variables.
//
unsigned char _rxBuffer[BUFFER_SIZE];       // Buffer holding the received data.
unsigned char _txBuffer[BUFFER_SIZE];       // Buffer holding the data to send.
unsigned char *_rx;                         // Place to put the next byte received.
unsigned char *_tx;                         // Next byte to send.
int _rxCount;                               // Number of characters received.
int _txCount;                               // Number of characters sent.

We will also need to provide a mechanism to reset the SPI buffer pointers back to a default state ready to receive data:

//--------------------------------------------------------------------------------
//
//  Reset the SPI buffers and pointers to their default values.
//
void ResetSPIBuffers()
{
    SPI_DR = 0xff;
    _rxCount = 0;
    _txCount = 0;
    _rx = _rxBuffer;
    _tx = _txBuffer;
}

We also no longer have a single byte of data to output on the diagnostic pins. We therefore need to add a new diagnostic method to output the data we are receiving.

//--------------------------------------------------------------------------------
//
//  Bit bang a buffer of data on the diagnostic pins.
//
void BitBangBuffer(unsigned char *buffer, int size)
{
    for (int index = 0; index < size; index++)
    {
        BitBang(buffer[index]);
    }
}

The main method needs to be modified to take into account the changes we have made. The code becomes:

int main(void)
{
    //
    //  Initialise the system.
    //
    __disable_interrupt();
    InitialiseSystemClock();
    InitialiseSPIAsSlave();
    ResetSPIBuffers();
    for (unsigned char index = 0; index < BUFFER_SIZE; index++)
    {
        _txBuffer[index] = index + 100;
    }
    InitialiseOutputPorts();
    _status = SC_UNKNOWN;
    __enable_interrupt();
    //
    //  Main program loop.
    //
    while (1)
    {
        __wait_for_interrupt();
        if (_status == SC_RX_BUFFER_FULL)
        {
            BitBangBuffer(_rxBuffer, BUFFER_SIZE);
        }
        _status = SC_UNKNOWN;
    }
}

So far all of the code changes have been to support the initialisation and configuration of the system. The one area we have not touched upon is processing of the data which is being transmitted / received, namely the SPI ISR.

SPI Interrupt Service Routine

For the application we have built so far, the ISR must take into account three possible scenarios:

• Buffer Overflow
• Data received
• Data transmission buffer empty

The code will utilise the three status we identified earlier in order to determine which action to take. In each case we will do the following:

• SPI Overflow (SPI_SR_OVR is set)
  Use the status codes to indicate an overflow has occurred and exit the ISR
• Data Received (SPI_SR_RXNE is set)
  Add the byte received to the buffer and update the buffer pointers. Set the status code to indicate that we have received some data.
• Data transmission buffer empty (SPI_SR_TXNE is set)
  Grab the next byte from the transmit buffer and send it. Update the transmit buffer pointers accordingly.

We will be adopting a naïve buffering solution for this application. The buffers will be circular. The ISR can assume that there is space to save the next byte (i.e. we never overflow) as when we reach the end of the buffer we simply set the pointer back to the start again. The code for the ISR becomes:

#pragma vector = SPI_TXE_vector
__interrupt void SPI_IRQHandler(void)
{
    //
    //  Check for an overflow error.
    //
    if (SPI_SR_OVR)
    {
        (void) SPI_DR;                      // These two reads clear the overflow
        (void) SPI_SR;                      // error.
        _status = SC_OVERFLOW;
        OutputStatusCode(_status);
        return;
    }
    //
    //  Looks like we have a valid transmit/receive interrupt.
    //
    if (SPI_SR_RXNE)
    {
        //
        //  We have received some data.
        //
        *_rx = SPI_DR;              //  Read the byte we have received.
        _rx++;
        _rxCount++;
        if (_rxCount == BUFFER_SIZE)
        {
            _status = SC_RX_BUFFER_FULL;
            OutputStatusCode(_status);
            _rx = _rxBuffer;
            _rxCount = 0;
        }
    }
    if (SPI_SR_TXE)
    {
        //
        //  The master is ready to receive another byte.
        //
        SPI_DR = *_tx;
        _tx++;
        _txCount++;
        if (_txCount == BUFFER_SIZE)
        {
            OutputStatusCode(SC_TX_BUFFER_EMPTY);
            _tx = _txBuffer;
            _txCount = 0;
        }
    }
}

If we run these two applications and connect the logic analyser we are likely to see traces similar to the following:



SPI Slave Buffered output on Logica Analyser

This is not what we expected. In fact we expect to see something like the following:



Correctly synchronised SPI buffered output on the Logic Analyser

The reason for this is the simple buffering and we have used and the fact that there we have not implemented a method for synchronising the two systems (Netduino and STM8S). The trace can be understood if we follow the deployment and startup cycles for each application. The sequence of events will proceed something like the following:

• Deploy code to the Netduino Plus
  At this point the application will start to run. We will be outputting a sequence of bytes followed by a 200ms pause.
• Deploy the code to the STM8S
  The application on the STM8S starts and waits for data to be received on the SPI bus.

It is highly possible that when the application on the STM8S starts we will be part way through the transmission of a sequence of bytes by the Netduino. Let us make the assumption that this is the case and the Netduino is transmitting byte 16.

• Byte 16 transmitted by Netduino
  The byte is received by the STM8S and put into the buffer at position 0. The buffer pointers are moved on to point to position 1.
• Byte 17 is transmitted by the Netduino
  The byte is received by the STM8S and put into the buffer at position 1. The buffer pointers are moved on to point to position 2.
• Netduino enters the 200ms pause
  The STM8S waits for the next byte
• Byte 0 transmitted by Netduino
  The byte is received by the STM8S and put into the buffer at position 2. The buffer pointers are moved on to point to position 3.

This sequence of events continues until the buffer on the STM8S is full. As you can see, the buffers started out unsynchronised and continue in this manner ad infinitum.

Interestingly, if you power down the two boards and then power them up simultaneously (or power up the STM8S and then the Netduino Plus) you will see the synchronised trace. This happens because the STM8S has been allowed to enter the receive mode before the Netduino Plus could start to send data.

Synchronising the Sender and Receiver

The key to the synchronisation is this case is to consider using an external signal to indicate the start of transmission of the first byte of the buffer. In theory this is what the NSS signal (chip select) is for. The STM8S does not provide a mechanism to detect the state change for the NSS line when operating in hardware mode (which is how the application has been operating so far). In order to resolve this we should consider converting the application to use software chip select mode.

Chip Select

The first thing to be considered is the port we will be using to detect the chip select signal. In this case we will be using Port B, pin 0. This port will need to be configured as an input with the interrupts enabled. The InitialisePorts method becomes:

void InitialisePorts()
{
    //
    //  Initialise Port D for debug output.
    //
    PD_ODR = 0;             //  All pins are turned off.
    PD_DDR = 0xff;          //  All pins are outputs.
    PD_CR1 = 0xff;          //  Push-Pull outputs.
    PD_CR2 = 0xff;          //  Output speeds upto 10 MHz.
    //
    //  Initialise Port B for input.
    //
    PB_ODR = 0;             //  Turn the outputs off.
    PB_DDR = 0;             //  All pins are inputs.
    PB_CR1 = 0xff;          //  All inputs have pull-ups enabled.
    PB_CR2 = 0xff;          //  Interrupts enabled on all pins.
    //
    //  Now set up the interrupt behaviour.
    //
    EXTI_CR1_PBIS = 2;      //  Port B interrupt on falling edge (initially).
}

One point to note about the above method is that we initially only detect the falling edge of the chip select signal. My first attempt at this code had both falling and rising edge detection in place. With this method enabled I found it difficult to detect which edge was causing the interrupt to be triggered. I therefore decided to initially detect only the falling edge. I would then add code to change the edge being detected to the ISR controlling the chip select. The code which detects the change of state for the chip select pin is as follows:

#pragma vector = 6
__interrupt void EXTI_PORTB_IRQHandler(void)
{
    if (EXTI_CR1_PBIS == 1)
    {
        //
        //  Transition from low to high disables SPI
        //
        SPI_CR1_SPE = 0;                        //  Disable SPI.
        SPI_CR2_SSI = 1;
        EXTI_CR1_PBIS = 2;                      //  Waiting for falling edge next.
        OutputStatusCode(SC_CS_RISING_EDGE);
    }
    else
    {
        //
        //  Transition from high to low selects this slave device.
        //
        EXTI_CR1_PBIS = 1;                      //  Waiting for rising edge next.
        ResetSPIBuffers();
        (void) SPI_DR;
        (void) SPI_SR;
        SPI_DR = *_tx++;                        //  Load the transmit with first byte.
        _txCount++;
        SPI_CR2_SSI = 0;
        SPI_CR1_MSTR = 0;
        SPI_CR1_SPE = 1;                        // Enable SPI.
        OutputStatusCode(SC_CS_FALLING_EDGE);
    }
}

This code performs two tasks:

• Falling Edge – Enable SPI
  Resets the SPI buffers and the SPI registers ready for data transmission> Next, enable SPI. Finally, setup the chip select to detect a rising edge.
• Rising Edge – Disable SPI
  Disables SPI and sets the chip select to look for a falling edge.

You will also note a few lines outputting status information. These should be removed in production code but are left in here in order to aid debugging.

The final thing we need to do is to modify the initialisation of the SPI registers. These are small changes and merely change the system from hardware to software chip select. One key change is that we do not enable SPI here. This is left to the chip select interrupt handler. The new version of the InitialiseSPIAsSlave method becomes:

void InitialiseSPIAsSlave()
{
    SPI_CR1_SPE = 0;                    //  Disable SPI.
    SPI_CR1_CPOL = 0;                   //  Clock is low when idle.
    SPI_CR1_CPHA = 0;                   //  Sample the data on the rising edge.
    SPI_ICR_TXIE = 1;                   //  Enable the SPI TXE interrupt.
    SPI_ICR_RXIE = 1;                   //  Enable the SPI RXE interrupt.
    SPI_CR2_SSI = 0;                    //  This is SPI slave device.
    SPI_CR2_SSM = 1;                    //  Slave management performed by software.
}

Conclusion

This post shows how we can overcome the naïve data transmission method presented by the previous post and add the ability to buffer data and to store a buffered response. Running the final version of the code overcomes the synchronisation problem we encountered at the expense of performing out own chip select handling in software.

As usual, the source code for this application is available for download (STM8S SPI Slave and Netduino SPI Master).

Source Code Compatibility

System	Compatible?
STM8S103F3 (Breadboard)
Variable Lab Protomodule
STM8S Discovery

For the next few posts I will be taking a look at SPI and how to use this to allow communication between two devices.

For some background reading I suggest that you visit Wikipedia and read the article on SPI. This post will assume that you are familiar with the material in that article.

In the first of the series we are going to be implementing a simple byte transfer between two devices, namely:

• Netduino Plus
• STM8S Discovery board

This scenario will require that SPI on the STM8S operates in slave mode as SPI on the Netduino Plus can only operate as a SPI master device. The Netduino family of products was chosen as the master because the SPI implementation is quick to setup and use. This means that we can be sure that any problems which arise during development are highly likely to be related to the STM8S code.

The problem definition is as follows:

• Configure the Netduino Plus as a SPI master device
• Send a repeated pattern of bytes over SPI to a listening slave device
• Configure the STM8S to operate as a SPI slave device
• Read the bytes from the SPI bus (MOSI) and send them back out on the bus (MISO)

We will also add some debugging code to allow us to connect a logic analyser to the STM8S and verify the data which is being received.

SPI Master – Netduino Plus Code

The initial version of this application will use a low bus speed for the SPI communication. By using a low speed we will reduce the influence of transmission errors and also allow the code to be debugged and logic errors eliminated without worrying too much about errors introduced through timing issues.

Our simple application looks like this:

public class Program
{
	/// <summary>
	/// SPI object.
	/// </summary>
	private static SPI spi = null;

	/// <summary>
	/// Configuration of the SPI port.
	/// </summary>
	private static SPI.Configuration config = null;

	public static void Main()
	{
		config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1,        // Which SPI module to use?
									   ChipSelect_Port: Pins.GPIO_PIN_D10,  // Chip select pin.
									   ChipSelect_ActiveState: false,       // Chip select is low when SPI is active.
									   ChipSelect_SetupTime: 0,
									   ChipSelect_HoldTime: 0,
									   Clock_IdleState: false,              // Clock is active low.
									   Clock_Edge: true,                    // Sample on the rising edge.
									   Clock_RateKHz: 10);
		spi = new SPI(config);

		byte[] buffer = new byte[1];
		while (true)
		{
			for (byte counter = 0; counter < 255; counter++)
			{
				buffer[0] = counter;
				spi.Write(buffer);
				Thread.Sleep(200);
			}
		}
	}
}

The configuration of the SPI bus is as follows:

• Chip select is digital pin 10
• Chip select is low when the bus is active
• Clock is active low (Clock Polarity – CPOL)
• Data will be valid on the rising clock edge (Clock Phase – CPHA)
• Clock frequency is 10Khz

It is important to note that the sampling settings must be duplicated on the slave device.

Once the SPI bus is configured, the application continuously loops outputting the bytes 0 to 254 on the SPI bus with a 200ms pause between each byte.

SPI Slave – STM8S

With the exception of the clock speed, we now need to configure the STM8S as a slave device using the same settings as the SPI master device.

The Registers

SPI_CR1_CPOL – Clock Polarity

The first setting we will consider is the clock polarity (CPOL). This is controlled by the CPOL bit in the CR1 register. This is defined as:

The master has an active low clock.

SPI_CR1_CPHA – Clock Phase

The clock phase determines when the data is ready to be sampled, i.e. on the rising or falling clock edge.

We will be sampling on the first clock transition, on the rising edge.

SPI_CR1_SPE – Enable or Disable SPI

This register determines if SPI is enabled or disabled. Setting this register to 0 disables SPI, setting it to 1 enables SPI.

SPI_ICR_TXIE and SPI_ICR_RXNE – Interrupt Enable/Disable

These two registers determine if the SPI interrupts will be triggered on transmit (TXIE) or receive (RXIE). Setting a bit to 0 will disable the interrupt, setting it to 1 will enable the interrupt.

SPI_DR – Data Register

The data register is used in two contexts, when data has been received and to transmit data. Reading this register will retrieve data from the receive buffer. Setting this register will load the specified value into the transmit buffer.

SPI_SR_RXNE – Receive Buffer Not Empty

This bit in the status register indicates if the receive buffer is empty. You can check this value before you read the SPI_DR register to determine if there is any data waiting to be read.

STM8S Code

The first thing we will need to do is to initialise the SPI bus matching the settings of the SPI master:

void InitialiseSPIAsSlave()
{
    SPI_CR1_SPE = 0;                    //  Disable SPI.
    SPI_CR1_CPOL = 0;                   //  Clock is low when idle.
    SPI_CR1_CPHA = 0;                   //  Sample the data on the rising edge.
    SPI_ICR_TXIE = 1;                   //  Enable the SPI TXE interrupt.
    SPI_ICR_RXIE = 1;                   //  Enable the SPI RXE interrupt.
    SPI_CR1_SPE = 1;                    //  Enable SPI.
}

This code not only matches the master settings but also enables the generation of interrupts for transmit empty and receive not empty. These interrupts are handled by the following code:

#pragma vector = SPI_TXE_vector
__interrupt void SPI_IRQHandler(void)
{
    if (SPI_SR_RXNE)
    {
        unsigned char byte;
        byte = SPI_DR;          //  Read the byte we have received.
        SPI_DR = byte;          //  Now transmit the byte.
        //
        //  Output some debug information.
        //
        OutputStatusCode(SC_OK);
        BitBang(byte);
    }
}

This method checks the SPI_SR_RXNE flag to determine if the receive buffer is not empty. If there is data ready for processing then the data is retrieved and then transmitted back to the master.

Note that this method offers a naive approach to sending and receiving data, something we will overcome in subsequent posts.

We have also provided two methods for debugging, one will output a status code; the second will output a single byte by bit banging the data using two pins on an output port. We will need to use these methods with care when we start to look at higher transmission speeds. The two debug methods need to operate at speeds which allow the interrupt service routine to complete before the next interrupt is ready to be generated.

Hardware Setup

The connections between the two devices are straight forward. The following pins should be connected:

In addition to the above connections between the two boards we have three pins defined for debugging/diagnostics.

Port D, pin 2 will be used to output a status code. The code will be output as a series of high/low transitions.

Port D, pins 4 (clock) and 5 (data) will output debug/diagnostic data. This will be output in a similar form to the SPI data being transmitted on the SPI bus. This form has been chosen as it allows a logic analyser to be used to interpret the data.

Results

If we connect the two devices and hook up a logic analyser we get output similar to the following:

Logic Analyser Output

The top four traces represent the data which is being transmitted by the Netduino and the STM8S on the SPI bus along with the clock and select control signals. The labelling on the traces indicate which signal is being shown.

The traces labelled 4 and 5 show the data which has been output from the BitBang method.

The final trace shows the status code.

If we read this trace from left to right we can see that the Netduino master output the byte 213 on MOSI. At the same time, the STM8S is sending the byte 212 back to the master on the MISO line. This difference of one is caused by the fact that the transmission from the STM8S is always one behind the transmission by the master to the slave.

Traces 4 and 5 confirm that the STM8S has in fact received the byte 213.

We see that the first thing that happens is that the transmission of data starts on the MOSI and MISO lines simultaneously. When the data transmission has completed we have in interrupt generated and the status code of 1 is output. Finally the application copies the data received onto the diagnostic output.

Conclusion

This application represents the first step on the road to building a faster application capable of transmitting and receiving greater amounts of data.

As usual, the source code for this application is available for download (STM8S SPI Slave and Netduino SPI Master).

Source Code Compatibility

System	Compatible?
STM8S103F3 (Breadboard)
Variable Lab Protomodule
STM8S Discovery

Komodex Labs recently released a couple of new modules for the Netduino GO! platform. The first is a seven segment display module and as we will see later this can be used to show sensor data. The second module is a breakout module for the GO! bus and this is probably more interesting to module developers.

As the postman was kind to me and managed to get these modules to me this week I thought I’d hook them up to the light sensor I have been playing with to see what they can do.

A Little Background

I have recently been working with a simple sensor to teach myself how to work with the STM8S. It has been a long slow task as the normal competing pressures of work, the house and general life stuff keeps calling for my attention.

The project uses a TSL235R sensor which converts the current ambient light level into a square wave with 50% duty cycle. The STM8S periodically reads the frequency of the signal generated by the sensor. This value is then made available to the Netduino GO! via the GO! Bus.

This project is going to read the value from the STM8S and display it on the seven segment display. The value is a 16-bit value and so can range from 0 to 65535 so we will be showing the value in hex.

Seven Segment Module

The seven segment display is a nice little module very professionally finished. It feels a solid – sort of odd to say that about a module. I was kind of surprised by the weight but then I have only been working with small modules so far.

I’d write more but I think the module is best described my Matt’s blog post. This shows some photos of the module along with a description of the API used to control it.

GO! Bus Breakout Module

This is a handy little module which only had a short production run. I was lucky enough to have ordered one before stock ran out. The module is aimed at module developers. It has a couple of sockets for module cables along with some handy breakout points.

Komodex Labs GO! Bus Breakout Module

The idea is simple, you connect your Netduino GO! to one side of the breakout board and your module to the other side of the breakout board. You can then hook up test equipment (scope / logic analyser etc.) to a row of headers on the board. This allows you to debug your module by snooping on the data going down the GO! Bus.

An alternative configuration and one I am using for development on breadboard, is to connect the breakout module to breadboard with the Netduino GO! connected to one side of the breakout board. This allows you to feed the GO! Bus signals into your circuit whilst at the prototype stage.

The breakout also has a lovely feature in that you can connect the ST-LInk/V2 module to the board and at the flick of a switch you can disconnect the SWIM/NRST signals from the Netduino GO! and connect them to the ST-Link/V2 instead. This allows you to re-program the STM8S on the fly without having to modify your circuit – NEAT !

For more information about this module I’d head over to Matt’s blog post.

Hooking it all up

Connecting the Seven Digit Module up to the go was easy, it simply needed a standard 5cm GO! Bus cable and that’s it.

The Breakout module was a little more difficult as it had to be hooked into an existing prototype circuit. From the Netduino side it was easy, just another 5cm GO! Bus cable. The ST-Link/V2 connection was also easy as the module has a connector already on the board and it is designed to ensure that the connection can only be made one way. The only complication was then ensuring that the connections between the GO! Bus and the prototype circuit were correct. Adding this module has in fact made my prototype circuit a little cleaner.

Here’s what the final circuit looks like:

Komodex Seven Segment in Light Sensor Prototype Circuit

Installing the Drivers

The Seven Segment Module is supplied with a set of drivers in the form of an executable. The drivers can be found on the Komodex Labs web site. Installation was quick, simple and painless.

Komodex Labs also provide the source code for the drivers along with a sample application. This is a separate download and as you will see later, this came in handy.

As you would expect, the breakout module does not require any drivers as there is no interaction between the module and the PC.

Writing the Software

The API provided with the module is comprehensive but in this case we are going to use only a small part of it. We need to display a hex representation of a 16-bit number.

So the first step is to create a new project and add a reference to the module. You will have to browse to the directory in which you installed the drivers and add the Komodex.NETMF.SevenSegmentDisplay.dll file. On my machine this was installed in C:Program Files (x86)KomodexModule DriversAssembliesv4.2

The next step is to add a using statement

using Komodex.NETMF;

and then declare and instantiate an instance of the module:

SevenSegmentDisplay display = new SevenSegmentDisplay();
display.SetValue(0);

The above shows the module being instantiated and the display value set to 0.

The remainder of the program continuously polls the sensor for a reading. This reading is converted into a string containing the hexadecimal representation of the reading. This reading is then displayed on the Seven Segment Module. The code looks something like this:

while (true)
{
	short diff = module.GetReading();
	string output = "";
	char c;
	for (int index = 3; index >= 0; index--)
	{
		int nibble = (diff >> (4 * index)) & 0xF;
		if (nibble < 10)
		{
			output += nibble.ToString();
		}
		else
		{
			c = (char) ('A' + nibble - 10);
			output += c.ToString();
		}
	}
	display.SetValue(output);
	Thread.Sleep(1000);
}

The line short diff = module.GetReading(); obtains a reading from the sensor module which I am prototyping. This value could come from any sensor or from any source / calculation.

Hitting F5 deployed the code to the Netduino GO! and values quickly started appearing on the display. Success!

No… Wait…

I’m getting some unexpected output. Every now and then the module displays a number with some spaces in place of digits. Hmmmmm… what is going on!

Time for a quick test program. I know that the module works OK as the test projects ran fine. Adding a Debug.Print of the output variable gave me a clue. There was a pattern. Any numbers with the digit 9 in them showed a space instead of a digit. A quick test program showed that displaying 2929 where the variable of type int displayed the number correctly. Doing the same where the value was stored in a string showed any digit except the digit 9, these were replaced with spaces. Now we know where the problem is.

As noted earlier, Komodex Labs supply the source code for the drivers. So opening this project and some poking around the code for the display resulted in the problem being found. A quick modification to the source, recompile and then reference the newly compiled DLL in my code and Success !

Edit: Komodex labs have confirmed that the driver has been patched and as of 27/07/2012 the driver download contains the fix for the problem noted.

Here is a short video of the sensor and display working together:

The 8 x 8 x 8 LED cube has been on it’s travels again. This time it has made an appearance at the Bay Area Maker Faire:

Thanks to fellow Netduino community member Chris Hammond for permission to use this photo.