Monochrome Graphics Driver?
Timothy D. Swieter
Posts: 1,613
I have a graphical LCD (128x64) that I have written a driver for.· The driver sends out the LCD control·data and the pixels from a memory block that I pass to it.· My next step is to create a graphics driver for stuffing the memory with lines, circles, text, etc.· Does a monochrome graphics driver exist?· I looked into using the graphics routine provided by Parallax but my first thought is that it would take too much to make it monochrome (maybe I need t read my Hydra book more :-)
·
In the object exchange I see a 128x64 graphical LCD driver written by Erik Friessen but the graphics portion and the LCD driver portion look interleaved with each other and not easily separable.
·
Any other suggestions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
·
In the object exchange I see a 128x64 graphical LCD driver written by Erik Friessen but the graphics portion and the LCD driver portion look interleaved with each other and not easily separable.
·
Any other suggestions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Comments
The set of assembly graphic commands for the Propeller VGA Demo: Text color and graphics are essentially monochrome by nature.· Feel free to use them as a baseline for·your graphics driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/6/2007 3:01:12 AM GMT
The driver I was writting had each bit be a pixel. The LSB bit of the first long (memory[noparse][[/noparse]0]) was 0,0 in the upper left corner of the screen. Since the screen is 128 wide it is four longs wide. Thus the the fifth long (memory) etc was the first long of the second row. The LSB of memory would be 0,1. This mapping makes sense to me, but I have not coded something like this before.
Edit:
I read through a couple sections in the Hydra Book and it appears to not be too difficult to interface the Tile Bitmap Memory to my LCD driver·routine. I am going to interface it.··I will implement the·2-bit color·to be either off (00) or on (11).· In the future I could implement a blink (01) or inverse (10) function.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Post Edited (Timothy D. Swieter) : 10/6/2007 4:53:24 AM GMT
There is some overhead in the use of two bits, but you get the great advantage of beeing compatible to GRAPHICS.SPIN.
You can even connect your display and a TV to the same buffer at the same time!
A minor advantage is to be able to simply use the ROM font, but with two lines only...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
if your LCD han be updated at say 50 or 60 Hz, maybe you can have 2 pages and 4 "shades" of gray
If you go with just one page, you can detect if something was changed and avoid refreshing, saving some power if needed.
I think I will look into the power saving idea. Though my product is plugged in, I still like to save power and keep from performing unneeded tasks.
Having the graphics driver work makes me so happy. Once I understood the memory map and modified my LCD driver I was instantly able to draw text and circles and lines and a modified verion, but very slow update, of the graphics demo. I appreciate having such a strong library and a positive community to provide support.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
The parallel interface, if is accessible, should be used, I mean, for faster transfer, if is somehow critic. I'd prefer it, but seeing that the prop has a limited (but all-purpose) number of pins somehow seems like a waste to spend so many pins just to drive a LCD. But if you do not think in what the future can bring and require and keep it to the purpose, i.e. good allocation of resources, may be you can spare the pins. A I/O expander, can also help in some cases.
It has been two weeks now that I am have been programming this product and it is is almost finished. The process has been rather smooth and such a blast. There is a lot of truth to that advertising about programming being fun with the Propeller. I also appreciate the object exchange. I reviewed various I2C object while I created my own code and I am using the graphics driver written by Chip. My User Interface would be no where as cool if it wasn't for this library code.
With the speed, I have found that I can afford to quickly get something running even though it might be sloppy code. Once things are working I can refine and add speed improvements.
So, when is the 64 pin prop coming out? My next project may need more I/O. I need to do some speed calcs and datasheet reading to see if a GPIO chip will suffice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com
One little spark of imagination is all it takes for an idea to explode
I have an LCD from Crystal Fontz that has it's memory arranged on two sections screens each being 61x32 pixels.
Pixels are sent one byte at a time. I have the code down on how to send the raw data to the LCD, I'm just not wanting to rewrite the base Graphics.spin file.
Thanks,
Jim Fouch
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
Did you have a look at the obex for a graphics driver ?
I did an application with a monochrome screen. I wrote the display driver in ASM and it clocked the data to the screen. Then I used the standard graphics.spin as the graphics driver. The display driver looked at the 2 bits of each pixel. If the bits were 00 then the pixel was off. If the bits were 11 then the display was on. I planned to add blinking mode for 10 and 01 case, but never needed to. This can save the trouble of writing a graphics display driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com
Timothy: I'm thinking I'd like to modify the standard graphics drivr to use one bit to save some memory.
With 122x32 I'd only need 488 bytes for each screen.
The LCD is laid out where each byte sent represents 8 pixels stacked top to bottom. I'm not sure if this is how the normal graphics.spin works. I think it's lined up horizontal. I could be wrong. I did notice that most all the Graphics.spin methods all call plotp. I shoud be able to sent up the parameters to define the size of memory, and modify how the plotp address the buffer area and get it to work. This will be way cool to have all the power of graphics.spin to leverage against a cheap $27-$7 display.
With simple spin I was able to send a full screen of graphics in ~35ms. Once I write that in assembly, we should have a pretty fast and nice set up.
' Plot pixel at px,py ' plotd mov px,dx 'set px,py to dx,dy mov py,dy plotp tjnz pwidth,#wplot 'if width > 0, do wide plot mov t1,px 'compute pixel mask shl t1,#1 mov mask0,#%11 shl mask0,t1 shr t1,#5 cmp t1,xlongs wc 'if x or y out of bounds, exit if_c cmp py,ylongs wc if_nc jmp #plotp_ret [color=blue]mov bits0,pcolor 'compute pixel bits and bits0,mask0[/color] [color=blue] shl t1,#1 'get address of pixel long add t1,basesptr mov t2,py rdword t1,t1 shl t2,#2 add t1,t2[/color] [color=blue] rdlong t2,t1 'write pixel andn t2,mask0 or t2,bits0 wrlong t2,t1 [/color]plotp_ret plotd_ret ret▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE