aeroman

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.

Hi, the buffer used for this driver (whole screen 400*240 pix) weighs a lot (12482 bytes). Is it possible with µGFX to work with a reduced screen area for the buffer ? thanks

Hi, the buffer used for this driver (whole screen 400*240 pix) weighs a lot (12482 bytes). Is it possible with µGFX to work with a reduced screen area for the buffer ? thanks

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

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.

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

Hi, it seems you missed #define GDISP_NEED_AUTOFLUSH TRUE in gfxconf.h

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;

Hi @inmarket, nothing has broken after changes you've done.

Hello @Joel Bodenmann thank you for your reply, i replaced the cmdBuffer by write_cmd, write_cmd2 functions (at most double bytes commands) and added the board template file. A little video to show the screen : https://www.youtube.com/watch?v=hBitl602EYc UC1610_2.zip

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