Results tagged “RaspberryPi”

While I've been waiting for the final parts to arrive (LEDs, SO-DIP-Adapter, ICs, etc.) I did some more theoretical work and tried to scale the 3x3x3 driver circuit to 8x8x8.

This is the result:

From LED Cube Images

This circuit diagram also shows one specific feature of my cube. I want to transmit the LED status via serial connection to the driver ICs but in contrast to eg. the solution on HNTE I want to transmit the serial data to all driver ICs in a concurrent fashion, not via chaining them. It should work by providing all ICs with the same clock and latch signal but running a seperate signal from the Raspberry Pi's GPIO to each IC's serial input. That way I can set up the configuration for a single layer with only 16 clock cycles instead of 64. I'm not sure if this works as expected. If not, I'll have to fall back to daisy chaining the ICs serial lines.

That's why I also tried to come up with a flexible solution for the software which allows me to quicly adapt the serial output if I have to change the circuit. My goal is to create an algorithm which determines the required clock/serial/latch output in an efficient way from an 8x8x8 LED status array. It should also be easily configurable so that I can port it from the first 3x3x3 prototype to the final 8x8x8 cube with minimal changes even if I have to change the driving circuit.

I had no success so far though which may or may not be related to the fact that I only found time to think about that in the past week after 11pm each day as I've been busy with other stuff earlier each evening.

|

As already mentioned in my LED Cube intro post one of the milestones on the path to a full-size 8x8x8 cube is a smaller cube for trying out my ideas and testing the fundamental theories on a smaller 3x3x3 cube. Of course on the way to a 3� cube there are more fundamental issues to solve.

The first issue is to get familiar with using the GPIO pins of the Raspberry Pi, as this will be essential for feeding the driver circuit later with the required animation/multiplexing data. So in the last few nights I've been busy downloading Raspbian, setting up the network connection with my computer (I don't have a HDMI- or Component-capable device available near the work area) and preparing the first GPIO test with LEDs.

It was a good first step which took a couple nights, but after issues with wrong resistors, not-working DHCP from my computer and a wrong connected Pi Cobbler ribbon cable, I could file success with 3 lit and controllable LEDs. These will represent the three channels which I will use later to feed the serial data to the driver IC.

From LED Cube Images

I also began drawing the circuit diagram using the free (for private use) EAGLE PCB Software. I did this to already have a better plan when all the parts arrive and maybe for a much later stage when the cube is ready and I bring the circuit from the breadboard to a custom PCB which is the other main functionality of EAGLE. The handling of EAGLE is a bit difficult, but an excellent (german) tutorial video for EAGLE helped a lot and covered everything I needed to finish the circuit for the 3x3x3 cube.

From Building LED Cube

The next steps on my plan are ordering the final parts, enhancing the circuit drawing for 8x8x8 and beginning to write the LED driving software.

|

It is pretty clear that it's very hard to control 512 LEDs without some tricks. Most already built LED Cubes rely on two realization concepts to bring the cube to life:

  • some sort of integrated LED driver circuit (read: using chips)
  • use multiplexing / POV to lower the number of LEDs to be controlled individually

Using an LED driver IC to controll the large number of LEDs is almost a no-brainer. Although there are solutions possible to control that many LEDs without resorting to integrated circuits (e.g. Charlieplexing logic) they all come with one or more drawbacks like complicated wiring schematics, lots of additional required components or being only able to light a single LED at any time. Using a LED driver IC avoids all those problems and makes it possible to control many LEDs even for non-professionals.

Multiplexing takes advantage of the human eyes incapability to detect light pulses or variations in brightness if they happen just fast enough. It's the same principle which is used in TV sets and in the cinema. In a LED cube this principle is realized by only lighting up one layer of LEDs at any time and switching between the layers fast enough so that the human eye gets the impression that the whole cube is active. For an 8x8x8 cube this means that at most 8x8=64 LEDs (within one layer) are active at any given moment and the currently active 64 LEDs are switched within the 8 layers several times per second. This reduces the required logic to drive 64 LEDs and a simple selection logic to choose one of eight layers resulting in 72 wires leading to the cube.

The heart of my LED cube will be the STMicroelectronics STP16CPS05 (datasheet). I got the inspiration for this driver from this project and decided to use it because:

  • serial input possible using 2 pins (+1 for latch)
  • serial input accepts 3.3v, perfectly fitting for the Raspberry Pi GPIO
  • high maximum frequency of 30MHz, great for fast multiplexing (and probably software-driven PWM)
  • 16 output pins
  • simple integration and control (just clock in active/open LEDs and signal latch)
  • chainable (like done in HTNE's cube), but in my circuit this won't be required
  • cheap

One drawback of this IC is that it is not offered in a DIP-package which could be immediately used on a breadboard. Therefore I will have to solder the ICs onto adapters to use them on my breadboards and such adapters themselves are not that easy to come by.

Some friends suggested alternate ICs, eg. TLC5940, MM5450 or the MAX6962ATH but either are those much more difficult to interface with, have a smaller range of applicable voltages or I would have to use them in the same way as the STP16CPS05 without the ability to take advantage of their additional functionality. So I settled with the, in my opinion, simplest solution.

Update 2013-05-11 Found another possible alternative, the TI [TLC5925][9]. This looks like a possible replacement if I have problems with the STP15CPS05.

[9]: http://www.ti.com/product/tlc5925 "TLC5925 16bit LED Sink Driver]

|

As already hinted last time my next electronics project will be a monochrome 8x8x8 LED Cube.

I chose this from a long list of possible interesting projects because its construction involves many of the areas in which I intended to work on something at some time.

  • Raspberry Pi programming
  • enhancing my basic electronics and soldering skills
  • beef up my electronics prototyping set
  • interfacing an uC/SBC with external hardware/components
  • creating an electronic circuit without step-by-step instructions
  • understanding and using an IC
  • designing and creating a PCB, maybe even etching it myself

LED cubes in particular striked my attention a few years ago but at that time Ialways repelled by the sheer complexity and number of components in most of the LED cube building instructions. But when I saw some another building plan for a LED cube I realized that I could use my Raspberry Pi to create a much simpler control circuit. And so the decision was set.

My plan for the next steps is to build a prototype (3x3x3) to test my whole concept, get comfortable with all the stuff and then scale it to 8x8x8. At first I'll set up everything on breadboard and maybe, if I'm sure that everything is finished on the hardware-side, make a permanent and smaller control PCB version. Probably as a Raspberry Pi shield.

The progress of this project will of course be documented on this blog.

|

|

I finally received my Raspberry Pi which I've ordered in the first quarter of this year. It's an interesting piece of hardware and even smaller than I expected.

Sadly I'm still unable to spend more time with this. I just took some nights and compiled OpenELEC and put it on a newly purchased class-6 SD card to boot. I chose a self-compiled OpenELEC because initially I only had a 1GB card available and it seems that there is no precompiled image available which fits on cards smaller than 2GB. (In the meanwhile I've purchased some additional cards with reasonable sizes.)

It took some attempts for me to be able to control the XBMC media center on my flatscreen TV but on the second day I've been successful to play some HD videos from the little gadget. The issues I had to deal with were

  • a dependency error in the OpenELEC sources (should be fixed by now)
  • unexpected long build duration on my machine
  • correctly partitioning the SD card manually, configuring the boot-parameters file
  • me not recognizing that the TV should be set to HDMI before turning on the Pi

But these were already all of the issues and since development for the Raspberry Pi is extremely fast I expect things to become faster and easier day by day. And this is currently just for my goal of getting a media center up and running, I wonder what will be possible when developers are going to put these GPIO pins into top gear...

|

1

Archives