inmarket

The STM32LTDC gdisp driver by default uses DMA. Perhaps there is a conflict there. Some drivers that use DMA support a config variable or have a setting in the driver config file that specifies whether dma should be turned on. I can't remember off the top of my head if the stm32ltdc driver has such a flag but you can check in the source code. This won't have anything to do with GADC.

The new code is already in the git repository. Interesting with the focus. That sounds like a redraw order problem between controls. I have no idea on that one currently.

PS. The symptom you were seeing previously was likely the maximum size bug I found.

You should not define GFX_COMPILER unless the build complains about not being able to autodetect the compiler type. Similarly anything using the default value (eg GFX_EMULATE_MALLOC) doesn't need to be defined and probably shouldn't be defined in order to be most future compatible. How did the textedit test go with the new code?

The current design to only send an event on button up is intentional. Particularly on touch screens pressing can be inaccurate. One way of handling that is to only send the button event if the button is pressed and released while the touch is over the button. Even desktop environments often to the same. To demonstrate this press over the button and while holding the touch/mouse down slide off the area of the button. You will see that the button remains in the depressed state. When you lift off the touch (release the mouse click) you will get one of two responses; if you were over the button on the release you will get a button event indicating the button was triggered. If you release outside the button area the button returns to its unpressed state and no event is sent ie the button press is effectively cancelled. If you add the extra event send on the button down you will need to either turn off the button cancelling feature or be able to handle sometimes not recieving the release event.

I have made changes to the TextEdit which should fix these problems. I additionally found a strange bug to do with the maximum size. Changes: gwinSetText() can now be used even with static text. It will be converted to dynamic text automatically when the text is actually edited. Setting the maximum length now only affects adding characters using the keyboard. API level calls (eg gwinSetText) or deleting characters ignore the maximum length. If the maximum length is set to zero then there is no restrictions on length. If memory allocation fails while trying to edit the text, the text is left unchanged. This should give safer behaviour in low memory situations. The code has been adjusted and compiled but I have not actually run it to test it (just due to time constraints currently). Can you please test this and let me know if it works correctly in all the situations specified above.

I have finally spent some time looking at it... Whilst I haven't done a full debug yet I can see a problem that can be caused on reallocating of the string buffer (due to an edit) most particularly if you are on ChibiOS. The reason ChibiOS is a particular problem is that its realloc call requires the size of the old buffer (yuck!). Once gwinSetText has been called however we have lost our original buffer size. If you are running ChibiOS it would also explain why you are seeing the problem but others are not and why it didn't appear during our development testing. I will look at coding a solution in the next day or so.

It is running late due to heavy workloads. At this stage there is no update on when the new release will be ready but the latest code is always available in the repository. A new major version (v3.0) is well under way but the changes are quite major internally and it is taking longer than we initially estimated.

Did you do a make clean to remove object files from previous compile attempts?

Sorry. Just short of time currently. I will try and look at it later today.

Please turn on the define as above, do a rebuild all and then tell us what compiler uGFX thinks you are using.

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