Page 1 of 1


Posted: Wed May 15, 2013 2:45 pm
by sam76
Hi !

One day, One problem.

Today I look for writing a Gfx driver for my ssd1322 Oled display.

May be I say bullshit but this is what I have understand about the display :
- The display have a 4 bpp depth, so I need to have 2 pixels for sending one data byte.
- Worst : Columns are addressing 4 by 4 (May be it is configurable at init ?), so I need to have 4 pixels for sending.

This is what I have written for testing the 2 pixels 'frame buffer' :

Code: Select all

void gdisp_lld_draw_pixel(coord_t x, coord_t y, color_t color) {
//We need to send 2 pixel at a time for 4 bpp depth
//So impair pixel must be kept for sending with the next one (the pair pixel associate with this one)

        static waiting_pixel;
        static waiting_pixel_x;
        static waiting_pixel_y;
        static waiting_pixel_color;

                if (x < GDISP.clipx0 || y < GDISP.clipy0 || x >= GDISP.clipx1 || y >= GDISP.clipy1) return;

        //if imppair pixel
        if ( x&0x01 )
                setviewport(x, y, 1, 1);

                if (!waiting_pixel)
                        waiting_pixel_color = 0;
                write_cmd1(RAMWR, ( (waiting_pixel_color<<4) & 0xF0) | ( color & 0x0F) );

                waiting_pixel = 0;
        else    //else impair pixel
                //if we have one pixel waiting but actuel pixel is not the pair
                // we send the last pixel with a black associated impair pixel
                if (waiting_pixel)
                        gdisp_lld_draw_pixel(waiting_pixel_x + 1, waiting_pixel_y, 0);

                //Store the new impair pixel
                waiting_pixel = 1;
                waiting_pixel_x = x;
                waiting_pixel_y = y;
                waiting_pixel_color = color;


I can have a problem and erase some pixels with this algorithm.
For 4 pixels, it will be more compicated and the possiblity of losing of pixels grown.

The only way I see is to store ALL unfinished group of 4 pixels. and flush them at the end. It is a fractionned frame buffer. In the worst case, I will use a complete frame buffer of 8ko (256x64/2)

I heard about ccm Ram, can I store this to ccm ? Is ChibiOs use ccm ?

Do you see another method ?

Re: SSD1322

Posted: Sun May 19, 2013 1:35 pm
by Tectu
After the talk on IRC, do you still need help here or did you get it working in the meantime?

And yes, there's a linker script to use the CCM memory. It's already in the Makefile of the F4 Discovery demo - you just have to uncomment it and comment out the other. But I've never used it myself.

~ Tectu

Re: SSD1322

Posted: Thu Jun 13, 2013 3:07 am
by inmarket
Sorry for the delay in answering this. I didn't see it earlier due to my work load.

Take a look at the Nokia6610ge8 driver. It is a SPI 12 bit per pixel (4 bits per color component) driver. It supports that packing and unpacking that is required by the driver. Use that as your template on how to handle packing.

Note that draw_pixel() may be called with non-adjacent pixels so you cannot just save 1 pixel and wait for another pixel to complete the byte of data. Draw pixel needs to support drawing a singular non-adjacent pixel. If your controller doesn't allow this then you either need to memory map the display buffer (not good for low RAM processors) or use an internal read-pixel call to get the adjacent pixel before updating it.

Not that area fills and blits can be optimised to be more efficient just as it is for the Nokia6610Ge8 driver.