inmarket

The stm32f4-discovery board files in the repository works perfectly well. Why rewrite what is already working?

Don't forget to do a "make clean" and then recompile.

Part 1: workaround... After moving the container do a gwinRedraw on your lightbulb. Part 2: fix... It is difficult to tell exactly what is going on without suitable source code. Please write the smallest program you can that demonstrates this problem, attach it in a zip to this forum topic and we will try and work out what is going on. I suspect it is either related to a partial redraw optimisation or alternatively the move code (which is not well tested as it is a less commonly performed operation)

This problem is usually caused by your include path containing the src/gdisp/fonts or src/gdisp/mcufont directory. Remove those directories from your include path and the problem should dissappear. If you search the forums this topic is not uncommon. Reading those posts will give you a lot of background on why it is this way.

Yes please. That would be great.

The link above contains generalisms. The license file that comes with the font is ALWAYS what you must pay attention to. Generally font licenses are written that generating characters and chatacter strings have license restrictions but once generated and layed out you can look at the result without license restrictions. In terms of embedded use, assume you are using the ttf file itself when reading the license even though you are using a file format derived from the ttf.

Well done in tracking down a curly problem. I will look in detail on the weekend and see if there is anything that needs migration into our source repository.

The gray problem with eclipse is exactly that - a problem in eclipse (not uGFX). The function that you have displayed for switching the mirror in effect changes the initialisation sequence of the controller. We will look to make this a board level define for that driver.

The wiki should be correct I think for most touch drivers. Note this belongs in your mouse board file (not the general gfxconf.h file). In the mouse driver itself it should use that board specified macro to set the extreme calibration flag in the drivers VMT flags when it is defining the VMT structure. It is possible that the mouse driver you are using has not implented that - if so let us know and we will fix it. I would have checked for you but you didn't mention which touch driver you are using.

1, 2, 3 & 7: yes. 4. The 0 is a special flag to FreeRTOS to shut down all threads. _gosDeInit is unlikely to ever be called in an embedded environment so it can quite safely usuallyvne left as an empty function. 5. Microsecond delays are seldom provided by os's and are not used by uGFX itself however a driver might try to use it. Rounding it to milliseconds is what most gos implementations do. 6. I have no idea. Take a guess or read the doco to understand its significance in threadx. 8 & 9. Great. 10. No problem as pointers and uint32_t are (usually) the same size. The only time it might be a problem is if you are on a 64bit pointer cpu however i suspect threadx doesn't support that. Just typecast the param pointer to a uint32_t.

This has been cleaned up a bit and added to the repository.

If you are using our makefiles there is already a OPT_xxx option that turns on producing a mapfile. Unfortunately I am not at my computer currently so I can't look it up for you but where to find the OPT_xxx documentation is listed near the top of the makefile. Update: The option is OPT_GENERATE_MAP. Set it to yes and it will generate the map file for you. It is described in tools/gmake_scripts/readme.txt

Easiest way is to fill the entire memory with a pattern eg 0x5a5a5a5a before the c runtime startup. It is then easy to use your debugger to examine memory to see where your stacks have got to.

It could be that it is to do with the external SDRAM however I think it is more likely it is a stack overflow issue. Stacks are allocated at the top of ram (usually) with heap just below that. My guess is that telling ChibiOS not to manage all the RAM leaves enough space for the "naughty" stack to be able to overflow without crashing everything else. For ChibiOS on STM32 don't forget the interrupt stack. It could well be that one which is overflowing.

Thank-you. We will look to adding into the official repository as quickly as possible.

All known problems with the STM32F746-Discovery board have been resolved. ChibiOS has no other known problems. It was in fact the os that we started the whole uGFX project with and the project was originally called ChibiOS/GFX. If you are having strange problems like that one of the first places to look would be your stack sizes. Nothing works reliably if you overrun a stack. Also, can you please explain the problem you are having? Is it returning data from the wrong file?

