SPI (ILI9341) Display is very slow to update the picture or text.

[karthickefy]

Hi Matrix Team,
Today I'm working with ILI9341 SPI display with STM32F407VE ARM Processor for one of my project to display Picture (Display the PASS/FAIL picture and our Company Logo. I have used Bitmap Drawer ROM option to store the BMP pictures and it is working fine. But is very slow picture update on the LCD display. Can you please guide me how to make it fast update . Also please help me to advice how to store pictures in Serial Flash instead of SD card or Internal ROM.

Karthick.

[Benj]

Hello Karthick,

Is reducing the colour pallet for the image possible? Currently the bitmap file is a 24-bit bitmap containing 90,000 bytes.

Reducing the file format to 256 or 16 colours should give you a fairly large speed boost.

BitmapFileTypes.jpg (26.18 KiB) Viewed 8002 times

Saved with 256 colour it looks identical and is now 30,000 bytes a saving of 66%.

Saving with 16 colours you do loose some of the quality but the file is now 15,200 bytes.

[karthickefy]

Hi Ben,
I have tried with 256 and 16 color and both are not working. I try with monochrome and it is working fine. only 24-Bit and Monochrome bitmap is working fine and the both type speed is same. No improvement.

[mnf]

Hi Ben,

Looking at the code for Picture__Display_BMP.

Image file size is 'hardcoded' into the program using switch statements to pull image width etc - would it be better to store the complete bitmap file and read this at runtime - this would allow images to be displayed from (for example) from an SD card in a more dynamic fashion.. It would also give smaller code? The image is also stored into a LUT (in EEPROM) - whereas a more flexible approach would allow EEPROM, SD, i2c EEPROM etc.

