inmarket

I think the key is the bottom one. You must be very nearly out of resources. Making the number of source listeners smaller must have freed up enough resource for things to work. It must be very borderline as source listeners are not large.

On FreeRTOS uGFX uses the FreeRTOS heap functions so the heap on uGFX is the FreeRTOS heap. As for what FreeRTOS does I am not really able to answer that. With 17K heap I am guessing you just ran out of memory. Heap memory is obviosly needed by FreeRTOS for file management and by all sorts of bits and pieces for uGFX.

We have not done a lot of testing with monochrome displays and gwin. When we get time we will look at it more closely and perhaps create a special b&w color style. In the mean time a custom renderer like @joel mentioned above will solve the problem. Perhaps someone else in the community using gwin with a monochrome display would like to comment and provide some tips?

That language construct is perfectly valid C but some compilers incorrectly generate warnings for it. This is actually a compiler bug caused by a misinterpretation of the C standard by the compiler writer. The most commonly known compiler with this bug is GCC. It looks like your compiler does one worse - it actually errors on it. Are you sure you just haven't set your compiler flags to error on all warnings? If not please send us the details of what compiler you are using so that we can put a special #ifdef around the code to account for its brokenness. I think the gfxconf option is something like GFX_OS_COMPILER_SHOW but check the gfxconf.example.h

1. The open file is required by the image during rendering so the file should only be closed once you are completely finished with the image. Its been a long time since I looked at the image stuff but from memory when you destroy the image object it will close the file for you - in which case you won't need the intermediary GFILE pointer again. Check the demo programs or the uGFX code (or even the doco) to be sure. 2. Keeping a file open keeps the GFILE allocated (and there is a fixed number of them in the system) however it is definitely faster than reopening/recreating the image each time. In the end I would typically keep things open until they are definitely not needed again. Next post: there is no need for them to be global. Whether to store a static object or to dynamically allocate the object and store the pointer is up to you. Using a static object saves calls to the memory allocator Note: If loading images from SD-CARD remember the issue of the card speed. uGFX generally does not load the image into RAM before rendering it thus saving lots of RAM. uGFX is the only image handling library that I know of that is capable of doing that. We custom wrote our own renderers for exactly that reason. The downside is that the image has to be reread from the card everytime it is rendered which affects the rendering speed. This is also the reason the image GFILE needs to be kept open for rendering. uGFX has the gdispImageCache call which can prevent the image being reread from disk each render by caching the image in RAM. When you call gdispImageCache the system tries to allocate memory for the image. If it succeeds you have a nice fast image and a lot less ram. If it fails to allocate enough ram you get the image still rendering (slowly) from the card but nothing stops working. It is therefore possible for the programmer to control what images are held in ram, in rom, or on sdcard and the performance compromises associated with that.

The first thing I noticed from a quick scan of the above code is that you have call _widgetCreate with a first parameter of NULL. I can't remember if this is internally checked and replaced with GDISP (the first display) but I suspect not. Try replacing the NULL with GDISP. Another trick that will help is to try compiling on window/linux/osx first as you can use the full debugging capabilities on those platforms to chase bugs. Most uGFX programs should be fully portable if written appropriately eg most of the provided demos are portable to any uGFX supported platforms with no code changes.

uGFX uses a 3 step strategy to implement the heap (gfxAlloc and gfxFree)... 1. If the operating system provides heap functions then those used to manage the heap in whatever way the operating system normally does. If the operating system has no heap functions eg RAW32 then step 2 or 3 is implemented by uGFX. 2. If GFX_OS_HEAP_SIZE is not set or if it is 0 then uGFX uses your c library malloc() and free(). 3. If GFX_OS_HEAP_SIZE is non-zero then uGFX provides it own heap implementation using GFX_OS_HEAP_SIZE bytes of RAM. Based on your symptoms it looks like on your platform that option 1 is not possible (you never told us what platform you were using in the posts above). It also looks like your compiler c library malloc/free routines are buggy and hence option 2 did not work. That is why when you specified GFX_OS_HEAP_SIZE (option 3) it suddenly started working. Now that you have a working keyboard demo you should be able to use that as a starting point for your own program. Change a little bit at a time and test after each change until you have it doing what you want. How much heap, stack, rom or ram you need is very dependant on the program you write. There is no fixed size that is going to work in all situations. Generally start as large as you can on your platform for heap and stack and reduce them as you need to to make space for other things. It is usually a very good idea to build it first to run on windows/linux/osx. A well written uGFX program will be completley portable to your embedded platform with minimal or no code changes. This enables you to test that you have written your code properly without any memory/stack issues and gives you the full suite of desktop debugging tools making it much easier to find bugs in your code.

That line is a "forward definition" and therefore is NOT equivalent to your suggested code. It is (in C++ terms) an abstract object not a reference to an empty structure.

