Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,617
  • Joined

  • Last visited

  • Days Won

    2

1 Follower

Recent Profile Visitors

14,051 profile views
  1. Glad to hear that you got it working! Thank you for reporting back
  2. Before we move any further, can you try using the latest `master` branch from the µGFX git repository? https://git.ugfx.io/ugfx/ugfx
  3. I am a bit confused by this error. The ILI9488 driver does not implement gdisp_lld_draw_pixel() which is correct. However, the GDISP API should not call that if it's not available. Some questions: Can the compiler/linker tell you the file & linenumber where this reference occurs? Are you calling gdisp_lld_draw_pixel() manually in your application code? Does your main() do anything (µGFX related) other than gfxInit()? Did you modify the ILI9488 configuration file? Are you using the latest master branch of the µGFX git repository?
  4. Hello & Welcome to the µGFX Community! Unfortunately, we don't speak Russian. I hope that google translate will work for you. I will try to use simple wording. Can you please show the complete compilation output when you do a clean build?
  5. @Rafael Zingler Did you have any chance to check whether you can reproduce the crash on the Win32 or SDL port?
  6. @Rafael Zingler Would you be able to share a minimum reproducible example (including the image and everything) which triggers the crash? Does running the same code on a desktop computer using the µGFX port for SDL or Win32 also result in the crash?
  7. Can you reproduce the crash by just calling pvPortMalloc(2); (i.e. outside of µGFX)?
  8. The gfxAlloc() function is simply a wrapper macro around pvPortMalloc() if you use the FreeRTOS GOS port. Could you tell us which architecture/platform you're running on? If it's Cortex-M based system, we might be able to get a bit more information out of this by printing out register values etc. in the hardfault handler. FreeRTOS has a resource on this: https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html @inmarket Any insights into this?
  9. Assuming your image is available via the GFILE module, you can just use the gdispImageXxx() API from here: #include "gfx.h" int main(void) { gImage myImage; // Initialize uGFX and the underlying system gfxInit(); // Set up IO for our image gdispImageOpenFile(&myImage, "my_image.bmp"); gdispImageDraw(&myImage, 0, 0, gdispGetWidth(), gdispGetHeight(), 0, 0); gdispImageClose(&myImage); while(1) { gfxSleepMilliseconds(1000); } return 0; } You can find a ready-to-run demo under /demos/modules/gdisp/images.
  10. Hey @cheater - Nice to hear from you again! We're all still looking quite forward being able to have a look at your awesome work! The µGFX-Studio does exist. However, we're currently not handing it out. The plan was to release the first public version together with the v3.0 release of µGFX. After an initial dead blow during the COVID-19 pandemic we got drowned in support requests as everybody was scrambling to migrate their products to whatever silicon was available during the semiconductor shortage and right now we're engaged in larger customer projects. The question of when the µGFX-Studio will be released has therefore become a question of when µGFX v3.0 will be released. Most of the work around µGFX v3.0 has been completed by now. The "only thing left to do" is migrating the higher-level GWIN module to the new GDISP changes as well as updating all examples & documentation. The µGFX library v2.10 is certainly due for a release. You might want to upgrade your application to the latest `master` branch of the git repo to get all the new goodies. Especially the STM32LTDC driver got improved quite a bit.
  11. One of them is a binary representation of an actual file (Target_whiteBG_20x20.bmp in your case) whereas the other one is most likely raw decoded pixel data. The file2c utility just creates a C array of the binary representation of any file you pipe into it. You'd use its output to include into ROMFS and then draw the actual image via the high-level GDISP API with all the bells and whistles (color conversion, rotation, palette stuff, RLE and so on). Your "LCD image converter" on the other hand provides a raw pixel values tied to a specific format and resolution. Two entirely different things. You don't see an RGB666 option for the LTDC pixel format because that is not supported by the LTDC peripheral found in the STM32F429.
  12. The file2c utility simply creates a C array of the byte-content of the file you feed into it. It doesn't perform any conversion. In fact, it doesn't even know whether you feed it a picture, an audio file or an SQL database dump. It just wraps binary data into a C array and adds some entries to use it with ROMFS. If you need to do conversions you'll have to make them before feeding the file through file2c. @inmarket An STM32F4 with LTDC and external SDRAM via FMC can actually handle a 320x240 display with two layers and RGB565. I think it can also handle 320x480. I was working on a project not so long ago with a 480x480 display, dual layer LTDC and RGB565. But yes, this is definitely true: Bandwidth considerations need to be part of the hardware design phase. If your application needs a lot of I/O bandwidth then LTDC can be a real show stopper - especially when paired with SDRAM
  13. If you managed to get it working with your PNG approach you'll definitely be able to get it working by directly rendering to a display surface as that is easier (no need to mess with PNG). Instead of writing to a PNG buffer, you'd be iterating the QRcode array the same way but you're directly rendering each QRcode cell to a display surface. This can either be your physical display or a pixmap. The approach should be very simple: Clear the display area which will be occupied by the QRcode using gdispFillArea() For each cell in the QRcode leave it either blank (clear color) or color it in the opposite color as needed using gdispFillArea() Done Given that this is a free public support forum we maintain in our spare time we're usually not able to write actual code for customers. Please feel free to get in touch regarding commercial support if desired.
  14. Yes that is a likely cause. The µGFX library will try to write to the memory. It needs to be byte addressable. Usually you'd put the framebuffer in your SDRAM and setting the address(es) accordingly in the board file. You might just as well use the file2c utility that ships as part of the µGFX library in conjunction with ROMFS which allows you to draw pictures from flash all within the cross-platform high-level µGFX API. However, that doesn't resolve the issue that you need to have a writable framebuffer that both LTDC and the CPU (µGFX) can access. That will certainly cause a variety of problems. Just setup your hardware correctly (i.e. RGB565). The µGFX library does not really care tho. It supports a vast number of different pixel/color formats. Both RGB565 and RGB888 are known to work with the STM32LTDC driver. What problem did you encounter? Most likely you're running in the issue mentioned above: When drawing an image using the corresponding GDISP API the µGFX library will load your image (via ROMFS) and then draw that to the framebuffer (either via soft-copy or via DMA2D if enabled and applicable (it has some... restrictions regarding display orientation). Ignoring a lot of details it will basically "copy" your image located in FLASH to the framebuffer as needed. I would generally recommend not to spend time on trying to get stop-gap solutions working and instead making the system work properly as intended by ST. In your case this means having a large enough framebuffer to fit in at least one image (usually two, µGFX supports both a 2nd custom layer as well as built-in double-buffering) and configuring the system accordingly. In any case, it seems like you're almost there!
  15. Those settings are specific to yourr display panel. You'd get them from the corresponding datasheet. What exactly do you mean by that? Are you getting a brown-out event? Any high-level example in /demos should work. For board file examples you can have a look at the board files some of the STM32 eval/discovery boards that use LTDC. The STM32F746-Discovery comes to mind. Attached you can find a board file of some custom hardware I was working on recently. The hardware used an ST7701 display controller and the customer insisted on having the display controller configuration in a separate file so the board file simply calls ST7701_Init() and the rest is entirely specific to the LTDC driver. board_STM32LTDC.h
×
×
  • Create New...