display bitmap on lcd

[anhhuy0701]

Posted on March 27, 2014 at 04:21

Hello everyone

I'm  newbie in LCD, I use keil4 for stm32f4 to display a text on LCD 128x64 and it's succes.

Now I want to display a bitmap image but I don't have any tutorial about that, can anyone give me some link or document for that. My lcd controller is S6B0108

(I really want to know the mechanism displays image on LCD)

Thank and best regard!

[jj2]

Posted on March 27, 2014 at 15:44

Sometimes you've got to be careful of that you seek.  As a mono Lcd - w/out any gray-scale - your ability to import existing images is severely limited.

[chen]

Posted on March 27, 2014 at 16:06

Hi

sprague has a point - you cannot display colour or grey scale on  a mono display.

You can get utilities to turn colour/grey scale into mono (via dither patterns).

You say that you have successfully displayed text on the LCD.

Do you have the source code for the driver which wrote the text to the LCD?

The LCD controller does not specify the relationship between memory and the bit position on the LCD screen, this can be found out with trial and error or by looking at the text display driver.

Figure out how to draw, eg lines, on the LCD.

Then find libraries that load bitmaps into memory. Then use these libraries to load into the memory for the LCD controller, knowing how the bits map to memory.

[chen]

Posted on March 27, 2014 at 16:15

Hi

sprague has a point - you cannot display colour or grey scale on  a mono display.

You can get utilities to turn colour/grey scale into mono (via dither patterns).

You say that you have successfully displayed text on the LCD.

Do you have the source code for the driver which wrote the text to the LCD?

The LCD controller does not specify the relationship between memory and the bit position on the LCD screen, this can be found out with trial and error or by looking at the text display driver.

Figure out how to draw, eg lines, on the LCD.

Then find libraries that load bitmaps into memory. Then use these libraries to load into the memory for the LCD controller, knowing how the bits map to memory.

[jj2]

Posted on March 27, 2014 at 16:21

Added to my earlier post - provided great detail - and forum ''ate'' those 10 minutes of thought/effort...

Search for ''Osram-BMP'' - they briefly sold mono Oleds - which benefitted from such BMP images - and provided a neat Ap Note answering your questions.

Note that the BMP file structure is well defined - it's top describes the colors in play and image size - the image data is embedded further down - and (surprisingly) stored in bottom to top rather than the more expected format.  Further - as your Lcd likely follows the original Hitachi control format - bytes are organized vertically - not horizontally as on PC Paintbrush or similar.  This means you must rotate your image thru 90° prior to saving it - and then transferring to the Lcd.

You'll surely migrate to larger displays - the newer ST Discovery for F4 includes a 2.4'' TFT - and the ability to directly display JPG files (full color and/or gray-scale) attached via a USB drive.  This is your future - mono not so much - mono's time has passed. 

Your project/product deserves (almost) a display equal to any teenager's cell!  (which is never a 128.64 mono...)  Minus color - and adequate pixels - you risk ''boring'' your users to death...

Note that earlier F4 Discovery did not include the 2.4'' TFT - new board is wondrously priced and includes F429I MCU - a 180MHz, 225DMIPS powerhouse - great value & performer!

[rigomate2]

Posted on March 31, 2014 at 10:00

This tool might be a help for you:

https://code.google.com/p/lcd-image-converter/

[frankmeyer9]

Posted on March 31, 2014 at 10:21

This tool might be a help for you:

 

https://code.google.com/p/lcd-image-converter/

 

Not to forget GIMP, which can export images as C source.

[jj2]

Posted on March 31, 2014 at 16:02

FM: ''Not to forget GIMP, which can export images as C source...''

Indeed - yet our group prefers the use of ''GIMP/others'' to harvest image data - but to not burden the program itself w/that source code.  Instead - our m.o. is to place such image data in an off-MCU storage medium - ideally one easily & quickly accessed by the MCU.

Merit of this technique is that storage media may easily be copied in bulk - used across multiple projects - and on occasion has enabled the use of a smaller (memory sized), less costly MCU - as well.

(m.o. = modus operandi)