inmarket

This driver is now in the repository.

Thanks for reminding me about the WS29EPD driver. It is now in the repository.

There are a few EPaper drivers already in the repository that you can use as a template. The ED060SC4 driver handles an EPaper display without a controller chip. The UC8173 driver is probably the most complete EPaper driver, even supporting loading of temperature and waveform profiles. I think the UC1610 is also an EPaper controller. I don't know how close any of those are to the HAT EPaper display that you have (or the Waveshare driver in the above post by cpu20) but it should give you an idea.

I won't be changing this double const currently because... It is valid C syntax and to remove the double const is actually ambiguous, GCC only produces a warning (except when someone has their flags set to nasty), If you really want to make it go away in GCC you can add that pragma to your gfxconf.h, It is all going away shortly in V3 as the way the structure is being stored will be changed, and I am stubborn

This has now been added to the official repository (slightly altered for better future proofing).

Have you added a GDISP driver as per the instructions?

GFX_OS_NO_INIT should definitely not be true for RAW32. You will not need to define the compiler or the endianness unless our autodetect gets it wrong in which case let us know so we can fix the autodetect. With RAW32 the specified heap size is declared as a static byte array of that size which the RAW32 memory management calls then carve up to satisfy memory requests. Given the above settings being correct there are some possible problems... 1. The specified size is too small for what you are trying to allocate and you are just running out of memory. 2. The specified size is too big and your stack is growing down into the top of the memory array thereby corrupting it. 3. There is a bug in gfxRealloc. This we consider unlikely as the code has been well tested but it is not impossible.

Yes, that is the one. In this case as it seems your compiler is gcc based you will need to change the compiler options/flags so it treats it as a warning not an error. The other thing I noticed is that you seem to be compiling main.cpp when the error occurs. Note you cannot include the gfx source into a cpp file as gfx requires a C compiler not a C++ compiler. The .h files can be included however because they are suitably wrapped to make them C++ compatible.

The fact that gfxReAlloc is returning 0 is the problem. We really asking the operating system to increase the size of the allocation and it is failing. So, what operating system are you using? Do you have enough free memory available for your allocator to be able to expand the size of the memory block?

We have just pushed another major step towards V3. This version replaces types such as bool_t, int8_t etc with our own internal typed gBool, gI8, gU8 etc. As always the old types are still defined and compatible because GFX_COMPAT_V2 is set to GFXON by default. Internally we are now using a mix of the old and new types however that will be updated over the next few commits to just use the new types. In the mean time we ask that people please test their compilation with the new source to make sure we haven't broken support for your operating system or compiler. If we have please let us know via the normal support forum/topics.

Hardcoding the values is a great option for a one-off device. For a production run that is obviously too unweildy as each device will require different calibration values. In that situation a load/save is best as it can be calibrated once during manufacture or on first startup and it will be correct thereafter.

Yes, you are right.

Very nice!

If it is a non-cycling multi-family GIF image the last frame will return TIME_INFINITE. If you want to start at the beginning again just call gdispImageNext again. So to turn a non-cycling GIF image into a cycling image just replace a TIME_INFINITE delay period with a set period that you want the last frame displayed for before restarting.

Good idea but difficult with the current software (to be fixed in V3) because the board interface is different for each driver although there are a often a lot of similarities between them for the same driver type. In general any current documentation (if any) will be in the template board file found in each driver directory. If you have specific questions please ask here.

Are you initialising freeRTOS correctly?

Another trick you can use is in the init_board routine set the g->board field to a structure that contains register pointers and pin definitions for that display. Each display has its own g->board field. In any other routine you can use that field to access the structure and thus not have to switch on every operation.

Simply remove the GDISP_TOTAL_DISPLAYS setting from your gfxconf.h. That setting is designed for when you have multiple displays all using the one controller type.

There are two ways to implement multi-tasking.. 1. Write an assembly language routine for each CPU variant, or 2. cheat by using setjmp and longjmp. Method 1 is used internally by FreeRTOS and any other multi-tasking operating system. The operating system writer has done all the hard work for you. Similarly for our BareMetal (RAW32) port we have written assembly routines for the Cortex Arm 0 to 7 series of processors. Method 2 works because setjmp and longjmp are supposedly a standard part of the C library and therefore this method should work everywhere and on every CPU. The problem here is that sometimes the C library is missing these routines, sometimes it is buggy (setjmp and longjmp are usually not well tested by the library writers), and sometimes a C library from an not-fully-compatible CPU is incorrectly used. Stack checking code that is inserted by some compilers can also cause problems although this can usually be turned off with a compiler flag. All of this is to provide general multi-tasking, either pre-emptive or cooperative. These other libraries you are talking about are NOT multi-tasking libraries but rather task execution frameworks (as evidenced by their lack of a yield function). They are not the same and uGFX requires true multi-tasking. We are looking at removing that requirement in future (with suitable restrictions in functionality) but that is definitely well after v3.0 as it requires very large internal changes and considerations.

If the adafruit library supports a rectangular fill then add that as a gdisp acceleration. It will significantly boost performance. It can still never match the underlying adafruit library as it has its own overheads and it uses the adafruit library, but it will improve the gdisp performance significantly. By the way, the layering of gdisp over another API is what the Win32, Linux-X, SDL, and OSX display drivers do too. While it has a performance impact over the native library it is a quick and easy way to get started with uGFX and provides great portability. A specific driver can be added later eg linux-Framebuffer.

Nice work!

Note you should only set GFX_USE_OS_FREERTOS if you really are using the FreeRTOS operating system. The problem with the paths is caused by the Arduino IDE itself. Normally you will add the FreeRTOS directory to the compiler include path. The Arduino IDE doesn't support that and uses a crazy "library module" scheme hence requiring changes to the sources that are different to every other compiler. Whether there is some way to fool it or not is another matter - I haven't had time to investigate in enough detail.

First note that the sense of the parameter between uGFX and the adafruit code is reversed. Second, the startup reset delays for a controller chip are normally documented in the controller data sheet is. It is a controller specific property once the power supply is stable (which it definitely should be by this code stage). So, in this case there are three possible problems... 1. Whoever wrote the board file didn't notice the parameter is logical level not pin level and was therefore holding the controller in the reset state, or 2. The driver writer did not include delays as per the dataset, or 3. The controller is a cheap Chinese equivalent with significantly different speed properties. Nevertheless, your idea of making it a single board level routine has some merit. I will look at how it can be used in V3 which uses a gBus module for all io of this type.

The init is called seperately for each display. There is a integer field in the GDisplay structure that reports the display number on the controller and another field that reports the display number in the whole system. See some of the example template board files for various controllers, you will see a switch statement in the init function that demonstrates how 2 displays on the one controller type can be used.

1. Yes. Most micros don't have enough RAM for a framebuffer so uGFX (unlike most graphics libraries) doesn't require one. Three are a couple of exceptions - when the display controller requires one, and where the controller is not pixel addressable (eg sub 8 bits per pixel). 2. V3 is a work in progress that is taking much longer than originally intended due to there being more work involved than we expected and we have had fewer resources to devote to it than we expected. We were hoping it would have been out by now but it isn't, and so I am now reluctant to put time frames on it. Hopefully soon (read that as months not weeks).