Embedded Developer

In this latest in the series I am taking a look at communication between two systems (namely a Netduino Mini and a STM8S103) using SPI.

As with previous articles the system will use the IAR compiler and the STD Peripheral Library. The Netduino Mini will use Visual Studio and .NET to act as the master for the SPI bus.

I ran into some problems along the way and had to ask for help in the Netduino Forums. Special mention to Chris Walker and CW2 for their help.

Netduino Mini Application

SPI is one of the protocols supported by the NETMF framework on the Netduino platform. As such there is little work to do. The Mini will have to act as the SPI master as this is the only role which is supported on the Netduino for this bus. We simply need to set up the SPI bus with the correct parameters and then start writing data to the bus.

To remove as many possible problems as possible we will perform a simple task, have the Netduino Mini write some data to the bus on a regular basis. In this case we will write three bytes with the values 1, 2 and 3. The code on the Mini is as simple as the following:

public static void Main()
{
	SPI.Configuration config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1,
							   ChipSelect_Port: Pins.GPIO_PIN_5,                        // Enable pin is D5.
							   ChipSelect_ActiveState: false,                           // Active Low
							   ChipSelect_SetupTime: 0,                                 // 0 uS setup time.
							   ChipSelect_HoldTime: 0,                                  // 0 uS hold after data transmission has completed.
							   Clock_IdleState: false,                                  // Clock line is low when the device is inactive.
							   Clock_Edge: false,                                       // Data is sampled on the clock falling edge.
							   Clock_RateKHz: 500);                                     // 500 KHz clock speed.

	SPI spi = new SPI(config);

	byte[] buffer = new byte[] { 1, 2, 3 };
	while (true)
	{
		spi.Write(buffer);
		Thread.Sleep(1000);
	}
}

This code configures the bus as follows:

• Chip select will be D5 on the Netduino Mini
• Chip select will be active low
• Clock is low when the device is inactive
• Data is sampled on the falling edge of the clock signal
• Clock rate is 500 KHz

The selection of these values is deliberate as they match the values used on the GO! bus.

STM8S Code

This is where it got tricky and where I need some help. We have a simple application on the Netduino Mini which simply sends out three bytes, waits a second and then repeats. In order to know that we have received this data OK, the application on the STM8S will read these bytes from the SPI bus, add 100 and then send the result back to the Mini.

The first thing we need to do is to set up a project similar to the first article in this series. The main STD Peripheral Library module we will be using here is the SPI library which can be found in stm8s_spi.c. Add this to the project and then reference the stm8s_spi.h in the main program file.

Now we have the SPI library referenced and the library file added to the application we need to start using it. So the first step we need to take is to configure the library ready for use. The following code should achieve this matching the parameters we have set up in Netduino Mini project above.

SPI_DeInit();
SPI_Init(SPI_FIRSTBIT_MSB,                      // MSB first.
		 SPI_BAUDRATEPRESCALER_32,              // For slave comms this does not matter as the clock is controlled by the master.
		 SPI_MODE_SLAVE,                        // SPI Slave
		 SPI_CLOCKPOLARITY_LOW,                 // Clock is high when the bus is idle.
		 SPI_CLOCKPHASE_2EDGE,                  // Falling clock edge clocks the first data bit.
		 SPI_DATADIRECTION_2LINES_FULLDUPLEX,   // Full duplex transmission.
		 SPI_NSS_HARD,                          // Disable slave management by software.
		 0x07);                                 // CRC style.
SPI_ITConfig(SPI_IT_RXNE, ENABLE);              // Interrupt when the Rx buffer is not empty.
SPI_ITConfig(SPI_IT_TXE, ENABLE);               // Interrupt when the Tx buffer is empty.

The first this we do is call SPI_DeInit to reset any SPI bus configuration.

Next we call SPI_Init to configure the system, as a SPI slave using the same parameters as the SPI master (i.e. the Netduino Mini). You should not that although the baud rate prescalar parameter is set here it will be ignored. The master controls the clock on the SPI bus.

The final two statements (SPI_ITConfig statements) determine which actions will generate an interrupt. In this case we are instructing the system to generate an interrupt in the following cases:

