Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by inmarket

  1. uGFX can work with no buffer at all provided pixels are individually addressable when talking to the controller and the controller itself maintains an internal framebuffer. When that is not the case the driver needs to maintain enough of the screen image that it can merge pixel drawing operations into the existing screen image before sending the merged data to the controller. In practice it is typically controllers driving displays of less than 1 byte per pixel that fall into this category. As the buffer is managed by the driver, the buffer can be in any format that works for the controller, be that expanded to one pixel per byte, packed into a byte stream (like most uGFX monochrome drivers), or compressed in some other way.
  2. 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.
  3. 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.
  4. inmarket

    Compilation error

    Have you edited gfxconf.h to enable GFX_NEED_GDISP (set it to GFX_ON)?
  5. 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.
  6. 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.
  7. This is now fixed and in the repository. Thanks for finding it.
  8. 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.
  9. 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.
  10. 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 .
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. The "blinking" you are seeing is because your display communication is slow (SPI) and you are constantly updating the display.
  18. Please stop the chatter. The group is alive and well. We do however get very busy supporting real paying projects so our support on this forum is in our spare time and on occasion it can take a few days for us to reply. If you want the Beta please follow the instructions. Asking to be included here will not help.
  19. Editing chibios.c/h is the way to go. We have already added support in our uGFX v3 code but that is significantly different to the current V2 code base. Due to the significant changes for v3, V2 is currently in lock-down (emergency bug fixes only). V3 is not yet available for the public as changes are still in progress.
  20. There appear to be 2 things it is complaining about... 1. It is missing the math library. Add -lm to the link line. 2. It appears you have turned on mouse support but have not included a mouse driver. The raspberry pi uses the standard Linux event device if running in framebuffer mode, or the X input driver if running in X mode.
  21. GwinPrintg uses the internal printg framework which requires gfile. GwinPrintg effectively creates a pseudo file based on each window. This in practice is a very efficient use of code reuse. For now enable GFILE and the "string" sub-system as that enables sprintf equivalent functionality and the string sub-system is tiny. I will look at how easy it is to change the code so it can either be used without GFILE or at least without any sub-module file-systems turned on.
  22. And the development boards for these chips are generally cheap eg a STM32F4-Discovery board which includes the LCD is somewhere around US$25 from memory.
  23. The problem is that you are assuming that the source and destination bitmaps have the same line width or that you are even drawing the full width of the source bitmap. Note CX != X2. Similarly you are not using the starting position x1,y1 for the source bitmap. Passing the extra info to your draw routine you should be able to recode the X,y loop to fix the problem.
  24. Note you can also use the command line binaries for windows or Linux that are found in the repository under the tools directory. The binaries have none of the restrictions of the web version.
  25. The trouble here is that you get any two devices from different sources and they will possibly have different alignments between the touch screen and the display screen. To make things worse very few devices are well aligned physically. Also the resolution of the display seldom matches the resolution of the touch panel. What this means is that floating (or fixed) point multiplication is needed in 99% of cases whether or not that is via fixed calibration settings. Despit this we have implemented fixed alignment code as an option for some drivers but that doesn't work for all devices (as you have already discovered) due to the reasons above. In V3 we are looking at providing better fixed alignment code that caters for more orientations but for now the correct solution is either a custom driver hack or, preferably, the fixed calibration matrix.
  • Create New...