RSS

Archive for the ‘STM8’ Category

Transmitting Data Using the STM8S SPI Master Mode

Sunday, June 23rd, 2013

So far in The Way of the Register series we have only looked at SPI from a slave device point of view as we have been working towards creating a Netduino GO! module. For every slave device there must be a master, here we will look at configuring the STM8S to operate in SPI master mode.

The project will look at controlling a TLC5940 in order to emulate the work described in the post TLC5940 16 Channel PWM Driver. We could simply bit-bang the data out to the chip but instead we will use the SPI interface to achieve this.

The project breaks down into the following steps:

  1. Generate the grey scale clock and blank signals
  2. Bit-Bang data out over GPIO pins to create an operational circuit
  3. Convert the data transmission to SPI

See the quoted post for a description of how this chip works and for an explanation of the terminology used.

Generating the Grey Scale Clock and Blank Signals

The TLC5940 generated 4,096 grey scale values by using a PWM counter. Once the counter reaches 4096 pulses it stops until it is told to restart. The Blank pulse acts as a restart signal. This project will be controlling LEDs and so will want to continuously keep the counter running. If we did not keep the counter in the TLC5940 running then the LEDs would light for a short while and then simply turn off and remain off.

The greyscale clock is generated by using the Configurable Clock Output (CCO) pin on the STM8S. This pin simply outputs the clock pulses used to drive the STM8S. Reviewing the data sheet we find that the maximum value for the grey scale clock is 30MHz. Using out standard clock initialisation generates a clock with a frequency of 16MHz (approximately). This is well within the tolerances of the TLC5940. To output this we need to make a simple modification to our standard code, name change the line:

CLK_CCOR = 0;   //  Turn off CCO.

to:

CLK_CCOR = 1;   //  Turn on CCO.

The starting point for our application becomes:

#if defined DISCOVERY
    #include <iostm8S105c6.h>
#elif defined PROTOMODULE
    #include <iostm8s103k3.h>
#else
    #include <iostm8s103f3.h>
#endif
#include <intrinsics.h>

//
//  Setup the system clock to run at 16MHz using the internal oscillator.
//
void InitialiseSystemClock()
{
    CLK_ICKR = 0;                       //  Reset the Internal Clock Register.
    CLK_ICKR_HSIEN = 1;                 //  Enable the HSI.
    CLK_ECKR = 0;                       //  Disable the external clock.
    while (CLK_ICKR_HSIRDY == 0);       //  Wait for the HSI to be ready for use.
    CLK_CKDIVR = 0;                     //  Ensure the clocks are running at full speed.
    CLK_PCKENR1 = 0xff;                 //  Enable all peripheral clocks.
    CLK_PCKENR2 = 0xff;                 //  Ditto.
    CLK_CCOR = 1;                       //  Turn on CCO.
    CLK_HSITRIMR = 0;                   //  Turn off any HSIU trimming.
    CLK_SWIMCCR = 0;                    //  Set SWIM to run at clock / 2.
    CLK_SWR = 0xe1;                     //  Use HSI as the clock source.
    CLK_SWCR = 0;                       //  Reset the clock switch control register.
    CLK_SWCR_SWEN = 1;                  //  Enable switching.
    while (CLK_SWCR_SWBSY != 0);        //  Pause while the clock switch is busy.
}

//
//  Main program loop.
//
void main()
{
    //
    //  Initialise the system.
    //
    __disable_interrupt();
    InitialiseSystemClock();
    __enable_interrupt();
    while (1)
    {
        __wait_for_interrupt();
    }
}

Wiring up the STM8S and connecting the scope to PC4 (CCO output pin) gives the following trace on the scope:

CCO On Scope

CCO On Scope

The trace on the scope has a minimum value of around 680mV and a maximum of 2.48V. In an ideal world this signal should range from 0 to 3.3V (based upon a 3.3V supply). Adding an inverter from a 74HC04 and feeding the signal through one of the gates gives the following trace:

Invertor output on the scope

Inverter output on the scope

This is starting to look a lot better. The next task is to create the Blank signal. There are several ways of doing this. The most automatic way of doing this is to generate a very short PWM pulse using one of the timers in the STM8S. One drawback of this method is that it is more difficult to generate a Blank pulse on demand. Instead we will use the interrupt method described in the same article. Whilst not automatic it is still a trivial task to complete. We simply modify the code from the method to load the counters with 4,096. The code for the GPIO port, timer and interrupt becomes:

//
//  Timer 2 Overflow handler.
//
#pragma vector = TIM2_OVR_UIF_vector
__interrupt void TIM2_UPD_OVF_IRQHandler(void)
{
    PD_ODR_ODR4 = 1;
    PD_ODR_ODR4 = 0;
    TIM2_SR1_UIF = 0;       //  Reset the interrupt otherwise it will fire again straight away.
}

//
//  Setup Timer 2 to generate an interrupt every 4096 clock ticks.
//
void SetupTimer2()
{
    TIM2_PSCR = 0x00;       //  Prescaler = 1.
    TIM2_ARRH = 0x10;       //  High byte of 4096.
    TIM2_ARRL = 0x00;       //  Low byte of 4096.
    TIM2_IER_UIE = 1;       //  Turn on the interrupts.
    TIM2_CR1_CEN = 1;       //  Finally enable the timer.
}

//
//  Setup the output ports used to control the TLC5940.
//
void SetupOutputPorts()
{
    PD_ODR = 0;             //  All pins are turned off.
    PD_DDR_DDR4 = 1;        //  Port D, pin 4 is used for the Blank signal.
    PD_CR1_C14 = 1;         //  Port D, pin 4 is Push-Pull
    PD_CR2_C24 = 1;         //  Port D, Pin 4 is generating a pulse under 2 MHz.
}

Hooking up the scope to PD4 gives the following trace:

Blanking pulses

Blanking pulses

The single pulses are being generated at a frequency of approximately 3.9kHz. A little mental arithmetic dividing the 16MHz clock by 4,096 comes out to about 3,900.

Zooming in on the signal we see:

Single Blanking Pulse

Single Blanking Pulse

This shows that the signal is 125nS wide. This is acceptable as the minimum pulse width given in the data sheet is 20nS.

So at this point we have the 16MHz grey scale clock signal and the Blank pulse being generated every 4,096 clock pulses.

Connecting the TLC5940

The next task is to connect the STM8S to the TLC5940. You should refer to the article TLC5940 16 Channel PWM Driver for more information on the pins and their meaning. For this exercise we will use the following mapping:

STM8S PinTLC5940 Pin
PD4Blank (pin 23)
PD3XLAT (pin 24)
PD2VPRG (pin 27)
PD5Serial data (pin 26)
PD6Serial clock (pin 25)
PC4 (via inverter)GSCLK (pin 18)

You will note that the serial data and clock are currently connected to PD5 and PD6 respectively. Whilst the eventual aim is to communicate with the TLC5940 via SPI, the initial communication will be using Bit-Banging. We will move on to using SPI once the operation of the circuit has been proven using tested technology.

The first changes we will have to make create some #define statements to make the code a little more readable. We also add some storage space for the grey scale and dot correction data.

