inmarket

Please post the patch files or better please put in a pull request for your changes. If it breaks other code (board files etc) that code will need to be appropriately fixed.

The easiest way is to attach the driver as a zip file to this forum thread. If you wish you can also create a pull request on the main uGFX git repository.

Yes. A font that large (tall) is likely to not work. Given that most embedded displays are 320x240 or smaller it is not unexpected that a line height of 267 would be considered invalid. That means a single line of text won't fit on most displays. Given the aspect ratio of most fonts you would be struggling to fit 3 characters width wise as well. I know displays are getting larger and you obviously have a use case for such a large font, but I am not surprised it fails at this size. We will have a look to see if we can fix this but that won't be quick due to our other workloads. Alternatives, 1. You can try editing the produced c file and manually adjusting the line height down to 255 (the largest value currently supported). 2. Fix the font problem in ugfx and the encoder and submit them as patches to ugfx. We would greatly appreciate them.

As I said, you either need to... 1. Not use the F7 specific code for RAW32, or 2. Fix the assembler so that it works with your compiler, or 3. Use a different underlying operating system. Whilst the c code in ugfx is extremely portable, any assembler code is optional and both cpu and compiler dependant. With Keil v6 it is passing our protection tests limiting that assembler to arm code chain compilers however it is not compiling it. So, you have 3 alternative actions you can take above that will solve the problem. Persisting without doing one of the above will not work.

