Graphics OLED writing... faster...maybe
Moderators: David Barker, Jerry Messina
Graphics OLED writing... faster...maybe
I've just about finished my OLED driver.
It's not comprehensive but does as much a I need.
It got me thinking about better ways to write to an OLED which is nice and fast.
So, THINKING OUT LOUD...
Assuming we have a 'big' enough PIC, wouldn't it be better to work on an array?
Then write the whole array to the OLED as bytes.
At the moment, with the current Modules, writing a pixel requires setpos, readbyte, bitwise op, writebyte.
And doing a line requires lots of those.
And doing a Fill requires even more.
It works flawlessly, but , alll in all quite slow.
Doing an array version means allows a much faster bitwise processing of an array element.
And writing bytes blindly to OLED controller is much faster than fiddling with reads / test / bitwise / writes.
I don't know if all OLEDs are the same in principle but if you write a byte to the SDD13005 controller it auto increments pointer, so NO manual SetPosition is needed - so saves even more time.
So, once the array is sorted in nice fast code, it can write the array as bytes with no read or Setpointer time overhead.
Simple tests of filling the screen using WriteByte is very fast.
It can easily do 250 complete screen writes in 1.5 seconds.
Does this have any mileage?
(Does it make any sense? )
It's not comprehensive but does as much a I need.
It got me thinking about better ways to write to an OLED which is nice and fast.
So, THINKING OUT LOUD...
Assuming we have a 'big' enough PIC, wouldn't it be better to work on an array?
Then write the whole array to the OLED as bytes.
At the moment, with the current Modules, writing a pixel requires setpos, readbyte, bitwise op, writebyte.
And doing a line requires lots of those.
And doing a Fill requires even more.
It works flawlessly, but , alll in all quite slow.
Doing an array version means allows a much faster bitwise processing of an array element.
And writing bytes blindly to OLED controller is much faster than fiddling with reads / test / bitwise / writes.
I don't know if all OLEDs are the same in principle but if you write a byte to the SDD13005 controller it auto increments pointer, so NO manual SetPosition is needed - so saves even more time.
So, once the array is sorted in nice fast code, it can write the array as bytes with no read or Setpointer time overhead.
Simple tests of filling the screen using WriteByte is very fast.
It can easily do 250 complete screen writes in 1.5 seconds.
Does this have any mileage?
(Does it make any sense? )
Hello Ryan. It's a Denstron DD12864YO.
I'm also using the 26K20.
I've just been modifying code to setpixels in an array and send the whole thing.
Result: MUCH faster. Fills are done in half a blink of the eye - in fact you don't actually see it filling - it just 'appears' as a solid.
Basically, I've changed the Driver 'SetPixel' and added a WritePage routine.
I have got a problem with Wrtiting Strings.
It'll only print the first character of a string onto the screen.
ie WriteAt/WriteStr(1,1,"HELLO") gives H on the display.
I'm using the simple pixel-by-pixel WriteChar routine to bitwise the Pixels in the array.
Squares, rectangles.lines, circles etc. are perfect, just writing chars to Screen is playing up.
The Font shape is fine, I juat lose the rest of my string.
I've declared the big array in the SDD1305 module.
(Yes, I am using a working copy of all Modules used :))
Not sure whether doing that has upset it.
I get the feeling that GLCD.WriteItem has got upset. I'm a bit stuck.
I'm also using the 26K20.
I've just been modifying code to setpixels in an array and send the whole thing.
Result: MUCH faster. Fills are done in half a blink of the eye - in fact you don't actually see it filling - it just 'appears' as a solid.
Basically, I've changed the Driver 'SetPixel' and added a WritePage routine.
I have got a problem with Wrtiting Strings.
It'll only print the first character of a string onto the screen.
ie WriteAt/WriteStr(1,1,"HELLO") gives H on the display.
I'm using the simple pixel-by-pixel WriteChar routine to bitwise the Pixels in the array.
Squares, rectangles.lines, circles etc. are perfect, just writing chars to Screen is playing up.
The Font shape is fine, I juat lose the rest of my string.
I've declared the big array in the SDD1305 module.
(Yes, I am using a working copy of all Modules used :))
Not sure whether doing that has upset it.
I get the feeling that GLCD.WriteItem has got upset. I'm a bit stuck.
There are 20+ Graphic OLED's here http://www.crystalfontz.com/products/index-oled.html
Hello rmteo,
did you already tested some of these OLED displays?
I need for an application a display that could be sun readable, I need a simple black on white one ... something that can be read under sun.
Did you tested these OLED under sunny weather? on the crystalfontz site they also propose some other graphic displays said to be sun-readable? does anyone tested them in real conditions?
Regards
octal
did you already tested some of these OLED displays?
I need for an application a display that could be sun readable, I need a simple black on white one ... something that can be read under sun.
Did you tested these OLED under sunny weather? on the crystalfontz site they also propose some other graphic displays said to be sun-readable? does anyone tested them in real conditions?
Regards
octal
One of these: http://www.sparkfun.com/commerce/produc ... ts_id=9560 might do the job.octal wrote:I need for an application a display that could be sun readable
What do you think of the graphic OLED on the EA Base Board?octal wrote:Hello rmteo,
I need for an application a display that could be sun readable, I need a simple black on white one ... something that can be read under sun.
Regards
octal
Its response time seems much better than GLCD's that even using the SPI interface, it is faster.
Yes, it's really a nice OLED, but the pb, for my application, it's too small.
I need the display for a handheld device, that has to show orientation, inclinaison (using a mems sensor) and some other data (sun light intensity ...)
This is why I need it to be sun readable, it will be used mostly outdoor in sunny regions.
For dimensions I need it to be at least 2.5" to be really usable.
Regards
I need the display for a handheld device, that has to show orientation, inclinaison (using a mems sensor) and some other data (sun light intensity ...)
This is why I need it to be sun readable, it will be used mostly outdoor in sunny regions.
For dimensions I need it to be at least 2.5" to be really usable.
Regards