Jump to content

Support for Digole displays


Nikki

Recommended Posts

Hi,

I'd like to try uGFX with Digole display. It does not have frame buffer interface. It is connected over serial bus (uart, spi or i2c) and controlled by high level graphic commands like: draw_pixel, draw_line, draw_circle, draw_rect, draw_bitmap, move_rect_area, set_clip_region. It also have some flash onboard, and command sequences can be stored in it and replayed as macros. Also it has loadable fonts and can render text by itself. Here is the command reference: http://www.digole.com//images/file/Tech_Data/Digole_Serial_Display_Adapter-Manual.pdf

The serial bus limits the speed of rendering, so the window driver mode it possible but impractical. I'd like try "point and block" model. However I cannot understand quite well how can I make use of accelerated Digole's commands draw_circle, draw_bitmap, move_rect. Or is it possible at all.

Link to comment
Share on other sites

Hi,

I think you can search where gdisp_lld_fill_area() is called when you draw rectangle primitive, implement draw_circle as gdisp_lld_draw_circle() and add call to this funtion in circle primitive routine same way as it is called in rectangle and proceed with each accelerated functions.

Link to comment
Share on other sites

Adding your own accelerated functions is generally not a good idea for several reasons:

  • It disrupts the driver model and makes it incompatible with every other driver and with multiple display scenarios.
  • It makes it incompatible with work currently progressing on uGFX V3
  • It creates a custom modified version of uGFX that cannot be updated easily as we change uGFX or fix bugs
  • Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)
  • On most small controllers, the accelerated functions actually perform slower than the mechanisms we use to accelerate drawing despite the SPI interface. The reason is that the controllers simply do not run fast enough silicon.

 

Link to comment
Share on other sites

I feel like we should add those interfaces ourselves anyway. They can easily be added, it's simple to maintain and using #ifdef macros means that it adds zero overhead to drivers that don't use it. I need hardware acceleration of primitives myself or another upcoming project anyway.
However, everything that @inmarket mentioned still applies though.

 

15 minutes ago, inmarket said:

Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)

Note that this doesn't apply to owners of a commercial license.

Link to comment
Share on other sites

I have to point out that at this moment it is hard to implement uGFX driver for displays that works in approach of command list (this is similar situation as with FT80x), since they have clear limitations with standard pixel drawing method. It can create huge value for some customers if uGFX could create list of primitives to share with graphic coprocessor, since it can allow better styling capabilities than enginge built in hardware driver. As far as I know uGFX would be the only library to provide such behavior at the moment.

What I meant was contribution to the library with expansions (hopefully) consistent to current design patterns by simply adding new Optional Routines.

 

EDIT: there will be still some problems with handling texts :(

Edited by chodzikman
Link to comment
Share on other sites

14 hours ago, inmarket said:

 

  • It makes it incompatible with work currently progressing on uGFX V3
  • It creates a custom modified version of uGFX that cannot be updated easily as we change uGFX or fix bugs
  • Unless those modifications are submitted back to the repository it will breach the license agreement (any custom modifications to uGFX itself need to be contributed back under the license agreement)

I have no problem with sending back my patched to uGFX. I'm rather worrying of the fact the V2 is at the end of its life, so there is no reason to improve it at the moment.

It would be great if accelerated circle and text drawing and font loading functions will be supported in V3's driver model.

Link to comment
Share on other sites

6 hours ago, Nikki said:

I have no problem with sending back my patched to uGFX. I'm rather worrying of the fact the V2 is at the end of its life, so there is no reason to improve it at the moment.

Things will be ported over to v3. v3 is not just a rewrite from scratch where we will drop everything that we made so far and completely drop v2. The "only" real difference between v3 and v2 will be the underlying (GDISP). driver interface. All the high-level stuff will stay mostly unchanged except for some simple renaming of types and API functions to keep it clean, consistent and to get rid of some namespace collisions. However, there is the GFX_V2_COMPAT macro (which is turned on by default) that maps all these back to the "old" v2 calls in order to stay completely backwards compatible except for the drivers - which we will all port to v3 if they are part of the repository and provide a guide for everybody else to do it with their own ones.

Long story short: Nothing you do now for v2 will be for nothing. If you're working on high-level stuff (everything above the drivers layer) you won't be affected at all and if you made changes to a driver or if you created a new driver you can either contribute it to the v2 repository and we'll port it for you or you can port it yourself to v3 once that stuff is ready.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...