• When the Rx buffer is not empty (i.e. data has been received)
• When the Tx buffer is empty (i.e. the system is ready to send more data)

Interrupt Handler

The data will be handled by an interrupt handler. This handler will be called when we need to send data or when we have data ready for processing. As before, the handlers can be found in the file stm8s_it.c. The handler we will be looking for is the SPI_IRQHandler. Locate this handler and replace the code with the following:

INTERRUPT_HANDLER(SPI_IRQHandler, 10)
{
    if (SPI->SR & SPI_SR_RXNE)
    {
        //  u8 ch = SPI_ReceiveData();
        u8 ch = SPI->DR;
        //  SPI_SendData(ch + 100);
        SPI->DR = ch + 100;
    }
    SPI->SR = (u8) 0;
}

The two lines commented out are the equivalent calls into the SPI library. Remember that ISR’s should be as fast as possible. Replacing the calls with the appropriate expansions will decrease the amount of time required to execute the ISR.

So, here we check to see if the ISR is being called because the Rx buffer is not empty. If the buffer is not empty then we extract the value from the buffer, add 100 to it and then put this in the Tx buffer.

The final thing we do is to clear the interrupt from the status register.

Main Program Loop

The code in the main program queues up a byte ready for transmission, enables the interrupts and then repeatedly waits for more interrupts. The code looks like this:

int main(void)
{
    Initialise();
    SPI_SendData('*');                          // Ready to send before master can initiate transfer.
    enableInterrupts();                         // Make sure interrupts are enabled.
    while (1)
    {
        wfi();
    }
}

So What Happened?

After spending a fair amount of time with the logic analyser and the debugger I hit a brick wall. The interrupts we not getting fired as I expected. This is where Chris Walker and CW2’s help was required. The point I was missing regarded the SPI_NSS signal. On the STM8S103 chip I was using this function is an alternative function for the labelled pin. In order to allow this pin to act as the chip select for the SPI bus it was necessary to set the alternative function register on the chip. Once this was set correctly the system started to generate interrupts as expected.

So you have just purchased that wonderful sensor and now need it to grab the attention of the STM8S – enter the interrupt. In this post I will run through how to set up a GPIO port to have an incoming logic signal generate an interrupt.

As in previous posts on the STM8S, this post will use the IAR development environment and the STD Peripheral Library from ST.

Configuring the Port

The first step is to configure a port for input. The following code configures a pin on GPIOB for input:

GPIO_DeInit(GPIOB);
GPIO_Init(GPIOB, GPIO_PIN_5, GPIO_MODE_IN_FL_IT);

the next thing we need to do is to tell the system that this pin is allowed to generate an interrupt:

EXTI_SetExtIntSensitivity(GPIOB, 
                          EXTI_SENSITIVITY_RISE_ONLY);

So that should be all that’s required to configure the system to accept interrupts. Now we just need to process them.

Interrupt Handler

If you have followed my previous posts you will know that we need to copy some standard files across in order to access the STD Peripheral Library. One of the files we add to the project is stm8s_it.c. This holds the interrupt table for the chip. Scroll through the file and you will eventually reach some code which looks like this:

INTERRUPT_HANDLER(EXTI_PORTB_IRQHandler, 4)
{
  /* In order to detect unexpected events during development,
     it is recommended to set a breakpoint on the following instruction.
  */
}

Just place the code to be executed in this method. Remember, interrupt handlers should be small and concise.

Modules

This post requires that you add the code files for the following STD Peripheral Library modules:

• stm8s_gpio.c
• stm8s_exti.c

Conclusion

A relatively short post but there’s not much too it. I have successfully used this code to generate an interrupt from a sensor which generates a square wave of up to 500 KHz. The conditions I was using it in gave a maximum frequency of 20 KHz.

This post has been superseded by the post Using Timers on the STM8S in The Way of the Register series.

In the first post about this chip I showed how the internal clock could be output on a single pin. Here I am going to use one of the internal timers to generate my own clock signal. So in this post we will use two new concepts:

