inmarket

Most likely cause for this is that the include directories path is not correct. I am not sure how to specify these in your ide, probably in the compiler options. These end up as -I directives in the compiler arguments. The -I directives must include the directory containing those stm header files.

BTW, a native image in ugfx terminology is a image that has the same pixel format that the ugfx system uses in an unpacked pixel arrangement (maximum of 1 pixel per byte, word or dword depending on the number of the pixel bits)

You can use the BMP image handling in ugfx. BMP images support a 1 bit per pixel format. The only thing you may need to do is to fabricate a BMP header. Because BMP also support RLE encoded formats you may also be able to compress your 1 bit images and so save rom/ram. Writing a bitblit routine for your driver to handle your "special format" image is probably not the best way to handle this. Similarly with your alpha request, use the image processing support built into ugfx. For example, ugfx handles transparent gif's. It also handles PNG images with an alpha channel although alpha blending is supported to varying degrees based on your display controller.

Ginput handles mouse or touch events and any other input such as keyboard.

It sounds like something is going on with your memory allocator. The uGFX logo is actually not an image. It is a series of rectangles drawn on the screen. It is therefore possible that this call is the first call to the memory allocator. That is something you can test and debug. The other possibility is that the image is corrupt somehow. This is easy to check by looking at the parameters that are going to be used by the palette allocation and seeing if they are reasonable. Another possibility is that you have stack checking turned on in your compile. Many memory allocators are assumed to be single threaded and will hard-fault if running on a thread on a stack other than the main threads. Given you are running FreeRTOS which is multi-thread aware you can assume that its allocator is multi-thread capable however still check that you are compiling without stack checking turned on.

Last I tested that was sufficient.

Generally you would read the analog input in the dial driver directly. GADC is designed for when you have a single ADC device with multiple inputs, some of which you want to use for high speed sampling e.g. for audio, and some for low speed sampling such as dial devices. There is currently only one GADC driver, for the SAM7 cpu which has a single ADC that reads 8 input lines simultaneously. GADC is then required to pick off samples at low frequency from sampling that is occurring much faster say for the purpose of GAUDIO. If you are not in such a circumstance GADC is probably overkill and the dial input analog input can be read directly in the dial driver.

I have finally had a chance to check the line in question. That line is never used - it is a comment put in for use by the documentation system doxygen. You can see the corresponding conditional compilation on line 132. The line that actually gets used is the block of macros between line 304 and 313 for true color pixel formats. So, in a proper compile it will correctly generate the color mapping.

If you want to create a latched button use the checkbox instead with a button draw routine instead of the normal checkbox draw routine. The draw routine already exists and the checkbox provides the latched button state and events you are after.

Glad to be able to help.

Each display driver creates a GDisplay object to hold its run-time data. The first display in the system gets assigned to the GDISP pointer. All drivers, of any type, are maintained in a GDriver list. In your case because the init process is not happening correctly GDISP is totally invalid.

This looks like GDISP is set to some random value in flash. It is certainly not valid. The GDISP variable is not initialised until after the first display driver is initialised so don't expect it to be valid until after that. With regard to eclipse - I don't use it but I know there are many in the community that do. Personally I much prefer the make system - just create a makefile (I can't remember off the top of my head where the master example one is) and it does everything for you.

The problem here is a build problem. GDISP builds in 2 possible modes - single display and multiple display. Which it uses is a complex combination of include paths, variables in gfxconf.h and linking. The build results in quite different code for the two options. If your gdisp_lld_init is not being called it means you have this process wrong. First GDISP_TOTAL_DISPLAYS, GDISP_DRIVER_LIST and GDISP_PIXEL_FORMAT should not be defined at all in your gfxconf.h for a single display. Instead the specific driver directory you want to use should be on your compiler INCLUDE path and the specific driver files should be included in the build. Also, the various _options.h files should not be altered. All your customizations should be in your gfxconf.h file. See the example demo programs and the provided gfx.conf.example file in the top directory. In general look carefully at the provided build files and the wiki if you have any questions.

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.