Make RGB LED Display with xc-3 kit more Economical

[jagspaul]

I am new for XMOS. And now I am just a learner. I have a project idea and that I want to share with you.

First I would to appreciate the RGB LED Display with xc-3 LED tile kit. This is a excellent project. But practically this is not economical rather RGB LED Display control kits available in market. Market available each tile kit support up to 65000 pixel in 1/8 & static scan, where as XMOS support 4096 pixel only in 1/8 scan and.

In LED-Applications Capabilities of-XS1-G4.pdf it is mention that

1) G4 144BGA support 16000 pixel in static scan.

Question:
For 16000 pixel buffer size required 16000 * 3 = 48000 bytes for single and 96000 bytes for dual buffer. As the prototype project is using dual buffer then how it is possible to allocate 96000 bytes buffer in a G4 core which is having 64K bytes only for code and data.

2) G4 512 BGA support 12228 pixel in 1/8 scan.

Question:
There is no prototype project available for LED Tile with G4 512. Then how a new XMOS lover can build the same.

So my dream is to build a modified version of RGB LED Display based on G4 144BGA and 512 BGA with maximum pixel support as possible.

In first phase we have to modify the existing XC-3 LED Tile project to support maximum pixel. In this case we may use single pixel buffer and increase the LED module DATA line.

In second phase we have to port the project to G4 512 controller and have to introduce one more LED I/O handler with pixel buffer in core 1. In this way we can make pixel capacity simply double in 512BGA then 144BGA.

So I request all of the XMOS lover to come forward and have a look on this project idea.

Thanks & regards
jags

[MaxFlashrom]

I am new for XMOS. And now I am just a learner. I have a project idea and that I want to share with you.

First I would to appreciate the RGB LED Display with xc-3 LED tile kit. This is a excellent project. But practically this is not economical rather RGB LED Display control kits available in market. Market available each tile kit support up to 65000 pixel in 1/8 & static scan, where as XMOS support 4096 pixel only in 1/8 scan and.

In LED-Applications Capabilities of-XS1-G4.pdf it is mention that

1) G4 144BGA support 16000 pixel in static scan.

Question:
For 16000 pixel buffer size required 16000 * 3 = 48000 bytes for single and 96000 bytes for dual buffer. As the prototype project is using dual buffer then how it is possible to allocate 96000 bytes buffer in a G4 core which is having 64K bytes only for code and data.

2) G4 512 BGA support 12228 pixel in 1/8 scan.

Question:
There is no prototype project available for LED Tile with G4 512. Then how a new XMOS lover can build the same.

So my dream is to build a modified version of RGB LED Display based on G4 144BGA and 512 BGA with maximum pixel support as possible.

In first phase we have to modify the existing XC-3 LED Tile project to support maximum pixel. In this case we may use single pixel buffer and increase the LED module DATA line.

In second phase we have to port the project to G4 512 controller and have to introduce one more LED I/O handler with pixel buffer in core 1. In this way we can make pixel capacity simply double in 512BGA then 144BGA.

So I request all of the XMOS lover to come forward and have a look on this project idea.

Thanks & regards
jags

I've not looked at this kit but, anyway, 16000 RGB pixels with each LED on/off only is 16000*3 bits = 48000bits. This could be packed into 6000 bytes. A G4 has 4 cores, each of which has 64KBytes(64*1024). Having 8-bits/LED would give you 24-bit colour if you drove each LED with an 8-bit DAC, rather than just on/off. This would require 48000 bytes. Early computers had a colour mapping table which allowed one to select a pallette of colours(a smaller subset of all available colours) This saved on memory to code an image.

Max

[jagspaul]

Max,
This is basically 24bits color (R,G,B each 8 bits) not LED ON/OFF.
Please go through the project XC-3 led tile and see only one core is used for LED pixel buffer.

Thanks
jags

[MaxFlashrom]

I've had a look at the schematics, although I don't see one for the LED driver module, althought I did find datasheets for the drivers. I saw, as you mention, the allocation of a buffer of 2 frames, with three bytes for each pixel in one of the cores. As you observe, there is only 64K in a single core, so with the current program as it is, obviously there's not enough space for 2 frames of 16000 RGB pixels in a single core. I saw https://www.xmos.com/download/public/LE ... 1.0%29.pdf, which you cited, that claimed that the chip could support this.

With external memory to store a frame buffer or a different use of the cores this might be possible.

Max.

[jagspaul]

Look, this document claims that the prototype designed support 16000 RGB pixel and the same design doesn’t contain any external ram. This is my confusion actually.

Any ways if you are interested we can start to rebuild the design to support maximum pixel. Also I invite other XMOS developer to come forward and join together.

jags

[jagspaul]

Specially I request the person who is right now maintaining XC-3 LED tile reference project to join with us .

jags

[Interactive_Matter]

Specially I request the person who is right now maintaining XC-3 LED tile reference project to join with us .

jags

Hi jags,

