1.5" 128x128 color lcd display controlled by girder

[mhwlng]

If you're looking for a 'low cost' very small display with graphics capabilities and colour,

(for example as a status display inside your pc)

see here :

http://www.dontronics.com/micro-lcd.html

I just received mine today...

it's basically a 1.5" 128x128 65535-color lcd display from a phone with a usb or rs232 port.

It's easy to control via girder....

I've made a G4 serial device driver for this display (works with usb or a 'real' serial port), which I'm still expanding.

If anyone wants the work-in-progress, let me know...

note that the screen update isn't very fast, so it's not possible to do fancy animations...

(disclaimer : I'm not associated with dontronics)


Marcel

[Ron]

neat, serial communication fast enough to get any kind of refresh rate going?

OT: I actually found a beer called "Eindhoven" in the regular supermarket here. Of course it had nothing to do with Eindhoven it was brewed in Schinnen (Limburg). Weird though, I never heard of that beer in Holland.

[danward79]

Any pictures of your work?

[mhwlng]

serial communication fast enough to get any kind of refresh rate going?

I haven't done any serious tests yet, but uploading a 128x128 pixel 16 bit colour picture is quite slow (takes several seconds using their test app, I've not done that part in girder yet) so no full-motion-video :D ...

I'm impressed with the picture quality of the lcd display especially at full brightness...

the speed of the built-in text/line etc. functions looks ok, they are fine to make a chart or show the temperature or something like that.
but don't expect too much. I'll do some more tests later...

there are also 64 user-defined 8x8 characters that you can probably use to speed certain graphics up a bit (not tested yet)....


Any pictures of your work?

the hardware pictures are on the url above....

I'm still working on adding more functionality to the g4 serial device driver.

once I have something, I'll make some pictures, but my camera (or the cameraman :roll: ) is quite bad at closeup pictures...

here's some pictures by somebody with more photographic talent than me :

http://www.next2nilhosting.com/micro-lcd/Micro-LCD_Pictures.html

(again, those pictures take several seconds to send to the display)

Marcel

[mhwlng]

I've done some tests with sending image data to the display :

you basically have to set each pixel to a certain colour by sending a 5 byte message 0x50,x,y,msb colour,lsb color and wait for an ack byte (0x6) before sending the next message.
so to fill the screen, you need 16384 messages....

I use :
BaudRate = 115200,
CallbackType = serial.CB_FIXEDLENGTH
ReceiveFixedLength = 1,

when I use this type of construction :




ReceiveResponse = function ( self, data, code )
if math.band(code, serial.RXCHAR) >0 and data then
self.Response = data
else
self.Response = nil
end
serial.Classes.Queued.ReceiveResponse (self,data,code)
end,

....

for x=0,127 do
for y=0,127 do
self:SendCommand(".....")
while self.ResponsePending do
win.Sleep(1)
end
end
end

then it takes 35-40 seconds to set all pixels to a certain colour. (you have to add to that, the time it takes to extract all pixels from a .bmp/.jpg/.png which I have not coded)

If I use the queue mechanism, then first I have to change the HARDCODED max. queue size from 100 to 20000 in init.lua

then use :


OnResponse = function ( timestamp, data, code )
end,

....
for x=0,127 do
for y=0,127 do
self:SendCommand("....",self.OnResponse,false,false)
end
end

now it takes 1min 15 sec to write all pixels. (so a lot slower)
-while the queue is being filled, I see wrong data appear on the lcd display.
-the cpu utilization is 100% during the execution time

so either method is too slow to be practical....

The supplier's test application (written in python) takes 7 seconds to send a whole image to the display. I saw someone mention that he could send an image in 2-3 seconds ?

Marcel

[Promixis]

Maybe try the sending using the low level serial commands on a seperate thread?

[mhwlng]

this is a test on the main thread, no error checking, timeouts etc...



local uLCD,err = serial.Open(13)
uLCD:Baud (115200)
uLCD:Flow ('N')
uLCD:Parms (0,1,8)
uLCD:BurstSize (5)
uLCD:RxClear()

local ResponsePending = true
local X=0
local Y=0
uLCD:Callback(serial.CB_FIXEDLENGTH,
1,1000,
function (self, data, code)
if (Y~= 128) then
local bytes,err = uLCD:Write("P"..string.char(X)..string.char(Y)..string.char(100) ..string.char(100))
X = X + 1;
if X==128 then
X =0
Y = Y+1
end
else
ResponsePending=false
end
end)

print ("start")

local bytes,err = uLCD:Write("E")

while ResponsePending do
win.Sleep(500)
end
print ("done");

uLCD:Close()


now, it takes about 20 seconds with cpu utilization of about 30% during transmission...



Marcel

[Promixis]

