inmarket

If it is a non-cycling multi-family GIF image the last frame will return TIME_INFINITE. If you want to start at the beginning again just call gdispImageNext again. So to turn a non-cycling GIF image into a cycling image just replace a TIME_INFINITE delay period with a set period that you want the last frame displayed for before restarting.

Good idea but difficult with the current software (to be fixed in V3) because the board interface is different for each driver although there are a often a lot of similarities between them for the same driver type. In general any current documentation (if any) will be in the template board file found in each driver directory. If you have specific questions please ask here.

Are you initialising freeRTOS correctly?

Another trick you can use is in the init_board routine set the g->board field to a structure that contains register pointers and pin definitions for that display. Each display has its own g->board field. In any other routine you can use that field to access the structure and thus not have to switch on every operation.

Simply remove the GDISP_TOTAL_DISPLAYS setting from your gfxconf.h. That setting is designed for when you have multiple displays all using the one controller type.

There are two ways to implement multi-tasking.. 1. Write an assembly language routine for each CPU variant, or 2. cheat by using setjmp and longjmp. Method 1 is used internally by FreeRTOS and any other multi-tasking operating system. The operating system writer has done all the hard work for you. Similarly for our BareMetal (RAW32) port we have written assembly routines for the Cortex Arm 0 to 7 series of processors. Method 2 works because setjmp and longjmp are supposedly a standard part of the C library and therefore this method should work everywhere and on every CPU. The problem here is that sometimes the C library is missing these routines, sometimes it is buggy (setjmp and longjmp are usually not well tested by the library writers), and sometimes a C library from an not-fully-compatible CPU is incorrectly used. Stack checking code that is inserted by some compilers can also cause problems although this can usually be turned off with a compiler flag. All of this is to provide general multi-tasking, either pre-emptive or cooperative. These other libraries you are talking about are NOT multi-tasking libraries but rather task execution frameworks (as evidenced by their lack of a yield function). They are not the same and uGFX requires true multi-tasking. We are looking at removing that requirement in future (with suitable restrictions in functionality) but that is definitely well after v3.0 as it requires very large internal changes and considerations.

If the adafruit library supports a rectangular fill then add that as a gdisp acceleration. It will significantly boost performance. It can still never match the underlying adafruit library as it has its own overheads and it uses the adafruit library, but it will improve the gdisp performance significantly. By the way, the layering of gdisp over another API is what the Win32, Linux-X, SDL, and OSX display drivers do too. While it has a performance impact over the native library it is a quick and easy way to get started with uGFX and provides great portability. A specific driver can be added later eg linux-Framebuffer.

Nice work!

Note you should only set GFX_USE_OS_FREERTOS if you really are using the FreeRTOS operating system. The problem with the paths is caused by the Arduino IDE itself. Normally you will add the FreeRTOS directory to the compiler include path. The Arduino IDE doesn't support that and uses a crazy "library module" scheme hence requiring changes to the sources that are different to every other compiler. Whether there is some way to fool it or not is another matter - I haven't had time to investigate in enough detail.

First note that the sense of the parameter between uGFX and the adafruit code is reversed. Second, the startup reset delays for a controller chip are normally documented in the controller data sheet is. It is a controller specific property once the power supply is stable (which it definitely should be by this code stage). So, in this case there are three possible problems... 1. Whoever wrote the board file didn't notice the parameter is logical level not pin level and was therefore holding the controller in the reset state, or 2. The driver writer did not include delays as per the dataset, or 3. The controller is a cheap Chinese equivalent with significantly different speed properties. Nevertheless, your idea of making it a single board level routine has some merit. I will look at how it can be used in V3 which uses a gBus module for all io of this type.

The init is called seperately for each display. There is a integer field in the GDisplay structure that reports the display number on the controller and another field that reports the display number in the whole system. See some of the example template board files for various controllers, you will see a switch statement in the init function that demonstrates how 2 displays on the one controller type can be used.

1. Yes. Most micros don't have enough RAM for a framebuffer so uGFX (unlike most graphics libraries) doesn't require one. Three are a couple of exceptions - when the display controller requires one, and where the controller is not pixel addressable (eg sub 8 bits per pixel). 2. V3 is a work in progress that is taking much longer than originally intended due to there being more work involved than we expected and we have had fewer resources to devote to it than we expected. We were hoping it would have been out by now but it isn't, and so I am now reluctant to put time frames on it. Hopefully soon (read that as months not weeks).

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.