Our lates videos on YouTube

Here on this page you can find codes for the projects. I'm using ASM30 for the PIC30/33F family, no C30 or any other C is available. I like the ASM especially the ASM30, much much easier than the PIC16 assembler, yes it is harder to do things in assmebler, but it is the fastest way, and you know what's going inside the chip to the last bit.

OK, I'm going to discribe the basic principles behinde the code - the workflow.

I'm starting with the bLAMP project as it is just the essence of the larger code for the RGB 5x5x5 cube.

Fist, what the code should do?

It is supposed to drive the leds in some patterns, and that is all. It hasn't got any interface, nor mechanical neighter software. So it is simply repeating "one and the same". The code is divided into sub-routines, and the most important one is the DRAW routine.

DRAW routine

It reads the graphic buffer (GBUFF) and drives the leds. The GBUFF is a memory array, each cell is one byte and it represents the brightness value of a LED in the led matrix, so we have 48 bytes for GBUFF. One byte is compossed of 8 bits, but we use bit7 as a flag, whether the led is on or off. So we have a maximum of 128 brightness values per led. We have 4 levels of 12 leds, total of 48 leds. We are going to light them one level at a time - this is our inner loop. To represent the brightness we use an outer loop ... ok take a look at the construction bellow.

         *  - variable = value of variable
         ** - [variable] = value at memory address equal to the variable's value

         ; the outer loop                          
         repeat 128 times{
            gbuff_Pos = [GBUFF]
            ; the inner loop  
            repeat 4 times{
               ; the load data loop
               repeat 12 times{
                  value = [gbuff_Pos]
                  ; value bit7=0 - LED is off; bit7=1 - LED is on
               ; light the current level with the loaded data
               CALL write_data_to_led_levels 
         ; clear all bit7s

So, what we have here are 3 loops, the inner two loops, read the states of all 48 leds, and then call the function that drives the leds. One very important thing that you should notice is the line marked in red. This line increases the value of a LED each time we read its state. As we go further noticing, we are increasing each LED brightness value exactly 128 times, and this is what the outer loop is for. We cycle through all the 48 leds, 128 times, each time we increase the value of the leds, thus we change their state at some point (as the state is the bit7), and this is very important, because this change in state give us the ON/OFF ratio of the PWM(pulse width modulation) we are using to simulate the brightness. The ratio is from 0:127 (compleately off or brightness=0) to 127:0 (or fully on and brightness=127).

OK, lets take an example, say we have brightness value(B) = 20(decimal). 20 = 00010100(binary), here bit7=0, so the state is OFF, on the next cycle of the outer loop the (B) will be 21, and again bit7=0=OFF, and so on and so on until we get (B)=128. At this point 128=10000000(bin), we have bit7=1 and state is ON, so we light the LED up. The next time the (B)=129 and agoin state=1=ON, and so on until we get out of the loop at (B)=20+128=148 (all values from 128 to 255 has bit7=1). Now we can do the math and find how many times the LED was ON or OFF. Well there are (127-20=107) times OFF and (127-107=20) times ON, or ratio of 107:20 (OFF/ON). After the last cycle the value would be 148=20+128=10010100(bin), this is exactly what we began with (20=0b00010100) but the bit7 is set, so to reset the GBUFF in its original values, all we have to do is to clear all bit7s of each GBUFF cell. With this done, we are ready to return from the draw routine.

If you have understood this, you are almost ready with the most important function of the project. Everything else is optional, and the real driving of the leds depends on your hardware specifications.

The graphic buffers

In the code, we are using two type of buffers. First is the primary buffer it is called GBUFF, and the other is the so-called equBUFF (this name is coming from the first thing I used this buffer for - equalizing the RGB Channels). The GBUFF holds the real valus of the LEDs, while equBUFF holds the GBUFF with applied effects. It is essential to have the original values as with the transformations we are loosing data, so for example, we can apply a HSV(hue-saturation-value) filter, while preserving the original data and modifing it when we need to.

So, GBUFF holds the original data, while equBUFF holds the values after the effects have been applied. We can switch between the two buffers, using the drawSTAT value, that control the source for the DRAW routine.

TIMERs interrupt routines

We are using 2 timers the T1 and T2.

On every T1 interrupt, we call DRAW, and on every T2 interrupt we process the effects. The T1's priority is set above the T2's, as DRAWing is the most critical feature of the code.

Some random thoughts on the brightness

The brightness of the LEDs is very important and desired. The more brightness the better the cube would be viewed in daylight. As we use POV (perception of view) effect, we are decreasing the brightness by design. Every switching of the plane/level/channel dulls the light. The design rules the factor we decrease the brightness by. In the case of bLAMP, it has 4 levels and only one channel, as it is monochrom, we decrease the factory LED brightness by 4. So full bright, value of 127, is 4 times duller than the LED's specs. For the cube, the factor is 15 (5 planes by 3 channels). Because of this factor, we need super-bright leds, as the low quality dull leds, would be dimmed even more. You should notice, the higher the leads out of the LED matrix, the lower the factor would be, but this leads to more complicated designs and constructions of the matrix and the controller. In the RGB LED CUBE, we are using common anode LED, and this is the lowest posible complexity of the controller and the matrix, thus lower leads out of the matrix. With some modifications on the matrix and the controller we could achieve a factor of 3, no matter how many levels we will have. This factor would be achieved at the expense of 5x5=25 vertical leads per level, thus a total of 100 leads more for the 5x5x5 RGB cube. Take a notice that the whole cube has a total of 40 pins now!

Source codes

bLAMP-source-20_12_2010.zip - These are the source codes for the bLAMP project in ASM30. Compile them with MPLAB for the HEX file.