inmarket

If you made any changes to get it working can you please post them here (as ay zip file) or create a pull request on the repo. Great work on getting it going!

I would love the patch. You can either attach it as a zip file in this forum or send a pull request on the repo. I will make sure it all gets updated in the master repo.

Always try the existing code first before playing with the init sequence as there are commonly things not mentioned in the datasheets. Also sometimes extra code has been added to handle clone chips (which can be very hard to distinguish from the original physically). Only change the init sequence if it doesn't work for you and even then change it as little as possible to get it to work.

I have no idea with the driver initialisation as this is not a driver I wrote or a display I currently own. I could check against the datasheet but we all know that has little meaning as the datasheets are often incorrect or incomplete or the silicone has bugs etc. To date each driver has defined its own routines that the board file has to implement. Whilst many drivers are similar there is no real standard. This particular driver writer obviously didn't handle/debug the 8 bit bus case. This inconsistency is part of why the uGFX v3 gdisp driver interface is changing. A lot of these issues will be fixed. That doesn't mean however that a deiver won't have bugs when used in a situation that hasn't yet been tested. Unfortunately that just naturally happens.

It looks to me that this driver has been written with written with a 16 bit bus. The only time a 16bit bus is actually treated as a 16bit bus is after the 0x2C command and the one place that would need to be changed for an 8 bit bus (other than perhaps some initialisation sequence) is line 280. Change line 280 to write_word(g, gdispColor2Native(g->p.color)); write_word() would then be defined as write_data() for a 16 bit bus and as two write_data() calls for an 8 bit bus. eg... #ifdef GDISP_ILI9481_8BITBUS #define write_word(g, data) { write_data(g, (data)>>8); write_data(g, (uint8_t)(data)); } #else #define write_word(g, data) write_data(g, (data)) #endif If you want to make a patch and test that it works we can incorporate that into the repository.

In uGFX, children windows are always clipped (and resized) to their parents. To do anything else is incredibly complex would require lots of code and significant amounts of RAM. As Joel said, the correct solution is a custom draw on the container that will draw the 2 half images

At the moment the best template is the source code of another driver that operates in a similar way.

uGFX V3.0 is now (intermittently) compilable. Adding GBUS (see below) may have broken it today but generally the V3.0 branch will now compile subject to certain restrictions. Those restrictions currently are: Win32 platform only (GFX_USE_OS_WIN32 = GFXON) Only with functionality in the GDISP basics demo Some more new features for uGFX V3.0: gColor, gPixel & gPoint replace the old types color_t, pixel_t, point & point_t. Again the old types are still available if you have set GFX_COMPAT_V2 A new config option GDISP_NEED_ORIENTATION has been created. Orientation support (being able to rotate the whole display) can add a fair bit of code and tends to be either used or not depending on the application. Orientation support used to be part of the GDISP_NEED_CONTROL option. We are trying to implement display orientation support that is provided by the GDISP layer itself even when the display controller doesn't support it. While it may still work for a display controller with no orientation support, it may operate a little less efficiently. Final details on this feature will be released once more of the new GDISP driver architecture is finalised. All GDISP drivers (and hopefully all other drivers by the time we are complete) will be able to be included by defining an option in your gfxconf.h file. This then makes all such drivers compatible with single-file-make scenarios. There will be no need to separately compile or link the driver into uGFX. A new module GBUS has been added. Many drivers require access to a hardware bus of some sort, be it parallel, SPI or I2C. Previously each bus call was enumerated in each driver board file. What this meant is that there was a lot of code replication between boards and it was easy to get the hardware interface wrong. With the new GBUS module you will be able to use any of the predefined bus types and just hook it to your driver in the board init call. This will significantly simplify using a custom hardware interface or pin-out with a standard peripheral such as the LCD. A single LCD driver could then theoretically work on a SPI, I2C, 8bit parallel or 16bit parallel bus simply by changing the bus that is connected to the driver (subject to the controller supporting that). It also means that complexities such as pin initialisation, busy waiting vs yielding, DMA or non-DMA can be transparently handled for the user ensuring the most efficient mechanism of talking to the bus. While no drivers for GBUS have yet been written, some of the drivers might be things like STM32_SPI_WITH_DC, STM32_I2C, STM32_Parellel_8bit, STM32_Parellel_16bit, STM32_Parellel_16bit_over_8bit_MSB_first, AT91_SPI, MSP430_I2C, ChibiOS_SPI, ChibiOS_Parellel_8bit etc. Although not finalised yet, we are looking to add new integer trigonomic functions (eg sin, cos, atan2) that rely on integer boundaries and table lookup to provide very fast trigonomic operations with high accuracy with very small table sizes. With a 256 byte table (held in flash/ROM) the angular accuracy should be around +/- 0.35o (0.006 radians). Unfortunately the API will be different to the existing uGFX V2.x trigonomic API as the old API simply couldn't represent any angle less than 1o. GFX_COMPAT_V2 will allow the old API to still be used albeit with its existing limited resolution. Call for assistance: uGFX V3.0 is going to be a big job to release. At this stage we are hoping for around June/July but there is no guarantees that we will be even close to that date. We would therefore be very interested in any one prepared to help with testing V3.0, or with converting drivers to uGFX V3.0 as we get closer to the release date. Please send me a private message if you are prepared to help and in what capacity and/or how much time you can commit. Depending on the response we may be prepared to offer (minor) incentives eg perhaps a commercial license, an embedded board, early access to the new version of uGFX Studio or something else that interests you. No promises here though - we just want to make sure you know we appreciate your efforts. That's all for now. We will let you know when something else interesting happens.

