Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Joel Bodenmann

    Choose touch drive

    There's currently no built-in driver for the GT911 touch controller. You'll have to write a GINPUT driver for it. Have a look at the interface documentation and the various existing driver implementations.
  3. inmarket

    STM32F746-Disco & Eclipse - Makefile approach

    Have a look in the example makefiles. It should be obvious.
  4. This has now been updated into the repository. Thanks for finding it.
  5. Simon

    STM32F746-Disco & Eclipse - Makefile approach

    I mean the Makefile approach shown here and in the image below rather than the Single file inclusion approach. I guess the issue I have encountered is that I can create a Makefile project and tell it to use the uGFX makefiles but how do I then incorporate my own code and tell Eclipse to include that in the builds.
  6. zhuantou215

    Choose touch drive

    I hope the administrator can give me a reply. I would like to thank you very much.
  7. cpu20

    STM32F746-Disco & Eclipse - Makefile approach

    With Makefile approach do you mean using the Makefile system provided by uGFX? Because then you need to make a Makefile project in Eclipse. When you create a C project in Eclipse, it will create a Makefile for you depending on how you configured the project. When you create a Makefile project, Eclipse will not generate any makefiles and use the Makefile you provide. What you are currently doing is manually configuring the whole Eclipse project to compile correctly. That is a very difficult process, but I think it is possible.
  8. Simon

    STM32F746-Disco & Eclipse - Makefile approach

    Thanks @inmarket I appear to be winning, I've got a clean compile but execution is failing in initialisation. I'll post an update when I've sorted all the problems out.
  9. Yes, but as can be seen on line 525 of gwin_widget.c (µGFX v2.8), both are treated the same: if (!text || !*text) gw->text = "";
  10. @neon1 Have you tried instead of passing NULL pointer here gwinSetText(ghTextedit, NULL, FALSE), to pass a pointer to a char buff, which first element is 0, or just gwinSetText(ghTextedit, "", FALSE) ?
  11. AlexK17

    GSourceHandle ???

    Hi. Thanks for assist. Best regards.
  12. Earlier
  13. inmarket

    STM32F746-Disco & Eclipse - Makefile approach

    Use our file instead of the firmware file in your build. STM keep changing their firmware in incompatible ways which is why we include a particular version in our repository. @cpu20 is the expert in getting ide's to include the correct files. He has published a number of guides that may help. The other way is to not rely on the ide's build generator and to instead create a true makefile project in eclipse. It is by far the easiest way to build uGFX and it is where we as developers started. If you are nterested in this have a look at some of the prepared makefiles in the various board example directories.
  14. Thanks. I will look closely at that asap and update the repository accordingly.
  15. Hello, I've been troubleshooting a memory corruption issue triggered by keyboard events in a TextEdit widget after gwinSetText() has been used on it. It is probably the same issue described a bit cryptically here: https://community.ugfx.io/topic/415-keyboard-and-textedit-problem/. Of course, as a µGFX newbie I may be simply misunderstanding something, so in that case feel free to tell me off. Reproduction: Create a TextEdit widget. Type some text into it using the (virtual) keyboard. Clear the widget's text by calling gwinSetText(ghTextedit, NULL, FALSE), without changing the focus. Do not tap/touch the TextEdit widget at this point. Type another character => memory corruption (likely causing a crash/hang/whatever). Analysis: Looking at gwin_textedit.c, the cause seems to be that the TextEdit widget does not learn of the fact that its text buffer has been replaced, and thus does not update/reset its cursorPos. cursorPos may then point at a position beyond the new buffer, causing memory corruption the next time a character is inserted or deleted. If the user taps the TextEdit widget after the text has been set and before typing again, the cursorPos is reset to a reasonable value and the issue does not appear. Workaround: Do not use gwinSetText() on TextEdit, but recreate the widget instead. Fix: A clean fix with proper cursorPos resetting would probably require TextEdit to be notified of text changes. A sort-of fix by checking cursorPos before using it is attached. Thanks for creating and maintaining µGFX! It's the best GUI library of its kind that I've come across, and the out-of-the-box virtual keyboard is a killer feature 😄 – Manuel patch-textedit-cursorpos.diff
  16. Hi, In the past I have successfully built uGFX using the single file inclusion approach (notwithstanding issues with the sdram code - see later). I want to use the Makefile approach so it is easier to incorporate bug fixes made to uGFX. I have looked at the CibiStudio wiki post to try to replicate the same in Eclipse. The steps I have taken are: created a new C project for the STM32F746-Discovery board including firmware version 1.9 Made a link to the cloned uGFX repository: Added exclude filters for source files in the following folders: boards/addons boards/base (excluding STM32F746-Discovery folder) demos drivers/gdisp (excluding STM32LTDC folder) drivers/ginput (excluding touch/FT5336) drivers/multiple src/gfile Added the ugfx folder linked to above to the Include path Renamed 'board_STM32LTDC_template.h' to 'board_STM32LTDC.h' Added ugfx/drivers/gdisp/STM32LTDC to the Include path to reolve an inclusion issue Created a userfonts.h file in ugfx/src/gdisp to resolve a missing dependency issue Excluded all .c font files in ugfx/src/gdisp/fonts from the build (I figured I could sort the fonts problem out later) Added ugfx/boards/base/STM32F746-Discovery to the Include path On compiling I now get the error: In file included from /home/simon/uGFX-git/ugfx/drivers/gdisp/STM32LTDC/gdisp_lld_STM32LTDC.c:94:0: /home/simon/uGFX-git/ugfx/drivers/gdisp/STM32LTDC/board_STM32LTDC.h:22:20: error: 'SDRAM_DEVICE_ADDR' undeclared here (not in a function) Finished building: /home/simon/uGFX-git/ugfx/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.c (LLDCOLOR_TYPE *)SDRAM_DEVICE_ADDR, // Frame buffer address My problems with the single file include method as mentioned above is the the file stm32f746g_discovery_sdram.c is duplicated in the uGFX repository but with reference to a header file called stm32f746_discovery_sdram.h but the version of stm32f746g_discovery_sdram.c included in the firmware references a header file called stm32746g_discovery_sdram.h If I proceed to try and resolve this problem it becomes very messy and I didn't document how I have resolved it with the single file inclusion method. So, two simple questions (!): is this the correct way to implement the makefile approach in Eclipse? how to correctly resolve the issues caused by the sdram files? Thanks Simon.
  17. zhuantou215

    Choose touch drive

    First of all, I would like to thank you for your help. My screen has been able to display normally, I am trying to touch. But I don't know which touch driven template to use. My LCD screen is RGB888, which belongs to capacitance screen. My touch chip is gt911, I2c driver touch chip. I hope you can tell me which touch drive template should be used!!!
  18. inmarket

    GSourceHandle ???

    If the line specified is right at the top of the function my guess is that it will work. If it is not at the top then you are running into a common C, C++ language misconception. C does not allow variable definitions except at the top of a block. Once a non-variable definition statement has occurred variable definitions are not allowed in the block. Whilst the C language does not allow this, C++ does. As many C compilers have associated C++ compilers many C compilers relax the rules and allow such definitions eg gcc. My guess is that the IAR C compiler follows the language standard and doesn't allow this. In general in C it is a good idea to seperate variable definitions from code to set the variables.
  19. AlexK17

    GSourceHandle ???

    Hi. GSourceHandle enterHandle = ginputGetToggle(GINPUT_TOGGLE_ENTER); Why can this string cause a compiler error? Error[Pe059]: function call is not allowed in a constant expression but if use #define enterHandle ginputGetToggle(GINPUT_TOGGLE_ENTER) It does not cause an error and works fine. Compiler IAR 7.5 Best regards, Alexandr.
  20. Joel Bodenmann

    support unicode and RTL language

    Alternatively, you can use the forum search and find this:
  21. inmarket

    support unicode and RTL language

    It is possible to use RTL languages with ugfx but it's a little more work for the programmer. 1. Use right justification instead of left justification for all your text boxes. 2. Reverse the characters in any string you want to print so they appear in the correct order when displayed. This can either be done programmatically (something like the gtrans module) or simply writing any fixed string with the characters reversed when programming. Eg. "abc def" would be written as "fed cba" and then right justified.
  22. Guest

    support unicode and RTL language

    @vahid4134 could you implement RTL languages with ugfx? I'm trying to show Arabic using Google NotoSans Arabic font.
  23. inmarket

    Running µGFX on ESP32 and Arduino IDE

    Yes
  24. Alucardz

    Running µGFX on ESP32 and Arduino IDE

    Hello, can we run it without an SD Card ? i mean, will i be able to configure my adafruit 2.8'' tft screen, without the SD carD ?
  25. Joel Bodenmann

    Problem with low performance

    I'd like to add some info: This is not a hardware problem but how your uGFX board file(s) are configured. That's the reason why you're getting better performance with a different solution. The LTDC stuff allow for a lot of different configurations - You have to go through everything and figure out what the right ones for your hardware are. Especially check on DMA2D. Also don't forget to set your CPU and compiler in the uGFX configuration file.
  26. inmarket

    Problem with low performance

    I presume you are using an M3 with the internal ltdc video controller. If that is not the case the below discussion may help even if it not directly applicable to your circumstances. The problem is likely to be related to your external sdram and it's bandwidth. The proof of this is the slow performance (noticeable redraw speed) of the gdispClear loop.The image drawing tests are therefore meaningless until that problem is solved. The first thing to try is putting the framebuffer into internal ram as a test. If that operates quickly the problem is your bus interface to the external sdram. Note that if your framebuffer is in external ram do not put any other objects, heaps, stacks, code or anything else in that external sdram. Framebuffers are extremely bandwidth intensive just with video refreshing. Other things to check are your CPU clock is running at full speed, wait states and speed and width of the sdram bus and also look for any other high speed requirement that may affect available bandwidth or speed.
  27. DCWR

    Problem with low performance

    Hi, We have a problem with low GUI performance on TFT. Our HW setup: LPC1853 - Cortex-M3, 180 MHz External SDRAM - 90 MHz TFT - 768x128px, RGB, TFT running at 10 MHz Our SW setup: RGB565 format single framebuffer (framebuffer footprint - 192kB) FreeRTOS We setup uGFX and established initial code for that : void APP_Init(void) { TFT_BacklightOnOff(true); Set_TFT_Backlight(PWM_100); SysInterfaceInit(); // Create the initialization task xTaskCreate(APP_InitTask, "Init Task", 1024, 0, 1, &InitTaskHandler); vTaskStartScheduler(); } static void APP_InitTask(void* pvParameters) { gfxInit(); xTaskCreate(APP_GuiTask, "Gui Task", 1024, 0, 1, 0); vTaskDelete(InitTaskHandler); } static void APP_GuiTask(void* pvParameters) { for (;;) { gdispClear(Black); vTaskDelay(1000); gdispClear(White); vTaskDelay(1000); } } And we quickly find out that it works slowly. It is easy to see the redrawing process. There is nothing else in the system. We are only drawing this in one task. We tried also to show on the display .png file from USB stick. We set up a FatFs on that and tried to show pictures like that : Variant 1 - png format directly from USB; Variant 2 - the same picture converted to raw RG565 format; // VARIANT 1 static void APP_GuiTask(void* pvParameters) { gdispImage myImage1; gdispImageOpenFile(&myImage1, "1:1.png"); gdispImageCache(&myImage1); } // VARIANT 2 static void APP_GuiTask(void* pvParameters) { gdispImage myImage2; gdispImageOpenFile(&myImage2, "1:a.bin"); gdispImageCache(&myImage2); } Both ways gave us an answer: very slow performance. We used cache mechanism to improve performance with a result: slow performance (a small improvement, really small). We also check how it looks when we use external flash memory (QSPI, 60 MHz) - nothing happens, GUI is still working slow enough to see the redrawing process. Please see gfxconf.h in the attachment. Could you help us? PS. We made on this HW setup one project with commercial graphics framework, and we had good performance (with animations). Best regards, DCWR gfxconf.h
  1. Load more activity
×