inmarket

What i was saying with the text wrapping is that i am unsure how the text wrapping affects the vertical alignment. There are 2 solutions... 1. If you are using the gwin label widget you could write a custom draw for it that aligns it vertically how you want. There is already a right align custom draw in the code to demonstrate how this might be done. 2. Use the console widget (with history for data retention). It by default aligns from the top left.

It is hard to understand your question however I think your are asking how to display a log of data. Assuming my understanding of your question is correct and you are talking about text data then the best way is by using the console gwin widget.

I cannot answer the text wrapping problem. Joel will answer that. With regard to changing the orientation of text, this is actually computationally quite difficult requiring all sorts of different hinting and even sometimes special fonts. As uGFX is designed to be small this has not been implemented and probably won't in the short term as it requires extensive work on a complex font engine. There is however a workaround. If your display supports orientation changing you can change the orientation of the display, draw your text, and then change the orientation back. This works because uGFX strongly suggests for driver writers that orientation is taken to mean changing the drawing orientation rather than changing the mapping of the video ram to the display. When you draw with the changed orientation remember to alter the drawing coordinates to the new orientation. If you are running multithreaded drawing also take a lock during the series of operations to draw the rotated text to stop other threads drawing while your orientation is altered.

Although not specified above i am guessing that you are using the linux framebuffer. If so what that message is saying is that GDISP_PIXEL_FORMAT does not match the capabilities of the framebuffer linux driver for your machine. Try changing that macro in your gfxconf.h to match the hardware capabilities.

You need to get someone who can understand English better to help you with the instructions above. The instructions above have been clear and simple. We speak a limited range of languages and we run this forum in English. We do our best to help but we can't help where our words are not understood.

It looks like a problem with your cross compiler. The compiled code seems to be using a different c calling convention to the c library. Run some test cross compiles with simple hello world programs first to make sure your cross compiler is working. Also try it using the same compiler flags uGFX uses (that's why each uGFX compile prints the options first). You can also try compiling uGFX for your host machine. That will at least demonstrate that uGFX works. Note it is very important to do a "make clean" between each change in platform or options.

There are a couple of errors in your code that also may be causing your problem... 1. Don't use HAL_Delay. It prevents uGFX being able to respond to events. 2. The 2nd parameter to geventEventWait is a timeout. Specifing zero means to not wait for an event - just return one if there is one available. The error occurs if there is no event available - the function will return NULL. You are however dereferencing the result without checking for NULL first. The correct way to do what you are currently trying to do is to drop the HAL_Delay and the gfxYield and instead put 50 as the 2nd parameter to geventEventWait. Also check for NULL before testing the type. The other solution is to use TIME_FOREVER for the 2nd parameter (still dropping HAL_Delay and gfxYield). In that case you are guaranteed it won't return until it has an event and you won't have to check for NULL.

Also compare and contrast it with the demos/modules/gdisp/fonts_cryllic demo program.

There are previous forum entries on this topic. The issue is the uGFX does not handle overlapping windows optimally due to memory constraints. Instead it redraws conservatively which eventually results in the correct display but may result in multiple drawing passes (as you have seen). The previous forum posts discuss how to improve this performance using the sysvisible flags when it can be guaranteed there is a complete area overlap.

The browser text search capability is also helpful.

We officially haven't supported vs2015 yet however i believe others have used it. uGFX is designed to be portable so there shouldn't be any major problems.

Don't use gwinSliderGetPosition to get the position for your label as the final position has not been set yet (and won't be until you release). The position to use is available in the event itself.

There is another solution. UGFX supports putting the display into power down. If the ppwer control is written correctly in the driver that could be used to do exactly what you are after. In the application you would tell the display to power down and then to power up again. That would take care of the hardware reinitialisation. You would just then need to redraw the display.

If you are using GWIN there is gwinRefresh (or is it gwinRedraw). I think from memory that passing a NULL ghandle causes it to redraw the whole display.

If your display supports pixel read back it should be possible to write a routine that cycles through the pixels of the display and averages them using the gdisp api. Averaging in a 2x2 square or a 3x3 square should look reasonable. It would probably not be fast. Without pixel read back it is not possible to do it generically. It would be possible but complex for images but it would require altering the image decoder itself which would in turn require modification of the ugfx library itself.

If the c freerros functions are available then it should all just work when you use the c++ wrapper for other freertos calls. The hardfault that you got is likely related to something else. Debug that first before going to the trouble of writing a probably unneeded cpp freertos gos port.

Yes GINPUT drivers are required for most gwin objects as they actually interact with the user. The ones that don't are the base gwin object, the console object and the graph object. All others require a GINPUT driver.

This is a touch problem. What happens is that as the touch is being released or pressed many touch controllers give wildly inaccurate readings - including obviously your controller. If not detected and filtered correctly they give exactly the symptoms you are seeing. Do not use the controllers touch detected pin (if it has one). They are just too inaccurate. Instead use z values provided by the controller registers. There are plenty of other drivers to show how it is done. Please play with the touch demo as requested above. It will help you set the correct values in your board file to get reliable performance. Look particularly at the z value figures for touch detection and the jitter deltas.

Note: GFX_USE_OS_KEIL is for the Keil CMSIS operating system. This has nothing to do with the Keil IDE. The Keil CMSIS is provided as part of the Keil professional license.

There is a board file in your project for the RA8875 driver which specifies parameters for Error, Debouncing, Touch levels and various other factors. It is likely that those parameters are not right for your hardware. The touch demo tools mentioned above help you set the correct values for your hardware.

I had a look at the video. To me that looks like a touch driver problem. You don't seem to be getting consistent readings (or perhaps touched detection) from the touch device. This is causing the button to flicker as it tries to redraw to keep up with the variant readings it is getting. Try using the demos/tools/touch* demos to get reliable behaviour from your touch device first.

Using the CubeHAL audio driver is totally unsupported in a uGFX environment. It may work but also may not work (particularly when there are hardware contention issues). What we would really like is for you to create a uGFX driver for that codec chip, handling the contention appropriately. We can then add that as a configuration we will support. Whilst we can help with uGFX related issues and provide pointers on where to look for related issues (like the above problem), we are not able to support or debug outside uGFX code.

Using the Keil compiler with raw32 you are required to set GFX_CPU appropriately in your gfxconf.h file due to bugs in the Keil c runtime library. You also need to use the latest master branch from the ugfx git repository in order to get some recent updates for the Keil compiler.

Yes manual calibration will always give a better result than automatic calibration. The reason is that there is always some physical misalignment between the touch panel and the lcd screen. Automatic calibration calibrates values from edge to edge on the touch panel which is slightly different from edge to edge on the lcd screen (which is really what you want). Manual calibration does calibration relative to the lcd panel which should always give a better result for the user.

Yes that touch display looks fine.