Jump to content

inmarket

Moderators
  • Posts

    1,295
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by inmarket

  1. Thanks for letting us know of the website problems. We will look into them. Glad to hear you found your problem.
  2. If you are extremely memory constrained, only want to do a couple of boxes and some text with no OS, ugfx may not be the best choice for you. There are a number of Arduino libraries that directly drive the display that may be better. uGFX is intended as a full graphics library and windowing system but one that can run on embedded systems. As a graphics library it is probably heavier than you might want. If however you want to try, the minimum set of modules to turn on is GDISP using the RAW32 or Arduino version of GOS. If you look in the gfxconf.h file you will see all the options that can be turned off and on.
  3. 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.
  4. 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.
  5. 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.
  6. Have you edited gfxconf.h to enable GFX_NEED_GDISP (set it to GFX_ON)?
  7. 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.
  8. 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.
  9. This is now fixed and in the repository. Thanks for finding it.
  10. 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.
  11. 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.
  12. 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 .
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. The "blinking" you are seeing is because your display communication is slow (SPI) and you are constantly updating the display.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...