• GPIO pins to output a signal.
• Timer 2 to control the timing
• Interrupt Service Routines (ISR) to do the work

The program will work by setting up timer 2 to generate an interrupt on a regular basis. When the timer interrupt fires we will reverse the direction of a GPIO pin. The net result will be a clock signal with a frequency of twice that of the timer.

As with the previous post I will be using the IAR environment with the STD Peripheral Library.

Setting up the GPIO

#define CLOCK_OUTPUT_PORT       GPIOD
#define CLOCK_OUTPUT_PIN        GPIO_PIN_3

These #defines hold the port and pin numbers we are going to use for the clock signal. So in this case we are using pin 3 on port D. Next we need to configure the port.

GPIO_DeInit(CLOCK_OUTPUT_PORT);
GPIO_Init(CLOCK_OUTPUT_PORT, CLOCK_OUTPUT_PIN, GPIO_MODE_OUT_PP_LOW_FAST);

The first statement resets the port so that we can configure the port. The second sets up pin 3 of port D for use. Note that you can use each pin on a port in a different way, so we could have pin 2 on port D as an input whilst pin 3 is an output. To do this you simply add more GPIO_Init statements under the first. Now let’s have a look at the final parameter to the GPIO_Init statement. This defines how the pin will be set up for us. You can decode this as follows:

• GPIO_MODE_OUT – this is an output port
• PP – the pin will be used in Push-Pull (as opposed to open drain). This means Setting the pin to 1 will make the pin high, setting it to 0 will make it low.
• LOW – the pin will start out low
• FAST – the pin will be used for fast signalling.

Setting up Timer 2

Next step is to configure the timer to interrupt on a regular basis. The first step is to set up the clock to use a known clock signal. For simplicity we will set this up to use the internal high speed clock source which runs at 16MHz. This code is similar to the code in the first post.

CLK_DeInit();
CLK_SYSCLKConfig(CLK_PRESCALER_CPUDIV1);                // CPU Prescaler = 1.
CLK_SYSCLKConfig(CLK_PRESCALER_HSIDIV1);                // Prescaler = 1, 16 MHz.
CLK_ClockSwitchConfig(CLK_SWITCHMODE_AUTO,              // Automatically switch
                      CLK_SOURCE_HSI,                   // Switch to internal timer.
                      DISABLE,                          // Disable the clock switch interrupt.
                      CLK_CURRENTCLOCKSTATE_DISABLE);   // Disable the previous clock.

The only real difference is that the prescaler for the system clock is set to 1 to give the full clock speed.

The next task is to set up the timer to run at a particular frequency:

TIM2_DeInit();
TIM2_TimeBaseInit(TIM2_PRESCALER_4096,      // Interrupt every 4096 clock pulses.
                  1);                       // Period is one.
TIM2_ITConfig(TIM2_IT_UPDATE, ENABLE);      // Enable the overflow interrupt.
TIM2_Cmd(ENABLE);

The comment interrupt every half millisecond is approximate as you will see when we come to take some measurements later.

The Interrupt Service Routine

The final piece of the puzzle is the interrupt service routine. These should always be small and fast. In this case we will simply toggle the specified clock pin to generate a clock signal.

All of the ISR’s are defined in the file stm8s_it.c. The ISR we will be working with is the timer 2 update overflow handler. This will fire when the counter for the timer overflows or becomes zero and the specified number of occurrences of this event have occurred. So in this file we need to locate this code:

INTERRUPT_HANDLER(TIM2_UPD_OVF_BRK_IRQHandler, 13)
{
}

and translate it to this:

INTERRUPT_HANDLER(TIM2_UPD_OVF_BRK_IRQHandler, 13)
{
    GPIO_WriteReverse(CLOCK_OUTPUT_PORT, CLOCK_OUTPUT_PIN);     // Generate a clock signal.
    TIM2->SR1 = (uint8_t) (~(uint8_t) TIM2_IT_UPDATE);          // Clear the interrupt.
}

The first line of the ISR toggles the specified bit. The second line is important as this clears the interrupt. If we do not do this then the system will return to this ISR as soon as we exit the routine.

Clock Signal

