inmarket

Try setting the option to TRUE (or GFXON if using the latest repository version).

Not presently. Anti-aliasing requires being able to read back from the display surface and adds significant complexity to the algorithms particularly if you want to do it using integer mathematics. Many display controllers simply don't provide read back access to the display surface. We fudge it for fonts by assuming a constant background colour or, if we can't do that, we simply ignore anti-aliasing on the anti-aliasing font. This strategy is unlikely to be useful for basic shapes as the whole point of anti-aliasing is to mix the edges of the shape with the background. Similarly the additional complexity (read that as code size, stack space requirements, and speed) is not worth it for most embedded platforms. In uGFX we have very well optimised image handling and with the right image this can replace most needs for anti-aliasing shapes. Having said all that, we are adding the technology basis in V3 to allow these operations in future if the programmer and hardware designer are prepared to meet the requirements and are prepared to accept the speed and code overheads of these routines.

I see what you are talking about. I will check the code later today.

The strategy you are suggesting will not work and is unnecessary. The ms parameter is in milliseconds. The whole number of seconds will always be ms/1000. Adding anything else to it will cause it to be too much. Similarly the nsecs field gets the fraction of the second and is expressed in nano-seconds. Ms%1000 gives you that component. It just needs to be multiplied by 1000000 to convert from milliseconds to nanoseconds. If you are getting overflow it is because your compiler is not extending the arithmetic on the left hand side of the expression to 64bit as it is supposed to as the tv_nsecs field is 64bit. The way around this is to add constant expanders to the constant in the left hand side ie change 1000000 to 1000000ULL. Unfortunately this is compiler dependant and not all compilers support that syntax but it is a work-around for the compiler not following the C standards properly.

You are misunderstanding. The way the raw32 scheduling works is by playing with the stack. This is incompatible with Keil compiler stack checking by very definition. If you are however using a RTOS as you explained in your later posts you should not be using raw32 at all. Instead you should be porting gos for your RTOS. Freertos, cmsisv2 and rawrtos are examples of that.

Don't forget to check the size of the main thread. This is normally done using a linker script or for Keil it is somewhere in the project properties. 2K should be more than enough for most situations. You may also need to turn off stack checking as uGFX provides non-preemptive threading by manipulating the stack. However, now that you mention you are using a RTOS, using the bare-metal port is probably not the best approach. Bare metal (raw32) is designed for when there is no RTOS. Your best solution is to provide a gos port for your RTOS eg see rawrtos or freertos or cmsisv2 for examples. Again please contribute your result.

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.

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 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.

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.

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.