Make RGB LED Display with xc-3 kit more Economical

[jagspaul]

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).

I is not a mater whether you are XMOS employee or not. I just know you are a XMOS lover and we can work together. But I should tell you that I am not experienced like you, I am a now comer.

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.

Please find the attached pdf and go through page 5.

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.

With single buffer we cam simply increase the pixel buffer size double. So we have to find out a better way of single buffer. We can declare a blanking flag and when the buffer will be written the flag will set and display scan routine will stop until the flag is reset. The flag will be reset at end of buffer write routine.

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.

we can make another 6 more data pin with second connector of XC3. In core 1 we have 64KB buffer free. We have to declare a pixel buffer in core1, ethernet packet will be updated in this buffer through input channels and scan routine will fetch data from output channels of the buffer. Finally scan routine will use second connector of XC3 and send the core 1 buffer data to display module.

Please comment on this point.

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.

Do you mean that the ethernet chain of the prototype LED Tile project is not working at all. did you check with sending video file through PC and connecting two Tile in a chain??

However integration of the official ethernet module is very good idea. But in that case we have to maintain the ethernet chain.

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.

From hardware point of view BGA package is very difficult and expensive to use rather TQFP. Is it possible to port the system in a multiple 1 core board (att the core will be connected through sys channels). I am asking because PCB fabrication of TQFP package is feasible for me.

Thanks
Jags

[jagspaul]

Hi Nisma,

Your simple xor compression idea is very good. But in source code I didn't find any compression. Please give sample code of compression and decompression. I need to implement the same.

If possible have a look on the source

Thanks
jags

[Interactive_Matter]

Hi Jags,

to come back to some of your discussed issues:

…

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.

Please find the attached pdf and go through page 5.

Uhm, yes I found the figures in the PDF, but I do not really know how they come up with such a number. Nevertheless the buffer sizes in the LED Tile software is quite easy to configure. Hence it should be really straight forward to try it out ;)

we can make another 6 more data pin with second connector of XC3. In core 1 we have 64KB buffer free. We have to declare a pixel buffer in core1, ethernet packet will be updated in this buffer through input channels and scan routine will fetch data from output channels of the buffer. Finally scan routine will use second connector of XC3 and send the core 1 buffer data to display module.

Please comment on this point.

Yes, all hardware outputs (LED Module IN, LED Module OUT, Expansion Header) are located on core 0 (if I read the hardware manual correctly). So outputting the address on an 8 bit port is no problem and the approach you are describing above should work.

Do you mean that the ethernet chain of the prototype LED Tile project is not working at all. did you check with sending video file through PC and connecting two Tile in a chain??

That was very strange and hence I decided to completely rip out the old Ethernet solution:
It worked with the burnt in firmware. But somehow it did not work with the provided source code. I suspect that the source code that got published is not really the latest version. So I just did not care about those problems and integrated the new Ethernet stack.
I think to be more usable it seems very useful to me to also change the way of network interaction. Especially in configuration mode the XC-3 Modules could send back a bit more status information to the network client initiating the configuration procedure.

However integration of the official ethernet module is very good idea. But in that case we have to maintain the ethernet chain.

Exactly the opposite is true (I hope). The code for the Ethernet communication was an outdated copy of the official Ethernet stack. The current stack fully supports the XC-3. So I think that after we sorted out some small problems we can simply rely on further development of the Ethernet stack and don't have the efforts in our project. Since we use source directly from git and not a local copy.
Currently I have my own fork of the Ethernet stack, but only because there is a very small bug, which cannot be fixed right now. But the guys from XMOS are aware of this so I think that this is a matter of some weeks.

From hardware point of view BGA package is very difficult and expensive to use rather TQFP. Is it possible to port the system in a multiple 1 core board (att the core will be connected through sys channels). I am asking because PCB fabrication of TQFP package is feasible for me.

[/quote][/quote]
Yes I think that this is possible. But I doubt that you end with less board space than XC-3 or XC-2. And perhaps you loose one or the other port. Shouldn't be a problem though.

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.
…

The led buffer makes very little assumptions about the data format in it. It is mostly a question of how the host program writes the data and how the driver converts those data to LED values. I think it would be a great idea to try YUV encoding (perhaps with some compression). I do not want to convert the whole solution to YUV but removing any assumptions on the data format from the central LED buffer and completely solve this by driver and client sounds very good to me, since it gives you exactly the flexibility to do this as you like.
Regarding the Gamma- and error correction this is quite easy. This is all done in the process to convert the 8 (or if you like 24) bit data buffer to 16bit or whatever LED driver output format. So no matter in which format the pixels are stored you can still rely easily on corrections of the pixel values.
Of course, timing problems can occur, but this is solvable I think.