Looks like you have broken something with that change. Better to put it back to what it was as the likely problem for both symptoms is an error in the initialisation sequence.

The current STM32F469i-Discovery board files have been added to repository. Note it is not a complete (or tested) board file definition yet. I have just added it to the repo so that it doesn't get lost over time.

The current STM32F469i-Discovery board files have been added to repository. Note it is not a complete (or tested) board file definition yet. I have just added it to the repo so that it doesn't get lost over time.

This has now been added to the official repository.

You always need some support functions. RAW32 is exactly that - support functions designed for use when there is no operating system. In your case you need to turn off GFX_USE_OS_RAW32, GFX_USE_OS_RAWRTOS or any other GFX_USE_OS_xxx symbol and then add your own GFX_USE_OS_MQX. The required routines in your gos_MQX.h etc are well defined in gos.h and the api documentation and there are plenty of other operating system examples to copy from.

That will be the GDISP_PIXELFORMAT in the gdisp_lld_conf.h file. Change RGB to BGR or visa versa. Alternatively their is usually a controller init command the controls the pixrl direction.

I will look at the code to check at the first opportunity.

You won't be able to use pixmap as pixmap assumes an addressible framebuffer. What you can do is create an equivalent create function for your ra8876 driver that allows creating a display surface in the extended ram of the ra8876. Note you won't be able to use the image equivalent appearance of the pixmap and the standard gdispBlit routine because again the virtual image and the blit functions need the image bits to be in addressable ram. The way around this is to have a ra8876blit routine for transferring the offscreen images to the onscreen image.

There is no problem with that - a ghandle is effectively just a void *. Just be aware that if you exit the function without destroying the window you have lost the pointer to the window. That may however be perfectly acceptable eg a label on a container. After creation there may be no future need to access the label seperately from its container.

MISRA C is not something we have investigated yet. I will have a look as soon as I get an opportunity.

Very nice. Thank you. We will add this to the official repository as soon as possible.

Pursuing this would be very difficult currently. Replacing the font engine (even with a hardware based engine) would require major changes to lots of uGFX code and in the most complex area of uGFX. If you really need to do it let me suggest that this not be attempted in V2.x. Wait until V3.0 is released and then we can start this conversation again as it would need to be reimplemented for V3.0 anyway.

No, I am saying that uGFX has always ignored line_height and used height instead. The reasons are historical and difficult to change without affecting previous application code. If we make the change it will be on a major version change (eg the change to V3.0) and will be disabled for applications compiling with V2 compatibility. Thanks for the reminder. I should add it to the V3.0 development list.

Comment out the GFXBOARD definition in the first makefile.

I prefer to test for the previous operation completion before starting a new operation (eg in gdisp_draw_pixel) rather than testing for completion of the operation before returning. The reason is simple, doing the test immediately before any new operation allow as much asynchronous operation as possible. The cpu can be preparing for the next drawing operation while the previous operation is still completing.

All the board make does is add a makefile from the uGFX boards directory. If you are running a custom board you can do ine of two things... 1. Just include your board level stuff into your project directory. 2. (Recommended) Create your own board directory with your own board files and a board makefile outside the uGFX tree. Include this makefile after the source macro definitions (but before the 3 master includes at the bottom) into your top level project makefile.

It may not restrict you from putting it in the driver config file - it is just the wrong place to put it. It is a global setting for a user to change on a per project basis hence its placement in gfxconf.h If you fix your gdisp_fill_area routine I think that looks to be quite suitable in terms of speed.