inmarket

I suspect this is a property of the lcd panel itself. I haven't had time to investigate in great detail. Evidence that suggests it is the panel is that the f4 board using the same ltdc driver code but with a different panel displays much better. This is not proof though - more investigation is required. It is interesting to note the stm examples for the board (carefully) avoid images that would show the problem.

No. We work on it as we have spare time. We are currently in the api design and proof of concept stage. When the api design is largely complete we will release the doco for public comment.

That stm hal file will need to be added to your makefile instead of trying to include it from another source file.

Don't replace __IO with extern, just remove the __IO. That should make the definitions compatible and it should then compile. Annoying the way ST keep changing their definitions.

Have a look at this post...

The easiest way is to write a GFILE interface for your SPI Flash. GFILE interfaces are pretty simple. You don't even have to support a full file directory if you are using the entire SPI Flash to hold a single file - just hard code a filename match against say "SPIFlash". As the flash is non-addressable you will need to reserve some RAM as a "block buffer". I would suggest going no lower than about 8 bytes for that buffer. Obviously the larger the RAM buffer the faster image rendering is likely to be because more of the image will be in RAM at any point in time.

This is caused by an update to the STM32 HAL header files since we wrote the f7 support. In the STM32 HAL file stm32f7xx_hal_dma2d.h it is now defining structure field members as "Blue", "Green" and "Red" which are macro predefined uGFX colors. The solution is that the uGFX colors Red, Green and Blue must be #undef'd before the STM32 header file is included but after the uGFX header file is included in file boards/base/STM32F746-Discovery/stm32f746g_raw32_ugfx.c In uGFX V3 we will be renaming the colors so that these conflicts are less common but we can't do that yet as that would break many user programs. I have pushed an update to the repository that contains that change (although I haven't tested it). Let me know how it goes.

Not easily in ugfx V2. V3 (which is still in the design phase) is likely to have a mechanism to handle this. The solution for uGFX V2 is to copy the source code for the button to your project, rename the create routine to something like gwinButtonExCreate() and then alter the mouse down code so that it doesn't call _gwinUpdate(). For now this is the simplest solution.

The chibios3 and f7 result you are seeing (white screen with no action) is exactly the strange incompatibility problem we were talking about with chibios3 and the f7. We have not got to the bottom of that yet despite spending considerable time on it. The raw32 compile error is not a problem we see. I suspect that the definition of the symbol LSE_STARTUP_TIMEOUT is missing for some reason. See if you can find where that definition is. I suspect it should be in the stm32 hal header files.

Sorry it has taken me a while to reply. I had trouble viewing the video on my phone. There are a couple of posdible causes for this type of flicker... 1. There is a hardware contention between the touch and the display. Easy test: turn off the drawing when you get a click event. If you still get the flicker when you touch then it is likely there is a pin connected to both devices or being driven by both devices. 2. The stm32f4 will be struggling running at that size display based on our previous tests. Look carefully at the fmsc parameters for the ram access to the sdram and tune them as much as possible to give you the best possible bandwidth. If you are bandwidth deprived you will definitely see results like you are seeing as the ltdc cannot supply the data fast enough to the panel leading to the image shifting you are seeing. 3. Check for anything that has higher priority than the ltdc controller. Check interrupts and other devices (particularly those to do with the io for the touch). Anything that takes too long at a higher priority that the ltdc can cause the issues you are seeing. I hope that helps.

Yes there are definitely problems with chibios v3/16 and ugfx on the f7 platform. Looking at your error message however seems to be pointing to a problem in your makefile. It can't find the demo makefile and it seems to have double included the ltdc driver. Check your makefile carefully.

Studio is cuurently 64bit only. The compilers/toolchains are available from multiple sources in both 32bit and 64bit versions. The pc vs w32 change seems to be a cygwin difference between the eabi and the elf versions or in this case the toolchain for compiling windows programs versus those to compile command line programs hence it complaining about main(). We will look at updating the wiki when we have had a chance to test it with a new version of cygwin.

In any decent sized system like uGFX there will always be internal functions that someone eventually wants to use to extend the functionality. On one hand we want to keep support functions private (static) to avoid cluttering the api and to prevent misuse but on the other hand sometimes those functions are useful to someone else. There is no perfect solution. When this occurs code must either be copied or the original code modified (which makes upgrading more difficult). For your new gdisp function adding it to gdisp.c would appear to be the correct solution. I am currently in the phase of playing with api and build structures for ugfx v3. It has given me the opportunity to re-examine decisions made in the past. As part of that, the problem you are describing may go away as i am planning to add an "extension/plugin" facility that would enable you to add and test new core functionality without modifying the ugfx code itself (in most cases). Stay tuned for more details over the next few months on ugfx v3.