Compiling and deploying this code to the processor results in the following output on pin 3 of port D:

The scope we set up for 2 milliseconds per division and this looks about right. The exact frequency count comes out to be 976.6 Hz which is right if you divide the clock signal by the prescaler.

A few days ago I wrote about my first attempt at coding for the STM8S003 but forgot to mention how I connected up the chip to the PC. So here is a quick post explaining how to do it.

The STM8S Chip

The STM8S chip chosen was the STM8S003F3 in a TSSOP20 package. This form factor is incredibly small and there is no way to mount it on a breadboard without some for of adapter. Luckily Sparkfun have a SSOP to DIP Adapter 20-Pin in their catalog. However, I could not get hold of one in the UK so I ended up getting the 28 pin version instead. A bit of a waste but it worked.

So armed with the adapter, a chip and some connectors it was time to break out the soldering iron. A brief experiment with drag soldering did not work and I finally settled on soldering each pin very carefully with the finest soldering iron tip I had.

The next job was to mount all of this on the breadboard. There are only really two additional components required for this circuit, 1uF and 0.1uf ceramic capacitors. You can see both of these to the left of the chip in the above picture. The 0.1uf capacitor connects ground and +3.3V and acts as a power smoothing capacitor. The 1uF capacitor connects V_cap and ground.

ST-Link/V2 Programmer and Debugger

The chip is programmed using the low cost (£20 approx) ST-Link/V2 programmer and debugger. This works with both the STM8 and STM32 range of processors.

Putting it all Together

If we put the two components together we get something which looks like this:

The red PCB between the programmer and the STM8S circuit is a breadboard power supply which has been set to supply 3.3C to the circuit. The wires connecting the STM8 to the programmer are as follows:

The last few weeks I’ve been getting things together to start to look at developing a smart module for the Netduino GO!. This post looks at the first steps and ends up with some working code on a STM8S003 chip.

STM8S Discovery

My starting point was to get the software tools installed and working. In order to verify this I purchased the STM8S Discovery board. This has the STLink module and a STM8S105 microcontroller built into a convenient package for less than £7.00. This board itself was easy to set up and worked straight out of the box.

Development Environment

Having the board is one thing but we need a development environment to work with. I tried several environments and in the end I found I was happiest with the IAR environment so for the moment I’m sticking with it whilst I find my feet. Set up was easy and it found the STM8S Discovery straight away.

Start With Something Simple

I wanted to start with a really simple project which would not require any additional hardware other than a scope to check that the application was working. That way I could transfer the program to a microcontroller on a breadboard and know that I had as few possible points of failure as possible. To this end I decided that I would put the microcontroller clock pulses out on one of the pins. I could verify that everything was working but uploading a new program which changed the clock scaler and if all was well I would see a different trace on the scope.

This choice of application was no accident as the data sheet for the chip shows that it has a pin labelled CCO. You can configure this pin to output the controller’s clock signal. Not only that but you can also use the microcontroller’s internal clock generator as the clock signal. So in theory, all I needed to do was add a few discrete components to the breadboard along with the STM8S and I should have a small, simple, self contained system to test the tool set.

Creating a New Project

First thing to do is create a new workspace and project using IAR. Simple enough, enter a name for both and a new main.c is presented to you. Good game but not much use as it stands.

Luckily ST provide a standard library of drivers for the various features available on their chip sets. I downloaded version 2.1.0 of the library and this contained the drivers and some sample applications. The trick is to understand the way in which you access the libraries. It’s really simple and basic. In effect, you add the C source files for the library to your application and compile your application and the libraries at the same time. Both of these are then deployed as a single binary to the microcontroller. Basic but it works. The source files are broken down by microcontroller feature. So, all of the routines etc. for timer 2 are in the header file stm8s_tim2.h and the source code is in the file stm8s_tim2.c.

To make things easier (well, easier for me anyway) I have taken to copying the source and include files from the standard library provided into each project directory I create. That way you simply need to add the source file for a feature as you need it. In this case the only feature I’m going to be using is the clock and so I need to make sure I add the stm8s_clk.c file to the project.