As an aside: Antialiasing is an interesting problem. It requires the ability to know what the background is so that colors can be mixed. There are 2 ways to do this; "know" the background color eg gdispFillString, or read the background back from the display. Option 1 is limited to particular functions with filled backgrounds and option 2 is limited to displays that have that capability (definitely not even the majority of displays supported by uGFX). Also reading back from the display surface is often VERY slow even when it is possible. This then limits the usefulness of generic antialiasing in an embedded environment and is the major reason we have not invested the time into implementing it for anything other than fonts. On a small display antialiasing also can make everything extremely "blurry". A much better approach for small displays is subpixel optimisation and is probably far more interesting for implementation for embedded purposes but it has higher computational requirements and the same read issues as antialiasing. Another issue with antialiasing is that drawing the same object twice in the same location leads to different displayed results (except in the case of a known background color). The reason is that the antialias weights on the 2nd draw get mixed with the antialias weights from the first draw. This then requires careful placement of draw order in order to ensure that things only get drawn once and the pixel areas affected by 2 antialiased operations don't affect each others antialiased results. This draw management adds complexity and computation resource requirements to the engine - usually more than would be suitable for an embedded environment. So, the conclusion of the above is that general antialiased drawing is not at all simple. While simplifications can be made it is still complex and would not be available for many drawing operations or on many types of hardware. Antialiasing is also not the best strategy for small lcd/oled displays with subpixel optimisation having significant advantages. All the above lead to antialiasing on general drawing not currently being worth the time when there are so many other areas we can improve uGFX first.

Remember that .h files are c source code. The object created by a 3MB .h file is likely to be much smaller than 1MB. The size in ROM will be the same size (plus a few bytes) as the original image file - not its .h representation.

If you are using a timeout value (eg 100) to geventEventWait rather than TIME_INFINITE then geventEventWait can return NULL indicating that there was a 100ms timeout. Either change 100 to TIME_INFINITE or put in code to handle the NULL before the switch statement.

Crteensy's link above should give you how he integrated uGFX. It is a great strategy for a serious arduino programmer. For the less serious see the wiki article. It is a slightly simpler method but less suitable for multiple projects. Once setup most of the uGFX demos will run subject to RAM and ROM. eg the combo demo may struggle to fit non ARM arduino cpus due to lack of resources.

Great to hear you got it working. Well done!

Another note: just looking at the code that looks like an interrupt handler. Try setting the interrupt stack size. Also note: 0x23000 is way too big for a stack on this hardware. Try numbers like 2k (0x0800) or 4k (0x1000).

This stuff seems to be buried in what looks like chibios code. It certainly doesn't look like uGFX code. I have a couple of suggestions for you... 1. Try to debug and find out what the last line that was executed in the uGFX code and we might be able to help you find a cause. 2. Contact the chibios forums as it definitely looks like a chibios problem.

This should be defined in your halconf.h (I think that is what the stm32 cube config file is called). Another possibility is you are using an old version of the stm32 cube files. STM change them often in incompatible ways.

The issue with the color names and various other name conflicts that occur on some platforms will be fixed in uGFX v3.0. The colors Red, Green, Blue etc will be renamed as GFXRED etc. The old color names will still be defined in v3 (for user program compatibility reasons) unless you rurn off V2.x compatibility. The reason this is being done in V3 (a new major version) is because changing these color names breaks existing user program code.

Also check your stack sizes. The default chibios stack sizes are a bit small for uGFX.

1. Make sure you are using the latest version of the F7 HAL files. STM change them often and in incompatible ways. We try and keep compatible with several versions of the HAL but it is a losing battle with the time we have available. 2. If that doesn't work look for where HAL_StatusTypeDef is defined and find out why the definition is not being included. Please let us know what you find.

Joel, it looks like this controller only supports x-axis reversal (atleast the way the control code is currently set up) and hence lines 133 to 148 is necessary. I haven't checked the datasheet to see if y axis reversal is really possible and I would want to have the hardware before trying that. Line 188 matches line 197. Whilst the or with 0 is unneeded, it will be optimised out by the compiler and properly documents the set/reset instruction for program enable and hence is worthwhile for code readability.

This has been added to the repository. Can you please check that I haven't broken it as I made some small efficiency changes on the way through.

Nice.

Check if you are overflowing one of your stacks. That is the most likely cause of this sort of problem. Another test is to run the same program using the win32 or linux emulators. If it runs fine there you know the problem is definitely not in the text edit or your program. In that case it must be memory or stack or something similar - something that is runtime environment sensitive.

There is a keyboard driver as part of the X multiple driver that should show you the simple mechanism for doing a keyboard without layout support (multiple language and scan code support). A keyboard without layout is equivalent to a "cooked" terminal under linux. If you want full layout support then look at the Win32 keyboard driver. Although the layout is only implemented for a US keyboard it does demonstrate the scancode to ascii conversion engine using a set of tables for each language layout.

There is actually an option for that in our makefile process (OPT_MAKE_LIB=yes). See tools/gmake_scripts/readme.txt for more options.