regarding the community that is more or less me (still do not know if there is still somebody at XMOS who wrote the source code).

First of all the central LED buffer runs on one core - so the 16bit RGB double buffer must fit into 64K plus some other data. I think the source code claims 8000 LEDs, my biggest experiment yet was with abt. 4000 LEDs. I had not checked this upper bound.

The solution was quite lightly documented, but I have put everything which I need for my experiments in the wiki over at github https://github.com/xcore/sw_led_tile_controller/wiki - especially the basic design of the display modules https://github.com/xcore/sw_led_tile_co ... ay-modules

Hope that helps.

The source is currently a bit strange since the burnt in code works much better than the published source code. You can get the original version via the tag https://github.com/xcore/sw_led_tile_co ... aintenance
Anyway I suggest using the most current version from the master branch. I have forked a repository, which contains a massively updated version, where I removed the driver switching for a more flexible pin assignment and integrated the newer ethernet stack (this is currently untested). So I really appreciate if you can collaborate with me on this version.

To really answer your question:

I think it is absolutely doable to port the software to an XC-2 kit an use several cores as led buffers - the display module output can be a tad more complicated with this. In my HL1606 project, I used 4 output buffers to easily address 4 of the breakout connectors on an XC2.

I would be glad to help you with this (esp. in a way where all the results contribute to a more usable LED Tile solution).

Does this help you?

[jagspaul]

egarding the community that is more or less me (still do not know if there is still somebody at XMOS who wrote the source code).

First of all the central LED buffer runs on one core - so the 16bit RGB double buffer must fit into 64K plus some other data. I think the source code claims 8000 LEDs, my biggest experiment yet was with abt. 4000 LEDs. I had not checked this upper bound.

What do you mean LED? Do you mean Pixel (1R, 1G & 1B LED)??
Please note that 8000 LED = 8000/3 pixel and 8000 pixel = 8000 * 3 LED.

Please go through https://www.xmos.com/download/public/LE ... 1.0%29.pdf and see XC-3 LED Tile prototype claims to support 16000 pixel in static scan and 2048 pixel in 1/8 scan. I am confuse for 16000 pixel support. In case double buffer 16000 * 2 * 3 = 96000 bytes size buffer is required.

Please have a look on ledbuffer.xc as follows.

#define FRAME_SIZE (FRAME_HEIGHT * FRAME_WIDTH)
//Number of pixel in a frame
#define BUFFER_SIZE (2 * FRAME_SIZE)
//As it is double buffer (multiply by 2)

