inmarket

This looks like a cygwin dll version problem. Either you have a mismatch between the compiler or make and your cygwin dll versions, or the various dll version do not match. Look for old left over versions of the cygwin dlls in your windows and system32 directories.

Resizing within the widget code is nasty because of the various locks and redrawing required. While the label widget supports auto-sizing there are situations where it can get into endless resizing loops when you try to update the auto-size after widget creation. If you want to auto-size let me suggest that you only do it during widget creation and not dynamically thereafter. If you follow the placement of the code that the label uses for sizing on widget creation you should be relatively safe. Resizing after the widget is created is highly likely to cause you all sorts of pain.

Do you not have a touch or mouse decice? Check you are using the most recent version from the repository as there were recently some changes that should allow gwin to work without a touch/mouse device.

It is all about the design decisions you make when coding the widgets. We strive to give maximum functionality in the smallest possible code and ram. That sometimes leads to contradictory requirements. Which way you lean is up to you provided it is something you have thought about. Sometimes we use an option define to control whether extra functionality is included. Another trick we use is to have different display methods as different draw routines. Sometimes it is an init time flag. Eg. The question on gridlines could be either an alternative draw function or a init flag to determine if gridlines should be drawn. Your question on optimised drawing... We tend to redraw the whole control. While slower it usually uses less code and doesnt have possible issues relating to redraw timing. The extra redrawing is usually not visible to the end user as you are overwriting without changing the bulk of the widget surface. It is also the more compatible with ugfx3 where we are considering supporting limited clip area redrawing. In that situation all the redrawing code would be called but only clip area would be updated to the screen.

I like the idea of queue items for both rows and columns. This definitely provides the best flexibility for a generic widget. AsyncQueues are very efficient. They only use 4 bytes per item on most platforms.

Please post widgets in the "Development and Feedback" section of the forum as a zip or 7z file if the widget may be if use to others. We will then look at including it into the official repository. If you widget is highly specialised for your application but you want to share the code for others to look at, the appropriate section is the "User Projects" section of the forum. No table widget currently exists. We would love to have your contribution.

As an example, the stm32f439-eval board uses a 640x480 display. We are just writing a set of board files for it now.

Glad to hear you got it working

This has now been added to the repository as gwinPrintg().

Linking above refers to filesystem linking to fool the eclipse makefile generator. We internally always use a custom makefile in eclipse. For an example look at boards/base/xxx/example Ugfx is far more than just a collection of sources. I will be surprised but pleased if eclipse makefile generation can be fooled to make ugfx correctly.

Well done. We look forward to seeing the result.

Rather than linking the entire uGFX source tree which then causes eclipse source detection to include too much, try linking the "src" directory to get step 2, the "demos/gdisp/basics" directory to get the demo step 1 code, and then link to each individual driver that you want included in the build.

UGFX normally requires 3 things... 1. Gfxconf.h and a main program. These can come from your project or by including a makefile in one of the demo directories. 2. The main source itself built by including ugfx.mk. This automatically includes all the necessary sub makefiles. 3. Any drivers you need for your hardware. Again there are makefiles in each driver directory that you can include. Obviously you would only include one gdisp driver unless you intended to create a multiple display system. Alternatively you can use a makefile in the boards/base directory tree to include all the drivers and hardware io interfacing for a particular supported board (and any glue logic). All 3 parts above rely on GFXLIB being set to the ugfx directory. The above makefiles build a GFXSRC and a GFXINC make variable which your outer makefile then uses to set the compiler include path and then build the source. The 3 parts are just linked together. Our example makefiles (under the boards/base/xxx/example directories) just make this this combining task simple. They support building for a few embedded operating systems without the complexity of a complicated user makefile. Many people however (such as yourselves) want to include uGFX into their own makefile system. In such a case the process is the same, include the 3 parts above into your own makefile wrapper.

Thank you. That is a very useful contribution. I will add it to the repository as soon as i get an opportunity although i will probably change snprintf to snprintg to avoid pulling all the full c library io overhead. Well done.

