Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. 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.
  3. Hi, the buffer used for this driver (whole screen 400*240 pix) weighs a lot (12482 bytes). Is it possible with µGFX to work with a reduced screen area for the buffer ? thanks
  4. Hi, the buffer used for this driver (whole screen 400*240 pix) weighs a lot (12482 bytes). Is it possible with µGFX to work with a reduced screen area for the buffer ? thanks
  5. Last week
  6. I want to give uGFX a try and integrate it into my existing cubeMX Makefile Project. (Bare Metal, no OS, no special tool-chain). As I understand, I have to do following steps: 1) Download the GFX Library - done 2) Edit the gfxconf.h: #define GFX_USE_OS_RAW32 GFXON - done 3) Edit the Makefile which cubeMX generated. Correct? Set the GFXLIB variable to the path pointing to the µGFX library root directory Include the main µGFX Makefile (/ugfx/gfx.mk) Add GFXSRC to the sources variable/list Add GFXINC to the include paths variable/list Include additional Makefiles of the µGFX library to include board files, drivers, ... How do I do this and where in the cubemx generated Makefile? Is there an example somewhere? This would be awesome and save lots of time 🙂
  7. Earlier
  8. 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.
  9. I have problem with more than one thread in system witch uGFX and ChibiOS. If one thread is running all is ok, but if I start another thread I get error SV#4 from ChibiOS. Threads are very simple, first thread drive blinking led and second only realize delay in while() loop 100ms. Have anyone any ideas what might be wrong?
  10. kpapr1

    Compilation error

    No logo at power on... I start the debugger and take it step by step, the program goes through the "gfxInit();" command and then goes to the "gdispDrawPixel(10, 10, White);" command. I step into this command which finally leads me to the "drawpixel_clip(g);" command and then I get the hard fault error. I'll have a look again tomorrow. Thanks.
  11. 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.
  12. kpapr1

    Compilation error

    Hello again! So, I upgraded to version 2.9 but I still didn't find the "GFX_NEED_GDISP" definition anywhere, so I set the "GFX_USE_GDISP" to "GFXON". Anyway, the problem now is that any draw command causes a hard fault. The function call that generates the hard fault is in "gdisp.c" and it's "drawpixel_clip(g);". I don't know why this happens or how to fix it, so any help would be greatly appreciated!
  13. kpapr1

    Compilation error

    I see I'm using version 2.8, so I'll upgrade to the latest one. Thanks!
  14. You're using an older version of the library. We'd recommend using the latest master branch of the official repository or getting the latest stable v2.9 release from the downloads section.
  15. kpapr1

    Compilation error

    So, compilation errors are all sorted out. Now I need to understand how to make ugfx know where my SPI interface is, as well as the reset and /CS signals. Also, I have a 3-wire SPI interface, which means I need to send a 9-bit word. Any help on this would be greatly appreciated! 🙂
  16. kpapr1

    Compilation error

    OK, what I found out is that I copied the gfxconfig.h file to my project's SRC dir (as the installation guide for Keil said), but the compiler still reads this header file from its original location (where all header definitions are commented out). Now I got a bunch of different errors that I'll try to sort out. I have followed the instructions for installing ugfx in Keil, but it seems it's not working out for me or I have done some things wrong. I'll check it out and come back. Thanks everyone for trying to help me! 🙂
  17. kpapr1

    Compilation error

    I don't see "GFX_NEED_GDISP" anywhere in my gfxconfig.h, but I have enabled this option --> "#define GFX_USE_GDISP TRUE".
  18. inmarket

    Compilation error

    Have you edited gfxconf.h to enable GFX_NEED_GDISP (set it to GFX_ON)?
  19. kpapr1

    Compilation error

    Yes, "gfx.h" header is in "main.c"
  20. Hello & welcome to the µGFX community! Did you include the "gfx.h" header in the files where you call the high-level API functions such as gdispDrawPixel() ?
  21. kpapr1

    Compilation error

    Hi, I have a custom board with an SSD1322 OLED display and an STM32F103 MCU. I'm using Keil and have setup the ugfx. Everything is fine and I get a successful compilation when I include the gfxInit() command. But all other commands, like gdispDrawPixel or gdispFillCircle give a "warning: #223-D: function "gdispDrawPixel" declared implicitly" and "L6218E: Undefined symbol gdispDrawPixel (referred from main.o).", which means that these functions are not referenced. But I don't understand why. I have included in my project "gfxconfig.h", "gfx_mk.c", "SSD1322.h", and "gdisk_IId_SSD1322.c". I have also included the paths "..\ugfx" and "..\ugfx\drivers\gdisp\SSD1322". What am I missing?
  22. Thank you for sharing your driver We'll look into the forum upload issue that you mentioned.
  23. Hi, just to share this gdisp driver for Sharp LS027B7DH01 memory in pixel display, monochrome 400x240 LS027B7DH01_driver.zip . I've tweak gdisp.c (line 18) to add choosing the logo color ability in gfxconf.h : #ifndef GDISP_STARTUP_LOGO_COLOR #define GDISP_STARTUP_LOGO_COLOR GFX_WHITE #endif The driver works but is not extensively tested for now. ps : i was unable to upload the file, the web page returned " There was a problem uploading the file." or "-200" messages. So here a google drive link : https://drive.google.com/drive/folders/1kaTg_je2_ncuifPSORbFXQg_BW9XKjqj?usp=sharing
  24. Have a look at the various GWIN (and widgets) documentation. Especially the /demos directory that comes as part of the library might be a valuable resource. the /demos/modules/gwin and /demos/applications applications will demonstrate the proper use of the event system to dispatch widget events.
  25. 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.
  26. Hi all, the option GDISP_NEED_AUTOFLUSH is defined as TRUE in my configuration file. Thus, as expected, my board_flush() function is called automatically after the drawing operations. However, I have a doubt about the behavior of the library when this option is enabled: when I call the function gdispFillArea, for example, the board_flush function is called just once, at the very end of the drawing process. But when I call the gdispDrawImage function, the board_flush function is called many times during the drawing process. Is this the library's default behavior with GDISP_NEED_AUTOFLUSH enabled? For my case, ideally the board_flush should be called just once, after the whole image has been drawn (same behavior as with the gdispFillArea function). I would like to know if there is something else I need to adjust in my configuration file, to make the flush function be called just after the drawing process has finished. Any help is welcome!!
  27. 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.
  28. This is now fixed and in the repository. Thanks for finding it.
  1. Load more activity
×
×
  • Create New...