Interesting solution ;)

What about not using callbacks at all? This is more expensive than just using the read/write calls of the serial plugin.

[mhwlng]

Whatever you want, Mike :D


print ("start")

for x=0,127 do
for y=0,127 do
local ResponsePending=true
local bytes,err = uLCD:Write("P"..string.char(x)..string.char(y)..string.char(100) ..string.char(100))
while ResponsePending do
local data,bytes = uLCD:Read(1)
if (bytes ~= nil) and (bytes == 1) then
ResponsePending = false
else
win.Sleep(1)
end
end
end
end

print ("done");




this takes 34 seconds (also about 30% cpu utilization)....

If I remove win.Sleep(1), then It takes 19-20 seconds
so same as above, but with 100% cpu utilization



Marcel

[Mastiff]

OT: I actually found a beer called "Eindhoven" in the regular supermarket here. Of course it had nothing to do with Eindhoven it was brewed in Schinnen (Limburg). Weird though, I never heard of that beer in Holland.

Did you find a truckload of it? :wink:

[mhwlng]

ok Dan,

here's a picture... (and in focus as well, I found the correct button on the camera :D )

it actually works, it's not a mock-up :D

this worldtime example just shows different sizes/colours of text built-into the display..

the display can also handle lines/rect/circle/user-defined characters...


every 10 seconds, another page of status information can be displayed.

e.g. weather,traffic situation etc...


p.s. the sticky tape is just to prevent the backlight from blinding me :D


Marcel

[danward79]

Nice work, I like that. I like the background too!

I would have to think of a reason to have one and a use...

(please submit ideas below.... :lol: )

[Mastiff]

Currently playing track for all zones in JRMC? (Now would you expect less from me, the Multi-Zone Tzar?) :wink:

[mhwlng]

That depends on whether you can make a perfect square hole in the front of your pc :D

You could implement your 'famous' kWh charts on this screen ?

or the surfing conditions

or show how many times you flushed the toilet or opened the refrigerator door...

I'm also not sure how/where to mount it yet...



Marcel

[danward79]

No room in the from of my pc, it is taken up by a lot of hard drives a reservoir, card reader and dvd drive

I wonder thou... Keep your imagination going!

[mhwlng]

ok...
another picture

weather for today and tomorrow...

(It seems the previous sharp image was a fluke, now it's blurry again :D )

Marcel

[Promixis]

Whatever you want, Mike :D


print ("start")

for x=0,127 do
for y=0,127 do
local ResponsePending=true
local bytes,err = uLCD:Write("P"..string.char(x)..string.char(y)..string.char(100) ..string.char(100))
while ResponsePending do
local data,bytes = uLCD:Read(1)
if (bytes ~= nil) and (bytes == 1) then
ResponsePending = false
else
win.Sleep(1)
end
end
end
end

print ("done");




this takes 34 seconds (also about 30% cpu utilization)....

If I remove win.Sleep(1), then It takes 19-20 seconds
so same as above, but with 100% cpu utilization



Marcel

Interesting, the win.Sleep probably has a resolution of < 50 ms so that callbacks are faster.

I wonder how much faster a multithreaded version using signaling between threads would be.

Do you have to wait for a response between each send?

[mhwlng]

Do you have to wait for a response between each send?

unfortunately, yes...

Marcel

[mhwlng]

last picture for today (I promise :roll: )

transparent gif files work (unfortunately, the ones that come with girder aren't fantastic, especially on a non-white background :D )

it was actually quite easy using the lua "gd" library built into girder..


SendIcon = function&#40;self,x,y,filename&#41;

local im = gd.createFromGif&#40;filename&#41;
local xsize, ysize = im&#58;sizeXY&#40;&#41;
local transc = im&#58;getTransparent&#40;&#41; or -1

for yy=y,y+ysize-1 do
for xx=x,x+xsize-1 do
local c = im&#58;getPixel&#40;xx-x, yy-y&#41;

if &#40;c ~= transc&#41; then
if &#40;self&#58;GenericCommand&#40;self&#58;CmdStr_PutPixel&#40;self,xx, yy,self&#58;RGBToColour&#40;im&#58;red&#40;c&#41;,im&#58;green&#40;c&#41;,im&#58;blue&#40; c&#41;&#41;&#41;&#41;~= true&#41; then
return false
end
end
end
end
return true
end,

this 30x30 gif file from the girder weather report takes about 2 seconds to draw using above methods... which is not great...

I think that the only place that we can have a performance gain is in the serial library

for example, if I create a table with, in this case, 30x30 = 900 5 character strings

and pass this to serial.Write (stringtable)

and the serial library would 'stream' them all , waiting for the 0x6 ACK character between each ... that should be faster than doing it in lua...


Marcel