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.

Thanks, Joel. The GDISP_NEED_MULTITHREAD option is already configured as TRUE in the gfxconf.h file. For now, to solve the problem, I´ll implement the consumer/producer scheme to guarantee "serial" access to the console, with only the consumer accessing this widget. I´m going to replace, then, the gwinPrintf () calls with xQueueSend() calls, to send the desired messages to the console. Thanks.

Hi, I´ve doubts about the console widget with in a project that uses FreeRTOS. There are calls to the gwinPrintf() function in more than one thread. When this function is called from a timer callback function and simultaneously in other thread, the console´s content is jumbled. Sometimes, even the characters are not correctly redrawn in such case. Is this behavior expected? Thanks.

Hello, Thanks for all for the replies. I'm using the SSD1963 driver. I solved it simply changing the orientation from 270 to 90 degrees, keeping the screen also in a portrait orientation. Even so, I will try the work around suggested by inmarket. On some cases, it may be necessary.

Hi, I´m trying to draw a bmp image stored in the microcontroller´s internal Flash. With the display in native orientation, the image is drawn correctly. However, I need to use the screen in PORTRAIT orientation. ( GDISP_ROTATE_270 ). After I call the function to change the orientation, the image is drawn incvorrectly. All other functionality still runs OK. Thanks in advance.

Joel, thanks for your reply. It was a problem in my read_xyz() function. Sometimes, after releasing the touchscreen, my hardware was reading values significantly different when compared with the values generated with the key pressed. When this happens, the problem occurs. I solved it easily in firmware.

Hello, I'm using a virtual keyboard in a project. It's working OK, but sometimes the whole keyboard widget (not only the pressed key) is redrawed. When this happens, the ASCII character (c[0]) returned by the geventEventWait() function is wrong. As long as only the pressed key is redrawed, the returned ASCII code is always correct. I've implemented my own mouse board file, wich included the read_xyz() function. It was not clear to me when this function should return TRUE or FALSE, so until now it returns always TRUE. Can this perhaps cause a different behavior sometimes? Thanks.

Hello, Joel. It´s finally working. I have made the following changes on my system: in gdisp_lld_config.h, changed the pixel format from GDISP_PIXELFORMAT_RGB565 to GDISP_PIXELFORMAT_RGB888. in gdisp_lld_SD1963.c, changed PIXEL DATA INTERFACE configuration from SSD1963_PDI_16BIT565 to SSD1963_PDI_8BIT (in function gdisp_lld_init()). In the same file, gdisp_lld_write_color() function now calls the board function write_data() 3 times sequentially, shifting the color parameter appropriately on each call (R, G, and B). My board functions, write_index() and write_data() remains unchanged, writing a single byte at a time. Grateful for your immediate reply, and congratulations for that very nice and powerful framework.

Joel, I´m doing only one write cycle (as an 8-bit value) in my write_index() and write_data() functions, even being the bus between my LPC1768 and the SSD1963 only 8-bit wide. Do you think this can be wrong? Must I write the high and low portions of the received value in 2 write cycles (high an low bytes)? Making so, how can I know when I must write the received value in only one cycle (command, for example) or 2 cycles (pixel data)?

Hello. The display I´m using is based on the SSD1963 controller, with an 8-bit data interface to the host processor (ARM Cortex-M3). When I draw pixels directly to the display, using some basic routines I wrote, the colors were OK. However, calling the uGFX functions, the colors don´t seem to be right. I think, accordingly to the topic bellow, the problem is that the current SSD1963 driver don´t support the 8-bit data interface. I´ve seen, by reading back the configuration registers from the controller, that after calling gfxInit() my previous configurations have been modified. For example, the pixel data interface I´ve previously configured to 0x00 (8-bit) is changed to 0x03 (16-bit 565 format). Have someone already worked on an 8-bit driver for the SSD1963 controller? Thanks!!

Hi, I´m using a custom board, running FreeRTOS. The uGFX has been ported to this board without any problems, using FreeRTOS as the OS in the gfxconf.h file. So, it was already possible to draw some objects, like lines, circles, printing strings, and so on. Now, I´m trying to draw images on the display, and have enabled the GFILE_NEED_FATFS in the configuration file. However, the compiling process returns errors, saying the disk access functions (disk_initialize, disk_ioctl, etc) were undefined. Is there an easy way, perhaps a step-by-step tutorial, to use the uGFX image resources calling the FreeRTOS FAT-SL API functions? I imagined an adapter layer, who calls the FreeRTOS FAT functions and is called by the uGFX library functions. Thanks.