The stm8s.h file contains definitions for a whole range of controllers. It is therefore necessary to define a preprocessor macro for the type of controller the application is targeting. This can be done in one of two ways, either in the stm8s.h file itself (as this in included in the other standard library files) or as a macro in the project. I personally prefer to do this in the project as it makes updating the library code easier.

So Let’s Get Started

First thing to do is to get a workspace and project created. So open IAR and create a new workspace. Next, go to the Project Menu and create a new project. The following dialog should appear:

Select a C project and click OK. The next dialog asks you to select a name and location for the project. So decide on a location and name. Being very creative, I went for Test as the project name. Once completed I had a project which looked like this:

The next job is to add the include and source files for the standard peripheral library. So copy the include and source files from the library and add them to the directory containing your project. I normally put the include files in the inc directory and the sources in the src directory. The next thing to do is add these files to the project. So right click on the project name (in this case Test – Debug and select Add – Add Group. Enter the name STD Peripheral Include

Repeat this to add the source file group with the name STD Peripheral Source. Your project should now look like this:

Now we need to add the files to the groups. For the include files I add all of the files. For the source files I only add the ones I will be using. To do this you right click on one of the file groups we have created, say the STD Peripheral Include group and select Add – Add Files…. For the include files navigate to the directory containing the copied files and select them all.

Repeat for the source files but this time we only select the files we will be using. In this case the clock file stm8s_clk.c. Your project should now look something like this:

There are still a few extra steps before we can write some code. The STM8S include files require that the type of chip is defined before any code will compile so we will need to define a preprocessor macro indicating which chip we are using. Next we need to tell the compiler about the location of the include files. Finally, we need to tell the system how to deploy and debug the application.

So let’s start off with the chip family. Firstly we want to tell the compiler about the target family. So right click on the project name and this time select Options. Under General options, select the chip family to be targeted. For the Discovery board the family is STM8S105, for the final module we will be targeting the STM8S003.

The next step is to tell the preprocessor about the chip family and the location of the include files. From the same dialog as above, select the C/C++ compiler and the Preprocessor tab. Add the entry $PROJ_DIR$inc to the include files and define a symbol for the chip set. Define STM8S105 for the Discovery board and STM8S003 for the final module.

The final step is to tell the IDE how to deploy and debug the application. From the Options dialog select the Debugger category and set the Driver to ST-LINK.

Now click on OK to set the options. We can now start to write some code.

Let’s Write Some Code

Replace the code in the main.c file with the following:

#include "stm8s.h"
#include "stm8s_clk.h"

int main(void)
{
    CLK_DeInit();
    CLK_SYSCLKConfig(CLK_PRESCALER_CPUDIV1);                // CPU Prescaler = 1.
    CLK_SYSCLKConfig(CLK_PRESCALER_HSIDIV8);                // Prescaler = 8, 2 MHz.
    CLK_CCOConfig(CLK_OUTPUT_HSI);                          // Output clock on CCO pin.
    CLK_ClockSwitchConfig(CLK_SWITCHMODE_AUTO,              // Automatically switch
                          CLK_SOURCE_HSE,                   // Switch to internal timer.
                          DISABLE,                          // Disable the clock switch interrupt.
                          CLK_CURRENTCLOCKSTATE_DISABLE);   // Disable the previous clock.
}

Connect up board/chip and hit Ctrl-D. This will compile and deploy the application. The debugger should start with the first line of main highlighted. Press F5 and the application should start. Hooking up the oscilloscope gave the following trace:

The clock frequency of the chip using the internal high speed oscillator is 16 MHz. Diving this by 8 should give a 2 MHz signal (as indeed the above trace shows). Just to check if this is a coincidence, change to CLK_PRESCALER_HSIDIV8 to say CLK_PRESCALER_HSIDIV4 and the scope output should change to show the new clock frequency and sure enough it does.

My Netduino Starter Kit finally arrived from the USA this morning. The days plans are a long and distant memory as boy must play with toys! So here is a short video I made of my first project.

The Secret Labs team have just release a new product, Netduino Go. This is a NET MF board based on the STM32F4 family of chips. For more information have a look at:

Netduino Home Page
Launch Announcement in Community Forums

I recently came across the STM32F4 Discovery board. This board is an ARM processor on a board with 1MB flash and 192KB RAM, ADC, Audio processing, motion detection USB for both debugging and HID support – not bad for less than £10. Given the price and a bit of research and I thought I’d risk it.

So the board arrived and now it’s time to set up the tool chain. There are several toolchains available but the one which was attractive was the Atollic toolchain. The LITE version 2.3 IDE had no code limitations and instead it limited the features available through the IDE. Note that since buying the board and downloading the software Atollic have gone down the route of removing the restrictions on the IDE and placing a code size restriction on the environment. This fits in with the approach taken by several of their competitors.

Installing the Software and the Board

Installation of the software and the board seemed to go OK. Connecting the board found a few problems. The first problem came from the samples. I imported the directory containing the samples and this seemed to pull in the samples for the Atollic system and also the samples for other development environments. This resulted in multiple projects with the same name and this (understandably) upset the Atollic environment. So a quick play with explorer deleting the extra projects and the remaining projects imported with now issues.

The second project came when I tried to compile, deploy and debug one of the samples. The debugger kept complaining that it could not find the board. Hello Google. The problem was simple to solve and all it required was to reinstall the driver for the board. All this required was to open control panel, selecting the board and then update the driver.

So far, so good. I have the board installed along with the software and I can deploy the sample projects.

Can I write my own software?

My First Application

For my first application I wanted to do a bit more than just flash the onboard LEDs, not much more but I wanted some indication of the speed of the board. So I decided to simply toggle one of the ports and look at this through a logic analyser.

So the first thing to do is to create a new project. So off to the file menu and I selected new project. The restricted version of the development environment does not allow C++ projects so I went for a C project and selected Embedded C Project:

Next I selected the board and hardware settings for the build:

And the final step is to configure the debugger settings:

Next thing to do was to modify the default sample code. I opened the main.c file and replaced the main program loop with the following:

GPIO_InitTypeDef  GPIO_InitStructure;

STM_EVAL_LEDInit(LED3);
STM_EVAL_LEDInit(LED4);
STM_EVAL_LEDInit(LED5);
STM_EVAL_LEDInit(LED6);

/* Turn on LEDs */
STM_EVAL_LEDOn(LED3);
STM_EVAL_LEDOn(LED4);
STM_EVAL_LEDOn(LED5);
STM_EVAL_LEDOn(LED6);

int flag = 0;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOD, &GPIO_InitStructure);
while (1)
{
    if (flag)
    {
        GPIO_SetBits(GPIOD, GPIO_Pin_0);
        flag = 0;
    }
    else
    {
        GPIO_ResetBits(GPIOD, GPIO_Pin_0);
        flag = 1;
    }
}