I hope that some of those answer helped you to get on ;)

Marcus

[nisma]

If using static driver, the led driver hold one buffer, so double buffering is not necessary.
If doing multiplexing, then buffering is needed. The source is not bad, but i don´t understand
the use of ethernet. The ethernet consumes >28k ram having only two buffer and need 6 threads, or
at least 4 if using external switches.
I propose to usa a controller board that trasform ethernet or usb to simple 2bit xlinks with differential driver
and ethernet cabling.

Example: 8x8 module with 60mm sqare leds that can be driven either 50mA or 70mA pulse at 12V.
Worst case, 16x16x3*0.05mA*12V=153.6W . Now assuming half the current, 75W as example.
Assuming one central screen with 3x2mt and two 1x3mt sidescreens are 850 16x16 modules and
the whole thing need 70KW assuming 89% efficency of power sources.
Further using 60/40 ration then it´s 42kw using static driver.
Using 1/5 mux, it´s 10kw and using 1/9 mux it´s 6kw for using 12mA or 6mA instead of 50mA.
Annother thing, heat sensor are required for this type of installation in order to reduce the driving
intensity if the heat is too heavy. Maybe the problem can be one 3-6kw xenon spot that heat up
some panels. The big question, what make sense, and remember, 2x3mt in this case is only a
resolution of 256x400 pixels. Having a 16x16x3 matrix, there are 48x16 pattern and it needs
8x 16bit led driver and one 6x driver in order to multiplex the panel at 12mA or 5x 16bit led driver and
10 drivers for driving the panel at 7mA.
If we limit the spi speed at 10Mhz and using one serial shift register to multiplex the lines using rs422/485
drivers for the clock and data, one xmos can handle 32 panels, maybe 64 using two spi ports.
This at 120hz update rate or 64panels at 60 hz update rate using a single spi interface.
For static leds, more that one interface is needed, maybe 4. Porting the mux lines out don´t make mutch
sense.

By that way, what is you goal to realize ?

[Interactive_Matter]

If using static driver, the led driver hold one buffer, so double buffering is not necessary. If doing multiplexing, then buffering is needed.

You are completely right. I completely overlooked this. The source is currently not ready for it, but this can be easily added

The source is not bad, but i don´t understand
the use of ethernet. The ethernet consumes >28k ram having only two buffer and need 6 threads, or
at least 4 if using external switches.
I propose to usa a controller board that trasform ethernet or usb to simple 2bit xlinks with differential driver
and ethernet cabling.

If you got a hammer everything looks like a nail ;)
I do not think that is generally bad to use the XMOS for ethernet, but not necessarily essential. In theory it is possible (and easy) to just connect the LED buffer to some protocol, since the ethernet stack is really quite isolated due to the channel to the LED buffer.

Sorry I could not really follow the rest of your posting. Can you try to explain to me what you propose as solution (and perhaps the problem too) ;)

Thanks

Marcus

[jagspaul]

Static scan is very expensive as lots of LED driver chip is needed and it is used only out door display. We can introduce static scan but to make our display cost low we have to make it ready for 1/8 and 1/16 scan too for indoor display.

If RAM size is the only issue then we can introduce a external Ram buffer. In this case one XMOS core will handle external RAM one core will be for LED module and another one will be used for Ethernet.

We can do this by using three single core XMOS chip as well as 4 core chip.

As distance between video source and LED display is quite long, I think Ethernet is best choice.
Instead of XMOS ethernet we can use a single chip ethetnet controller with internal PHY like W5300 (WIZnet). This chip has internal 128K Rx TX buffer and the application layer throughput 50Mbps.

Thanks
jags

[nisma]

I think xmos has made good job for making such a useless application note.
Useless because the led tile have many implementation flaw. However it´s a AN and not a finished application.

If you don´t consider the led tile, the AN is great and has surely other uses.
Annother point to consider is the fact that the Ethernet core as presented in the AN, there numbers, i don´t
have checked if there are true, fit inside the OTP and that the application processor for the ethernet implementation reside inside annother core. Theoretically loading the other core using tftp should be possilbe.

Back to the initial question, making RGB LED Display more economical.
Can you respond please on the question, whats is you´r goal to implement, how many pixel, how many streams.

