Jump to content

aeroman

Members
 View Profile  See their activity

  • Posts

    11

  • Joined

  • Last visited

 Content Type 

Posts posted by aeroman

  1. Sharp LS027B7DH01 display driver

    in Support

    Posted

    Thank you @inmarket for these explanations,

    i've seen the ED060SC4 driver as buffer size drop example.

    But this type of displays (sharp MiP) have limitation on memory writes frequency (max 20 Hz) and i suppose flushing the reduced buffer to display memory on driver side  when it's full may bring to not respect that requirement, using gdisp side timer flush seems more suitable.

    At this time, with my limited understanding of how gdisp drawing operations works, i don't see how to achive this driver with a reduced buffer.

    It's not a problem since my application can survive (for now) with this heavy buffer.

    Looking on these interresting (from a power consumption point of view) displays from "Japan Displays" https://www.j-display.com/english/product/reflective.html it would be nice to find a solution.

  4. Sharp LS027B7DH01 display driver

    in Support

    Posted

    Hi,

    just to share this gdisp driver for Sharp LS027B7DH01 memory in pixel display, monochrome 400x240 LS027B7DH01_driver.zip .

    I've tweak gdisp.c (line 18) to add choosing the logo color ability in gfxconf.h : 

    #ifndef GDISP_STARTUP_LOGO_COLOR
    #define GDISP_STARTUP_LOGO_COLOR        GFX_WHITE
#endif

    The driver works but is not extensively tested for now.

    ps : i was unable to upload the file, the web page returned " There was a problem uploading the file." or "-200" messages. So here a google drive link :

    https://drive.google.com/drive/folders/1kaTg_je2_ncuifPSORbFXQg_BW9XKjqj?usp=sharing

  5. STM32L1xx UC1610

    in Support

    Posted

    Hi,

    i reproduced this bug and it seems related to the gdisp_lld_flush() function when writing pages segments from RAM(g) to display ram :

    with the actual  y1 <= y2 in the "for" loop, when y2 is not a multiple of UC1610_PAGE_HEIGHT, the last segment is not writed to display ram.

    I found this solution : for loop condition based on the end address of the flush window : 

    		// write each page segment from RAM(g) to display RAM
		for (c = RAM(g) + xyaddr(x1, y1) ; c < RAM(g) + xyaddr(x2, y2) ; c += GDISP_SCREEN_WIDTH) {
			write_data(g, c, cx);
		}

    it seems to work correcly.

  6. STM32L1xx UC1610

    in Support

    Posted

    hi @quipu,

    for the "colors", i use 0, 1, 2, 3 (gray0 .. gray4) when calling gdisp drawing functions.

    the COM number is limited to GDISP_SCREEN_HEIGHT - 1 by the UC1610_SET_COM_END (CEN register) command in the init sequence.

    for the rotation problem, the way used by the driver is to mirror the ram to seg mapping for X axis (datasheet pages 36..38) and on your screen this produces some ram mapped with not connected seg (128 seg < 160).

    A workaroud might be to adapt the window function in gdisp_lld_flush() :

            // set window to fill
            cmdBuffer[0] = UC1610_SET_WINDOW_PROGRAM_ENABLE | 0;    // before changing boundaries
            cmdBuffer[1] = UC1610_SET_WP_STARTING_CA;
            cmdBuffer[3] = UC1610_SET_WP_ENDING_CA;
            cmdBuffer[5] = UC1610_SET_WP_STARTING_PA;
            cmdBuffer[6] = y1 >> 2;
            cmdBuffer[7] = UC1610_SET_WP_ENDING_PA;
            cmdBuffer[8] = y2 >> 2;
            cmdBuffer[9] = UC1610_SET_WINDOW_PROGRAM_ENABLE | 1;    // entering window programming
            switch (g->g.Orientation) {
                default :
                    cmdBuffer[2] = x1;
                    cmdBuffer[4] = x2;
                    break;
                case GDISP_ROTATE_90 :
                    cmdBuffer[2] = x1 + UC1610_SEG_NUMBER - UC1610_SCREEN_WIDTH;
                    cmdBuffer[4] = x2 + UC1610_SEG_NUMBER - UC1610_SCREEN_WIDTH;
                    break;
                case GDISP_ROTATE_180 :
                    cmdBuffer[2] = x1 + UC1610_SEG_NUMBER - UC1610_SCREEN_WIDTH;
                    cmdBuffer[4] = x2 + UC1610_SEG_NUMBER - UC1610_SCREEN_WIDTH;
                    break;
            }

    where UC1610_SEG_NUMBER == 160 and UC1610_SCREEN_WIDTH == 128

    I suppose there is a better way to process rotation ...

  8. crash initializing µGFX (UC1610 driver)

    in Support

    Posted

    Hi,

    i'm not sure but as i understand, the problem comes at the driver side when GFX_OS_HEAP_SIZE == 0 then gfxAlloc() return malloc() and PRIV(g) contained data are not initialized to 0 before the first flush. 

    Conversely when GFX_OS_HEAP_SIZE is defined, the heap where gfxAlloc() allocates PRIV(g) is  declared in gos_x_heap.c as static char  which appears in .bss ram segment, so data are initialized to 0 and gfxInit does not crash.

    Maybe it is necessary to force PRIV(g) data initialisation, just after memory allocation :

    g->priv = gfxAlloc(sizeof(UC1610_Window) + GDISP_SCREEN_WIDTH * GDISP_SCREEN_HEIGHT / UC1610_PAGE_HEIGHT);
    PRIV(g)->x1 = GDISP_SCREEN_WIDTH;
    PRIV(g)->y1 = GDISP_SCREEN_HEIGHT;
    PRIV(g)->x2 = -1;
    PRIV(g)->y2 = -1;

  11. trying to write a gdisp driver for UC1610

    in Support

    Posted

    Hello,

    thank you for your work and providing uGFX as open source.

    I'm trying to write a gdisp driver for UC1610 controller coming with EA-dog xl 160 lcd screen with the help of driver exemples (UC1601s and UC8173) from git repository.

    For now, the driver works on stm32F4 and i2c, but for sure, there are many improvements to do.

    Do you have advices helping to improve the driver ?

    thanks,

    Bye

     

    dogxl160-7e-4693.pdf

    uc1610_v1_36.pdf

    UC1610.zip

×
×
  • Create New...