joe714 / pixelclient

ESP32 firmware for PixelGW client
Apache License 2.0
11 stars 2 forks source link

HUB75E compatbilty and larger displays #1

Open TomForeman86 opened 1 month ago

TomForeman86 commented 1 month ago

I have this running on a p2 SMD1515 128x64 display with a HUB75E connector type and am having a couple of issues, is there a way to add support for the E pin on this display so that it outputs correctly? Also adjusting the conf for this display size to 128 * 64 prevents the firmware from booting.

TomForeman86 commented 1 month ago

20241020_143949.jpg

joe714 commented 1 month ago

There may be, but I don't have one to try. The main intention is for compatibility with the pixlet stack, which has an assumption of 32x64 all over the place.

Also FWIW, driving a 32x64 display and having room to store and decode a 15s webp image is pretty much the limit of the RAM on the stock ESP32-WROOM chips already, there's barely any RAM left over. It's 2kB per bit of color depth for a 32x64 display and the default is 7 bit, so 14k plus a little extra overhead for the DMA descriptors. 128x64 would be ~56kB, and there's nowhere near that much left right now even before you account for the increased webp animation size as well.

I've been looking at spinning a new driver board using the WROVER modules that have 8MB of PSRAM attached via SPI; the DMA buffer still has to come out of the main RAM but offloading the ~68k webp buffer to PSRAM should free up more room for the DMA buffer, but I haven't had time to get into it right now.

Dropping to 2 bit color depth and knocking a few kB off the webp buffer allocation might work in the short term, but you'd be severely limited by the size of the animations you could send. Some of the pixlet community apps already can go over 68k, hence my original desire to switch to the WROVER modules.

TomForeman86 commented 1 month ago

Thanks for pointing me in the right direction regarding the RAM, its now working although the colours are affected somewhat by changing colour depth (which cant be helped), had to make a few modifications to the pin definitions/signals for the extra E pin on this display, and an adjustment to scale the 32x64 image for a 64x128display.

// I2S Data Position Definitions // Upper half RGB

define BIT_R1 (1 << 0)

define BIT_G1 (1 << 1)

define BIT_B1 (1 << 2)

// Lower half RGB

define BIT_R2 (1 << 3)

define BIT_G2 (1 << 4)

define BIT_B2 (1 << 5)

define BIT_A (1 << 8)

define BIT_B (1 << 9)

define BIT_C (1 << 10)

define BIT_D (1 << 11)

define BIT_E (1 << 12)

define BIT_LAT (1 << 6)

define BIT_OE (1 << 7)

// Pin Definitions

define R1_PIN 21

define G1_PIN 19

define B1_PIN 18

define R2_PIN 5

define G2_PIN 17

define B2_PIN 16

define A_PIN 4

define B_PIN 2

define C_PIN 25

define D_PIN 15

define E_PIN 32

define LAT_PIN 26

define OE_PIN 27

define CLK_PIN 22

getpixel(const uint8_t* pix, int x, int y) { // Scale the coordinates down by 2 (as we are doubling the size) int scaled_x = x / 2; int scaled_y = y / 2;

int idx  = (scaled_y * 64 * 4) + (scaled_x * 4);

return ((uint32_t)valToPwm(pix[idx]) << 16) |
       ((uint32_t)valToPwm(pix[idx + 1]) << 8) |
       ((uint32_t)valToPwm(pix[idx + 2]) << 0);

}

i2s_parallel_config_t cfg = { .gpio_bus = { R1_PIN, G1_PIN, B1_PIN, R2_PIN, G2_PIN, B2_PIN, LAT_PIN, OE_PIN, A_PIN, B_PIN, C_PIN, D_PIN, E_PIN, -1, -1, -1 }, .gpio_clk = CLK_PIN, .clkspeed_hz = 20 1000 1000, .bits = I2S_PARALLEL_BITS_16, .bufa = bufdesc[0][0], .bufb = bufdesc[1][0], };

        if (rowAddress & 1)
            lbits |= BIT_A;
        if (rowAddress & 2)
            lbits |= BIT_B;
        if (rowAddress & 4)
            lbits |= BIT_C;
        if (rowAddress & 8)
            lbits |= BIT_D;
    if (rowAddress & 16) // This line handles the extra row address bit for HUB75E
        lbits |= BIT_E;

20241021_192722.jpg