Driver for MIO283QT-2 display / Himax HX8347-D chip (work in progress)

Patrick1ab

Hi everyone,

I'm currently working on a driver (see attachment) for a new LCD color display I recently bought. It is working quite well so far, although some parts of the driver are really slow and still need translation into pasm.
for example this part:

PUB lcd_fill(color) | i

  lcd_area(0, 0, (LCD_WIDTH-1), (LCD_HEIGHT-1))
  lcd_drawstart
  repeat i from (LCD_WIDTH*LCD_HEIGHT) to 1
    lcd_draw(color)
  lcd_drawstop 

lcd_draw always sends the color information for one pixel, so this loop, which you can see above, is enormously slowing things down.
One solution I have in mind, is to send one line (320 pixels) at once. This would reduce the number of loop cycles from 320*240 = 76800 to 240. Doing this, I will get two other problems:

1. Each of the 320 pixels has 18 bit color depth. Using one long sized variable for a pixel will result in a huge waste of RAM space (only ~56% efficiency). Merging several long sized variables to one big memory space (180 longs = 5760 bit = 320 * 18 bit) will give me 100% efficiency, but is rather difficult to program I guess.

2. At the moment I'm sending the 18 bits one after another. I won't be able to do this with 5760 bits, so I will have to write a loop with some "djnz" to count the number of remaining bits. This will slow down the code again...

Has anyone an idea how to solve these problems or maybe another approach?


Now something completely different:

I would like to print text characters on my LCD and I know that the Propeller has character definitions of 16 x 32 pixels in it's ROM. I can also get the address of each character with the "View Character Chart" function of the Propeller Tool. But how exactly do you read those characters pixel by pixel to send them to the display driver?

kwinn

Use a cog and PASM to send the line of data to the display, and store 2 16 bit values for each pixel with the PASM program inserting 2 extra 0 bits before sending the data to the display.

Patrick1ab

Hi kwinn,

thanks for your reply.

I just found a solution to speed up the lcd_fill method. As every pixel is of the same color, it is actually pretty easy:

lcd_fill_     mov       t3, displaysize
               shl       arg0, #14
:loop        call      #fast_data_out_
               djnz      t3, #:loop 

lcd_fill__ret    ret

arg0 contains the 18 bit of color information and is not changed by "fast_data_out". So I can call this function over and over again until all pixels have the same color.



Could you please explain your solution a bit more detailed? This could be very interesting when it comes to displaying windows bitmap files.

kwinn

Patrick, my original idea was to store 16 bit values for color instead of 18 bits. That would allow you to store 320 pixels in 160 longs. After reading the data sheet it seems that translation is not really necessary as the Himax chip has a 16 to 18 bit mode built in.

The idea was as follows (i is an intensity bit, r, g, b are color bits)

1 - irrrrrgggggbbbbb translates to irrrrr iggggg ibbbbb (32K co;ors + 2 high/low intens.

2 - rrrrrgggggbbbbbb translates to rrrrr0 ggggg0 bbbbbb (64K colors missing r & g lsb)

kwinn

For sending the data to the display, you could set up an entire line of 320 x 16 bit pixels (160 longs) in hub ram and have a pasm program in a cog send them to the display.

Patrick1ab

If someone is interested, here is an update of the display driver and a small sample program showing how to open/display a 24 Bit Color Windows Bitmap File.

I've improved the driver by translating several functions into Pasm and created a new function "drawrow" to allow drawing an entire row at once (huge speed gain).
Displaying a Bitmap file with "drawpixel" takes 17 seconds, with "drawrow" this is reduced to 0.8 seconds.

There are still many limitations; for example:

- The size of the Bitmap has to be 320 x 240 Pixels or less
(I'm working on some routines to allow scaling, but had no success so far.)

- only Bitmap files with 24 bit color depth will work, because I'm not reading color tables

- Still no possibility to display text or other characters, as I do not understand how to use the characters which are stored in the ROM of the Propeller chip


Next step will be, that I clean up the driver a bit by removing unnecessary functions, adding more comments and maybe I can make it even faster a bit.