Consider as example this:
Ethernet -> Xmos Controller (L1 or L2 >120 pin device)
+
|
+ xlink-0 -> Xmos Driver -> panel[0-31]
|
+ xlink-1 -> Xmos Driver -> panel[0-31]
|
+ xlink-2 -> Xmos Driver -> panel[0-31]
|
+ xlink-3 -> Xmos Driver -> panel[0-31]

The 2bit Xlink can be cabled using ethernet cables and have the same troughtput as 100mbit ethernet.
Annother approach can be using 64pin device for ethernet having only two link and on the drivers
cascading the links. This is more cheaper.

But tell, what you would realize, using 12V pixel (3 leds every color) or a single led every pixel, ... .
Even the power consuming need to be checked.

Currently i consider a matrix of 16x16 one panel with a average power consumation of 18W or 25W depending on the multiplexing used. As comparsion, static outdoor panels needs 90W of averaged power, peak power
is 120W.

[Interactive_Matter]

Consider as example this:
Ethernet -> Xmos Controller (L1 or L2 >120 pin device)
+
|
+ xlink-0 -> Xmos Driver -> panel[0-31]
|
+ xlink-1 -> Xmos Driver -> panel[0-31]
|
+ xlink-2 -> Xmos Driver -> panel[0-31]
|
+ xlink-3 -> Xmos Driver -> panel[0-31]

The 2bit Xlink can be cabled using ethernet cables and have the same troughtput as 100mbit ethernet.
Annother approach can be using 64pin device for ethernet having only two link and on the drivers
cascading the links. This is more cheaper.

This is an excellent idea. and by using different led buffers this is absolutely achievable and considerable cheap if you use the 64pin devices, which leads me to …

But tell, what you would realize, using 12V pixel (3 leds every color) or a single led every pixel, ... .
Even the power consuming need to be checked.

Currently i consider a matrix of 16x16 one panel with a average power consumation of 18W or 25W depending on the multiplexing used. As comparsion, static outdoor panels needs 90W of averaged power, peak power
is 120W.

From my experience with 110 meters of HL1606 led strips I know that driving them with 5V is a pain. The Ampere values you have to provide are really going through the roof.

So having some kind of panel with a local step down from 12V or better 24V is a very easy way to get the Watts to the LEDs

And combining those ideas you got a LED tile with an XS1-L01A-TQ48 or something similar, some ethernet connector for XLINK, a step down for efficient power distribution, some MBI5031 for 1/8 scanning and some RGB matrix modules - nice!

[nisma]

The other approach is:

Code: Select all

Ethernet -> Xmos Controller (48/64 pin device)
                       +
                       |                                     + Xlink-1 -> Xmos Driver -> Panel[0-31]
                       |                  + Xlink-1 -> Xmos Driver -> Panel[0-31]
                       + xlink-0 -> Xmos Driver -> panel[0-31]  
                       |
                       |                                     + Xlink-1 - > Xmos Driver -> Panel[0-31]
                       |                  + Xlink-1 -> Xmos Driver -> Panel[0-31]
                       + xlink-1 -> Xmos Driver -> panel[0-31]  

On the first view, it seems that 48pin devices suit better the application.

From my experience with 110 meters of HL1606 led strips I know that driving them with 5V is a pain. The Ampere values you have to provide are really going through the roof.

My experience coming from stage (music band) where standard panels (3 led every color pixel, 9 leds in total,
1 cm sqare dimension for a pixel, 16x16 panels) is used.
The driving pattern is ether 50mA fixed or 100mA peak for 1/10 mux or 80mA for 1/6 mux where the producer gives garantee about there lifetime and doe replacement with further failure analysis and if the temperature
derating is observed.
I know, the image screen is mostly dimmed, but when beginning at 6-8 pm in the
summer there need be not so dimmed and a rock band normally uses flashing the wall for some light effect
glowing to the max brigthness. I know, most video are not so bright and normally the wand is dimmed at
later hours, but when the same wand is used as example for mode shows, the watt indicated are needed.

[jagspaul]

From this Idea what I understand that is

One XMOS L1 controller will handle ethernet and its 4 xlinks will be connected with another 4 XMOS L1 (XMOS driver) chip and each XMOS driver will drive 32 RGB LED matrix module. The module size may be 16 X 16 or 16 X 32.
Am I right??
Also tell me the RGB LED module size?
What is the actual data throughput of ethetnet controller made by XMOS L1? Is it 100Mb or less?


jags