You are welcome to cannibalize my Draw Bitmap routines (I PM'd a while back, or I can offer to modify it?) - which stores the colour lookup table in an array (or EEPROM for 256 colour on Arduino, but could be modified for micros with a larger RAM) after reading from a file and could be quicker than using a LUT ??
Could the image be drawn to a buffer before being written to the gLCD (rather than plotted a pixel at a time)?

Something is also awry with the FC IDE's bitmap reader - it times out whilst reading a 24bit bitmap file) - a couple of times with 'an operation is taking a long time to complete' before FC gets Windows 'a program is not responding' message. It also does something bad to the IDE - compiling program with an attached bitmap (even a small 8 bit one) causing the IDE to become very slow (presumably because of the LUT generation) (Although I admit to using fairly large files here - 120 x 400 at 8 bit depth - which would be unrealistic for writing to the gLCD)

Martin

[Benj]

Hi Martin and Karthick,

The image is also stored into a LUT (in EEPROM)

The BitmapDrawer stores the file into Flash ROM. Only the pixel data is stored to make it as efficient as possible.

whereas a more flexible approach would allow EEPROM, SD, i2c EEPROM etc.

please help me to advice how to store pictures in Serial Flash instead of SD card or Internal ROM.

The BitmapDrawer FAT component allows files to be read from an SD card. Having two components means the code inside is cleaner and easier to work with and the properties are as designed for the selected interface. Often making something really flexible makes it much harder to work with.

I'm thinking about making a version of the FAT component for external Flash memory ICs. Need time to think about this and roll it out.

I have tried with 256 and 16 color and both are not working. I try with monochrome and it is working fine. only 24-Bit and Monochrome bitmap is working fine and the both type speed is same. No improvement.

Not sure why 256 and 16 colour modes aren't working for you. I'll investigate.

But is very slow picture update on the LCD display.

I've just pushed a set of new updates to the v8 update system, these contain new macros for the GLCD simulation, Updated Colour GLCD components and the Bitmap drawer components.

The Bitmap Drawer components now have a Display_BMP_Fast macro which should run faster by only assigning pixel coordinates at the start of each row. This looses functionality such as orientation, flip and rotation but should run significantly faster. If you need a flipped or rotated bitmap then you can simply do this on the PC before assigning into Flowcode.

BitmapFast.jpg (8.05 KiB) Viewed 7955 times

If the function does not simulate then the likelihood is the display you're using doesn't currently support the new fast routines. These are currently only available on colour GLCDs and not all colour GLCDs support the feature e.g. the 4D display and ST-ARM Discovery display components do not currently support it.

As always let me know how you get on.

[karthickefy]

Hi Ben,
Thanks for the details. Today I have tried with your new Macro "Display_BMP_Fast macro" from both ROM and FAT methods and both are not working (Display is blank). Also I have stored the bmp files into the SD Card and used Bitmap drawer FAT component with FC8 and this component update the pictures slower than ROM (Bitmap Drawer ROM). Also I tried with 256 and 16 colors in both FAT and ROM method, both are not working. only 24Bit and Monochrome pictures are working. Even I have tried with FC7 and that also shows same result as FC8.
Currently I'm using ILI9341 based 2.8 Inch(240x320) SPI based display. Below is the LCD display Link :
http://www.alibaba.com/product-detail/2 ... vzUk65&s=p

Attached is the FC8 code for your reference.

[Benj]

Hi Karthick,

Today I have tried with your new Macro "Display_BMP_Fast macro" from both ROM and FAT methods and both are not working (Display is blank).

Was this in simulation or on real hardware?

Also I have stored the bmp files into the SD Card and used Bitmap drawer FAT component with FC8 and this component update the pictures slower than ROM (Bitmap Drawer ROM).

Yes this is to be expected, reading from ROM is very fast.

Also I tried with 256 and 16 colors in both FAT and ROM method, both are not working. only 24Bit and Monochrome pictures are working. Even I have tried with FC7 and that also shows same result as FC8.

The 256 and 16-colour modes are working here for me, just tried them. Note v7 did not support the 256 or 16 colour modes these are new additions for v8.

I've just created a new test file here for you to try based on your project. I've tried it in simulation and on hardware using a PIC and both are working with all four bitmap colour depths for me.

Bitmaps.zip

(6.79 KiB) Downloaded 287 times

[karthickefy]

Hi Ben,
I used the real hardware. I have tried with your code and real hardware doesn't work. but simulation is working in "Display_BMP_Fast macro" mode. I'm using ARM STM32F407VE .

[Benj]

Hello Karthick,

Please can you confirm that the Display_BMP function is working with the various colour formats on the display.

I'll look into the Fast function, maybe there is a bug, I'm using the EBM001 component but this is an ILI9341 behind the scenes.

[karthickefy]

Hi Ben,
Yes. I have created the new image with 24bit, 256 and 16 color all are working fine. But almost same speed. Thanks.

[Benj]

Ok so it's all working for you now. That's good

But almost same speed. Thanks.

I got a 35% speed increase using the new fast function.

[karthickefy]

Hi Ben,
But Still Display-BMP-Fast macro is not working for me (I updated the definition). Display shows blank. But Simulation is working in FC8. If possible can you help to add PNG Picture file display option in Component list? PNG (portable network graphics) consume low space and can get more clear picture.

[Benj]

Hello Karthick,

Ok so the fast mode is still showing you nothing? Very odd I looked at the component code and couldn't find anything amiss, To be sure we are on the same page are you using the ILI9341_SPI component. Also did you try the bitmap files I posted, just to be sure it's not a file parsing issue. Also when calling the fast function can you also try printing to text to the display. Is the text working?

If possible can you help to add PNG Picture file display option in Component list?

PNG files are very complicated so I can't see us adding support for decoding these anytime soon but I can certainly add them to the list to investigate further.

https://en.wikipedia.org/wiki/Portable_Network_Graphics

[karthickefy]

Hi Ben,
Printing text is very fast. I have used Print (String) macro option, Print Number macro and both are very fast. If I choose big font with background color then it becomes slow update. Yes, I have tried your image. Your BMP picture size is too small and it displays very fast. When we increase the size of the picture, then it display slowly. Yes, we are in same page I'm using ILI9341 2.8 inch Display and the pixel is 320x240. While simulation, fast mode macro is working fine. but it is not working with real display. but normal display bmp macro is working perfect with slow response. Thanks.

Karthick

[Benj]

Hello Karthick,

I think I have spotted the problem with the component. The DC pin was being left in the command mode and so the fast data was being treated as commands rather than data.

Please run the update tool again and then the component should hopefully now work correctly in fast mode.

[karthickefy]

Hi Ben,
Sorry to say that still Fast macro is not working for me with both ILI9341 and ILI9341 SPI LCD components.

[Benj]

Thanks Karthick,

I've looked again and think I've spotted the cause, and hopefully added an extra speed boost to the components. That or broken them completely

I was deactivating the chip select pin after opening the LCD window and not reactivating it again to send the data. Now I activate the CS pin as part of the initialise and leave it that way. Seems to be working fine on my hardware.

Updates are available now.

[karthickefy]

Hi Ben,
Thanks. Finally the fast macro is working fine with my display. It is bit fast even with 24-Bit color picture. But I cannot change the picture Orientation for Fast macro with HW Display. But orientation macro is working fine with Fast macro for Simulation mode. Thanks.

[Benj]

Hi Karthick,

Brilliant glad it's finally working for you now.

The bitmap picture orientation cannot be changed with the fast mode. I'll see if I can get the simulation to replicate this so it's more obvious.

If you need to use the fast mode and the bitmap orientation to be altered then we recommend you change the orientation of the source file before loading into Flowcode.