Jump to content

inmarket

Moderators
  • Content Count

    1,241
  • Joined

  • Last visited

  • Days Won

    4

1 Follower

About inmarket

  • Rank
    µGFX Guru

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That is a better question to be asking in the ChibiOS forums as it does not really relate to ugfx. Try some of the pure ChibiOS test programs for threads. Similarly ugfx has a demos/modules/gos/threads test program to test ugfx's api abstraction of the underlying operating system.
  2. inmarket

    Compilation error

    When you first power on do you see the logo? I would suggest that you start your debugger and follow the chain of execution. It is not expeced or common to see the problem you describe.
  3. inmarket

    Compilation error

    Have you edited gfxconf.h to enable GFX_NEED_GDISP (set it to GFX_ON)?
  4. There are a number of options on how the flush actually works depending on your gfxconf.h settings. Normally the flush occurs after every low level gdisp draw routine. The gdispImage calls internally use low level gdisp routines and so the image is flushed continually as each part of the image is being drawn. They way to get around this currently is to set GDISP_NEED_TIMERFLUSH in your gfxconf.h file. It forces the flush to occur on a timer. Due to gdisp display locking even very short timer periods will provide much better results without creating excessive CPU load. The problem will be fully solved in V3 which will provide a nested DrawStart/DrawEnd type operation. The image calls will be updated to use this new Draw synchronisation mechanism and therefore the image will be flushed only when the complete image is drawn even if GDISP_NEED_TIMERFLUSH is not used. Unfortunately this operation is too complex to back-fit into V2.x as it requires some of the new capabilities that V3 gdisp will provide.
  5. The problem does not occur for most people as GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE is specified in pixels (not bytes). The issue occurs for pixel formats of a byte per pixel or less. This has now been corrected by using the compiler to detect if it is too small and adjust the setting if necessary (along with displaying a warning). This is now in the repository.
  6. This is now fixed and in the repository. Thanks for finding it.
  7. You only need one gListener object for the entire gwin system. Registering callbacks for gwin objects is unnecessary and is not a good idea. Create a listen loop instead like in the demo programs. See the widgets demo for a comprehensive example. In the loop you can always switch on the object handle in the event structure to call individual functions if you want to.
  8. Your method of setting a timer is already an implemented option in ugfx. Check the flush options. You just need to implement the board_flush and set the option. Ugfx will then call your flush routine when and if needed. There are 2 ways to prevent corruption (after sing he inbuilt timer flush)... 1. Make the copy back a synchronous part of the flush routine, or 2. Start the copy back in the flush with a muted lock that is released when the copy back completes. Te driver pixel draw routine then needs to have a test to see if copy back is complete and if not wait until it is.
  9. V3 code base is not available yet . You don't need to worry about the v3 changes except in 2 areas... 1. If you have a customised driver 2. If you are playing with the internal ugfx code The V3 includes extra functionality and improvements to the single file make system. For non-single-file-make everything will remain the same except that the linking of drivers will change slightly. From an application point of view it is fully compatible with the V2 Api .
  10. V3 is very dependant on available resources which, given that we are full time on commercial projects, is happening much slower than we want. Unfortunately we have to prioritise commercial projects. What this shows is that v2.x is still very good and very current. V3 adds new capabilities and makes improvements in compiling and the gdisp api but is a very big change internally that means it is slow to release. In conclusion, v3 will be soon but no published eta yet.
  11. Have a look at the gkeyboard drivers. They support having multiple character sets mapped to the same key depending on their mode. Take a normal pc keyboard, it produces scan codes (equivalent to your 4x4 keyboard producing codes 0 to 16) which get translated to ascii characters which depend on the language, the mapping mode eg numlock/capslock, and multi-key combinations like shift. So your 4x4 keyboard is a large simplification on a keyboard such as a pc keyboard for which you already have the driver in the ugfx repository for you to use as example code.
  12. No. gdispFillString always fills the background area first. This may change sometime after V3 is released but for now that is the way it works. A simple way to reduce the drawing is to not redraw the constant part of the string. For example "Temperature: " could be displayed once only and only the temperature itself be updated in your loop.
  13. In your board_SSD1331.cpp at the top of the file above all other #include's try adding... #include "gfx.h" This compile error has likely been introduced in V2.9 because we have changed lots of type names and unfortunately we don't get to test every platform before release. Let us know if this works.
  14. I can't remember off the top of my head if the ST7567 controller is already supported however there are plenty of similar STxxxx monochrome drivers that could be easily modified if necessary.
  15. There are a couple of example keyboard drivers you can copy and modify. Just copy an existing driver, modify it and link link it into your project instead on one of the standard drivers. While this is a bit laborious in V2.x it will be much easier in V3.
×
×
  • Create New...