Hooking up the logic analyser to Port D, pin 0 gave a square wave with a frequency of about 2.25 MHz.

Success!

Back to the samples and lets see where it takes us.

So you’ve built is and now we need some software to run it. To do this we are going to need to perform two tasks at the same time:

• Calculate what we are going to display in the cube
• Run the display

Multithreading is used in order to achieve this. The program has one thread which does nothing but cycle through each layer one by one shifting the data for the layer into the shift registers and then turning the layer on.

The second thread prepares the next item to be displayed and then passes this on to the cube to display.

LEDCube Class

This is a relatively simple class having a single constructor and two methods. The constructor sets the scene for us and makes sure everything is ready to use:

public LEDCube()
{
    config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1,
                                   ChipSelect_Port: Pins.GPIO_PIN_20,
                                   ChipSelect_ActiveState: false,
                                   ChipSelect_SetupTime: 0,
                                   ChipSelect_HoldTime: 0,
                                   Clock_IdleState: true,
                                   Clock_Edge: true,
                                   Clock_RateKHz: 100);

    spi = new SPI(config);
    buffer = new byte[64];
    for (int index = 0; index < buffer.Length; index++)
    {
        buffer[index] = 0;
    }
}

The buffer contains the data we are going to be showing in the cube.

The next two methods perform the work or updating and displaying the buffer. We need to be careful that the buffer is not updated whilst we are trying to update the display.

