BPI inside

Well, since the failure last time I've geared up some more. Sadly additionally to the equipment I also picked up a cold which interrupted my progress for some days. Nevertheless, it became pretty boring and so I decided to give it another try yesterday afternoon when my headace was merciful enough to allow me some hours of concentration.

I've learned two things through this second attempt:

• a clean solder tip is really essential (which was the main issue the first time in retrospective)
• solder flux is almost mandatory for SMT soldering

A big help was also to watch some SMT hand soldering tutorials. In the end I think I was able to fix my mistakes and I guess the soldering of the IC turned out not perfect but also not too bad.

From LED Cube Images

Looking nice, waiting for some action :) To check its functionality and if I damaged it during my previous drama it was quickly integrated into a test circuit on the breadboard.

From LED Cube Images

A manual test by quickly connecting and disconnecting the various pins manually resulted in a strong hint that everything was working but it seems that at 3.3V the IC is very sensitive on the CLK line and when holding the CLK wire just my hand while having it disconnected from 3.3V or GND it generated continuous clock signals autonomical to set or clear the OUT pins just fast enough to be recognizable. Since this could still be a hardware failure I decided to put together the first software fragments I have created in the meantime (a simple C++ layer for setting the GPIO ports).

A bit of debugging and tinkering later, where I already managed to light up single LEDs I was looking at this:

From LED Cube Images

This is a picture of the Raspberry Pi controlled LED driver circuit which is already continuously running a basic multiplexing logic which could be used to drive the prototype 3x3x3 LED cube. It's not visible on the photograph (there was some flickering visible in the camera's preview screen) but the LEDs on the right side are for controlling the layer selection and only one of it is turned on at any time. The LED on the left side represents the center LED set in the middle layer, therefore only turned on when the selection LED for the middle layer is also active.

Out of curiosity I also added some counter logic which tells me the refresh rate of the cube. It seems that I can update the 3x3x3 LED cube with about 500kHz when running at 100%. Adding a usleep(1) brings that down to 8kHz leaving the RPi idle with 60% so there should be plenty of reserves for additional logic to drive cube animations.

But one possible weakness of my design (driving LED cube directly via the RPi) showed first signs. I recognized very short and tiny flashes and blackouts in the LEDs while running my test application. It becomes more visible when I move the mouse pointer. This is very likely one of the effects of Linux being no Realtime-OS and running stuff in the background delays the update of the cube. Even if it's just in a milisecond scale it's very visible in a sudden surge or peak of the LEDs brightness. This will be one of the issues which I have to deal with later, probably by introducing a timing logic based on absolute time and spin-locking instead of relying on OS-provided delay methods. It may also be caused by voltage fluctuations caused by the RPi's CPU sucking more power during background tasks but that should be remedied when I build a proper power source (which is also planned for the cube, probably from an old ATX power supply).