inmarket
-
Posts
1,311 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
Also check the threads demo works.
The Keil compiler is supplied with a buggy C runtime library so make sure you have specified the CPU to uGFX so that it can use the CPU specific threading rather than the C library based one. This C library bug will result in symptoms just as you are describing.
-
This is an issue of sibling window drawing. uGFX's window manager does not currently support overlapping windows except for a container/child relationship. This is due to lacking complex clipping region support (due to memory and complexity overheads).
What this means is that whenever you touch something it gets fully redrawn regardless of any overlapping sibling windows.
Someone has written a replacement window manager that supports this but they didn't contribute that back to the community. This doesn't solve your immediate problem but it does demonstrate it is possible.
-
This is either an issue with your CPU, the definition of which CPU you are using, your startup code or an io configuration issue.
1. Check that the CPU you are using supports both DMA2D and ltdc.
2. Make sure you are correctly telling the stm32 Hal layer which CPU variant you have.
3. Check the board level startup code and make sure you are configuring the clocks and io as per the examples provided.
-
Please carefully read the guide suggested above. It will explain a lot.
The first error is caused by adding the GDISP_TOTAL_DISPLAYS and the GDISP_DRIVER_LIST settings in your gfxconf.h. These lines are for multiple display support and are not needed for a single display. Instead the correct driver is managed using the compiler include path and the link script as per the above guide.
The second error is caused by not including a mouse/touch driver. Either include a driver or remove the GINPUT_NEED_MOUSE setting and optionally the GFX_USE_GINPUT setting from your gfxconf.h file.
-
Try using a online font converter to convert from otf to ttf. Google will help you find one.
The uGFX font converter may or may not work with otf files - I either case it is not on the official support list.
-
Not yet unfortunately. The reason is that we have just been so busy and we are very resource constrained. We have two VERY large projects that are currently consuming us. We had actually hoped to have it out by now.
What is coming very soon is a V2.9 which contains some of the type changes that were part of V3. We are taking this step for two reasons; one to keep uGFX moving forward, and secondly to reduce the workload with keeping V2 alive while V3 is being developed (the internal source changes are quite significant).
With regard to your planned driver, if you develop it for V2 and contribute it to the repository we will port it to V3 as part of the V3 effort. We may need your help testing it but we will cover the porting work.
-
Only being able to insert into a list widget at the end is not uncommon eg Win32.
The correct method is to clear the list and re-add the items as per Joel's post above.
-
It is a very good idea when working with a new display to try the various gdisp demos first. These can help hilight problems related to gamma, different drawing mechanisms, rotation etc.
Start with the gdisp basics demo and then try the text demo. They will help you find where any problems might be.
-
When you commented out the fillarea calls you forgot to also comment out the if statement just before it. The if statement still being there is causing the following if statement to also be conditioned.
Comment out the if statement just before the commented out fillarea statements and I suspect it will work.
-
The issue here is not so much about Studio, uGFX itself doesn't support .ico files. Once support has been added to uGFX the Studio developers will quickly add support into Studio.
As Joel mentioned, if you want to take on adding .ico support to uGFX then the Studio developers will add support into Studio shortly thereafter. This shouldn't be too hard as I believe it is similar to BMP which is already supported.
-
This has been updated in the repository. Thanks for bringing it to our notice.
-
I am sorry we only support English on this forum. This is both for our ease (although we also understand some other languages) but also so that others can also make use of any information or answers to your post. Google translate normally does a good enough job of converting to English.
-
This is definitely more advanced uGFX functionality and uGFXStudio knows nothing of users so you would need to implement this yourself.
Let me suggest again that the best approach for screendumps for manuals etc is to run your uGFX program on the Win32 emulator and then use the windows screen capture tools. I'm sure the same could be done using the Linux and X combination if that is your preferred development platform.
-
From an application that is currently not possible. Remember that uGFX is designed for small embedded processors that often cannot read their own framebuffer.
If you want to draw onto a "virtual" display and then save that into a BMP file that is possible. Look at pixmaps. You will still need to do the BMP encoding yourself but you can use GFILE to save it to an SDCard.
If you are just after screenshots for a demo of your product (or something similar), the easiest way is to compile and run your uGFX program on the win32 platform. You can then use the windows snipping tool to take screenshots of what is happening.
-
Given that this seems to be font size dependant my guess is that it is the encoder having the problem as the decoder built into uGFX is font size agnostic.
Other than saying that, I have not heard of similar problems. Perhaps try using the win32 version of the encoder and also try the online converter to see if they give the same result.
There have been minor bugs fixed over time so also check that you are using the latest version from the repository.
-
There is probably something wrong with your file system permissions as per the error message.
-
The way you have used the gdisp driver is incorrect. It cannot be copied to the src directory - that just won't work. Please reread the instructions again on how to do this properly.
-
Well done on finding the problem!
-
All things are possible - and this "thing" would not be hard.
It is however not on our development agenda currently as it is not difficult for a user to get a running project with the makefile buuld system or with the single-file-make option. We are currently resources constrained and we are putting all our efforts into releasing uGFX V3.0
-
You have definitely not included the driver correctly. That is exactly what that error message you are seeing is saying.
It is telling you that the color system has not been defined. The color system is defined by the proper inclusion of the driver.
Please reread the instructions carefully.
-
Yep. Exactly correct. Much easier to use than a FreeRTOS semaphore.
-
1. This sort of thing is deep in the FreeRTOS code so really has nothing to do with uGFX. If #2 below fails you will need to seek help from the FreeRTOS forums.
2. Where you might be coming unstuck is if your main thread stack is too small. Again this is a FreeRTOS setting. What gives this indication is your comment on something pointing to the wrong memory area.
-
Use gfxMutux objects and calls instead.
1. It is portable to any uGFX supported os.
2. It prevents errors in coding as gfxMutex's are easier to use than FreeRTOS semaphore calls.
-
There are really only four possibilities...
1. The FreeRTOS semaphore functions aren't working properly. To ensure its not a coding error try using the gfxMutex object and calls instead. That way you can also remove the loop, just use the mutex enter and exit calls with no timeout.
2. A bus_release is not being called when it should be effectively causing the bus to remain locked thus preventing drawing.
3. There is a call to the hardware that is not surrounded by the mutex and that is causing contention.
4. You are suitably protecting the bus however you aren't getting the chip selects etc correct. Eg if the display and touch chip selects somehow both end up set or unset simultaneously. It could also be a chip select timing issue.
the gwin/button demo doesn't work
in Support
Posted
Try either the m7 or m7_fp (fp stands for hardware floating point) first but also make sure you are also compiling as if it was a m7 processor.
The other arm versions can also be tried - the difference between them corresponds to differences in the instruction set of the variants of arm cpu. The corresponding code used is found in the src/gos/gos_x_threads.c etc.
It is likely one of the existing arm CPU specific code options will work for you. If not you may need to add one for the arm9. If an existing one works for you please let us know which one and similarly if you add you own for the arm9 don't forget to contribute the code so other users can benefit too.
We would attempt to add it ourselves but unfortunately we don't have a board with that chip on it for testing.