Waylander

i tried debugging the code and now i know what is the cause. when ugfx comes to a moment to draw the text on calibration screen, display driver calls aquire_bus as 4 times before this moment but after calling gfxMutexTake MCU goes into infinite loop. it actually fails in queue.c in this code block: line 1444/* Check to see if other tasks are blocked waiting to give the semaphore, and if so, unblock the highest priority such task. */ if( listLIST_IS_EMPTY( &( pxQueue->xTasksWaitingToSend ) ) == pdFALSE ) { if( xTaskRemoveFromEventList( &( pxQueue->xTasksWaitingToSend ) ) != pdFALSE ) // this is the last line executed { queueYIELD_IF_USING_PREEMPTION(); } else { mtCOVERAGE_TEST_MARKER(); } wtf is going on? i'm too newbie to understand.. this function above calls this block of code in tasks.c line 3000 /*This function assumes that a check has already been made to ensure that pxEventList is not empty. */ pxUnblockedTCB = ( TCB_t * ) listGET_OWNER_OF_HEAD_ENTRY( pxEventList ); configASSERT( pxUnblockedTCB ); ( void ) uxListRemove( &( pxUnblockedTCB->xEventListItem ) ); // fails here why it removes something, while it is supposed just to take mutex? and this last line goes into list.c and calls this line of code: List_t * const pxList = ( List_t * ) pxItemToRemove->pvContainer; and just after this it goes into infinite loop. i think it is some sort of exception, but i don't know which. where can i look for a type? but freertos's hooks for malloc_failed and stackoverlow do not get called, but they should be called if this occurs, right? i've looked at this pxItemToRemove in the debugger and all the fields of this struct are zeroes, so it means this pointer is pointing into wrong memory area? but why???

nothing is working neither with freertos mutex nor with ugfx's one. currently i've tested completely empty touch driver (even no mutex usage) and a display driver that uses mutexes. and calibration screen is drawn without text. if i remove mutex usage from display driver (touch driver still empty), calibreation screen is drawn fully. this is insane! two function calls just break everything! and most interesting thing that gui works fine (at least it draws fine), buttons and labels.

thanks for the tip! never thought that there is built-in mutex wrapper in ugfx. But i don't understand how to use it. For example i have two drivers in separate .c files. In which there are lots of functions and also in each there are aquire_bus and release_bus functions. So i just need to place gfxMutexEnter and gfxMutexExit calls accordingly (and gfxMutexInit somewhere in init code of main.c)? And that's all? Code after gfxMutexEnter will be suspended until mutex is available? No timeouts, no loops?

can someone suggest a proper way to use mutex in freertos to share an lcd bus between display and touch driver? This variant of aquire_bus function does not work properly (calibration screen only fills with color, but no text is drawn). while (xSemaphoreTake(lcdBusMutex, MUTEX_DELAY) != pdTRUE) { gfxYield(); } Without mutex and empty touch driver calibration screen is drawn fully. Seems like inside ugfx something goes wrong because of tasks being paused by freertos (because of failed mutex take) or something like this.

well, i'm again stuck with conflicting display and touch driver. but now at least i know that when i remove while (xSemaphoreTake(lcdBusMutex, MUTEX_DELAY) != pdTRUE) { gfxYield(); } from code, it works (text and cross is visible). but if i get the actual code for input driver back, it prevents calibration screen to be fully drawn (top of display is filled with blue color and there is part of "Calibration" text), because touch driver uses same pins as display driver. but how do i use mutex right here? i've tried without gfxYield() (do i need it at all?) and it made no difference.. the code releases the mutex when job is done. but why text and crosses aren't drawn, after the screen is filled blue?

now i was trying to figure out what setting actually fixed the issue and strangely they aren't concerned ugfx ones. they are from freertos config: configUSE_IDLE_HOOK 0 configUSE_TRACE_FACILITY 1 configQUEUE_REGISTRY_SIZE 4 very strange! everything in linker script and in ugfx, all the heaps and stacks are default! But with those settings i get that holy cross on the screen, lol. Haven't checked yet whether touch works.

lol. while i was tinkering with stack and heap sizes of freertos and ugfx and linker script, i 'fixed' everything. the thing was that i was still calling calibration manually, while START_RAW was already disabled, and that produced incomplete output (but why tho?). when i've noticed it, i've commented out the manual call and SAW THAT CROSS!!! touch driver is still empty, so i can't press it for now. will write here later. anyways, thanks for a tip in another post where you've written about stackoverflows. btw may be you can suggest some values for stack and heap? i'm not going to use images. Just flat gui (but complex tho).

Hi, i'm using 2.8 release, that is located in download section. It is said in its release notes that it has that reworked freertos support. May be i'd better downgrade then?

When i've set GFX_EMULATE_MALLOC there appeared only a part of "C". Changing heap and stack size in gfxconf.h makes no difference tho.

I've viewed other posts and it seems like we have similar issues. May be even because of stack or heap. Is 20kb RAM enough for ugfx using gdisp, gwin, widgets and touch?

Hmm.. Do you use touch input here? May be it is connected with my issue, because sometimes my lcd also shows garbage.

I'm having strange issue while trying to use ugfx with freertos. In prev forum post i've asked about ugfx and shared pins and i got this issue. But i thought it was because of wrong driver code (i'm using custom disp and touch drivers), but as i understood now, it is because of freertos. I just took the freertos config from the demo project that i've downloaded from this site and it changed the output of my project. Previously it was not outputting the text in calibration screen, an with other freertos config, it outputs "Calibrati" and top of "o". I totally do not understand what is going on. Moreover my display behaves strangely, it is not possible to reflash MCU more then once (i need to constantly power off the lcd and reconnect MCU to st-link and only then power on the lcd) and sometimes it outputs noise and artefacts. It is totally not because of malfunction lcd or mcu, while i currently also studying another graphic lib and it works flawlessly (i even managed to get touch working there). Seems like i'm using ugfx in the wrong way, but i don't know where to look for. BTW: current touch driver is empty and does not influence the bus.

may be you can check the code of input driver? because i'm not sure if i've done it right. https://pastebin.com/57sTTdW4

Yeah, something seems very wrong with using this mutex. Can you confirm that i'm using it right with ufgx? My drivers have such aquire_bus code: while (xSemaphoreTake(lcdBusMutex, MUTEX_DELAY) != pdTRUE) { //MUTEX_DELAY = portTICK_PERIOD_MS = 1ms gfxYield(); } So i'm using here freertos's xSemaphoreTake which has maximum wait parameter, after which (i think) it suspends the process. And it returns pdTRUE is mutex was taken. But if it was not, i call gfxYield() as you suggested. Today i saw another 'cool' stuff on calibration screen, it was outputing garbage of pixels instead of solid color, so i believe there is some fight between disp and input drivers. Btw if i disable calibration screen, my test screen with button (which is unfunctional at the moment, because of unfunctional input driver) and label, that is updated continuously by task, runs flawlessly. Input driver is still active tho, not calibrated.

I've tried setting caption background to green and i saw it, but text is not there. Font seems to be loading fine, the font variable is filled with some data. And i don't know how this calibration should function, but when i press screen few times, nothing happens, but i think it should proceed, after some inputs? And crosses aren't visible too. So the only thing that is drawn is caption background. I'm still not sure whether my touch driver code works properly for ugfx to understand input data, but i believe that it should at least return proper z value, so touches should be recognizable.

Me again, lol. Mutex did the job (partially), now calibration screen is entirely drawn (all filled blue), but there is no text present. The function that should draw that text is called actually, but displays nothing. That is strange. But if i disable the calibration screen, add a lable that is updated by separate task every tick, so i see that label is updated and touchscreen is polled as expected (every 25 ms), so i assume that there is no deadlock. But why calibration screen fails? What could be the reason? Color is filled, but no text drawn, while the function, that draws "Calibration" string is called.

I've looked into implementing aquire_bus and release_bus in the gmouse_lld_MCU_board.h file, but they aren't appear to be called and there is no setting i see that can enable them and it seems to me even in ginput_driver_mouse.h there is nothing about them. What is the right way to do it? Should i just call them manually from read_xyz() ? Actually may be i need to take and give mutex in the beginning and end of read_xyz() function? Or there is already implemented way, but i don't see it?

Hi and thanks for the tip, seems like i misunderstood bus_aquire and bus_release, i just switch lcdcontroller's CS pin here. But what should i do more? I failed to find board examples, so i made it from scratch just using the template file. May be you can point me to the example of MCU touch driver (would be cool if it uses stm32 SPL)? Because i'm also not very confident if the values that i return from driver are correct for ugfx input subsystem. You mean that ginput driver (that MCU driver) should also have bus_aquire and bus_release functions? But what should they contain? This topic is unknown for me. UPD: may i use freertos's mutex in both lcd's bus_aquire and touch bus_aquire? I mean will it work? Because i don't know whether drivers are separate tasks or not. Will calibration routine be suspended if touch driver fails to get mutex? Will normal touch polling routine be suspended too, if it fails to get mutex? Won't this suspension break the functionality of ugfx?

Hello all! I'm having hard time with ugfx, because i'm newbie in C world, but i've already managed to create a driver for my lcd (because it is unsupported) and even run ugfx under freertos! But i have an issue with touch support. My lcd board has no touch controller, it is raw 4 wire resistive touch panel. And what is important (i believe) that those 4 wires are shared with lcd controller (2 data lines and 2 control pins, controller is in parallel mode). And without calibration everything works (except that i can't click anything), but when calibration starts, display fills for about 30 lines with blue and a top of 'C' letter is visible too in the drawn area. I believe that calibration starts before screen is redrawn. But i don't know how to resolve this. Does ugfx support such cases when touch panel wires are shared with lcd controller?