assert() at line 96 in LCD16bpp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-24 12:13 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-24 12:26 AM
I can't read the text on the message box, the useful part of your sceenshot is really tiny.
An assertion is a check the developer implemented to assure all his assumed preconditions are met.
An "assertion failed" tells you missed something, or did something wrong in conjunction with this code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-24 12:42 AM
Added a new screenshot. The problem is to figure out what preconditions are not fullfilled when I don't have access to LCD16bpp.cpp file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-24 01:09 AM
> The problem is to figure out what preconditions are not fullfilled when I don't have access to LCD16bpp.cpp file.
Good question.
Consult the documentation that came with the software/library (if any...) ?
Ask the vendor ?
The info given from the source line (and displayed in the message box) is rather vacuous.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-24 05:04 AM
Hi Mats!
LCD will assert if your image format does not match the instance of LCD you're using (LCD16 in this case). Can you check if your opaque image format is RGB565? (non opaque can be ARGB8888).
Best regards,
Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-25 12:01 AM
Hi Martin!
The image format is RGB888 but my display is RGB565 so I choose the LCD16bpp as the dsiplay driver. When I change to the LCD24bpp driver I don't get the asserts any more. Does that mean that the format of the images selects what display driver you should choose?
Is there any way to control the format of the images generated from touchGFX designer?
Best regards,
Mats
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-25 12:06 AM
Hi mats!
You're absolutely right. The concrete instance of LCD determines how pixels are written to the framebuffer. For image formats, LCD just stops you right there because there's no reason to try to write a wrong format into the framebuffer. So, yes, the image formats you use should match the LCD instance, but everything should of course look correct on the final display.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-25 12:14 AM
Hi Martin!
Ok I figured that out, because I had to change the STM32F7DMA so it does a pixel trnasformation from RGB888 to RGB565 when it draws the image. But does touchGFX designer always gnnereate the images in RGB888 format regardless of what format the picture has when it is supplied to the designer?
/Mats
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-01-25 12:51 AM
Hi Mats,
No, you need to define the image format in the application configuration (config/gcc/app.mk for gcc) - This is what the image converter uses when it converts images. This setting is made for you when you select bit depth when you create your application. Along with this configuration the touchgfx startup code will also use the appropriate LCD class and set the correct depth of the framebuffer.
/Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-05 07:13 AM
Hi @Community member​,
Curious to know how you're doing on this problem.