Jump to content

remon

Members
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Which part of the code would be helpful to you? The entire project is quite extensive. I've added the display driver code to this post, since you referred to it in a previous post. gdisp_lld_ST7586S.c board_ST7586S.h
  2. Sorry for the late reply, I was busy last week. I do have a debugger, however it doesn't have support for freeRTOS threads, so I can only see the current active thread. I could setup traces to check but this will take some time. I basically have one high priority thread that is called when data from an accelerometer is available (50 Hz). When the data is received it increments a counter by one and calls gwinSetText to update the value on the screen. Since I don't want the LCD to refresh 50 times a second, I've set the GDISP_NEED_TIMERFLUSH option to 1000ms. However the counter is only incremented once a second, the same rate as the framebuffer flush, indicating that the high priority thread is blocked by the flushing. When I set the flush timer to 500 ms the counter also increments twice as fast. I'm using the freertos api to create threads not the gfxThreadCreate function, but the GOS also calls the freertos function, so I see no problem here.
  3. I'm running freertos 9 as the underlying system.
  4. I enabled the 'GDISP_NEED_TIMERFLUSH' option to flush every 500 ms which works fine. However the 'gwinSetText' still blocks the high priority thread until the flush has been performed. Furthermore, I don't see how this problem could be related to the display driver code.
  5. Hi, My display controller requires me to flush the entire framebuffer to the controller in order to update the display. To limit the consumed resources, I have a low priority thread that will flush once a second. However, when I call the 'gwinSetText' function from a higher priority thread it seems to block until the framebuffer has been flushed. Is there any way to prevent this behaviour?
  6. remon

    Toggle driver

    I'm trying to get the toggle driver to work however, when compiling I get the following error. I did implement the ginput_lld_toggle_board.h board file and included the driver path in the compiler options. /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c: In function '_gwidgetInit': /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c:368:26: warning: implicit declaration of function 'ginputGetMouse' [-Wimplicit-function-declaration] geventAttachSource(&gl, ginputGetMouse(GMOUSE_ALL_INSTANCES), GLISTEN_MOUSEMETA|GLISTEN_MOUSEDOWNMOVES); ^ /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c:368:41: error: 'GMOUSE_ALL_INSTANCES' undeclared (first use in this function) geventAttachSource(&gl, ginputGetMouse(GMOUSE_ALL_INSTANCES), GLISTEN_MOUSEMETA|GLISTEN_MOUSEDOWNMOVES); ^ /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c:368:41: note: each undeclared identifier is reported only once for each function it appears in /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c:368:64: error: 'GLISTEN_MOUSEMETA' undeclared (first use in this function) geventAttachSource(&gl, ginputGetMouse(GMOUSE_ALL_INSTANCES), GLISTEN_MOUSEMETA|GLISTEN_MOUSEDOWNMOVES); ^ /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/ugfx_2.5/src/gwin/gwin_widget.c:368:82: error: 'GLISTEN_MOUSEDOWNMOVES' undeclared (first use in this function) geventAttachSource(&gl, ginputGetMouse(GMOUSE_ALL_INSTANCES), GLISTEN_MOUSEMETA|GLISTEN_MOUSEDOWNMOVES); ^ make: *** [ugfx/subdir.mk:23: ugfx/gfx_mk.o] Error 1
  7. remon

    Write_data

    Thanks for the information, I managed to get the driver working.
  8. remon

    Write_data

    Yes, but I'm still a bit confused about the order in which the data is stored in the framebuffer( i.e. which bit relates to which x,y position).
  9. remon

    Write_data

    The ST7586 controller column address is 2 pixels wide. Therefore, when the gdisp_lld_draw_pixel() function is called, I can't simply draw only one pixel since the information on the neighbouring pixel will be lost. Unfortunately it is not possible to read from the controller ram, so I think I have to keep a buffer of all the pixels on the display.
  10. remon

    Write_data

    Hi, I'm writing a driver for my lcd screen (ST7586 IC) however it requires a strange frame format. The spi transmission is as follows D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 P1 | P1 | x | P2 | P2 | x | P3 | P3 where P1, P2, and P3 are the pixels represented by a 2 bit value where a 1 on both bits turns the pixel on and a 0 turns it off. After this the column counter increases by two, so that the last pixel of the previous transmission is the same as the first pixel of the second transmission. I wanted to implement this in the "write_data" function of the driver template, whoever I'm having issues understanding the format of the framebuffer (RAM(g)), e.g. how to the data is related to the x,y position. I tried looking on the wiki and the api docs, however is was unable to find the format. Regards, Remon
  11. Hi, I'm trying to compile uGFX on a NXP Cortex M0+ microcontroller using freeRTOS, however when compiling I get the following error: Building file: ../src/gwin/gwin.c Invoking: MCU C Compiler arm-none-eabi-gcc -DDEBUG -D__CODE_RED -DCORE_M0PLUS -D__MTB_BUFFER_SIZE=256 -D__USE_ROMDIVIDE -D__USE_LPCOPEN -D__LPC11U6X__ -D__REDLIB__ -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_board_nxp_lpcxpresso_11u68/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/freertos/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc" -O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m0 -mthumb -specs=redlib.specs -MMD -MP -MF"src/gwin/gwin.d" -MT"src/gwin/gwin.o" -MT"src/gwin/gwin.d" -o "src/gwin/gwin.o" "../src/gwin/gwin.c" In file included from ../src/gwin/gwin.c:13:0: ../src/gwin/../../gfx.h:31:22: error: expected identifier before numeric constant #define FALSE 0 ^ /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc/lpc_types.h:50:15: note: in expansion of macro 'FALSE' typedef enum {FALSE = 0, TRUE = !FALSE} Bool; ^ make: *** [src/gwin/subdir.mk:80: src/gwin/gwin.o] Error 1 There seems to be an conflict between the FALSE define in the uGFX and the chip library, Any thoughts on how to solve this? Kind regards, Remon
×
×
  • Create New...