//
//  Define which pins on Port D will be used as control signals for the TLC5940.
//
//  BLANK - A pulse from low to high causes the TLC5940 to restart the counter
//  XLAT - A high pulse causes the data to be transferred into the DC or GS registers.
//  VPRG - Determines which registers are being programmed, High = DC, Low = GS.
//
#define PIN_BLANK                   PD_ODR_ODR4
#define PIN_XLAT                    PD_ODR_ODR3
#define PIN_VPRG                    PD_ODR_ODR2
//
//  Bit bang pins.
//
#define PIN_BB_DATA                 PD_ODR_ODR5
#define PIN_BB_CLK                  PD_ODR_ODR6
//
//  Values representing the modes for the VPRG pin.
//
#define PROGRAMME_DC                1
#define PROGRAMME_GS                0

//
//  TLC5940 related definitions.
//
#define TLC_NUMBER                  1
#define TLC_DC_BYTES_PER_CHIP       12
#define TLC_DC_BYTES                TLC_NUMBER * TLC_DC_BYTES_PER_CHIP
#define TLC_GS_BYTES_PER_CHIP       24
#define TLC_GS_BYTES                TLC_NUMBER * TLC_GS_BYTES_PER_CHIP

//
//  Next we need somewhere to hold the data.
//
unsigned char _greyScaleData[TLC_GS_BYTES];
unsigned char _dotCorrectionData[TLC_DC_BYTES];

The Bit-Banging methods should look familiar to anyone who has been reading any of the posts in The Way of the Register series.

//--------------------------------------------------------------------------------
//
//  Bit bang data.
//
//  TLC5940 expects the data to be shifted MSB first.  The data
//  is shifted in on the rising edge of the clock.
//
void BitBang(unsigned char byte)
{
    for (short bit = 7; bit >= 0; bit--)
    {
        if (byte &amp; (1 << bit))
        {
            PIN_BB_DATA = 1;
        }
        else
        {
            PIN_BB_DATA = 0;
        }
        PIN_BB_CLK = 1;
        PIN_BB_CLK = 0;
    }
    PIN_BB_DATA = 0;
}

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

Related to the Bit-Banging methods are the two methods which will send the grey scale and dot correction data:

//--------------------------------------------------------------------------------
//
//  Send the grey scale data to the TLC5940.
//
void SendGreyScaleData(unsigned char *buffer, int length)
{
    PIN_VPRG = PROGRAMME_GS;
    BitBangBuffer(buffer, length);
    PulseXLAT();
    PulseBlank();
}

//--------------------------------------------------------------------------------
//
//  Send the dot correction buffer to the TLC5940.
//
void SendDotCorrectionData(unsigned char *buffer, int length)
{
    PIN_VPRG = PROGRAMME_DC;
    BitBangBuffer(buffer, length);
    PulseXLAT();
    PulseBlank();
}

We also need a few methods to make the TLC5940 latch the data and also restart the counters:

//--------------------------------------------------------------------------------
//
//  Pulse the Blank pin in order to make the TLC5940 reload the counters and
//  restart timer.
//
void PulseBlank()
{
    PIN_BLANK = 1;
    PIN_BLANK = 0;
}

//--------------------------------------------------------------------------------
//
//  Pulse the XLAT pin in order to make the TLC5940 transfer the
//  data from the latches into the appropriate registers.
//
void PulseXLAT()
{
    PIN_XLAT = 1;
    PIN_XLAT = 0;
}

Next we need to set the initial condition. For this we set the TLC dot correction off and also turn all of the LEDs off:

//--------------------------------------------------------------------------------
//
//  Initialise the TLC5940.
//
void InitialiseTLC5940()
{
    for (int index = 0; index < TLC_DC_BYTES; index++)
    {
        _dotCorrectionData[index] = 0xff;
    }
    for (int index = 0; index < TLC_GS_BYTES; index++)
    {
        _greyScaleData[index] = 0;
    }
    SendDotCorrectionData(_dotCorrectionData, TLC_DC_BYTES);
    SendGreyScaleData(_greyScaleData, TLC_GS_BYTES);
}

The final support method we need to add is the method which sets the brightness of an LED. The brightness is a 12-bit value (0-4095). This means each LED uses 1.5 bytes for the brightness value. The following methods breaks down the value and ensures that the correct bits are set in the grey scale buffer depending upon which LED is being changed:

//--------------------------------------------------------------------------------
//
//  Set the brightness of an LED.
//
void SetLEDBrightness(int ledNumber, unsigned short brightness)
{
    int offset = (ledNumber >> 1) * 3;
    if (ledNumber &amp; 0x01)
    {
        _greyScaleData[offset + 1] = (unsigned char) (_greyScaleData[offset + 1] &amp; 0xf0) | ((brightness & 0x0f00) >> 8);
        _greyScaleData[offset + 2] = (unsigned char) (brightness & 0xff);
    }
    else
    {
        _greyScaleData[offset] = (unsigned char) ((brightness &amp; 0x0ff0) >> 4) &amp; 0xff;
        _greyScaleData[offset + 1] = (unsigned char) ((brightness & 0x0f) >> 4) | (_greyScaleData[offset + 1] & 0x0f);
    }
}

We should also create a similar method for changing the dot correction value for an LED. This is left as an exercise for the reader as we will not be changing this value in this code.

Proving the concept

If we have connected the TLC5940 correctly and our code works we should be able to connect up some LEDs (common anode) to the TLC5940 and change the brightness under program control.

This main program loop slowly increases the brightness of the LEDs. When they are at full brightness they are turned off and the process starts again:

//--------------------------------------------------------------------------------
//
//  Main program loop.
//
void main()
{
    //
    //  Initialise the system.
    //
    __disable_interrupt();
    InitialiseSystemClock();
    SetupOutputPorts();
    SetupTimer2();
    
    InitialiseTLC5940();
    __enable_interrupt();
    //
    //  Main program loop.
    //
    int brightness = 0;
    int counter = 0;
    while (1)
    {
        __wait_for_interrupt();
        counter++;
        if (counter == 20)
        {
            TIM2_CR1_CEN = 0;
            counter = 0;
            for (int index = 0; index < 16; index++)
            {
                SetLEDBrightness(index, brightness);
            }
            SendGreyScaleData(_greyScaleData, TLC_GS_BYTES);
            brightness++;
            if (brightness == 4096)
            {
                brightness = 0;
            }
            TIM2_CR1_CEN = 1;       //  Finally re-enable the timer.
        }
    }
}

If you connect a scope to the cathode of one of the LEDs you will see that the wave form slowly changes over time. At the start, the LED is fully on and the trace on the scope shows a horizontal line, i.e. a constant voltage. As time moves on and the value in the dot correction buffer changes you start to see a PWM signal similar to the following:

PWM Output On Scope 1

PWM Output On Scope 1

This trace shows the signal when the LEDs are a little brighter:

PWM Output On Scope 2

PWM Output On Scope 2

Having arrived here we now know that the circuit has been connected correctly and that the control logic in the main method works. We can now move on to considering what we need to do in order to use SPI in master mode. The aim will be to simply remove the Bit-Banging methods and replace these with an interrupt driven SPI master algorithm.