public void UpdateBuffer(byte[] newValues)
{
    lock (buffer)
    {
        for (int index = 0; index < buffer.Length; index++)
        {
            buffer[index] = newValues[index];
        }
    }
}

The lock statement helps us to achieve this by locking the buffer so we can copy data into it and also stop the display method from trying to read the buffer and show the data.

The display method is a little longer:

public void DisplayBuffer()
{
    while (true)
    {
        lock (buffer)
        {
            byte[] displayData = new byte[8];

            for (int row = 0; row < 8; row++)
            {
                int offset = row * 8;
                for (int index = 0; index < 8; index++)
                {
                    displayData[index] = buffer[offset + index];
                }
                enable.Write(true);
                bit0.Write((row & 1) != 0);
                bit1.Write((row & 2) != 0);
                bit2.Write((row & 4) != 0);
                spi.Write(displayData);
                enable.Write(false);
            }
        }
    }
}

Wrapping all of this in the LEDCube class means that we now have a very simple class where we can spawn the DislpayBuffer method into it’s own thread. So off to out Main program. We are going to need an instance of the cube and a buffer to hold the next “frame” we wish to display.

private static LEDCube cube = new LEDCube();
private static byte[] nv = new byte[64];

The first thing we do when entering the main program is to set all of the values in the buffer (set them to zero) and to start the display thread going:

ClearCube();
Thread display = new Thread(new ThreadStart(cube.DisplayBuffer));
display.Start();

ClearCube does just that, sets the values to zero and then calls the cube Update method to copy this zeroed buffer into the cube buffer.

The next line spawns a new thread which runs the DisplayBuffer method and the following line starts it.

At this point we have two threads, the main program loop and the display thread. We can now perform calculations in the main program loop and call cube.UpdateBuffer when we have new data to display.

So how about something to display, a little rain perhaps:

private static void AddDrops(int count, int plane = -1)
{
    for (int drops = 0; drops < count; drops++)
    {
        bool findingSpace = true;
        while (findingSpace)
        {
            int x = rand.Next() % 8;
            int y = rand.Next() % 8;
            int z;

            if (plane == -1)
            {
                z = rand.Next() % 8;
            }
            else
            {
                z = plane;
            }

            int position = ( z * 8 ) + y;
            byte value = (byte) ((1 << x) & 0xff);
            if ((nv[position] & value) == 0)
            {
                nv[position] |= value;
                findingSpace = false;
            }
        }
    }
}

private static void Rain(int noDrops, int cycles)
{
    ClearCube();
    AddDrops(noDrops);
    cube.UpdateBuffer(nv);
    for (int currentCycle = 0; currentCycle < cycles; currentCycle++)
    {
        int bitCount = 0;
        for (int plane = 0; plane < 8; plane++)
        {
            byte value = 1;
            for (int bit = 0; bit < 8; bit++)
            {
                if ((nv[56 + plane] & value) > 0)
                {
                    bitCount++;
                }
                value <<= 1;
            }
        }
        for (int plane = 7; plane > 0; plane--)
        {
            for (int currentByte = 0; currentByte < 8; currentByte++)
            {
                nv[(plane * 8) + currentByte] = nv[( (plane - 1) * 8 ) + currentByte];
            }
        }
        for (int b = 0; b < 8; b++)
        {
            nv[b] = 0;
        }
        AddDrops(bitCount, 0);
        cube.UpdateBuffer(nv);
        Thread.Sleep(75);
    }
}

AddDrops simply adds a specified number of rain drops to the buffer. It also makes sure that if asked for 10 it will always add 10 by checking to see if one exists in the location it wanted to use.

Rain adds the specified number of drops to the buffer, shows the drops and then moved them all down by one plane. Before doing this it counts how many drops are going to fall out of the cube. After all the drops have moved down one plane it adds the drops which have disappeared out of the bottom of the cube back in at the top in random positions.

We can display this by adding this to the main program:

while (true)
{
	Rain(10, 60000);
}

The full source code to this project is current hosted on Codeplex.

