Rafael Zingler

Hello @Joel Bodenmann. No, I didn't do it. But as I mentioned, now it is already working (after changing the GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE directive to 64). Thanks for all your support!

@inmarketWhen the crash happens, there is a first allocation of 72 bytes, and a second one of just 2 bytes.

@Joel BodenmannI didn't test the Win32 port. But yes, I will try ASAP to provide more information (including part of the code) that triggers the crash. Thank you!

I tried calling pvPortMalloc(2); directly from my startup code and it didn't hang.

Hi all. Defining the GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE in 64 (defaults to 32) solved my problem.

Hi, Joel. Thanks for your fast response. I'm using a LPC1768 (Cortex-M3) microcontroller and Keil uVision 5. It is the pvPortMalloc() function that is causing the fault (attached), spe cifically after updating the xFreeBytesRemaining variable.

Hello. I was able to make SSD1306 work (logo is shown, display API is working well). However, when I try to open a image from Flash memory, I'm getting a HardFault, caused by FreeRTOS memory allocator (using FreeRTOS heap4.c). The debugger shows me that the failure happens on the second call of gdispImageAlloc function (image attached): in this second call, the size to be allocated is 2 bytes. Could this be leading to a memory corruption due to unalignment? It is also important to mention that it's my fisrt time dealing with monochrome BMP's on uGFX. When I try with a 24 bit BMP, the program doesn't stuck, and both gdispImageOpenMemory and gdispImageDraw return SUCCESS, despite of no image data being shown on the display. Any idea of what could be wrong? Thanks in advance.

Hi all, I have an ImageBox in a container. The image related to this ImageBox needs to be loaded from a memory card. GFILE is already working. My doubt is: is there a way to make the image be drawn automatically everytime the container is shown, or should I draw the image manually in this case? Thanks in advance.

Hi all, the option GDISP_NEED_AUTOFLUSH is defined as TRUE in my configuration file. Thus, as expected, my board_flush() function is called automatically after the drawing operations. However, I have a doubt about the behavior of the library when this option is enabled: when I call the function gdispFillArea, for example, the board_flush function is called just once, at the very end of the drawing process. But when I call the gdispDrawImage function, the board_flush function is called many times during the drawing process. Is this the library's default behavior with GDISP_NEED_AUTOFLUSH enabled? For my case, ideally the board_flush should be called just once, after the whole image has been drawn (same behavior as with the gdispFillArea function). I would like to know if there is something else I need to adjust in my configuration file, to make the flush function be called just after the drawing process has finished. Any help is welcome!!

Hi, thanks for the reply. It's already working with the GDISP_NEED_TIMERFLUSH enabled (100 ms). Very nice resource that I did'nt know yet!! Thank you very much!

Hi, I'm currently using the frame buffer driver in a project with the LPC1788 microcontroller (which has an embedded LCD controller). I've implemented double buffering in the system, to eliminate the undesirable tear effect that appeared on the screen every time the driver put new content in the buffer. Thus, when the driver is pointing to buffer A, buffer B is being shown on the screen, and vice-versa. The operating system (enabled in gfxconf.h) I'm using is FreeRTOS. Another important thing was the need of a "policy" to decide when system must switch the buffers. For this, the option GDISP_NEED_AUTOFLUSH was set in the gfxconf.h file. In this way, I've implemented the board_flush() function, which starts a software timer. Thus, a little time after driver finishes writing, the timer callback function is called, and in the callback function the buffer switching is made (along with the data copy from the front to the back buffer). Basically, the idea is a "driver writing timeout", which makes the callback function be called, and inside it, the buffer switching. The problem I'm facing now is related to the moment on which the driver writes new data after finishing the last writing. If my callback function is still copying data from one buffer to the other and the driver writes new data, there is a data corruption in the "back buffer". I would like to know if anyone has an idea of how to solve this, or had been facing this same situation. Thanks in advance!!

Hello, I would like to know how to use the uGFX library in the best way for what I need to do. The screens I need are numbered below: 1) Idle state: In this state, a console with messages is displayed at the bottom of the screen. At the top of the screen, images are alternately displayed. These images are stored on an SD card. 2) The screen is similar to the one at state 1, but with an extra image. This extra image (smaller than the one at the top of the screen) is displayed between the console and the top image. 3) There is a virtual keyboard at the bottom of the screen, and some components (a label, and a string or text box) to display the password (asterisks) typed by the user through the virtual keyboard. 4) A tabset is displayed. This is the equipment menu. Every page related to this tabset implements some kind of configuration and has its own set of components, like labels, text boxes, radio buttons, check boxes, and so on. When the equipment is in state 1 (idle) and a barcode reading is performed, the equipment goes to state 2. After a few seconds, it returns to state 1. When the equipment is in state 1 (idle) and the user touches the screen, the equipment goes to state 3. When the user presses "OK" on the virtual keyboard, the equipment goes to state 2, and, after a few seconds, it returns to state 1. When the equipment is in state 1 (idle) and a physical key on the board is pressed, the equipment goes to state 5 (menu). Any suggestions on how to organize the screens in the best way to use the uGFX library? Thanks in advance.

I´m using Keil uVision 5 IDE with de default compiler. Below are the build flags for optimization level 0: -c --cpu Cortex-M3 -g -O0 --apcs=interwork --split_sections -I ../Biblioteca/ARM/FreeRTOS_10.0.0.1/Source/include -I ./application -I And those of optimization level 2, with the option "Optimize for time" enabled: -c --cpu Cortex-M3 -g -O2 -Otime --apcs=interwork --split_sections -I ../Biblioteca/ARM/FreeRTOS_10.0.0.1/Source/include -I ./application -I When I talked about startup, I meant that is when writing is done inside the FreeRTOS initialization task (vApplicationDaemonTaskStartupHook function). In this case, the console fails to write text at the second line with optimization level 0. Normal operation means using the console within other FreeRTOS tasks (it then works OK, no matter the optimization level). Thanks.

Hi, I´m working in a project that uses a console to facilitate the process of displaying messages on the screen. I´m using a compiler optimization for make the screen update faster. When I use the optimization, the console works OK. Without optimization, only the first line of the console is written, the second line is left blank. Could the slower update of the screen cause this behavior? This problem only happens when I use the console during startup. During normal operation, the problem does not occur, even without using compiler optimization. But using optimization, it never happens. Thanks in advance.

Hi, I´m working on a project where I have a console on the main screen. When the user touchs the screen, I draw a virtual keyboard at the same place the console was on the screen, so that the user can type a password. Sometimes, my program stops working, an when this happens, I see the console jumbled with the virtual keyboard on the screen. I´m not controlling the visibility of the widgets so that just one of them is visible. Could that be the problem´s origin (maybe the uGFX library is confused about the existence of two widgets on the same place simultaneously)? Thanks in advance.