The image decoder converts the image colour into the GDISP_PIXEL_FORMAT. By default that pixel format is the same format as the drivers native format. It doesn't have to be however. If a different value is specified in gfxconf.h then that format will be translated by the driver to the display native format. You could then set that pixel format so it is suitable for dma, or set it to rgb888 and translate on the fly (if your dma supports it). The difficulty will be if your color format for dma ends up splitting one of the colors on the byte boundary. In that case you would have to write a full set of custom color macros to support the byte swapped color format. This would not be a simple undertaking.

Check the other points above.

The windows CreateProcess is failing when it tries to start the compiler. The most obvious reason for that would be that arm-none-eabi-gcc.exe is not on your path. Make sure the directory that contains that compiler is set as part of the eclipse project file environment settings. Another reason might be that your compiler is failing to run because a dependant dll is missing. Either way it is your eclipse and toolchain setup that is causing the problem.

I can see a couple of problems that may (or may not) be the cause. 1/ gfxInit should be the very first call. It must occur before the gaudioPlayInit. 2/ unless you have turned off operating system init in your gfxconf.h there is no need to call halinit and chinit as gfxinit will call them for you. 3/ The stack size (4096 x 10) you are specifying for the audio thread seems overly big. This is probably running you out of heap space causing all sorts of strange problems. 4/ the number of buffers specified for audio buffering with gfxBufferAlloc seems a bit small/few depending on your cpu speed etc. 5/ note that PLAY_FORMAT_FILE is only available on a vs1053 audio chip because the codec itself implements it. 6/ check you are not running out of file descriptors. By default only three are enabled. It can be increased by a setting in your gfxconf.h I hope one of those hints help.

Just to be clear... Each listener contains a single event buffer. An event will be put in the buffer provided it is not already full with an event (whether or not the listener is currently waiting). If it is currently full most event sources mark a flag that indicates on the next event that an event has been lost eg the mouse source. A listener with an event in it gets that event cleared/released when it calls geventEventWait or geventEventFree. The gwin and other event sources have been carefully written to ensure that a single source event doesn't create a chain of subsequent events that would be lost due to listeners already being full. Eg. That is why a slider only generates a "change" event and doesn't support sending a "click" event. As @Joel Bodenmann mentioned this design is really all about resource management for small micro's. An event queue uses up too much ram or more specifically an non-determinate amount of ram. Restricting listeners to a single event at a time prevents problems on ram constrained micro's.

Postinit is a call to a routine in the driver called gdisp_lld_postinit(). It is useful where the display initialisation must happen at one bus speed but the data thereafter can be sent at a higher bus speed. Postinit is called after all driver initialisation has completed but before any drawing is done to the display. Most drivers do not define such a routine. I am not sure what the ed driver is doing in that routine. Have a look at that routine to find the problem.

Thanks.

The thing to watch out for is that gwinShow may not immediately redraw depending on the current gwin redraw policy. If it doesn't immediately redraw, adding a gfxYield may be sufficient to allow the redraw timer to be triggered and run before you close the image. If it is just an image box you might want to consider just using the gdisp calls themselves to directly draw the box on the screen especially if you are planning on managing any redraw manually yourself. This would save the ram overhead of the gwin image box itself. Assuming that it is the FAT file descriptor that is the overhead you want to avoid and not the gfile descriptor (which is small) or the gdisp image structure, another solution would be to change the image code so that it saves the filename and reopens the file automatically if it is closed. Doing that at the gwin level could even save the image structure overhead. All that however would require changing the ugfx library code for the benefit of not having to manually manage the redraw. If you decide to go that path please contribute the modifications.

@EttoreBarattelli Can you please zip and attach your hello world solution project files? It will save me some time in testing for integration.

The visual studio compiler should be detected automatically, we just need to add the appropriate #if tests. I will look at it later when i get some time.

The gdispStreaming api is probably the bit you will need to get video displaying on the lcd