There are two errors in this. The warnings can be ignored, there is actually nothing wrong with those, the compiler is being unnecessarily noisy. The two errors relate to assembler code usd for the F7 specific version of the RAW32 task switcher. There are two alternate ways around this... 1. Turn off the F7 specific code in the task switcher by setting the appropriate macro in your gfxconf.h file. (I am not at my desktop right now so I can't immediately tell you which that macro is). We wrote the assembler routines for some cpu's and some compilers because the setjmp routines in their C libraries were broken. Keil was one of those. Hopefully in upgrading the compiler they have also fixed their C library. Alternatively you could fix the assembler so i works for Keil v6 and contribute the code back to us 2. Use a different underlying operating system. You are currently using RAW32 (our own implmentation of a minimal os). You could try the Keil ROS for which both versions are supported, the later being the better os. You could also try FreeRTOS or ChibiOS

There is no reason that we know of that it should not compile with Keil v6 as we actively support and use around a dozen different compilers including lcvm, gcc, arm, msvc, tcc and even arduino reference based compilers. At least Keil v5 is based on the arm reference compiler. We have not found a c compiler yet that cannot be used, from 8 bit compilers all the way to 64 bit compilers. As a result I expect that the problem is either something to do with the build configuration or the compiler switches being used. Send us a list of your errors and we will look closely at it. We will also look at adding Keil v6 to our supported list but that will take time (and money) so don't expect that quickly.

My guess is that gimp is breaking something in the image format once it reaches 150 colors. Have a look through the header bytes of the image and compare that with the code. If you have a debugger that will make it easy to find exactly what ugfx thinks is wrong. If you get stuck, attach the image here and when we get time we will look for you. Note that this may take a while just because of our busy schedules.

Most likely problem is that the pins are not correct or they have not been initialized correctly. Best way to test this is to use a scope and check you are getting waveforms you expect. 2nd most likely problem is that there is something wrong in your controller initialisation. Often chips that as marked with a part number are not actually that part number particularly from Chinese sources. It is often good to check the chip markings match what you were told it was. Sometimes the documentation is wrong. Good luck.

While the bdf format is a bitmap font format, it is not the same as the mcufont format. Some of the parameters (obviously including the spacing) is calculated from the font data itself. I am not sure of the details of what is calculated and what is accepted verbatim from the source font. It will also change depending on the type of source font. Mcufont was generously donated to ugfx, along with a compatible license, in the early days of ugfx. We have maintained it, fixed bugs, and updated portions over time but I wouldn't go so far as to say we understand as well as the rest of ugfx. Good font drawing is an incredibly difficult process particularly on low powered cpu's hence making the value of the mcufont contribution very significant.

As you are using a different filter range (hence the availability of the degree symbol), and possibly because of other parameter changes, it has converted the font differently.

As uGFX initializes the external RAM in the stm32746-discovery board file (and uses that for the framebuffer), any excess external RAM can be used by the application. You simply need to calculate the last address used by the framebuffer and use anything after that. There is however one really big problem with this. Depending on the size of the display, whether you use both front and back display surfaces, the color depth you are using, and the refresh rate of the display, you may find that there is no available bus bandwidth available. Any reads/writes to the external RAM may cause display problems simply because the memory access prevents the display getting the data it needs.

If both black and red are turning out yellow then the problem is more likely in the controller initialization sequence for your panel. If you have any code that can initialize the panel copy that into the gdisp driver and see if that solves your problem.

Thanks for letting us know of the website problems. We will look into them. Glad to hear you found your problem.

If you are extremely memory constrained, only want to do a couple of boxes and some text with no OS, ugfx may not be the best choice for you. There are a number of Arduino libraries that directly drive the display that may be better. uGFX is intended as a full graphics library and windowing system but one that can run on embedded systems. As a graphics library it is probably heavier than you might want. If however you want to try, the minimum set of modules to turn on is GDISP using the RAW32 or Arduino version of GOS. If you look in the gfxconf.h file you will see all the options that can be turned off and on.

uGFX can work with no buffer at all provided pixels are individually addressable when talking to the controller and the controller itself maintains an internal framebuffer. When that is not the case the driver needs to maintain enough of the screen image that it can merge pixel drawing operations into the existing screen image before sending the merged data to the controller. In practice it is typically controllers driving displays of less than 1 byte per pixel that fall into this category. As the buffer is managed by the driver, the buffer can be in any format that works for the controller, be that expanded to one pixel per byte, packed into a byte stream (like most uGFX monochrome drivers), or compressed in some other way.

That is a better question to be asking in the ChibiOS forums as it does not really relate to ugfx. Try some of the pure ChibiOS test programs for threads. Similarly ugfx has a demos/modules/gos/threads test program to test ugfx's api abstraction of the underlying operating system.

When you first power on do you see the logo? I would suggest that you start your debugger and follow the chain of execution. It is not expeced or common to see the problem you describe.

Have you edited gfxconf.h to enable GFX_NEED_GDISP (set it to GFX_ON)?

There are a number of options on how the flush actually works depending on your gfxconf.h settings. Normally the flush occurs after every low level gdisp draw routine. The gdispImage calls internally use low level gdisp routines and so the image is flushed continually as each part of the image is being drawn. They way to get around this currently is to set GDISP_NEED_TIMERFLUSH in your gfxconf.h file. It forces the flush to occur on a timer. Due to gdisp display locking even very short timer periods will provide much better results without creating excessive CPU load. The problem will be fully solved in V3 which will provide a nested DrawStart/DrawEnd type operation. The image calls will be updated to use this new Draw synchronisation mechanism and therefore the image will be flushed only when the complete image is drawn even if GDISP_NEED_TIMERFLUSH is not used. Unfortunately this operation is too complex to back-fit into V2.x as it requires some of the new capabilities that V3 gdisp will provide.

The problem does not occur for most people as GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE is specified in pixels (not bytes). The issue occurs for pixel formats of a byte per pixel or less. This has now been corrected by using the compiler to detect if it is too small and adjust the setting if necessary (along with displaying a warning). This is now in the repository.

This is now fixed and in the repository. Thanks for finding it.

You only need one gListener object for the entire gwin system. Registering callbacks for gwin objects is unnecessary and is not a good idea. Create a listen loop instead like in the demo programs. See the widgets demo for a comprehensive example. In the loop you can always switch on the object handle in the event structure to call individual functions if you want to.

Your method of setting a timer is already an implemented option in ugfx. Check the flush options. You just need to implement the board_flush and set the option. Ugfx will then call your flush routine when and if needed. There are 2 ways to prevent corruption (after sing he inbuilt timer flush)... 1. Make the copy back a synchronous part of the flush routine, or 2. Start the copy back in the flush with a muted lock that is released when the copy back completes. Te driver pixel draw routine then needs to have a test to see if copy back is complete and if not wait until it is.

V3 code base is not available yet . You don't need to worry about the v3 changes except in 2 areas... 1. If you have a customised driver 2. If you are playing with the internal ugfx code The V3 includes extra functionality and improvements to the single file make system. For non-single-file-make everything will remain the same except that the linking of drivers will change slightly. From an application point of view it is fully compatible with the V2 Api .

V3 is very dependant on available resources which, given that we are full time on commercial projects, is happening much slower than we want. Unfortunately we have to prioritise commercial projects. What this shows is that v2.x is still very good and very current. V3 adds new capabilities and makes improvements in compiling and the gdisp api but is a very big change internally that means it is slow to release. In conclusion, v3 will be soon but no published eta yet.