Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,619
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Joel Bodenmann

  1. 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?
  2. 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?

  3. 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.

  4. 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.

  5. 18 minutes ago, PaulyLV said:

    Here are snippets of the C files generated using file2c utility and LCD image converter (specified RGB565 format). I don't understand how both these arrays would generate the same result when used as the framebuffer address in LTDC.

    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.

     

    50 minutes ago, PaulyLV said:

    Are you saying that the pixel format specified in these files is not related to the DPI interface but is the framebuffer format?  How does the LTDC peripheral "know" that I want the RGB666/18-bit DPI format then? What am I missing?

    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.

  6. On 10/11/2023 at 16:16, PaulyLV said:

    Is there a way to specify the pixel format in the 'file2c' utility?

    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 :D

     

  7. 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:

    1. Clear the display area which will be occupied by the QRcode using gdispFillArea()
    2. For each cell in the QRcode leave it either blank (clear color) or color it in the opposite color as needed using gdispFillArea()
    3. 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.

  8. 6 minutes ago, PaulyLV said:

    I commented out the gdisp_lld_draw_pixel function. This has stopped the microcontroller from resetting as soon as LTDC is enabled. The reset is from an exception frame. I wonder if has to do with the frame buffer address being that of an array stored in flash.

    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.

     

    7 minutes ago, PaulyLV said:

    I am using a header file for an image that I generated using a program called 'LCD_Image_converter' that I found online.

    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.

     

    9 minutes ago, PaulyLV said:

    I am using the RGB565 pixel format but my hardware is connected for RGB666. I chose RGB565 since LTDC does not support RGB666.

    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.

     

    10 minutes ago, PaulyLV said:

    I tried using file2c program in uGFX and had less success. Any help you can provide is appreciated. 

    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! :)

  9. 9 hours ago, PaulyLV said:

    but left the front porch, back porch settings as is. 

    Those settings are specific to yourr display panel. You'd get them from the corresponding datasheet.

     

    9 hours ago, PaulyLV said:

    The microcontroller resets during the call to gDispClear. 

    What exactly do you mean by that? Are you getting a brown-out event?

     

    9 hours ago, PaulyLV said:

    Are there any examples using uGFX STM32LTDC you could recommend?

    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

  10. The QRcode type contains an array representing a width*width grid of cells making up the QR code. All you have to do is writing a simple function accepting a const pointer to a QRcode and the size of one QR code cell in pixel. Then clear the drawing area (i.e. with white color), iterate over the array/grid and drawing a black rectangle of the specified size for each cell in the QR code that needs to be black.

  11. Glad to hear that you got it working!

     

    22 hours ago, PaulyLV said:

    I am working on the LTDC portion now. Should I start a new topic, or can I continue to ask questions on this one?

    Up to you - I think this thread/topic was not overly specific to either SPI or LTDC.

  12. Given that your QRcode object consists of a width-by-width array of 8-bit values for each "pixel", you might just as well render it using gdispFillArea() and bypass all the image non-sense if the QR-Code is not needed for an extended period of time.

  13. Yes, that is certainly possible.

    When it comes to displaying images there are two things to consider:

    • The format/encoding of the image itself. This happens through the GDISP image API.
    • The way you're loading the image. This happens via the GFILE abstraction module.

    There are plenty of options to choose for both of these points.

    For the first point, you might translate the QRcode into a NATIVE image format which is easy to achieve as it's the most basic way of representing an image.
    If you'd like to have more control, you can implement a custom image format wrapping your QRcode object directly.

    For the second point, you might be able to use the existing MEMFS implementation to load the image from memory. If that is not sufficient, there are provisions for RAMFS.
    If your underlying system already provides a native filesystem interface with the ability to handle in-memory files you can use NATIVEFS.

  14. The µGFX library provides several image decoders and mechanisms to load, decode & draw an image. To get started, you might want to enable ROMFS and use the file2c utility to put an image into your flash. Then display that using the GDISP API to draw the image. You do not (necessarily) need any 3rd-party tooling for this.

    See:

    Examples are available too.

  15. Hello & Welcome to the µGFX community!

    Unfortunately, we're unable to help at all without being given some information.

    If you are able to draw rectangles, lines, circles and so on you definitely have the "hard part" done. Most likely you're just missing the correct configuration settings. Check the documentation or provide more information :)

  16. An STM32F4x9 with an ILI9488 configured in 3-wire SPI is probably the worst combination you can have. The STM32 peripheral doesn't provide 9-bit mode so you would have to bit-bang it which is very slow (and eats up all your CPU). Never the less, you can get it to work if that is all you desire.
    Otherwise, either use the ILI9488 in 4-wire SPI mode or set it to RGB parallel mode and use the LTDC peripheral - that is what it has been designed for.

    Most of these display modules have simple solder bridges / jumpers for the IM configuration pins. They are rarely "backed into the PCB" if you buy them from a reasonable vendor. Check the module you have. Maybe you can just reconfigure it with a simple solder job yourself without having to make a different purchase.

    If none of that is an option, and you really just want to get something to show up on the display, I think your only option is to bit-bang the interface as @inmarket mentioned.

     

    1 hour ago, PaulyLV said:

    If what he is saying is right, then all LCDs that need SPI initialization would ship with IM pins set to SPI interface.

    The point of those IM configuration pins is to select the correct hardware logic (inside of the chip) to talk the interface/protocol you specify. As the same physical pins are shared for different interface options the hardware needs to know which interface it should expect on those pins to setup the correct state machine, command decoder and probably a bunch of other things.
    Think of these IM pins as being similar to the LSB address pins of some I2C slaves: It's a permanent setting within your finished hardware/device but it's still different between different devices. Therefore, while those can be hard wired on your particular hardware they still need to be configurable.

    The table from the datasheet illustrates this:

    image.thumb.png.dbe89adba8737878f76caa20ea6fbc6b.png

    Just as a disclaimer: Personally, I have not all the details of the ILI9488 in my memory. However, the ILIxxxx chips tend to all work in similar fashions. But be sure to check the datasheet.

     

    1 hour ago, PaulyLV said:

    I tried to set all the bits on the "LCD red" pins and don't see anything. Did you mean setup LTDC first and then set the pins high/low? 

    Nah, that was just a long shot in case you would have gotten everything else right and the IM pins are configured for the RGB parallel interface.

     

    2 hours ago, PaulyLV said:

    I am desperate and willing to try anything to see something other than white on my display. :)

    If we may ask: Is this a hobby project? We do offer commercial/paid support where we directly work with customer's hardware to get things up and running. It's sort of our daily bread-and-butter.

×
×
  • Create New...