It is interesting your compiler is complaining about that when it is defined in the c standards that an undefined macro is to be treated numericly as zero for expression evaluation (which in turn is evaluated as false). Thus your compiler is giving invalid warnings. Having said that, in ugfx we have tried to predefine each macro so in this case it means that either a) we have missed the predefinition of those two symbols, or b) there is something wrong with your compile setup. We will check the code but if your compile is working you can certainly ignore those warnings (or turn them off with compiler flags).

I checked the code and a define I thought was there wasn't so I have added it to the code in the repository so that you can use your external FATFS library. The new options are GFILE_PETITFS_EXTERNAL_LIB and GFILE_FATFS_EXTERNAL_LIB. Please read the documentation carefully about the options as they impose restrictions on the implementation of some of the sub functions required to make fatfs work. The relevant documentation is in src/gfile/gfile_options.h I haven't tested the new options. Please test them and let me know of any changes required so that they work properly.

Post 1. The short answer is that this is possible. The long answer is that i will need to review the code to remember the details. It has been a big day at work today, I will try and answer in the morning. Post 2. The diskio base routines are kept in a file that is #included. Currently there is only an implementation for Chibios. Even for Chibios it should be possible to override the default implementation by declaring a file of the same name earlier in the include directory list. I think there are macros that control that. Again i will try to check in the morning and let you know more specifics. Hopefully that gives you a clue on where to look if you need it solved before i can check tomorrow.

Adjust the pixel values passed in the polygon points array to fix the appearance. If you can then post the changes we will make equivalent changes in the other standard controls. I suspect adding 1 to each x value on the right hand side of the polygon will fix the appearance problem. I asked if you could please do it and let us know as currently i am working on uGFX V3 api and dont have time to test it.

Yes it is true that the polygon fill is asymmetric by 1 pixel on the right and it is intentional behaviour. It is mentioned in the polygon filling code in the comment about polygon joining. I guess however that we should adjust the arrow definitions to compensate. Can you please test the numbers for the right arrow edges to correct the problem and we will add it to the repository.

So the answer is: gwinGetDefaultBgColor () There is obviously a corresponding set routine.

Yes. The bacground color in the widget is its own background, not the background color of the underlying surface. When a widget is hidden its parent is checked. If the parent exists and can draw itself that region is redrawn by redrawing the parent with a limited clip area. If there is no parent or the parent can't redraw itself (eg graph), it uses some background color - i can't remember which one right now but i think the code is in gwin_wm.c although i am not positive about that. Note ugfx doesn't understand overlapping windows so it is the strict parent/child relationship that determines underlying aurface redrawing. I hope that helps.

It is exactly the same as any operating system delay function - the delay is affected by the resolution of the tick counter used by the operating system. A tick counter of 1ms will of course give a resolution of 1000us. There are only one way around this... 1. Hardware support for a more accurate timer that is busy polled with interrupts disabled. Operating system calls that pretend to offer high resolution timing without busy polling are lying as simply switching tasks is an expensive operation. So, as far as this routine is concerned both the required hardware support and the busy polling (with interrupts off) are a problem. In practice this routine is never used in any vanilla ugfx code. In the next major version of ugfx it will be removed.

The issue is the maximum number if open GFILE handles. To conserve resources a low limit has been set. You can increase this number in your gfxconf.h file and it should fix your issue. Each open image requires one open GFILE handle.

You have to be careful comparing with the define TRUE. C defines any non-zero value as logical true. The define TRUE represents only a single true value from the set of true values. The define FALSE however is the one and only false value. Note that even in ugfx TRUE will be defined as either 1 or -1 depending on the compiler, the hardware platform and the embedded operating system. Similarly the bool_t type may be a bit, a byte, or even an int. Additionally there is no guarantee that !FALSE == TRUE as that depends on the compiler and the value defined for TRUE. On some compilers the compiler may even give different values for !FALSE in different circumstances. In reality this is a consequence of their being no real boolean type in C. Some compilers add a boolean type as a language extension but it is still non-portable and the same problems may still exist depending on the internal machine representation of that type. Thus to say "if (xxx == TRUE )" is very bad code. You should either say "if (xxx)" or "if (! (xxx == FALSE))". The define TRUE is thus useful for assignment to a bool_t type but it is worthless as a comparitive value.

Provided you only have one plotted y point for each x value (as per your diagram) you can store the y values for each x value in a simple array. This would make it easy to redraw. A similar strategy is used by the gaudio oscilloscope demo. That demo creates a custom gwin control that uses the above strategy to get smooth updating of the oscilloscope. Once you have stored values it is easy to get your widget to redraw when the covering box is removed.

I have added the SSD 1848 driver to the repository (with some minor changes). Many thanks Czhou.