Make RGB LED Display with xc-3 kit more Economical

[jagspaul]

Maia
Why don't you take MBI5024 (No in build PWM, you have to make PWM on XMOS).
I get MBI5024 $0.2 each.
I think software PWM LED driver like MBI5024 is best choice on economical point of view.

jags

[jagspaul]

Is it true that when we purchase XC-3 we get it per loaded LED Tile firmware with working network stack.??

If so then some one tell me how to backup this firmware so that after loading new build firmware in flash one can retrieve the board to pre-loaded firmware.

jags

[jsmaia]

Hi jagspaul,
IMHO the most inportant now is the definition of the parts we will use, test the ethernet and design the power supply. The LED board with the driver may be easy to adapt later.
Regars,
Maia

[jsmaia]

Hi All,
Is this topic dead?
Regards,
Maia

[jagspaul]

No! not at all.

Today I am quite happy to see excellent performance of XMOS Led tile.

I used XMOS source and found Ethernet stack is working for me. I configure the modules for 32 X 64 frame (4 * 16 X 32) with SW PWM. I played movie with mlayer and found it on LED panel with excellent picture quality. I have test it with 10 & 8 bit SW PWM, in both cases result is simply excellent.

Now I want to make a prototype LED Tile control kit with two or maximum three L1 in a single PCB (as using BGA is impossible for me) which support 4 to 8K pixel (SW PWM).

For this I need to convert the existing source from 4 core to 2 core.
With removing watch dog I can simply convert it to 3 core. After that I need to make it one port Ethernet instead of two port and all the thread of core 3 has to be placed on the core where Ethernet thread exist.

I need help please tell me from where I should start.

jags

[Folknology]

You will find integrating other functionality with the ethernet on the same core can be tricky both in terms of space and threads. although I haven't looked at LED code itself.

regards
Al

[jagspaul]

I have one more idea.
In our system core 0 will be network & flash thread. If we could add all thread of core 3 including ledbuffer thread then only 2 thread of LED driver core will be in use and we can use another 2 thread for a parallel LED driver without effecting speed of the core.
In this way we can increase the pixel capacity even in SW PWM.

jags

[nisma]

@Folknology

The idea is to have one L1 core for the ethernet stuff and several others for the led implementation.
Additionally it should integrate the spi thread for reading from spi flash that actually reside in the led core.
The eth-L1 have only one ethernet interface as external switch are supposed if there are really needed
and this basically allows merging the code from core[2] and core[3] into a single core.

[jagspaul]

I have made Ethernet stack one port from two and shifted all the threads to core 0 & 2 and found it is running well.

But I am bit confuse why core 1 & 3 occupy at list one thread & one channel though in source there is nothing for core 1 & 2.

Please go through the following for reference.

Code: Select all

par
  {
    // Threads constrained by I/O or latency requirements
    on stdcore[2]: ethernetSwitch3Port(
        clk_mii_rx_0, p_mii_rxclk_0, p_mii_rxd_0, p_mii_rxdv_0, p_mii_rxer_0,
        clk_mii_tx_0, p_mii_txclk_0, p_mii_txd_0, p_mii_txen_0,
        clk_mii_rx_1, p_mii_rxclk_1, p_mii_rxd_1, p_mii_rxdv_1, p_mii_rxer_1,
        clk_mii_tx_1, p_mii_txclk_1, p_mii_txd_1, p_mii_txen_1,
        clk_mii_ref, clk_smi, p_smi_mdc_0, p_smi_mdc_1, p_smi_mdio_0, p_smi_mdio_1, p_mii_resetn,
        c_local_rx_in, c_local_tx, cWdog[0]
        );

    
    on stdcore[0]: leddrive(c_led_data_out, c_led_cmds_out, cWdog[1],
        p_led_out_r0, p_led_out_g0, p_led_out_b0, p_led_out_r1, p_led_out_g1, p_led_out_b1,
        p_led_out_addr, p_led_out_clk , p_led_out_ltch, p_led_out_oe ,
        b_led_clk, b_led_data, b_led_gsclk, b_ref);
    on stdcore[0]: spiFlash(cSpiFlash, p_flash_miso, p_flash_ss, p_flash_clk, p_flash_mosi, b_flash_clk, b_flash_data);
    
    // Unconstrained threads
    on stdcore[0]: watchDog(cWdog, 1);

    on stdcore[2]: pktbuffer(c_local_rx_in, c_local_rx_out); 
    
    on stdcore[2]: ethServer(c_local_rx_out, c_local_tx, c_led_data_in, c_led_cmds_in, cSpiFlash, cWdog[2]);
    on stdcore[2]: pktbuffer(c_led_cmds_in, c_led_cmds_out);
    on stdcore[2]: ledbuffer(c_led_data_in, c_led_data_out);
    
  }

Code: Select all

Constraint check for "stdcore[0]" (node "0", core 0):
  Stack available:   0x0000d568,   used: 0x000081a4 .  OKAY
  Threads available:          8,   used:          4 .  OKAY
  Timers available:          10,   used:          2 .  OKAY
  Chanends available:        32,   used:         10 .  OKAY
    Constraints checks PASSED.
Constraint check for "stdcore[1]" (node "0", core 1):
  Stack available:   0x0000f9bc,   used: 0x000000d0 .  OKAY
  Threads available:          8,   used:          1 .  OKAY
  Timers available:          10,   used:          0 .  OKAY
  Chanends available:        32,   used:          1 .  OKAY
    Constraints checks PASSED.
Constraint check for "stdcore[2]" (node "0", core 2):
  Stack available:   0x00009a18,   used: 0x00007c18 .  OKAY
  Threads available:          8,   used:          8 .  OKAY
  Timers available:          10,   used:          5 .  OKAY
  Chanends available:        32,   used:         27 .  OKAY
    Constraints checks PASSED.
Constraint check for "stdcore[3]" (node "0", core 3):
  Stack available:   0x0000f9bc,   used: 0x000000d0 .  OKAY
  Threads available:          8,   used:          1 .  OKAY
  Timers available:          10,   used:          0 .  OKAY
  Chanends available:        32,   used:          1 .  OKAY
    Constraints checks PASSED.

[phalt]

I've edited your post to stick the code inside the [ code ] brackets.

It is easier to tell the text from the code that way.