Conclusion

Hope that you enjoy trying out this project but be aware that it takes time. This consumed a lot of my spare time for about three weeks. There are still some tasks to complete

• Power supply
• A case

I have not covered the power regulation but you should make sure that you have a regulated 5V DC power supply capable of about 2A – but more would be better. I did actually add my own regulator to this project but it got very hot when the cube was fully lit. Beware – make sure you have a stable supply capable of supplying enough juice.

Having a cube of LEDs is of little use without a controller board. As previously mentioned, all 512 LEDs can be controlled from just 7 lines from the Netduino Mini. As you will have seen during the testing, we can turn on any LED by connecting the anode to a positive supply and the entire layer in which it sits to ground.

The positive supply is a relatively simple thing to achieve and our good friend the 74HC595 shift register will help us there. Connecting to ground requires a little more work but this is achieved using the 74HC238 and a bank of transistors. At the end of this process I had the following board:

So, a quick walk around the board. Box one contains the Netduino Mini. The two connectors to the bottom left of the board allow the Mini to be connected to the computer – they are the Mini’s COM1 connections. The two connectors at the top right are for the ground and the 5V from my USB – FTDI connector. Only ground is connected, the other connector allows me to stop the 5V lead from flying around and touching something it shouldn’t.

Box 2 contains the bank of 8 x 74HC595s, current limiting resistors and a connector to allow a ribbon cable to be connected the cube to the controller. These will determine which of the LEDs received power. Each of the shift registers will control one row of LEDs, 8 rows need 8 registers. So the shift registers can control 64 LEDs at once.

The remainder of the electronics on the board determine which layer will be connected to ground. The 74HC238 takes four lines from the Mini. Three of the lines represent a binary number 0-7, the fourth line is an output enable line. The decoder takes the number and switches on one of one of the output lines. This is in turn connected to the base of a TIP122 transistor. Applying power to the base allows the layer the transistor is connected to connect to ground.

So all is in place to use persistence of vision to be used to give the appearance that the cube is permanently switched on. Starting with the cube switched off we load the shift registers with the data for layer 0. We then load the 74HC238 with 0 and enable the output. This will turn on the transistor for layer 0 which will allow current to flow through the LEDs in layer 0. We then turn the cube off by disabling the output of the 74HC238 and repeat for layer 1 and so on.

Shift Registers

A little more repetition – don’t you just love it. The eight shift registers are wired together in a cascade with the shifted output of one register forming the input of the next. By connecting eight together we can control 64 outputs.

The basic connections for the shift registers is as follows:

This needs to be repeated until all eight of the registers are connected as in the above diagram. In the controller board diagram the serial data in wires are blue, the clock wires are white and the enable wires are yellow.

Note that a 100nF ceramic capacitor is connected between power and ground and one is placed by each IC as close to the IC as possible.

The current limiting resistors for this project were selected to keep the current per LED at 25mA per LED. The nearest value actually puts this at 26mA per LED. Multiplying this up means that a layer when all of the LEDs are switched on will draw 1.6A. The maximum output current rating per pin on the 74HC494 is 35mA so we are getting close to the limit per pin.

Layer Switching

Layer switching is achieved by connecting a layer to ground through a TIP122 transistor. This should be capable of sinking 2A which is greater than the 1.6A which we could theoretically need to sink if all of the LEDs on a layer are switched on. The 74HC238 selects which layer is connected to ground – or in fact none of them may be connected if the output from the 74HC238 is disabled. The circuit diagram for this part of the controller looks as follows:

Again, a 100nF capacitor is placed across power and ground for this IC.

Connecting the Controller to the Cube

The collector for each of the TIP122’s should be connected to a different layer. I connected mine with layer zero being the top layer.

Each of the shift registers should be connected to one row of LEDs. I connected mine with bit zero at the right of the cube. This was done with one of the female connectors (to fit the male connector on the controller board) and some ribbon cable.

The result of these two wiring decisions was a rather odd co-ordinate system. You may decide to use something more conventional.

Adding the Netduino Mini

The Netduino Mini connections have already been noted on the above schematics.