SPI Master

So now we have a working circuit we need to look at SPI on the STM8S. Firstly let’s remind ourselves of the serial communication parameters for the TLC5940. This chip reads the data on the leading clock edge (CPHA = 1). We have also set the clock idle state to low (CPOL = 0).

It is also advisable to start off using the lowest clock speed for SPI in order to confirm correct operation of the software and circuit. Lower speed are less likely to be subject to interference.

SPI Registers

You should review the previous articles on SPI communication if you are not already familiar with the SPI registers we have used so far. In this post we will only discuss the new settings required to switch from being a SPI slave device to a SPI master device.

SPI_CR1_BR – Baud Rate Control

The SPI baud rate is determined by the master clock frequency and the value in this register. The divisor used to set the baud rate according to the following table:

SPI_CR1_BRDivisor
0002
0014
0108
01116
10032
10164
110128
111256

The SPI baud rate is calculated as fmaster / divisor. So for our master clock speed of 16MHz we get the lowest clock speed of 16,000,000 / 256, or 62,500Hz.

SPI_CR1_MSTR – Master Selection

Setting this bit switches SPI into master mode (see also SPI_CR1_SPE).

Note that the reference for the STM8S also states that this bit (and SPI_CR1_SPE) will only remain set whilst NSS is high. It this therefore essential to connect NSS to Vcc if this device is not being used as a slave device.

Implementing SPI

Using SPI presents us with a small problem, namely the program will have to start to operate in a more asynchronous way. The code presented so far has only one interrupt to be concerned with, namely the timer used to control the Blank signal. Adding SPI to the mix means that we will have to also consider the SPI interrupt as well. It also adds the complication of sending dot correction data followed by grey scale data. This last problem will not be covered here and is left as an exercise for the reader.

The initialisation code merely sets things up for us:

//--------------------------------------------------------------------------------
//
//  Initialise SPI to be SPI master.
//
void SetupSPIAsMaster()
{
    SPI_CR1_SPE = 0;                    //  Disable SPI.
    SPI_CR1_CPOL = 0;                   //  Clock is low when idle.
    SPI_CR1_CPHA = 0;                   //  Capture MSB on first edge.
    SPI_ICR_TXIE = 1;                   //  Enable the SPI TXE interrupt.
    SPI_CR1_BR = 7;                     //  fmaster / 256 (62,500 baud).
    SPI_CR1_MSTR = 1;                   //  Master device.
}

Much of the code should be familiar as it has been used in previous posts discussing SPI slave devices. Not however that we do not enable SPI at this point. We simply set the scene for us to use SPI later.

The SPI data transfers will be controlled by using an interrupt service routine:

//--------------------------------------------------------------------------------
//
//  SPI Interrupt service routine.
//
#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.
        return;
    }
    if (SPI_SR_TXE)
    {
        //
        //  Check if we have more data to send.
        //
        if (_txBufferIndex == _txBufferSize)
        {
            while (SPI_SR_BSY);
            SPI_CR1_SPE = 0;
            _txBuffer = 0;
            PulseXLAT();
            PulseBlank();
            TIM2_CR1_CEN = 1;
        }
        else
        {
            SPI_DR = _txBuffer[_txBufferIndex++];
        }
    }
}

The main works starts when we have established that the transmit buffer is empty (SPI_SR_TXE is set). If we have more data then we put the byte into the data register (SPI_DR). If we have transmitted all the data we have then we wait for the last byte to complete transmission (SPI_SR_BSY becomes false) before we start to terminate the end of the SPI communication.

In order to send some data we really just need to setup the pointers and counters correctly and then enable SPI. So the SendGreyScaleData method becomes:

//--------------------------------------------------------------------------------
//
//  Send the grey scale data to the TLC5940.
//
void SendGreyScaleData(unsigned char *buffer, int length)
{
    PIN_VPRG = PROGRAMME_GS;
    _txBuffer = buffer;
    _txBufferIndex = 0;
    _txBufferSize = length;
    TIM2_CR1_CEN = 0;
    SPI_CR1_SPE = 1;
}

We also need to have a look at the main program loop as we use the __wait_for_interrupt() method in order to determine when we should start to process the next LED brightness value. We now need to ignore the interrupts when SPI is enabled otherwise the brightness will increase each time the transmit buffer is empty. A crude implementation eliminating the SPI interrupts is:

int brightness = 0;
int counter = 0;
while (1)
{
    __wait_for_interrupt();
    if (!SPI_CR1_SPE)
    {
        counter++;
        if (counter == 20)
        {
            TIM2_CR1_CEN = 0;
            counter = 0;
            for (int index = 0; index < 16; index++)
            {
                SetLEDBrightness(index, brightness);
            }
            SendGreyScaleData(_greyScaleData, TLC_GS_BYTES);
            brightness++;
            if (brightness == 4096)
            {
                brightness = 0;
            }
            TIM2_CR1_CEN = 1;       //  Finally re-enable the timer.
        }
    }
}

Making these changes and running the code shows that the system operated as before.

Increasing the Baud Rate

As noted earlier, the baud rate has been set low in order to reduce the chance of any problems being experienced due to interference. Now we have established that using SPI communication is possible and the circuit works as before we can start to increase the baud rate. Using our 16MHz clock we find we have the following baud rates which are theoretically possible:

SPI_CR1_BRDivisorSPI Frequency
00028 MHz
00144 MHz
01082 MHz
011161 MHz
10032500 KHz
10164250 KHz
110128125 KHz
11125662.5 KHz

A little experimentation is called for. Being ambitious I started with a clock frequency of 1MHz. This resulted in a flickering effect on the LED display. So, 1MHz is too ambitious, let’s start to reduce the frequency. I finally settled on 250 KHz as this allowed the circuit to function as before.

Conclusion

Using SPI master for data transmission was not as difficult as I originally thought. To make this application complete there are a few tasks to follow up on, namely:

  1. Receiving data over SPI
  2. Create the method to allow setting the dot correction values
  3. Transmitting buffers from a queue
  4. Minor tidying up of the timer control

The use of SPI here actually increased the time taken (597uS Bit-Banging c.f. 795uS for 250 KHz SPI) to reliably send the grey scale data to the TLC5940. I suspect that the time can be decreased if the circuit was taken from breadboard and put onto a PCB manufactured for the purpose. The breadboard for this circuit currently looks like this:

Bread Board And Flying Leads

Bread Board And Flying Leads

As you can see, there is a lot of opportunity for interference with all those flying leads.

While the time taken might have increased, the load on the microcontroller will have decreased as the SPI method is interrupt driven. The actual transmission is off-loaded to the microcontrollers dedicated circuitry.

As usual, the source code for this project is available to download.

Making a Netduino GO! Module – Conclusion

Tuesday, May 7th, 2013

Making the OutputExpander module has been an interesting journey. The original drawings started in August 2012 and then sat on the hard drive for about eight months. Much of the time following the original drawings were spent working out how the STM8S worked. You can find out more in The Way of the Register series (something I will pick up again soon, to my mind there are a few missing topics).

