Currently there is no function to do this.
In the mean time you can easily write one and then use any format you like.
If you do it pixel by pixel it won't be as fast as a native format bitmap but the pixel plotting
routines plot about 14k pixels/second so its not that bad.
@Bill: Thanks for the response.
It appears from the code you included (DrawBitmapXBM_P) draws the bitmap one pixel at a time using the SetDot method. Is this faster than the pixel plotting routines?
My application generates 32 pixels at a time (as an unsigned long) which represent a 1 pixel wide by 32 pixels high "bitmap". Would performance be better if I updated the screen as 128 x 2 of these bitmaps, or 128 x 64 individually plotted pixels? My code already
At the moment my application is coded to communicate directly with the KS0108 using 12 digital pins, ie. not using a library. Obviously this limits is re-useability on other types of GLCD, but it does enable a very fast screen update. I would like change the application to use the library, but need to k
The routine above that draws XBM images calls the low level pixel plotting routines
so it will not be faster than pixel plotting routines.
The DrawBitmap() routine however, is MUCH faster because it is slamming out
pixels in the native format by doing page writes.
For updating a display, there is no faster way
to update the display than the way that DrawBitmap() does it.
Drawing pixels vertically is definitely not the fastest way to update a ks0108 display.
To draw vertically you will have to reset the page position after each 8 vertical pixels.
The fastest way is to take advantage of the built in auto page increment capability of the ks0108.
So that means for a bitmap, you want to slam each ks0108 page into the display 8 vertical pixels at time
horizontally across the display. (this is what DrawBitmap() does )
The library is very fast at low level operations.
I spent many hours with a logic analyzer to optimize the operations.
The library keeps track of the addresses of the chips and only updates addresses or pages
For maximum speed you want to send as few commands to the display as possible
and do as few memory accesses to the display as possible.
To do that you must update the display page at time.
In your case, for your "bitmap" since it is 32 pixels vertical or 8 pages, there is a big penalty for
plotting the data that way since you have to send a command to the display to reposition
the address pointer after each page update. For speed, you want to write back to back consecutive
This is because the command to reposition the col address and set the page takes longer than a write.
If you can write back to back pages horizontally then you will only have to send
8 commands to set the page and col address (16 commands)
vs a command for each page and each col address which is 128 * 2 commands or 256 commands.
There are several options that I'd suggest, many of which are
quite simple to implement; however,
Since this is a specific implementation discussion, I'd recommend starting a new thread for
a discussion about options/alternatives for your project.