#pragma unsafe arrays
void ledbuffer(chanend cIn, streaming chanend cOut)
{
// Double buffer -- two frames
// Frame is stored with in columns (original bitmap xy swapped)
// This allows outputting one column at a time in a simple loop
unsigned char buffer[BUFFER_SIZE*3];
//As each pixel has three LEDs (multiply by 3)

Note that buffer is declare as “unsigned char” it means it support 24bits color. If our LED driver chip is 12 bits PWM then each gray scale value has to be left sifted by 4 bits (gray val << 4) before sending to driver chip.

I think we have to make it single buffer first and we will get simple double pixel size.
What do you think?

The solution was quite lightly documented, but I have put everything which I need for my experiments in the wiki over at github https://github.com/xcore/sw_led_tile_controller/wiki - especially the basic design of the display modules https://github.com/xcore/sw_led_tile_co ... ay-modules

Hope that helps.

Look at the module drive there is only two group data line, R1,G1,B1 and R2,G2,B2. We have to make it 4 group R1,G1,B1 - R2,G2,B2 – R3,G3,B3 and R4,G4,B4 In this way we can increase the refresh rate with large pixel capacity. Also with this approach we can increase the pixel as well if next 2 data group is made on another core and another sran buffer.

What you think??


The source is currently a bit strange since the burnt in code works much better than the published source code. You can get the original version via the tag https://github.com/xcore/sw_led_tile_co ... aintenance
Anyway I suggest using the most current version from the master branch. I have forked a repository, which contains a massively updated version, where I removed the driver switching for a more flexible pin assignment and integrated the newer ethernet stack (this is currently untested). So I really appreciate if you can collaborate with me on this version.

Yes I would like to collaborate with you. Please give me link where I can get your code.
Please explain what is the benefit with your new driver switching and ethernet stack.

To really answer your question:

I think it is absolutely doable to port the software to an XC-2 kit an use several cores as led buffers - the display module output can be a tad more complicated with this. In my HL1606 project, I used 4 output buffers to easily address 4 of the breakout connectors on an XC2.

I would be glad to help you with this (esp. in a way where all the results contribute to a more usable LED Tile solution).

XC-2 is made by G4-512 BGA but having only one Ethernet connectivity. How the Tile chain will be made?

I think we have to make a different board with G4 512 having two Ethernet and more data line for LED module rather XC-3. As it is hardware modification so I would like to go for it at the last phase. First we should try on XC-3 with software modification.

So lets make a plan to start the project.

Thanks & Regards
Jagadish paul

[Interactive_Matter]

Hi,

just to make some things clear. I am not an XMOS employee and therefore I also only got insight from the outside. Hence I cannot really answer the calculation that are done by XMOS in detail and offer my support just as a community member (even though I am interested in working together with you).

But I will give my best to answer some of your questions:

What do you mean LED? Do you mean Pixel (1R, 1G & 1B LED)??

Yes, I mean RGB LEDs - so technically 3 LEDs per LED.

Please go through https://www.xmos.com/download/public/LE ... 1.0%29.pdf and see XC-3 LED Tile prototype claims to support 16000 pixel in static scan and 2048 pixel in 1/8 scan. I am confuse for 16000 pixel support. In case double buffer 16000 * 2 * 3 = 96000 bytes size buffer is required.

I do not know where this numbers come from. Sorry. But with your calculations in mind 8000 pixels make perfect sense. As you stated later you can have a number of LED buffers on different cores.

Note that buffer is declare as “unsigned char” it means it support 24bits color. If our LED driver chip is 12 bits PWM then each gray scale value has to be left sifted by 4 bits (gray val << 4) before sending to driver chip.

Yes it is 8 bit per color (so 24 bit). For the output it is later converted to 12 or 16 or whatever bit depth the driver supports. The conversion includes color and gamma correction. Hence the output will be 'real' 12 or 16 bit. And you need it for real color depth due to the logarithmic response of the human eye.

I think we have to make it single buffer first and we will get simple double pixel size.
What do you think?

A lot of the code works with double buffer and latching between those buffers. So it would be real hard to remove the second buffer (ok, if you just remove the latching it is easier). But you can expect to get some flickering problems due to parallel updates and readout. I think it is easier to try to use more buffers.

Look at the module drive there is only two group data line, R1,G1,B1 and R2,G2,B2. We have to make it 4 group R1,G1,B1 - R2,G2,B2 – R3,G3,B3 and R4,G4,B4 In this way we can increase the refresh rate with large pixel capacity. Also with this approach we can increase the pixel as well if next 2 data group is made on another core and another sran buffer.

What you think??

This is no problem. On the XC3 there is a second GPIO port with a second connector which can be easily used for a larger address space.

Yes I would like to collaborate with you. Please give me link where I can get your code.
Please explain what is the benefit with your new driver switching and ethernet stack.

You can see my current status at https://github.com/interactive-matter/s ... controller but once everything is working I will integrate it back into the real amos repository. I just wanted to have some freedom the experiment without wrecking the 'official' source code.

XC-2 is made by G4-512 BGA but having only one Ethernet connectivity. How the Tile chain will be made?

Yes, you cannot chain the XC-2 since it just got one network port. But you can easily connect them all to one network switch. Especially since good Gigabit switches can handle the several 100MBit connections very easily.

Yes I would like to collaborate with you. Please give me link where I can get your code.
Please explain what is the benefit with your new driver switching and ethernet stack.

This was dead simple. The old network implementation was simply not working. Instead of debugging into the old and outdated network stack I wanted to integrate the official ethernet module from XMOS to benefit from future updates.

I think we have to make a different board with G4 512 having two Ethernet and more data line for LED module rather XC-3. As it is hardware modification so I would like to go for it at the last phase. First we should try on XC-3 with software modification.

So lets make a plan to start the project.

I think this is a viable and good way. Eg. constructing something like the XC-3 but with more CPUs. Anyway I think that the XC-3 is a good hardware starting point since here you can test data throughput, memory usage per core and so on. A different hardware would either scale this up or break out the pins in a more convenient manner.

Regarding to get this project started please contact me per mail.

Marcus

[nisma]

I don´t have checked the source code.

Suppose you use a YUV (4:1:1) as example, with 6 byte you have 4 pixel.
This mean less then 12kbyte for 8000 pixel. Using a simple xor compression,
you then have 6Kb of memory for 8000 pixel. I think with double buffering even
16000 pixel should be possible with a single core. Hovever, limiting only to 8000
pixel every core allows for (1:1:1) with double buffering, having 16000 pixel means
loosing the use of double buffering, maybe with a correct timing this is not a problem.
Annother point is the error correction, if you need bad pixel, intensity modification of
image and other voodo for a correct image visualization, then you need at least 3 bits
every led, that mean 9K of data, or maybe 4.5k after simple xor compression. It´s not
bad, but maybe gamma correction, color correction, edge filter, ... it´s annoter 10k that
is reserved for that purpose. 8000 pixel = 24000 leds = 50 tiles of 3x16x10 leds.
I prefer 1:10 mux instead of 1:8 mux because leds can be pulse driven with a 1:10 pattern.
Assuming a led cost 5 cent + the driver cost 1€ + pcb and connector cost 5€ = 1700€.
Assuming the assembling costs 500€ then one pixel costs 0.29€ . What is you target price
for a pixel ?