Going through your files... If your operating system has no memory allocation routine or memory free routine you can do what the Raw32 port does... in the bottom of your gos_threadx.h file include the following code... #define GOS_NEED_X_HEAP TRUE #include "gos_x_heap.h" What this does is include a uGFX provided gfxAlloc(), gfxRealloc() and gfxFree() routine. Make sure you also define a GFX_OS_HEAP_SIZE in your gfxconf.h to indicate what heap size you want. gfxYield() is releases the remaining time slice to another thread. All multi-threaded operating systems will have one. With regard to gfxThreadMe(), gfxThreadWait() - these again are multi-threading functions. Whilst uGFX does not use them, they are officially part of the uGFX API and should be implemented on any complete implementation. It looks like you are using an old version of the library as the current FreeRTOS implementation does provide these functions. Try downloading the current version from the repository at http://git.ugfx.io For semaphores - it is VERY important that you implement the limit. Lots of stuff won't work properly without it. Look through the other operating systems to see how they handle it if the operating system doesn't provide that feature. For gfxSemWaitI() - if your operating system doesn't provide a suitable routine just define it as equivalent to gfxSemWait() with an immediate timeout. Just don't try calling it from an interrupt context. This is largely used by various drivers to signal back to uGFX when an event happens. For gfxSemSignal() - the complexity is all about avoiding windows of opportunity that can cause the semaphore to not work properly. Getting semaphores to work correctly can be very complex. Look at the discussion in the forum on the recent updates to FreeRTOS gos port for exactly that reason. (I think you are working from the broken version). I hope that helps.

If that is your decision we are sorry we can't help you. From our side it is very hard to help when we don't have enough source code to really see what is happenning or even a list of the errors you are getting. We know that uGFX is used in many large scale projects. It is not the simplest library in the world but that is because of its power, flexibility and versatility. If you are serious about a possible switch to uGFX we do offer one on one support on a commercial basis. We will even write the code for you on a commercial basis.

Is it reading incorrect data or are you saying that the GFILE pointer is exactly the same? If you are saying the later then this is normal. GFILES are stored as a small array of structures (the number determined by GFILE_MAX_OPEN_FILES). The GFILE is then a pointer to one of those structures. So if you open a file and then close it, the structure is released ready for the next open. Open/Close/Open is then expected to return the same GFILE on both opens. Both the contents of the internal GFILE structures will however likely to be different in the two open cases - the exception being when the underlying file system handle is also an indirect association. Note there is no memory allocation at the GFILE layer although there may be in the underlying file-system layer.

This discussion may also help...

The problem is that because you have copied ugfx into your src folder, your IDE is trying to include every file in the ugfx tree into the project. This is exactly what we are trying to avoid. Your project tree needs to look something like this... /project/src - contains your project files and gfxconf.h /project/ugfx - contains the unaltered uGFX code Make sure your IDE is not trying to build files in the /projects/ugfx directory. Add /projects/src (if it is not already there) and /projects/ugfx to the include file path. Note: this is NOT adding them to the project source - this is adding them to the compiler include file path. Include the single file gfx_mk.c into your project to build. Don't move or copy the file, just include that single file in its existing location in /projects/ugfx into your project build. You will also need to add the driver source files you want to use into your project in the same manner as you did for gfx_mk.c. Also add the driver directories to your compiler include file path as you did for /projects/ugfx. That should solve the problem. The moment you get errors associated with font headers you can be sure you are including the wrong stuff into your project.

This is actually a very simple job. Look at the demos/gdisp/images directory. In particular pay attention to its gfxconf.h file.

Good idea for testing but it shouldn't be left in the production driver as some busses (or bus hookups) don't support reading eg SPI with the DI pin not connected. A suitable solution is to add an #if macro to enable or disable the id reading.

We will handle that. Thanks.

There are two ways of building uGFX. Including every source file in uGFX into an IDE is not one of them. uGFX is far more complex than that. The first involves using the makefile which selectively builds the components/source it needs. This can be emulated in an IDE by picking the same files to build and including the same include path that the makefile does. Note however that is a difficult way to do things. The second method involves adding just the gfx_mk.c file to your project (and nothing else) and the uGFX directory to your include path. We call this "single file make" and is ideal for IDE build systems. You will still need to add any driver source files and the driver directory to your include path. Single file make is also currently incompatible with some uGFX features eg pixmap. We plan to fix those incompatibilities in the next major release of uGFX ie V3.