Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. How to do a screen dump in my application.

    I'd just like to add that µGFX still has everything you need to read back the framebuffer. So if you GDISP driver and/or your hardware supports it, you can use GDISP high-level API to read back the framebuffer and write it to an image. Another alternative for a GWIN based application is to render everything into a pixmap. If you have a top-level container you can just change the display pointer to render into the pixmap. The pixmap itself already supports writing to an image. Here's a forum post regarding rendering to GWIN stuff to a pixmap:
  4. How to do a screen dump in my application.

    From an application that is currently not possible. Remember that uGFX is designed for small embedded processors that often cannot read their own framebuffer. If you want to draw onto a "virtual" display and then save that into a BMP file that is possible. Look at pixmaps. You will still need to do the BMP encoding yourself but you can use GFILE to save it to an SDCard. If you are just after screenshots for a demo of your product (or something similar), the easiest way is to compile and run your uGFX program on the win32 platform. You can then use the windows snipping tool to take screenshots of what is happening.
  5. I like to do a screen dump in my application and save it as bmp format, is that possible?
  6. Gwin vs Gwin_widget

    Ok thank you.
  7. Flicker

    I will try that in few days. Thank you for your help.
  8. Gwin vs Gwin_widget

    To save a lot of resources (especially RAM and also CPU time).
  9. Flicker

    This is the relevant code taken from the µGFX-Studio v0.22.4: void UGfxWindow::setDisplay(GDisplay* g) { if (!_ghandle) { return; } // Nullptr means default/standard display if (!g) { g = GDISP; } gwinHide(_ghandle); _ghandle->display = g; gwinShow(_ghandle); } _handle is the GHandle.
  10. Flicker

    There's no hacking involved. You just need to change the GDisplay* pointer. We did the same thing for the µGFX-Studio.
  11. Gwin vs Gwin_widget

    Hello, A question please, why (advantages or defaults) don't you coded console and graph as widgets ? Thank you
  12. Flicker

    Hi, I'm not memory limited, is there any exemple how to "pixmap hack" a widget ? Else, where i have to code that ? Thank you
  13. Flicker

    Hi, The most common solution is (as you mentioned) double buffer. However, proper double buffering is very hard to implement and also requires hardware support. While µGFX can fully support double buffering (with the multiple displays API) we do also provide you with a more flexible way: Pixmaps. You can simply render your widget into a pixmap and then blit that pixmap to your real display. Pixmaps have certain advantages over real double buffering. The most notable is that you don't need two times the memory for the entire display area - a pixmap can be just a small portion of the screen. Other than that there are other things which vastly improve these sort of things such as anti-tearing-effect flags and so on. But all of that needs to be supported by the hardware.
  14. Flicker

    Hello, How to avoid flicker during console or image update (like a double buffer) ? Thank you.
  15. Last week
  16. uGFX-Studio v0.20 - Beta

    v0.22.4 is available for download. Changelog: Fixing issues with default GWIN settings (default font and default widgetstyle) Fixing crash when modifying target properties in certain situations Many internal improvements regarding code generation
  17. LTDC performance problem

    Thank you very much for your help. Can you upload your template?
  18. MCUFont Glyph Character Codepoint Mix-Up

    Thanks for the response, @inmarket. I agree with your assessment that is likely an issue with the encoder. Thanks for the suggestions; we'll look into those.
  19. LTDC performance problem

    It appears that I get these stripes only if I go from the "button screen" to the "string screen". Both does not have a parent defined. But the 2nd one, when redrawing in gwin_wm.c in _gwinFlushRedraws function enters the while loop: // Do loss of visibility first while ((RedrawPending & DOREDRAW_INVISIBLES)) { ... _GWINwm->vmt->Redraw(gh); ... } and it clears the window with the default color. Honestly I do not have idea why It happens only in one direction and not in the other. Plus I do not see the point of clearing the display (the container area) with default color and then drawing the container with background color.
  20. LTDC performance problem

    Hello, I would like to ask if this is normal LTDC performance problem- in video when redrawing the screen you can see the black stripes for a moment. 1 per 5 times it does not appear. I am using containers (full screen)- first one is container with 2 buttons, second one is container with a label. I use gwinHide/gwinShow. I don't know if it is problem with memory access or with LTDC settings (default one with ALLOW_2ND_LAYER difned as GFXON). The system is STM32F429 with FreeRTOS. The screen is RGB666 640x480. VID_20180313_214255.mp4
  21. MCUFont Glyph Character Codepoint Mix-Up

    Given that this seems to be font size dependant my guess is that it is the encoder having the problem as the decoder built into uGFX is font size agnostic. Other than saying that, I have not heard of similar problems. Perhaps try using the win32 version of the encoder and also try the online converter to see if they give the same result. There have been minor bugs fixed over time so also check that you are using the latest version from the repository.
  22. MCUFont Glyph Character Codepoint Mix-Up

    Hi, My company is using uGFX for a project in which we need to translate and display all of our text in a variety of languages. Right now I am working on the Simplified Chinese text, and have encountered a strange bug with MCUFont that I am wondering if anyone else has encountered or is aware of. The problem I am having is that certain, seemingly arbitrary, Chinese glyphs are displaying on my screen as completely different Chinese glyphs. For example, if I attempt to print the string "共2页", on my screen it will appear as "停2页", where the first glyph is different but the rest match correctly. As I said, this only happens with certain glyphs, maybe 1 out of 30, if I had to make rough guess. I am using the MCUFont binary on Linux (Ubuntu running on VMware virtual machine), and the font I am converting is Google's Noto Sans CJK SC - Light. However, I had similar (but worse) issues trying to use Microsoft's SimHei font. The last detail I will note is that some of the glyphs that are of issue seem to be fixed by using a different font size, but the issue isn't isolated to a specific size. So far I have noticed it with sizes 14 and 16. It's possible it is affecting other sizes as well. Has anyone else run into this or know of a potential solution? Thanks!
  23. uGFX-Studio v0.20 - Beta

    Hello @baris, Please read the instructions given in the bright red box at the download page.
  24. uGFX-Studio v0.20 - Beta

    hello Joel .uGFX-Studio version 0.15 has expired. please send me new version. thank you.
  25. NUCLEO-F746ZG + 7" SSD1963 16-bit FMC

    Joel, thanks for helping and I'm sorry for taking your time. I now you are a very busy person and I really appreciate your attention. Knowing this, now I see the value 0x60020000 is wrong for FSMC_A16 since it would be a 1 on the 18th bit address bit 17. It should be 0x60010000. Unless I missed something, all the pins are correctly set, including Register Select which is PD11. I will triple-check this. I will do all the recommended tests using a scope and check timings in display datasheet, as suggested. I still have two things that I didn't get. 1) Looking at the struct from example board file above, it's missing 3 things. Mode, flipHorz and flipVert. Flip are pretty straight forward, but for mode I have all those options and I'm kind of lost on which should I be using. static const LCD_Parameters DisplayTimings[] = { // You need one of these array elements per display { 800, 480, // Panel width and height 2, 2, 41, // Horizontal Timings (back porch, front porch, pulse) CALC_PERIOD(800,2,2,41), // Total Horizontal Period (calculated from above line) 2, 2, 10, // Vertical Timings (back porch, front porch, pulse) CALC_PERIOD(480,2,2,10), // Total Vertical Period (calculated from above line) CALC_FPR(800,480,2,2,41,2,2,10,60ULL) // FPR - the 60ULL is the frames per second. Note the ULL! }, }; /* Set the pannel data width */ #define LCD_PANEL_DATA_WIDTH_24BIT (1<<5) // 18bit default /* Set the color deeph enhancement */ #define LCD_PANEL_ENABLE_FRC ((1<<3) | (1<<4)) #define LCD_PANEL_ENABLE_DITHERING (1<<4) // no enhancement default /* Set the dot clock pulse polarity */ #define LCD_PANEL_LSHIFT_FALLING_EDGE (1<<2) // default rising edge /* Set the horizontal sync pulse polarity */ #define LCD_PANEL_LLINE_ACTIVE_HIGH (1<<1) // default active low /* Set the vertical sync pulse polarity */ #define LCD_PANEL_LFRAME_ACTIVE_HIGH (1<0) // default active low /* Set the lcd panel mode */ #define LCD_PANEL_MODE_TTL ((1<<7) << 8) // default mode is Hsync+Vsync +DE /* Set the lcd panel interface type */ // default TFT mode #define LCD_PANEL_TYPE_SERIAL_RGB_MODE ((1<<6) << 8) // Serial RGB mode #define LCD_PANEL_TYPE_SERIAL_RGB_DUMMY_MODE (((1<<5) | (1<<6)) << 8) // Serial RGB+dummy mode 2) My display come from factory in 8080 parallel mode. I have no idea if the driver is expecting this or Motorola 6800. I don't even where it should be set. Would be it a STM32 FMC setting? Or it's implicit in the driver code? Maybe one of the previously mentioned mode macros? I also see an option for 24bit width, shouldn't it be a 16-bit option? Thank you very much. Any progress will be written here.
  26. NUCLEO-F746ZG + 7" SSD1963 16-bit FMC

    The SSD1963 has an R/S pin which is used to tell the display controller whether the incoming data is configuration data or actual pixel data. This is done so that you don't need to wire up all the address pins in order to address each pixel individually (and each configuration register). The two macros above are used to access the SSD1963's memory, one time with R/S set to 0 and one time set to 1 - essentially giving you the option to write pixel data or configuration using "stock FSMC" without having to manually control the R/S pin via a GPIO. You need to ensure that the macro which sets the R/S pin has the correct address. So if you hooked the R/S pin up to FSMC_A16 you need to sure that GDISP_RAM has address bit 16 (the 17th bit) set to 1. FSMC is usually extremely straight forward and there is little that can go wrong. Just make sure that you use low timings until everything is working. Then you can ramp them up. But usually you want to be somewhere in the range of 10k to 100k until everything works. Also make sure that your pins are setup correctly (that the correct pins are being set to alternate function and so on). The most difficult part with the SSD1963 is getting the panel parameters correct. Make sure that you always at least tripple-check them. Those parameters are different for each panel. You should get a table of values together with your panel. However, note that the parameters you get are not always the ones you need to enter into that parameter struct. They are often calculated differently. I know that this post isn't as helpful as you might have wished for but there's not much we can do. FSMC is pretty much self contained: It's all about accessing a memory region. Everything else is up to your hardware and proper pin configuration. Simply tripple-check everything, take a break and do it again. Also, you definitely want to use a scope or logic analyzer to have a peek at those FSMC pins. Keep in mind that you can test the FSMC outside of µGFX. All that FSMC is doing is accessing a memory region. Therefore, you can setup your pins and just try accessing the SSD1963 with the two macros above - no magic involved. You can then just make call to the one with R/S = 0 and one with R/S = 1 in the main loop and use a scope or logic analyzer to verify that the correct pin is toggling.
  27. What type of GWidgetObjset is it?

    GWidgetObject is the base widget call: https://git.ugfx.io/uGFX/uGFX/src/master/src/gwin/gwin_widget.h#L109 You don't usually worry about those as you always access them using the GHandle. Edit: Yes, GWidgetObjset is definitely a spelling error.
  28. What type of GWidgetObjset is it?

    In the ./ugfx_2.8/src/gwin/gwin_tabset.c file: static void fgarea(GWidgetObjset *gw, const char *text, coord_t y, coord_t x, coord_t w) static void bgarea(GWidgetObjset *gw, const char *text, coord_t y, coord_t x, coord_t w) static void ntarea(GWidgetObjset *gw, coord_t y, coord_t x, coord_t w) What is the type of "GWidgetObjset"? Where is the definition? Is it wrong to spell "GWidgetObject"?
  1. Load more activity