Just read that Silverlight 5 has just been released. Off to the downloads page and some replanning of this weekends activities.
For more information visit the Silverlight home page.
The emergence of low cost computers in the UK market in the early 1980s kick started many a career in IT. The early market was not dominated by one type of machine but rather one full of choices from a myriad of companies. School playgrounds across the country soon became split between two camps, you either loved the Spectrum or the BBC Micro (which quickly became known as the Beeb). There were friends with other computers (Vic 20, Dragon, Commodore 64 to name a few) but these people were in the minority and viewed as weird.
Today marks the day the BBC Micro was first launched on the market. At the time it was expensive compared to the other machines on the market but it was supported by the BBC in the form of a TV series about computers and their uses.
At the time the BBC Micro was launched I had already been programming for several years but it is this machine which I remember with fondness. I had a great time learning how this machine worked and even purchased the Advanced BBC Micro handbook. It was this handbook which allowed me to get closer to the hardware. I even wrote my own disc operating system. This also taught me a very valuable lesson, always backup your work – I accidental tested the format command on the disc containing the only copy of the source code. To my dismay it was one of those occasions where I had managed to write 200 lines of assembler which worked perfectly first time.
The early industry meant that schools had to quickly put together a programme of lessons which taught pupils about the new machines and how to use them. The lack of software such as spreadsheets, presentation software etc. meant that children were taught about the machines and how they worked. Something which is lacking today. This lack of understanding about how computers actually work is slowly being recognised here in the UK and it appears that the government is starting to recognise that something needs to be done. One group of people who remember those early days are already working on a small computer for the education market. Check out the Raspberry Pi for more information on the project.
You can read more about the BBC Micro in this article on the BBCs news web site.
Happy Birthday BBC Micro
Coding4Fun have just published my article on how to build a 512 LED cube controlled by a Netduino Mini.
A while ago I created a circuit and some code to control the TLC5940 LED driver using a Netduino Mini. This chip allowed the programmer to control 16 LEDs using a serial interface. In the conclusions I noted that it should be possible to control two or more of these chips by cascading the serial output from one chip into another. This article discusses the additional hardware required along with the software to control up to 32 LEDs using two of these chips linked together.
It is assumed that you have read and understood the previous article before you proceed further.
Linking two of these chips is a relatively simple affair and requires the LEDs you wish to control and only 1 additional component, namely a 2K2 ohm resistor, and some additional wire (assuming you are using breadboard).
Starting with the simplest part, the 2K2 ohm resistor connects the IREF pin on the second TLC5940 to ground. This sets the reference voltage for the LEDs connected to the second TLC5940.
The next part of the problem is to connect the two chips together. This is achieved by connecting the following pins:
| TLC5940 (1) | TLC5940 (2) |
| SCLK | SCLK |
| BLANK | BLANK |
| XLAT | XLAT |
| GSCLK | GSCLK |
| VPRG | VPRG |
| SOUT | SIN |
| XERR | XERR |
DCPRG on TLC5940 is connected to Vcc as it is on the first driver chip and the LED controller pins connected to the appropriate LEDs.
This PDF (PWMLEDControlv0.03.pdf) contains the full circuit diagram showing the connections required.
Now we have the additional LEDs in the circuit we will need to be able tell the software driver for the chips how many LEDs we want to control and then be able to control the brightness of the LEDs. In order to do this an additional parameter was added to the constructor numberOfLEDs. This parameter allows the system to work out how many TLC5940’s should be connected together. Once we have the number of chips calculated we can then work out the size of the buffers for the Dot Correction and the Grey Scale data.
The class uses two buffers for both the Dot Correction and the Grey Scale data. This may seem superfluous but doing this allows two different modes of operation:
For the moment we will be discussing the basic mode. In this mode, the software driver hides much of the implementation and the user only really needs to perform three tasks:
Tlc5940 leds = new Tlc5940(numberOfLEDs: 32);
You can of course use the additional parameters to define the pins used for the various control signals or just use the defaults.
The class contains a method which overloads the array indexing operator. Setting the brightness for a LED is simply a case of using this operator as follows:
leds[10] = 767;
This will set the brightness of LED 10 to the value 767.
An important note here is that the LEDs are numbered from 0 to 15 on the TLC5940 connected to the Netduino Mini, 16 to 31 on the next LED in sequence and so on.
The final piece of the puzzle is to output the data to the series of TLC5940s connected to the Netduino Mini. This is achieved by calling the Display method in the Tlc5940 class.
The source code for the controller class and a simple main program can be found here (CascadedTLC5940.zip).
The work with this chip has not yet finished as there are still some points which need addressing in order to round off this class:
One final item which needs addressing is to round off the code once these final feature have been implemented. A topic for another day.
I have recently been working with the TLC5940 LED Driver chip. This provides 16 PWM outputs which can be used to drive common anode LEDs and I suspect motors etc. For the moment I will be using it to drive 16 LEDs to prove the principle and work out how to interface the chip to the Netduino Mini.
The article and code contained here should allow the creation of a circuit capable of doing the following (and a whole lot more):
The objective of this exercise is to use the TLC5940 to control 16 LEDs under the control of the Netduino Mini. This will require the following to be developed:
A description of PWM and how it works is assumed. If you require more information then you can check out the Wikipedia article on PWM.
The TLC5940 uses an external timing signal to control the 16 grey scale outputs to the LEDs. This signal can be as high as 30 MHz. The design presented here uses an 8 MHz crystal / resonator. When I was developing the circuit I have little knowledge of how to build the timer and so used a NE555 configured as a 40 kHz astable oscillator. This was crude but was good enough to start the project. The final design uses an oscillator circuit from a document recommended by Mario on the Netduino forums. You can read the original post here. Mario recommended circuit 1d which is the one I finally used:
The final inverter is not really necessary but the chip contains 6 inverters and I was only using two so I fed the output from the timer through an final inverter. This had the effect or producing a squarer signal – although the final signal is still slightly rounded.
In the final circuit I actually used a resonator. I simply dropped this in place of the crystal connecting the outer two pins to the logic gates and the centre pin to ground.
As well as the clock signal, the TLC5940 requires several control signals to determine how the chip should treat the grey scale data. This section looks at each signal and describes its function.
This pin determines the output state of the TLC5940. When this pin is high the outputs are turned off. Setting the pin low turns the outputs back on. More importantly, it changes the internal counter for the PWM control and resets the counter to 0. It is to this counter to which we now turn out attention.
The TLC5940 uses 12 bits to determine the output level for the LEDs connected. Each LED is controlled independently and the full array of 12 bits requires a total of 192 bits (12 bits x 16 LEDs) of data to determine the output levels for the LEDs. The 12 bits for each LED gives a total of 4096 (remember this number, we’ll be using it later) levels for each LED (0 to 4095 inclusive). The TLC5940 uses this data and the current counter to determine the output state of each OUT pin.
Setting BLANK to high and then low causes the counter to be set to zero. An incoming clock pulse causes the counter to be incremented by 1. The chip then turns on all of the outputs which have a greyscale value which is non-zero. Each subsequent pulse cause the chip to do the following:
This process repeats until the internal counter reaches 4095 at which point the process stops and the outputs are effectively turned off (the counter value is greater than or equal the output value for the LEDs). This point is important as providing only one pulse to BLANK and a series of 4096 (or more) clock pulses makes this a one time only output. The LED on each output lights for the specified duty cycle and then turns off.
The trick here is to ensure that a BLANK pulse is generated for every 4096 greyscale clock pulses. This is achieved by attaching the output from the timer circuit to both the greyscale clock on the TLC5940 and a divider circuit. The divider counts 4096 clock pulses and then outputs a new BLANK signal to the TLC5940 effectively restarting the counting process. So the modified clock circuit looks something like this:
The clock signal is split and one connection to the GSCLK (grey scale clock) pin on the TLC5940, the other connection is to the clock inputs of a 14-bit counter/divider (74HC4060). The divider counts the clock pulses and sets the output pins of the chip to represent the current value of the counter. The counter is reset once it reaches the maximum value and the whole process restarts. The counter does not output the lower three bits but this is not an issue for us as we are interested in counting to 4096. We can use the output from bit 12 (2 ^ 12 = 4096) as a BLANK signal for the TLC5940. So for the first 4095 pulses the TLC is setting the outputs according to the values held for each pin. When the counter reaches 4096, the TLC stops displaying data but then a BLANK pulse is received from the divider. This then restarts the whole process. The result, we have the outputs continuously cycling the the LEDs on for the required duty cycle.
One final point about the BLANK signal. This could be used by the microcontroller which is controlling the circuit to turn off the outputs. To allow for this, the output from the divider is ORed with the BLANK signal coming from the microcontroller. The output from the OR gate is passed on to the TLC5940.
This signal determines the type of data being transmitted to the TLC5940.
When VPRG is high the chip expected 96 bits of data for the Dot Correction (DC) registers. The DC registers allow the controller to scale the output current supplied at each output pin. This is covered later in this article.
When VPRG is low, the TLC5940 expects 192 bits of data for the grey scale registers.
A low-high pulse on this pin latches the data received from the microcontroller into the DC or the GS registers. The data is latched on the rising edge (i.e. low to high) of the XLAT signal.
This pin is not used in this circuit and to connected to Vcc
This pin can be used to set the maximum current output on each of the output pins. This is done by connecting the pin to ground through a resistor. The value of the resistor is determined by the following calculation:
R = (1.24 / Imax) * 31.5
Where Imax is the maximum current to be supplied. The value of 1.24 is the reference voltage on the IREF pin.
For the LEDs I am using I want a maximum current of about 26mA. This gives a resistor value of 1502 ohms, so a 1k5 resistor should do here.
This pin is an output from the TLC5940 and can be used to report when an error is detected. This pin is not used in this project and is connected through a 10K pull-up resistor to Vcc.
The TLC5940 uses a value in the range 0-4095 to represent the duty cycle for each of the outputs. This gives an effective brightness for each LED given by the following calculation:
Percentage brightness = (Grey Scale value for output N / 4095) * 100
The dot correction reduces the current flowing through the output pins. This can have two effects, it can be used to adjust the current to bring it in range for a specific LED or it can be used to fine tune the output current for an output pin. This can effectively reduce the brightness of a LED. The change in maximum current for a pin is given by the following calculation:
Iout = Imax * (Dot correction value for pin N / 63)
Where Imax is set using the resistor connected to the IREF pin (discussed above).
The final circuit looks like this:
The whole circuit is controlled using a Netduino Mini. The four pink control lines in the above circuit are used by the Netduino Mini to control the TLC5940.
| Pin Name | Description |
| MOSI / SIN | Serial data output from the Netduino Mini (pin 14 on the Netduino Mini) |
| SPCK / SCLK | Clock signal for the serial data (pin 16 on the Netduino Mini) |
| XLAT | Data latch signal. This could be connected to the chip select although in the initial implementation this is broken out to it’s own pin. |
| VPRG | Determine the programming mode for the TLC5940. High: Dot Correction data is being loaded. Low: Grey Scale data is being loaded. |
| BLANK | Turn the outputs (LEDs) on or off. High: Outputs off. Low: Outputs on. |
The application encapsulates the TLC5940 functionality in a single class Tlc5940. This project only deals with one chip controlling 16 outputs (even though several can be linked together). The class only exposes 2 methods:
The constructor sets up the system to use the SPI interface and takes parameters to determine which additional control pins should be used.
The display method takes two parameters, one for each of the dot correction data and one for the grey scale data.
The main program contains a small demonstration of the functionality of this class and the TLC5940 chip. It slowly fades in 16 LEDs from off to full brightness and then fades them out to the off state again. This is repeated in a loop forever. For an example of the output see the video at the top of this article.
The code is pretty well commented and so further discussion is not provided here.
You can find the source code here (TLC5940.zip).
This article is really a starter for this chip as there is a whole lot more which is possible. There are a number of areas where I would like to expand both the code and the circuit, namely:
Adding these features will make this class more rounded and fully encapsulate the feature set offered by this circuit.
The first cube was completed in July and the initial posting generated some interest. I agreed to make a second and this one has just completed it’s first transatlantic journey and has made an appearance at MakerFare in New York. The following image appeared on Time Out New York’s web site:
Building the second cube was fun as I was able to implement all of the lessons learned from making the first cube.
Whilst the blog may have been a little quiet recently I have never the less been busy writing about the cube. There is a Wiki article on the Netduino web site showing how the cube was constructed.
I have also released the source code to the project on Codeplex.
I’m just about to start to write this up but I thought I’d share the cube working before I do. Here is a video showing a few animations:
Watch this space for more information over the coming days.
In a previous post I mentioned that replacing a single LED in the centre of a matric would be murder and so it will be. The matrix I have in mind is an 8 x 8 x 8 LED cube controlled by a Netduino board. Now it should be obvious that there are not enough pins to connect 512 LEDs to the Netduino without some magic being involved. This is where the Persistence of Vision post comes into the picture. In theory, it should be possible to control an array using a group of shift registers and a multiplexer circuit. So for the next few weeks this is what I’ll be looking at.
The previous post on Persistence of Vision had a simple while loop which allowed 16 LEDs to be controlled from the main program loop. In the final program this will be too cumbersome and timing is almost certainly to become an issue. To overcome this we will need to have the display logic separated from the control logic. This will allow the display to be continuously updated whilst the main program loop is working out what should be displayed next. The following tests this concept by turning on on LED at a time in a bank of 8. If this project has a chance of working then the 8 LEDs should all appear to be switched on permanently.
The hardware is relatively simple. We have one shift register connected to the Netduino. This is in turn connected to 8 LEDs through current limiting resistors. The schematic looks something like this:
The software requires us to take the display logic from previous posts and add this to a new class. This class will need to have a method executing in it’s own thread in order to allow the main program and the display driver to run at the same time. So splitting the display code into it’s own class we get something like this:
class LEDCube
{
/// <summary>
/// SPI bus to use to send data to the shift registers.
/// </summary>
SPI spi = null;
/// <summary>
/// CSPI bus configuration
/// </summary>
SPI.Configuration config;
/// <summary>
/// Buffer holding the display data.
/// </summary>
private byte[] buffer;
/// <summary>
/// Constructor for the LEDCube class.
/// </summary>
public LEDCube()
{
config = new SPI.Configuration(SPI_mod: SPI.SPI_module.SPI1,
ChipSelect_Port: Pins.GPIO_PIN_D9,
ChipSelect_ActiveState: false,
ChipSelect_SetupTime: 0,
ChipSelect_HoldTime: 0,
Clock_IdleState: true,
Clock_Edge: true,
Clock_RateKHz: 400);
spi = new SPI(config);
buffer = new byte[1];
buffer[0] = 0;
}
/// <summary>
/// Main loop which continuously updates the display from the buffer.
/// </summary>
public void DisplayBuffer()
{
while (true)
{
lock (buffer)
{
spi.Write(buffer);
}
}
}
/// <summary>
/// Change the byte in the display buffer.
/// </summary>
/// <param name="b">Byte to put into the buffer.</param>
public void UpdateBuffer(byte b)
{
lock (buffer)
{
buffer[0] = b;
}
}
}
Much of the code should be familiar, we have the SPI bus and config variables along with a constructor to make a new instance of the SPI bus. The new code is really the DisplayBuffer and the UpdateBuffer methods.
Note that both of these methods use locking to ensure that the methods are thread safe.
The main program loop now looks something like this:
LEDCube cube = new LEDCube();
Thread display = new Thread(new ThreadStart(cube.DisplayBuffer));
display.Start();
while (true)
{
byte value = 1;
for (int index = 0; index < 8; index++)
{
cube.UpdateBuffer(value);
value <<= 1;
}
}
A new LEDCube is created and at first this is not running in it’s own thread. The next two lines create and start a new thread. The thread is executing the DisplayBuffer method. We then start the main program lopp which simply sets each bit in a byte and the updates the buffer in the cube using UpdateBuffer.
Next step, build the control logic for 512 LEDs.
Delivery, 600 blue LEDs and a bunch of components. So if I’m going to work with these I need to test them first – replacing a single LED in the middle of the matrix is going to be murder so better make sure they are all good to start with.
Grab a resistor, power supply and a glass of wine. Be back later.
What matrix – All will become clear in the following posts 🙂