For those who do not know, I’m a software engineer and electronics is a hobby. The prospect of designing a board and using SMD components would have been unthinkable to me two years ago. Today I sit here with my first prototype PCB connected to a commercial board and the output looks reasonably professional – well I’ll let you decide.

Completed Board

Completed Board


Not looking too bad if I say so myself.

So let’s look at what I have learned and also how long the project took.

Lessons Learned

With all projects we should look back and learn from the experience, both good and bad. So here are a few things I have learned over the past few months.

Designing the Board

The original design started life in August 2012. I probably should have taken the plunge and developed the board a little quicker than I did although in truth, I did not get the major requirement of the board, namely GoBus 1.0 really sorted out until late November 2012.

Prototyping

This was probably the simplest bit of the project. I have all of the standard components in my toolbox already and I also have the tools required. This was really a case of getting the system working. The hardest part was getting to grips with the STM8S, a story I have documented in The Way of The Register series of posts.

Schematic

During this part of the design phase I tried several different packages. All of them had strengths and weaknesses. I finally settled on DesignSpark. For me this package had three major strengths:

  • It’s free
  • You can use it for commercial projects
  • It feels like a Windows application
  • In fairness it does have a few weaknesses. The most obvious for me was the lack of the ability to add images of any kind to the design. Come on, at version 5 you should have this one!

    Nets – I discovered these when producing the final draft of the schematic. These allowed the separation of the nets into logical groups/functions/areas. It made the schematic a lot cleaner.

    Schematic to Manufacture

    For me this was the where I learned the most. The first thing I learned was that auto-routers are dreadful. They are slow and produce some interesting board layouts. This board is a simple board and yet the auto-router still took a long time to make a half-hearted attempt at routing the board. In the end I did this manually. This was not too much of a problem as the board was simple.

    Next, you have to learn to think in three dimensions. You have two layers so use them.

    The Netduino modules produced by Secret Labs have nice rounded corners – these are a devil to produce in DesignSpark. I think that the module I produced has one corner which is slightly different from the others.

    The cost of prototyping is a lot lower than I thought. Ten boards including shipping costs about £18 and only took 10 days.

    I now know what 0403 means. The ‘0’ stands for Ohhh my goodness that’s small. Seriously, the four digits should be split into two and thy give the dimensions of the component. So for a metric component an 0403 part is 0.4 x 0.3 mm – that’s small.

    The STM8S part selected has a 0.65mm pitch for the pins. I originally found this a little worrying. Don’t be afraid – they are not that bad.

    Get a USB microscope when soldering SMD components. This tools is cheap and allows the examination of joints for shorts. The quality will never be great, mine only runs at 640×480, but a 400x zoom means you can be sure that you have no problems.

    Add test points. There came a point when I was making the board and I needed to see the data going through to the 74HC595’s. I did not have a suitable connection and so I had to solder a piece of wire to the board:

    Improvised Test Point

    Improvised Test Point

    A good test point would have made this easier.

    How Long Did it Take

    The original drawing started in August 2012 and the final board was put together and tested only yesterday. So in elapsed time that’s about nine months. In real working time this broke down as follows:

    Activity Duration (Hours)
    Building Prototype circuit 2
    Prototype software 3
    Schematic 6
    PCB layout 20
    Assembly and testing 5
    Enhanced software 4
    Total 40

    Something to bear in mind is that no production evaluation or component selection has been conducted as part of this project. It was supposed to be the final item on the list. I am still not sure if this should be taken through to manufacture – time will tell.

    Another item to be considered is to achieve the Netduino GO! logo approval. At the time of writing this required the approval of the board by Secret Labs – this activity has not been completed.

    Conclusion

    Well, that was a hectic few weeks.

    Did I enjoy it – YES!

    Would I recommend that you try it – YES!

    As for me, I’ll be taking a few days off of hardware development and blogging. Love doing it but it can take it’s toll.

    I suppose you may be interested in some downloads…

    If you use any of the code or techniques discussed in this series of posts then please let me know as I’m interested in what other people are doing with this work.

    Making a Netduino GO! Module – Stage 6 – Assembling the Prototype

    Monday, May 6th, 2013

    A few days ago I received a package from China, namely my Output Expander prototype boards:

    Bubble Wrapped Boards From China

    Bubble Wrapped Boards From China

    Could not wait to unwrap them:

    OutputExpander Bare Boards

    OutputExpander Bare Boards

    Only one thing left to do, start assembling them. As with all projects this will be broken down into steps:

    • Add the STM8S microcontroller and test
    • Add one 74HC595 shift register and test
    • Complete the board and add connectors and of course, test
    • By using a modular approach it should be easy to detect a problem with the design or assembly.

      Component List

      The board requires the following components:

      ComponentValueQuantity
      STM8S103F3NA1
      IDC socket1.27″ pitch1
      Sr1, SR2, Sr3, SR4SOL / SOP164
      C21uF0403
      C1, C3, C4, C5, C6, C7100nF – 04036
      Connectors0.1″Misc

      When these arrive be prepared, they are small!

      Adding the Microcontroller

      The board will need a microcontroller and some way of programming it. The logical first task is to add the controller, socket and the supporting passive components. Doing this will allow us to programme the controller with the firmware. As a test we can connect the programmed board to the Netduino Go!. If the connections between the board and the Netduino GO! are correct then the blue LED on the socket on the Netduino Go! should light.

      If you are attempting to follow this series and you are making your own board then I recommend you browse the net and have a look for videos on soldering SMD components. I found the tutorials on drag soldering really useful.

      Out with the soldering iron, a magnifier (it was needed). One thing I noticed was the difference between the 74HC595 pads and the pads for the STM8S. The 74HC595 component used was a built in component whilst the STM8S was a component I had created. The most noticeable difference between the two parts was the size of the pads on the PCB compared to the size of the component. The 74HC595 pads were elongated. These make soldering easier.

      STM8SPadsShiftRegisterPads
      STM8S75HC595

      Although the pins on the STM8S are only 0.65mm pitch, soldering is not as difficult as it first appears. A quick first attempt gave the following:

      STM8S Mounted On Board

      STM8S Mounted On Board

      There is only one item of concern and that is the whisker of solder between the fourth and fifth pins down on the right hand side of the image. This was quickly tidied up by dragging the soldering iron between the two pins.

      Next task was to add the passives which supported the STM8S leaving the passives for the shift registers for later. This is where you get some idea of the difference between the size of the components vs the size of the tools you are using:

      Capacitor and Tools

      Capacitor and Tools

      At this point I realised that an 0403 (metric sizing) component is 0.4mm x 0.3mm and the smallest soldering iron bit I has was about 1.5mm. Not to worry, the pads on the board are a reasonable size, simply tin the pads and then slide the capacitor into the molten solder.

      The next job was to add the socket for the GoBus. The sockets are surface mounted 1.27″ pitch IDC sockets. I found the easiest way to add these was to tin one pad and then slide the socket into place. The remaining pads could be soldered by placing the solder at the end of the connector and then applying heat and letting the solder run under the socket. It’s not as difficult as it sounds.

      At this point, the microcontroller should be in place with enough supporting hardware to allow it to be programmed. This was achieved by connecting the ST-Link/V2 programmer to the prototype board using the Komodex Breakout Board. The firmware developed in the previous posts was loaded into the development environment and deployed top the microcontroller.

      Programming the STM8S

      Programming the STM8S

      No deployment errors!

      A good indication that the microcontroller and the supporting hardware are functioning correctly.

      Add a Shift Register

      Next step is to add a single shift register and see if we get some output. Soldering the shift registers was a lot simpler than the STM8S as the pin pitch was greater. These could be soldered more conventionally although the pitch was finer than you may be used to if you have only worked with PTH components.

      Connecting the module to the Netduino GO! acts as a quick check:

      Netduino Go! Connected to OutputExpander

      Netduino Go! Connected to OutputExpander

      The blue LED lights up – the Netduino GO! recognises the OutputExpander as a valid module.

      Adding the single register worked and so the next task is to add the remaining registers and connectors.

      But All Was Not Well…

      During the assembly and testing process I had managed to accidentally short a few pins on the shift registers. This resulted in no output from the OutputExpander module. Breaking out the scope and the logic analyser proved that something was very wrong. The following trace shows the problem:

      Original Output From the OutputExpander

      Original Output From the OutputExpander

      It appears that the latch and clear lines were being triggered at the same time. I was able to establish by disconnecting the module from the circuit that there was not short between the two lines. Something else must be going on. Some further digging into the output from the logic analyser showed that the clear signal was being triggered slightly before the latch signal and that the latch was being released slightly after the clear signal. As a result I would expect no output from the shift registers – this is what I was seeing.

      Not wanting to waste money on components I continued to check the circuit but could not find anything else obviously wrong with the soldering or the software.

      Only one remaining option. Try a putting together a new board. Back to step one.

      A New Board

      Building the new board was a lot quicker than the first. Following the same procedure (one step at a time and test all the way) produced a new board:

      Before testing the board there was a final modification to make. This time to the software. The board has the outputs labelled from left to right with the lower bits being to the right of the board. The prototype module had the shift registers ordered from right to left. A quick change to the C code on the STM8S soon resolved this problem:

      //--------------------------------------------------------------------------------
      //
      //  GO! function 2 - Output the specified bytes to the shift registers.
      //  Tx buffer.
      //
      void SetShiftRegisters()
      {
          for (int index = 0; index < _numberOfShiftRegisters; index++)
          {
              _registers[index] = _rxBuffer[5 - index];
          }
          OutputData();
          NotifyGOBoard();
      }
      

      A small bug had also been noticed in the clock configuration method. The code stated that CCO was turned off but the code actually turned it on. The code should read:

      //--------------------------------------------------------------------------------
      //
      //  Setup the system clock to run at 16MHz using the internal oscillator.
      //
      void InitialiseSystemClock()
      {
          CLK_ICKR = 0;                       //  Reset the Internal Clock Register.
          CLK_ICKR_HSIEN = 1;                 //  Enable the HSI.
          CLK_ECKR = 0;                       //  Disable the external clock.
          while (CLK_ICKR_HSIRDY == 0);       //  Wait for the HSI to be ready for use.
          CLK_CKDIVR = 0;                     //  Ensure the clocks are running at full speed.
          CLK_PCKENR1 = 0xff;                 //  Enable all peripheral clocks.
          CLK_PCKENR2 = 0xff;                 //  Ditto.
          CLK_CCOR = 0;                       //  Turn off CCO.
          CLK_HSITRIMR = 0;                   //  Turn off any HSIU trimming.
          CLK_SWIMCCR = 0;                    //  Set SWIM to run at clock / 2.
          CLK_SWR = 0xe1;                     //  Use HSI as the clock source.
          CLK_SWCR = 0;                       //  Reset the clock switch control register.
          CLK_SWCR_SWEN = 1;                  //  Enable switching.
          while (CLK_SWCR_SWBSY != 0);        //  Pause while the clock switch is busy.
      }
      

      Testing

      The step by step testing process had shown that a single shift register worked, now to prove that four worked. Now it was time to add some more and connect some LEDs:

      Netduino Go OutputExpander and Some LEDs

      Netduino Go OutputExpander and Some LEDs

      And here’s a video of it working:

      Conclusion

      Assembly was not as difficult as it first appears even considering the small size of the components. In fact the STM8S was programmed first time.

      One piece of equipment I did find invaluable was a cheap USB microscope. These don’t give a high resolution image but they do allow you to zoom in on the board and check for problems.

      One final post left – time to reflect on the process.

    Making a Netduino GO! Module – Stage 5 – Enhancing the Drivers

    Saturday, April 27th, 2013

    This series of posts follows the steps required in order to make your own Netduino GO! module. To do this we are using a simple idea, an Output Expander (yes, it seems to have a name now) for the Netduino GO!. Using only a hand full of simple components, the Output Expander will add 32 digital outputs to the Netduino Go!.

    The Story So Far…

    The module has so far completed the following steps:

    • Concept and prototype on breadboard
    • Basic drivers
    • PCB design and layout
    • Generation of PCB manufacturing files

    The first batch of 10 boards were ordered on 20th April 2013 using iTeads prototyping service. I am expecting the manufacturing process to take about one week with a further two weeks for shipping as I used the cheap, slow courier service.

    In the meantime we still have the breadboard prototype to work with. This may only have two shift registers attached to it but by carefully parametrising the code we should be able to develop a driver which only needs to be recompiled when the final hardware becomes available.

    Features

    The driver for this module should be relatively simple as we are merely setting outputs from the shift registers to be either on or off. We shall start with the following list of desired features:

    • Default initialisation to set up for one board
    • Set the bytes for the digital outputs
    • Array like access for the bits
    • Configurable latching mode (automatic or manual)
    • Clear the output
    • Turn outputs from the registers on or off

    The only remaining task is to decide where the features are to be implemented. We have two options:

    • On the Netduino GO! in C#
    • On the STM8S in C

    Some of the code is better left on the Netduino GO! with the base features (setting all of the register values etc) being implemented on the STM8S.

    Initialisation

    Initialisation should allow for the use of cascaded boards. If you look back at the schematic you will notice a connector called CascadeConn. This connector allows the addition of a simpler board as an expansion module. This board only need to supply additional shift registers leaving the first, main board supplying the logic to communicate with the Netduino GO!. The concept is that if you want 64 outputs then you would have a single Output Expander module with a single, cheaper daughter board.

    In order to support the addition of the daughter board the initialisation will need to support the specification of the number of shift registers in the cascade.

    In supporting the cascading of these boards we will also need to provide some sensible default values. The basic case is a single board which contains four shift registers.

    We should also consider a maximum value for the number of shift registers. In this case I am going to set this to 12 for two reasons:

    • Power considerations – all of the power for the shift registers is being provided by the Netduino GO!
    • Data packet size – the data packets used in the GoBus are fixed size. Keeping the number of shift registers to a value where only one data packet is required simplifies the communication between the Netduino GO! and the module as a single packet can be used for all messages.

    In order to facilitate this we will need code on both the Netduino GO! and the module.

    Module Code

    The code on the module should allow for the number of shift registers to be set up (assuming a default value of four registers) and then clear the registers. The default code should be called when the module is re-initialised.

    //--------------------------------------------------------------------------------
    //
    //  GO! function 3 - Set up the module.
    //
    void SetUp()
    {
        U8 n = _rxBuffer[2];
        if ((n < 0) && (n < MAX_REGISTERS))
        {
            _numberOfShiftRegisters = n;
            free(_registers);
            _registers = (U8 *) malloc(n);
            ClearRegisters();
            OutputData();
            NotifyGOBoard();
        }
    }
    

    Netduino GO! Code

    The initialisation code on the Netduino GO! will assume that the startup code on the module will initialise itself to four shift registers. This will reduce the communications overhead between the Netduino GO! and the module. The following when added to the Initialise method should set up the module driver on the Netduino GO! for a variable number of shift registers in the sequence:

    //
    //  Next, set up the space to store the data.
    //
    _shiftRegisterData = new byte[numberOfShiftRegisters];
    for (int index = 0; index < numberOfShiftRegisters; index++)
    {
        _shiftRegisterData[index] = 0;
    }
    LatchMode = LatchingMode.Automatic;
    if (numberOfShiftRegisters != 4)
    {
        _writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
        _writeFrameBuffer[1] = CMD_SETUP;
        _writeFrameBuffer[2] = (byte) (numberOfShiftRegisters & 0xff);
        WriteDataToModule("Initialise: cannot setup the OutputExpander module");
    }
    

    Set Outputs

    Setting the outputs is simply a case of sending a number of bytes, one for each shift register to the 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 != _shiftRegisterData.Length)
        {
            throw new ArgumentException("registers: length mismatch");
        }
        for (int index = 0; index < registers.Length; index++)
        {
            _shiftRegisterData[index] = registers[index];
        }
        Latch();
    }
    

    The module code needs a slight adjustment to transfer the correct number of incoming bytes to the register store:

    //--------------------------------------------------------------------------------
    //
    //  GO! function 2 - Output the specified bytes to the shift registers.
    //  Tx buffer.
    //
    void SetShiftRegisters()
    {
        for (int index = 0; index < _numberOfShiftRegisters; index++)
        {
            _registers[index] = _rxBuffer[2 + index];
        }
        OutputData();
        NotifyGOBoard();
    }
    

    Array of Bits

    From a software point of view, a shift register is nothing more than an array of boolean values. Internally it makes sense for the driver to allow this abstraction and use the indexing operator to set a single bit at a time. The code for this operator looks something like this:

    /// <summary>
    /// Overload the index operator to allow the user to get/set a particular 
    /// bit in the shift register.
    /// </summary>
    /// <param name="bit">Bit number to get/set.</param>
    /// <returns>Value in the specified bit.</returns>
    public bool this[int bit]
    {
        get
        {
            if ((bit >= 0) && (bit < (_shiftRegisterData.Length * 8)))
            {
                int register = bit >> 3;
                byte mask = (byte) (bit & 0x07);
                return ((_shiftRegisterData[register] & mask) == 1);
            }
            throw new IndexOutOfRangeException("OutputExpander: Bit index out of range.");
        }
        set
        {
            if ((bit >= 0) && (bit < (_shiftRegisterData.Length * 8)))
            {
                int register = bit >> 3;
                byte mask = (byte) ((1 << (bit & 0x07)) & 0xff);
                if (value)
                {
                    _shiftRegisterData[register] |= mask;
                }
                else
                {
                    mask = (byte) ~mask;
                    _shiftRegisterData[register] &= mask;
                }
                if (LatchMode == LatchingMode.Automatic)
                {
                    Latch();
                }
            }
            else
            {
                throw new IndexOutOfRangeException("OutputExpander: Bit index out of range.");
            }
        }
    }
    

    Adding the above code allows the programmer to use constructs such as:

    OutputExpander outputs = new OutputExpander();
    outputs[2] = true;
    

    instead of the more obscure:

    OutputExpander outputs = new OutputExpander();
    byte[] data = new byte[4];
    data[0] = 0x04;
    SetOutputs(data);
    

    Not only is the former example more elegant but it is also more concise.

    Clear All Registers

    This method will simply clear the shift registers and set the outputs to 0;

    /// <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;
        for (int index = 0; index < _shiftRegisterData.Length; index++)
        {
            _shiftRegisterData[index] = 0;
        }
        WriteDataToModule("Clear cannot communicate with the Output Expander module");
    }
    

    This method could have been rewritten to set the values to 0 and then send the values to the module. However, the prototype already had an implementation of a clear command and so this was left in as is.

    Latch Mode

    The introduction of the array indexing operators does introduce on complication, namely that we cannot set all of the outputs to a specified value at the same time without delaying the latching of the registers. Consider the following case:

    OutputExpander outputs = new OutputExpander();
    outputs[2] = true;
    outputs[3] = true;
    

    In this case we would set bit 2 of the lower shift register followed by bit 3 of the same shift register. Because of the speed of .NETMF there would be a slight delay between the two outputs of the shift register being set high. In order to allow for this we introduce the ability to delay the latching of the data from the internal shift register into the output register.

    /// <summary>
    /// Determine when the data should be sent to the module.
    /// </summary>
    public enum LatchingMode
    {
        /// <summary>
        /// Automtically send the data to the module as soon as there are any changes.
        /// </summary>
        Automatic,
        /// <summary>
        /// Manually latch the data.
        /// </summary>
        Manual
    }
    
    /// <summary>
    /// Backing variable for the LatchMode property.
    /// </summary>
    private LatchingMode _latchMode;
    
    /// <summary>
    /// Determine how the data will be send to the module.  The default is to 
    /// automatically send data as soon as there are any changes.
    /// </summary>
    public LatchingMode LatchMode
    {
        get { return (_latchMode); }
        set { _latchMode = value; }
    }
    

    The initialisation of the class would also need to be modified in order to set the mode to automatic:

    LatchMode = LatchingMode.Automatic;
    

    The most lightweight method of using the LatchMode is to simply not send the data to the shift registers until the mode is either reset or until the controlling program explicitly latches the data. The Set method will therefore need some adjustment to take into account the two modes:

    /// <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 != _shiftRegisterData.Length)
        {
            throw new ArgumentException("registers: length mismatch");
        }
        for (int index = 0; index < registers.Length; index++)
        {
            _shiftRegisterData[index] = registers[index];
        }
        if (LatchMode == LatchingMode.Automatic)
        {
            Latch();
        }
    }
    

    Latch Operation

    The introduction of the LatchMode means that we also need to allow for the data to be latched into the shift registers.

    /// <summary>
    /// Call the Set command on the module to set the outputs of the shift registers.
    /// </summary>
    private void Set()
    {
        _writeFrameBuffer[0] = GO_BUS10_COMMAND_RESPONSE;
        _writeFrameBuffer[1] = CMD_SET_REGISTERS;
        for (int index = 0; index < _shiftRegisterData.Length; index++)
        {
            _writeFrameBuffer[2 + index] = _shiftRegisterData[index];
        }
        WriteDataToModule("Latch cannot communicate with the Output Expander module");
    }
    

    The above method simply sends the data to the module.

    Testing

    We can perform some simple testing of the software while the prototype boards are being made by using the breadboard test environment build in the first post. This board only has two shift registers but it should be possible to test the majority of functionality using this board.

    In the previous posts we have cycled through the bits one at a time either from 0 to 15 or down from 15 to 0. In this example we will perform some counting and use the LEDs to display the number in binary. Our test code becomes:

    output = new OutputExpander(2);
    short cycleCount = 0;
    byte[] registers = new byte[2];
    output.LatchMode = OutputExpander.LatchingMode.Manual;
    while (true)
    {
        Debug.Print("Cycle: " + ++cycleCount);
        short mask = 1;
        output.Clear();
        for (int index = 0; index <= 15; index++)
        {
            if ((cycleCount & mask) != 0)
            {
                output[index] = true;
            }
            mask <<= 1;
        }
        output.Latch();
        Thread.Sleep(200);
    }
    

    Deploying this application should result in the Netduino GO! counting up from 0 and the binary representation of cycleCount being output on the shift registers. The following video shows this in action:

    Conclusion

    The above minor modifications to the STM8S module code and the Netduino GO! driver has added the following functionality:

    • Default initialisation to set up for one board
    • Set the bytes for the digital outputs
    • Array like access for the bits
    • Configurable latching mode (automatic or manual)
    • Clear the output
    • Turn outputs from the registers on or off

    The code has been carefully written so that we should only need to change two parameters when the final PCBs arrive in order to change the drivers from two shift registers to four shift registers.

    A quick test has shown that the main functionality appears to be working on the breadboard prototype as demonstrated by the above video. The prototype PCBs have completed manufacture and are currently with the Hong Kong postal service (as of 27th April 2013). Delivery should take another 7-10 days so there is plenty of time to complete the test suite.

    Making a Netduino GO! Module – Stage 4 – Lay Out the Board

    Saturday, April 20th, 2013

    This series of posts will examine the activities required to take the concept of a module for the Netduino GO! through to production. So far in this series we have completed the following tasks:

    • Created a breadboard prototype
    • Linked the prototype on breadboard to the Netduino GO! with proof of concept software
    • Generated a schematic for a prototype PCB

    The next stage of the process is to convert the schematic into a PCB.

    This part of the process is the one which is totally new for me and so is the one which has the greatest chance of going wrong. This is where we will find out if my research is good.

    The Schematic

    Looking back at the previous post we note that we have the following schematic:

    Schematic

    Schematic

    PCB Layout

    The PCB layout process converts the schematic into a representation of the board which can be edited using the PCB layout tools. The layout can appear confusing as it is a layered version of the final board. Different colours map to the layers / artefacts on the board. It is this layering which can appear confusing at first.

    The layout process requires the following tasks to be completed:

    1. Conversion of the schematic into the ratsnest
    2. Reorganising the components in the ratsnest to their “final” position on the board
    3. Routing the tracks between the components
    4. Addition of additional artefacts such as text
    5. Design Rule Checks (DRC) and verification of the layout
    6. Production of the manufacturing files

    It is suggested that the above process is completed in order as each step adds new artefacts to the board.

    As noted earlier, the schematic and related files are being created using DesignSpark PCB. The processes being discussed are relevant to PCB manufacture in general.

    Making the Ratsnest

    The first step in the process is to convert the schematic into a PCB layout. Often this process creates a ratsnest of components and connections with no real layout:

    The ratsnest in DesignSpark’s PCB editor shows each component in the footprint it will occupy on the final board. The logical connections between the components are also shown as simple lines between the pads which will be used to mount the components. The lack of structure of the output gives the representation it’s name as it looks like a disorganised rats nest.

    Placing the Components

    The next step is to lay out the components out on the board. DesignSpark PCB converts the Schematic into a disorganised layout. The Output Expander board is a simple board and reorganising the layout should be simple. The layout can be broken down into the following functional units as follows:

    1. Connectors
    2. Shift registers
    3. Microcontroller

    The connectors should near to the edge of the board to allow the board to be connected to the Netduino GO! and external circuitry with ease.

    The shift registers and microcontroller can be placed anywhere on the board as we are looking at a low speed, simple board. Placement is more critical for more complex boards. For this board it is logical to place the shift registers near the output from the board as they will used to provide the 32 outputs for the board. It is also logical to place the microcontroller near the Netduino GO! connector as it is receiving instructions from the Netduino GO!.

    There are also a number of passive components on the board. These provide some signal filtering and power stabilisation. These components should be place as close to the chip they are supporting. For instance, each of the shift registers has a 100nf capacitor between power and ground. This capacitor provides a buffer for power spikes and it should be placed a close to the chip as possible. There are similar capacitors near the STM8S microcontroller.

    So the first step is to take the components and break them down into the logical groups. You can then deal with each group in turn.

    The following shows the start of the component placement:

    Components on PCB

    Components on PCB

    The major components are shown along with the connections between the components. This appears a little disorganised at the start as the yellow lines showing the connections between the components run in a straight line taking the most direct route.

    Routing the Tracks

    Routing is the process of placing copper connections between the components. So at this point you should have the components in their final resting place. If you have to move them later then you will disturb the routing. It is not too big a problem as you can always break the connection and then re-establish it with a new copper track.

    The next thing to consider is that for this simple board there are two types of tracks, power and signal. In DesignSpark PCB these are also broken down into two subcategories, nominal and minimum. Where possible I have always selected the nominal connection for both power and signal. You should also remember that it is possible it define your own track type.

    When connecting components DesignSpark PCB is reasonably intelligent and will take the connection type from the schematic and apply this to the PCB layout. By default this will be the nominal connection for either power or signal.

    Like many PCB layout packages, DesignSpark PCB provides an auto-router. In my experience these take a long time to run and does not always provide a complete board (i.e. they fail to completely route the board) and they also need a reasonable amount of computing power to complete. For a small and simple board like this one I have always found that manually routing the board is the preferred option.

    Routing also requires a change in the way of thinking about the board. PCB manufacture is a multi-layer process. The simplest for home manufacture is a single layer. This board can use two layers as this is relatively standard for low cost. Two and four layers are becoming common in the low cost prototype market. Larger numbers of layers are also possible but are currently too expensive and complex for the hobbyist. The simplicity of this board only merits a two layer board which also helps to keep the production cost lower.

    Time to start routing…

    After a while the board started to come together:

    Partially Routed

    Partially Routed

    The above image shows the partially routed board with some additional artefacts to give an indication how the final board will look. Some important points to note:

    1. Red traces are tracks which will appear on the top layer of the board.
    2. Cyan traces are tracks which are on the lower layer of the board.
    3. Thick tracks are used to carry the ground and power signals.
    4. Thin tracks carry signals between components.
    5. Small yellow circles in the tracks are vias (interconnections between the top and bottom layer of the board).
    6. Component outlines are shown in yellow. These represent the physical size of the component when it is mounted on the board. This will also appear on the top layer silkscreen.
    7. The green parts are represent the board outline and the mounting holes for the board.
    8. All of the changes in direction of a track are mitred rather than simple right angles.

    You can see that the board still contains some very thin yellow lines from the original ratsnest. These lines represent the connections which have not been routed yet. A quick check of the connections shows that all of these pads are connected to ground. These pads will become connected when the ground plane is added to the board.

    The final routing task is to add a ground plane to the top and bottom of the board.

    Top Layer With Ground PlaneTopLayerWithGroundPlane

    Top Layer With Ground PlaneTopLayerWithGroundPlane

    Adding Additional Artefacts

    Now the routing is complete we can return to the additional artefacts on the board. The first and possibly the most important is the board outline. The original outline in the image above was used to give an indication of the maximum ideal board size (10cm x 5cm). Most of the Netduino GO! modules released so far have had rounded corners. So the board outline was replaced by a board with rounded corners.

    The next check was to look at the silkscreen layers. These already contain the component outlines along with some names. Some useful additional information includes pin names for the connectors along with some information about the board – a name perhaps.

    A final note about the mounting holes. These should be placed on a 5mm x 5mm grid in order to achieve GO! certification. The holes should also be 3.1mm – 3.3mm in diameter.

    One limitation I found with DesignSpark PCB is the fact that you cannot place a logo/image in the silkscreen layer (or any other layer for that matter). This is a major limitation of the package. It appears that the solution is to create a font containing the image and then add text to the silkscreen using the font which has been created. For a package which is currently at version 5 seems to be a major omission.

    DRC and Verification

    The final step in the design process before going to manufacture is to verify the board and determine if the board can be manufactured successfully.

    Firstly, print out the board. Now double check the connections making sure that all of the pads are connected correctly. A print out is more useful to me as I can take it away from the screen and start to tick off the pads I believe to be connected correctly.

    Now for the DRC check. By default DesignSpark PCB has a set of design rules built in. These rules represent manufacturing parameters such as:

    • Track thickness
    • Minimum spacing between tracks
    • Minimum distance of a component from the board edge

    The list is much larger but you get the idea.

    I found that the values used for some rules was too cautious and would not let me route some tracks correctly. I had to change the default rules using values from the manufacturer I had decided to use. Rerunning the check with the new minimum values for track spacing allowed the board to pass DRC.

    Generate Manufacturing Files

    PCB manufacturers use Gerber files. The exact specification of the files used is determined by the chosen manufacturer. For this board we will need to generate a Gerber file in RS-274x format for the following layers:

    • Top layer: pcbname.gtl
    • Bottom layer: pcbname.gbl
    • Solder Stop Mask top: pcbname.gts
    • Solder Stop Mask Bottom pcbname.gbs
    • Silk Top: pcbname.gto
    • Silk Bottom: pcbname.gbo
    • NC Drill: pcbname.txt

    One thing to note is that there is nothing to represent the board outline. This has been added to the top silkscreen layer as requested by the manufacturer I have chosen.

    The Gerber files are simple text files which contain instructions for the CNC machines used in the manufacturing process.

    Now we have the Gerber files it is useful to check that they look right. Luckily there is an on-line Gerber viewer. Uploading your files will allow you to check that the image generated matches the design and layout.

    3D View

    A neat little feature of DesignSpark PCB is the ability to generate a 3D view of the board being made and to rotate the view. A quick check gives the following images for the final board:

    Top of Board in 3D

    Top of Board in 3D

    Note that the GND pin to the top right of the board has four tabs connecting it to the ground plane.

    The cube hovering above the board is the 3D model for the STM8S. A better model could be created, more along the lines of the 75HC595 shift registers. A task for another day…

    And rotating the board to view the underside we see the following:

    Bottom of Board in 3D

    Bottom of Board in 3D

    PCB Prototype Manufacturer

    The past 12 months have seen a number of PCB companies offer a low cost prototype PCB service. These services allow the production of a number of board (typically 10) starting as low as $10 for 10 5cm x 5cm boards. Some services even give you extra boards if you open source the hardware and hence allow them to add the board to their online shop.

    Companies offering this type of service include:

    The number of PCB options may be limited (i.e. silkscreen colour etc.) but this certainly makes the cost of production viable. For instance, a 5cm x 10 cm board costs less than $30 including shipping to the UK for 10 boards. Our module has been designed to just fit within the 5cm x 10 cm footprint.

    Another service for the hobbyist or prototype developer is that offered by Batch PCB. This company collects the production files from customers and creates a single panelised board containing one or more customer designs. This board is manufactured, the individual boards cut and extracted for shipping to the customer. By doing this the company can offer a low cost production service ($2.50 per square inch at the time of writing) for larger boards.

    There are a number of other companies offering low cost services for small runs. The companies quoted are ones I have noted over the past few months when I have been looking for low cost alternatives.

    Conclusion

    There will now follow a slight pause in the development of the hardware while the boards are produced somewhere in China. According to colleagues it typically takes about one week for manufacture and two weeks for shipping.

    This does not mean that development needs to stop. On the assumption that the prototype will work correctly we still have the following tasks which can be completed:

    • Order the components for mounting on the board
    • Develop the drivers

    In the next post we will look at developing the drivers for the board using the breadboard prototype as our test environment.

    Making a Netduino GO! Module – Stage 3 – The Schematic

    Friday, April 12th, 2013

    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:

    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
    4. 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

      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

      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

      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

      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

      Output Expander – 3D View

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

    Making a Netduino GO! Module – Stage 2 – Connect the GO! to the Breadboard

    Friday, April 12th, 2013

    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 &amp; PC4 initialised for output.
        PC_CR1 = 0x18;          //  PC3 &amp; PC4 Push-Pull outputs
        PC_CR2 = 0x18;          //  PC3 &amp; 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!

    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.

    Making a Netduino GO! Module – Stage 1 – Breadboard Prototype

    Saturday, April 6th, 2013

    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:

    Pin NamePin NumberDescription
    SI14Serial data input
    SCK11Serial clock signal
    /G or /OE13Output enable
    RCK12Transfer data from shift register to the latch
    /SCLR10Clear the shift registers

    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

    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:

    Pin Name74HC595 Pin NumberSTM8S PinDescription
    SI14Port D, Pin 2Serial data input
    SCK11Port D, Pin 3Serial clock signal
    /G or /OE13Port C, Pin 4Output enable
    RCK12Port D, Pin 4Transfer data from shift register to the latch
    /SCLR10Port C, Pin 3Clear the shift registers

    The above schematic becomes:

    STM8S and Shift Registers Schematic

    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

    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.

    Making a Netduino GO! Module

    Saturday, April 6th, 2013

    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.

    STM8S SPI Slave (Part 3) – Making a Go Module

    Monday, November 26th, 2012

    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:

    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:

    private Guid _moduleGuid = new Guid(new byte[] { 0x80, 0x39, 0xe8, 0x2b, 0x55, 0x58, 0xeb, 0x48, 0xab, 0x9e, 0x48, 0xd3, 0xfd, 0xae, 0x8c, 0xee });

    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

        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

        SystemCompatible?
        STM8S103F3 (Breadboard)
        Variable Lab Protomodule
        STM8S Discovery