[SpiROSE] SBC testing and test LED panel

This week was kinda quiet as far as the project went, due to the Athens week. However, this did not stop me from doing some actual testing on the SBC and the LEDs.

RGB on the SBC

First off, since we’ll be using the parallel RGB interface to transfer data to the FPGA, testing the flexibility of this bus was a must. Parallel busses get tricky once you get above 25 MHz. However, RGB is a simple display interface with basic control signals. Added to the 24 data bits, you have PCLK (pixel clock), HSYNC and VSYNC. The latter two are used to frame the actual image, with blanking intervals at the end of each line, and blanking intervals after the actual image. Because RGB is sort of a digital VGA, it uses the same timings, that are inherited from the CRT days. With those, you needed long blankings to let the electron beam go to the next line, wasting some precious bandwidth. For example, a 800 px wide image would have 224 wasted pixels per line on blanking.

However, an FPGA doesn’t care about electron beams, thus reducing those blankings to their minimum is essentials. As it turns out, the IPU of the i.MX 6 is very flexible, and allows us to set those blankings arbitrarily. A 1 px horizontal blanking and 1 line vertical blanking is feasible, and has been confirmed by measuring the output of the RGB interface.

Measuring RGB sync signals using poor’s man frequency meter

The measurement was accomplished using 3 STM32F103 boards (chinese clones of the Maple Mini, worth $2 a pop on eBay).

But what kind of frequencies can we expect? Well, our display being an LED matrix of 80×48, refreshing 256 times/turn at 30 turns/second, the total pixel clock is 80x48x256x30 = 29.5 Mpixels/s; thus a pixel clock a tad above 29.5 MHz (remember that cycles are wasted after each line, thus a slight overhead). Ouch, too high. But Wait! Our LED matrix is a whole slice of the cylinder along the diameter, not the radius. This means that, in a half-turn, we covered all of our display space, with the second half of the turn using the same pixel data. Great, we have our bandwidth reduced to a “mere” 14.75 MHz, which is much easier to route and work with.

But how to set those blankings exactly? I’m glad you asked! Linux drivers are well made for the i.MX 6, and once the LCD/RGB output has been enabled in U-Boot, a custom modeline in xrandr will do the trick. In our case, a resolution of 1024×480 exactly matches our pixel count, giving us a resolution of 1025×481 on the RGB (counting minimum blankings). As of frequencies, at 30 fps, this gives a pixel clock of 1025x481x30 = 14.79 MHz. This value shows that extra-reduced blankings are negligible for our application.

Corresponding measurements are the following :

From top to bottom : PCLK, VSYNC, HSYNC

Here is the modeline for this specific resolution:

Modeline "1024x480Z@30" 14.79 1024 1024 1025 1025 480 480 481 481

A few xrandr commands and you’re all set!


As FPGA development began and time advances, it was critical to validate the LEDs, and that our drivers are working. With the help of Alexis, we soldered samples drivers to breakout boards (QFN 56 is no trivial task) in order to test them.

However, what is a driver without any LEDs? Since 50 LEDs were ordered, I designed a very simple PCB that could be fabricated at school to test both the LEDs themselves and the multiplexing we’ll be doing. A single driver controlling 16×8 RGB LEDs, 50 units would not cut it, thus I only put a full column (16 leds) and a full line (8 multiplexed LEDs) with the required control logic (8 MOSFETS, here AO3401 I had laying on my desk). This only is an L shape, but allows us to test and develop the driver driver (no that’s not a typo). Oh and lots of pin headers for the wiring.

Bare board with small SMD parts soldered

I can’t say it enough, but kudos to Alexis for soldering all those components. For reference, the LEDs are 1.13×1.13 mm and the resistors are standards 0603.

Soldered PCB, wired up to the driver (not the blue board, which is yet another STM32 board)

Regarding brightness, I dare you to look straight at a single one of those LEDs for more than a few seconds. We did tests at extremely low brightness in an attempt to simulate the effective brightness once the panel would rotate. Even at 1.5% brightness, a single LED was easy enough to see in a brightly lit room. Furthermore, considering the density we have, I have no real concern at the moment regarding brightness.

What to do next?

Next week, I’ll try to build and run OpenGL apps on the SBC, and confirm that the voxelization algorithm can be run with OpenGL ES. It appears to be impossible without desktop OpenGL. If you recall my post about the algorithm, I use bitwise operands to combine different fragments. However, this is a feature exclusive to OpenGL. The rationale behind it (according to Khronos) is that most embedded GPUs lack a proper integer manipulation unit. Thus it is not part of the GL ES spec (for example, the glLogicOp function lacks, which is the function used to set the bitwise operation to logic XOR).

Thus I’ll either try to find a workaroud, or totally redesign the rederer, mainly on Alexandre’s ideas.

I will also benchmark the SBC in term of CPU power, to estimate if a 100% CPU implementation of the current algorithm is possible (spoiler: I doubt it).

2 comments to [SpiROSE] SBC testing and test LED panel

  • Samuel Tardieu

    So if you want to reuse pixel data on the second half turn you have to keep it in RAM in the FPGA, right?

    • Tuetuopay

      Yes, absolutely, thanks for mentioning it. I forgot it in the post, despite wanting to mention it.
      However, we don’t have enough ram in the FPGA to keep a whole image, thus we’ll need to re-send the image twice. For this, either duplicate the image in the framebuffer or have the RGB at 60fps with the renderer at 30fps. Either way, this will double the bandwidth and the pixel clock. This should not be an issue, as we are just shy of 30 MHz there, which is still manageable, albeit much harder to work with (PCB and signal wise).

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




This site uses Akismet to reduce spam. Learn how your comment data is processed.