uOLED-96-PROP ASM Display driver
Timothy D. Swieter
Posts: 1,613
I created an assembly language display driver for the uOLED-96-PROP that uses the 256 color mode.· For those wanting to do graphics and animation this driver is a ticket to performance.· Now you can code your own graphics engine (or use the sample code I hope to upload soon) to do faster animations (instead of the built-in functions of the OLED chip set).· The driver is simple, I think, and basically copies a block of Propeller memory byte by byte into the OLED memory for displaying.· There are a few things I want to add to the driver before I release the code here.· One thing I did include though was a method to determine how fast updates were being sent to the OLED.· The driver is sending a frame every 6ms which is about·166 FPS!!
In order to test the display driver I also had to create an graphics engine that handles 8-bits per pixel (256 color).· At the moment the graphics engine isn't really an engine, it is more of a collection of routines in spin to set pixels in the Propeller video memory.··The collection current has pixel, line, circle, sprite and text ability.· I hope to·add a fill command and clipping ability to the driver.· With time I also hope to·code it in ASM.· Clearly, the bottleneck for great performance,·at this time, is the SPIN graphics driver.
I uploaded a demo video to YouTube·(click here).· The colors do not show up the best because of my digital camera, but you have to trust me it looks pretty good.· I also attached an EEPROM file and if you have a uOLED-96-PROP you can load this in and it should run.
Note that this program/demo is running on 64MHz. clocked Propeller and·the OLED is setup for·8-bit color (RRR-GGG-BB).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
In order to test the display driver I also had to create an graphics engine that handles 8-bits per pixel (256 color).· At the moment the graphics engine isn't really an engine, it is more of a collection of routines in spin to set pixels in the Propeller video memory.··The collection current has pixel, line, circle, sprite and text ability.· I hope to·add a fill command and clipping ability to the driver.· With time I also hope to·code it in ASM.· Clearly, the bottleneck for great performance,·at this time, is the SPIN graphics driver.
I uploaded a demo video to YouTube·(click here).· The colors do not show up the best because of my digital camera, but you have to trust me it looks pretty good.· I also attached an EEPROM file and if you have a uOLED-96-PROP you can load this in and it should run.
Note that this program/demo is running on 64MHz. clocked Propeller and·the OLED is setup for·8-bit color (RRR-GGG-BB).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Comments
One of the hooks I want to implement in the driver is the ability to configure for "clock when I kick you" or "clock all the time".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Great Job!· ... and it's Spin!... When I did the VGA graphics, I started out building my blocks functionally with Spin, and then converting them to Assembly.· Seemed like the natural approach.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 3/20/2008 5:53:27 AM GMT
Code coming later today. I haven't had time to add and work on the additional features, but I figure I shouldn't keep you all waiting any longer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
There is still more work I would like to do for the display driver.· The same for the graphics driver.· If someone is keen and would like to code an 8-bit ASM graphics driver, that would be great.· Otherwise I will get to it eventually.
Enjoy and let me know what you think of the object!
http://obex.parallax.com/objects/301/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
With this OLED display there isn't a vsync signal (sort of).· I researched in the controller chip datasheet (Solomon Systech SSD1331) and did find a signal named "FR".· The "FR" is described as a RAM write synchronization signal to help the microcontroller synchronizes its writes to the OLED RAM.· Further on in the datasheet is a diagram and description of how to use this signal and a "fast write MCU" and a "slow write MCU" operation is described.· I don't know what frequency FR is operating at and I hadn't measured it or calculated it.·
The 4D Systems uOLED product does not connect the "FR" signal to the Propeller·so there is no ability to use this signal inside the Propeller software either.· Based on the description of the "fast write MCU" an OLED RAM update needs to start on the rising edge and finish before the next rising edge.· Since this signal was not available, I just wrote an ASM driver and started testing.· Voila - it worked!· I believe it works because the update to the OLED is so fast it falls clearly within the "fast write MCU" description.· I haven't experienced any tearing effects in the times I have spent playing with the display and this software.
Are you using the ASM driver?· Have you experienced tearing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Thanks for the info.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
http://www.sparkfun.com/commerce/product_info.php?products_id=712
The other thing I would like to include in the driver, but have not included yet, is a way to have the driver clocking data all the time or to have it only clock data when "kicked". In other words the driver could be used in a double buffered system or in a single buffer system. The main reason I want to add this is because of the display you referenced. 128x128=16384. If it is one byte per pixel, that is a lot of bytes for only one screen buffer. Not much left for second screen buffer not to mention the program!
I won't make any promises when I will look at the ASM code to work with the OLED from SparkFun. Please, feel free to beat me to it. I am focused on another product for Brilldea at the moment but perhaps I may have time while waiting for the PCBs. Like I said, the core ASM may work just fine once it is revised.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
You do great work.
I have to warn you that I am an optimization freak and a crazed PROP assembly language fanatic, so I could not resist meddling with your code. Please forgive me.
I have of course optimized it nearly to death and can now boast a frame rate of 3.073 ms from the original 6.16 ms. That's a whopping 325 frames per second. What ever are we going to do with all·those frames? We really only need·at most·one out of every ten,·so for the rest I suppose we·could just go take a coffee break. Right?
I have also converted most of the Graphics driver functions (only the really fun functions) over to assembly language.·You should see the demo rip. If I don't intentionally throttle back the poor thing with delay statements in the loops, the circle and line and text drawing routines will whiz by in a blazing blur. It's not very graceful, but it is exciting. It's like lighting a cat's tail on fire. I have never actually done that, but I did tie a helium balloon to a cat and watched as the cat tried despatately to escape the balloon. Don't try·that·at home.
Seriously. My only question is, where do I post my changes?
Mark
WOW! 3.073ms/frame! WOW! One word, WOW!
OK, let me try and talk here. WOW! I don't mind other taking the code and improving and modifying it. I tend to be a generalist and good at many things, but not an expert. WOW! I am delighted that you took the SPIN graphic functions and the assembly drivers and improved them.
Make sure you give credit to me for the original work, but go ahead and put your name on it and upload it to the forum. Post a note here pointing to your object. If you can, take a video of it blazing fast and slowed down and post it on YouTube. In the future, I hope we can find a good solution to expand the memory of the prop and use a larger screen. I don't want to wait for the prop II memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Attached is the turbo version of your 8-bit graphics driver.
Here's an excerpt from the new readme file:
I have included two versions of the top-level demo file as follows:
- Brilldea-8bit OLED-Demo-Throttled.spin
- Brilldea-8bit OLED-Demo-Turbo.spin
The first one contains timing adjustments to loops to allow the demoto flow slow and gracefully.
The second contains the loop timing constraints of Timothy's original
demo, so the circle, line and text drawing will whiz by really fast.
Mark Swann
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I have been playing with trying to get some large numeric digits to display on the uOLED-96-PROP. I must say that the way I accomplish is not really pretty but it works. I actually "draw" a number by using (6) 8x8 characters that I have modified to be parts of the digits. I actually took the second half of the 8x8 character set and re-used them - I figured I could do without lower case for the 8x8 characters, and that way I don't burn anymore memory up. I tried making 10 sprites, but that just took up too much memory. Anyway, I end up with a 16x24 numeric character. With Mark's turbo code running a three digit counter (pretty simple I realize but proved out the concept for me), with no delays put in, you can't even read the units digit because it is changing so fast - it's just a blur. All this and I have to clear the background in between each character.
I have to agree with Tim's assessment of the optimization - WOW.
On a related note, can anyone tell me why the built-in propeller font is not available on the uOLED-96-PROP and you have to waste so much memory loading the fonts into memory? Sure would be nice to be able to use the Propeller font (and it's scale command) and not use up the memory.
Ed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
http://www.rayslogic.com/propeller/3rdPartyHardware/uOLED-96-Prop/RS232Driver.htm
This has the two from 4d plus Clemen's "Secret font"...
Thanks Again,
Ed
Is it possible we can adjust current consumption by adjusting the display rate? Greater than 60 is overkill for me.
But really neat; makes me want to play with this again.
You have a severe warning about modifying the InitOLED and say:
'note: using assembly PPI engine to control all but reset and VCC enable pins!
I am using Tim Sweiter's UOLED IOC expansion board which uses pins 18 and 19 for the I2C, and I want to use pins 20 and 21 for direct monitoring of two magnetic reed switches. Would the PPI engine still allow me to do this?
Thanks,
Ed
I think I meant all "display" pins except reset and VCC enable... So, you should be fine.
Hopefully, Tim doesn't mind since you bought one of his boards [noparse]:)[/noparse]
That's kind of what I figured with Tim.
I have a question on your Turbo graphics driver. Tim's original plotchar routine in SPIN was like this (only the 8x8 part shown for brevity):
if _font ' font 1 8x8 _xC <<= 3 ' x 8 _yC <<= 3 ' x 8 repeat row from 0 to 7 repeat col from 0 to 7 if font_8x8[noparse][[/noparse]_char+row] & $80 >> col plotPixel(_xC+col,_yC+row, _color)I was able (since this was in Spin) to figure out how to incorporate the ability to optionally choose a background color (-1 leaves allows the character to still be printed with a "transparent" background). This allowed me to not have to clear the screen before writing text back over an area that already has text. It also allows for inverse characters. Here is my modification (Rayman, I know that this is similar to your implementation in your driver, but I really had figured this out before looking at your driver - great minds and all that)
if _font ' font 1 8x8 _xC <<= 3 ' x 8 _yC <<= 3 ' x 8 repeat row from 0 to 7 repeat col from 0 to 7 if font_8x8[noparse][[/noparse]_char+row] & $80 >> col ' the pixel is part of the character - plot with foreground plotPixel(_xC+col,_yC+row, _color) elseif _bgcolor <> -1 ' not part of character - if not transparent bg, then plot with _bgcolor plotPixel(_xC+col,_yC+row, _bgcolor)Since I really don't know assembly, is there a way to incorporate this in your turbo object? I'm greedy and I really want both the speed of your turbo driver and the ability to print characters with and without a background color.
By the way, kind of obvious, but I also added another parameter to the call
PUB plotChar(_char, _xC, _yC, _font, _color, _bgcolor) | row, col
Thanks,
Ed
Post Edited (Ed Parsons) : 9/21/2008 1:06:27 AM GMT
Ed,
My newest plotchar assembly code is below.
Look at the label named :innerloop. If you un-comment the two lines that follow it, you will get almost what you want. Adding code to test the background color (fill color) every time through the loop to test for transparent mode is expensive, so If I were to implement it, I would actually create two different loops, with and without the transparent mode.
'------------------------------------------------------------------------------- ' PlotChar ' asmPlotChar rdlong fromY, Parm2Addr shl fromY, #3 rdbyte temp3, Parm3Addr min temp3, #$20 sub temp3, #$20 rdlong fromX, Parm1Addr shl temp3, #3 jmpret _plotCharFontSwitch_ret, _plotCharFontSwitch1 call #plotCharSub jmp #commandComplete _plotCharFontSwitch1 jmp #_5x7_1 _8x8_1 shl fromX, #3 ' multiply by 8 jmp _plotCharFontSwitch_ret _5x7_1 shl fromX, #1 ' multiply by 6 mov temp1, fromX shl fromX, #1 add fromX, temp1 _plotCharFontSwitch_ret ret plotCharSub add temp3, currFontAddr mov dy, #0 rdlong temp4, temp3 add temp3, #4 mov pixelColor, color rdlong temp5, temp3 call #_plotChar mov temp4, temp5 call #_plotChar add fromX, charWidth plotCharSub_ret ret _plotChar mov l1, #4 :outerLoop mov temp2, temp4 shr temp4, #8 mov l2, #8 mov dx, fontCharOffset :innerLoop shr temp2, #1 wc ' if_c mov pixelColor, color ' if_nc mov pixelColor, fillColor if_c call #_plotRelativePixel add dx, #1 djnz l2, #:innerLoop add dy, #1 djnz l1, #:outerLoop _plotChar_ret retI have made extensive modifications to the rest of the 8-bit driver code. In my effort to reduce excessive redundant operations especially in the inner-most loops, I have actually reduced the number of parameters to the plotChar routine and others. For example,·below is my spin code for the plotChar routine. You can see I actually have two routines: one with the original color parameter and the other with it removed to speed things up.
'************************************** PUB SetColor(_color) '************************************** repeat while command parm1 := _color command := cmdSetColor '************************************** PUB plotChar(_char, _xC, _yC) | row, col '************************************** '' Plot a single character into the video memory. '' '' _char - The character '' _xC - Text column (0-11 for 8x8 font, 0-15 for 5x7 font) '' _yC - Text row (0-7 for 8x8 and 5x7 font) '' '' Based on routines from 4D System uOLED driver repeat while command parm1 := _xC parm2 := _yC parm3 := _char command := cmdPlotChar '************************************** PUB plotCharC(_char, _xC, _yC, _color) | row, col '************************************** '' Plot a single character into the video memory. '' '' _char - The character '' _xC - Text column (0-11 for 8x8 font, 0-15 for 5x7 font) '' _yC - Text row (0-7 for 8x8 and 5x7 font) '' _color - 8-bit color value (RRRGGGBB) '' '' Based on routines from 4D System uOLED driver SetColor(_color) repeat while command parm1 := _xC parm2 := _yC parm3 := _char command := cmdPlotCharMy point is that, instead of adding another parameter to plotChar,·you may want to consider adding another Spin function named setBackgroundColor. Since most of your characters will be plotted with the same background. For instance when plotting, let's say 10 characters, why set the foreground and background color 10 times when you can do it just·one time·up front.
In my case, I am maintaining the concept of a Fill Color, instead of a Backgound Color. IMHO It's really the same thing.
Edit: I'll see if I can add·this mode to my current plotChar assembly code. I can't promise that it will be a quick turn-around.
Mark
Post Edited (Mark Swann) : 9/28/2008 3:19:23 AM GMT