I've been looking at your code for the ST7920 assembly coding. Looking at the St7920 data sheet, it appears the initialization might be as listed here:
Byte 'my comment
$01 clear
$06 entry mode
$0C display mode
$18 cursor display control
$24 function set - extended instruction set
$22 extended function set - graphics ON, basic instruction
$02 home? DDRAM - 00h
$36 function set???
I've dealt with non-graphic LCD initialization before. Not always clear from the oriental data sheets. This one is a bit more involved because of the graphics mode. I'm trying to add comments to your code so I can understand what all is being done. Can decipher most instructions to comment them. Thanks for any aid you can provide.
I've just got my displays, but I can't identify the serial connections from the JHD520 data sheet or the Sitronix data sheet for the ST7920 controller chip. What pins correspond to CS, SCLK and SID (scs, sck and sdo in your software)?
Edit:
From the ST9720 data sheet it looks like it's these:
Leon: Look at the post in this thread from 11/15/2009 6:59 PM. It shows what pins to use.
I also got mine and have them up and running. Using the serial interface and doing the fonts in SPIN it's pretty slow, but I think it could be made to be sped up quite a bit. And for $22 and only 2 I/O pins, I'm not complaining.
Thanks. That table doesn't match Peter's software, which uses CS. Are you using different code?
I've designed a simple PCB for the display with a 2x3 IDC connector. The connections are similar to Peter's table, but I've tied RST high, and am using CS.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
@all
I received my displays, provided a header on a Prop Proto board, wired per Peter's information, but it wouldn't initialize. Well, found I had it connected to the 5v regulator output, but forgot that I'm using a 5v switching module which outputs about 4.8v. All is well now that I have the display connected to the power input. Though I will have to be careful when using any other higher power source.
Originally I had about 3 feet of ribbon cable and thought that was the problem, but wasn't. I did however cut about 3-1/2" off one end add a connector which allows the display to lie on the ribbon cable nicely. I'd prefer to have the display right over the proto board, but had added three momentary switches on the right side which now would have been overlapped. Difficult to plan far ahead when one doesn't know such a LCD module would become available. Now wish I'd ordered more than two modules to get a lower price/unit. Cheap ole me.
@Peter, probably delays would have to be added in the init and data passing routines to run at 3.3v, right? I wonder if anyone had tried to run so low. On 3.3v it wasn't as bright, obviously, but appeared to be sufficient for ambient room lighting. I wonder how much slower the device needs to run on lower voltages. Anyone tried running it on 3.3v? At least it appears the spec indicates it can run down to 2.7v.
It may be worth trying the 1-pin version using an RC. It will be slower but maybe save a pin. CLK & Data are tied together using an RC network. Leon posted the solution in the Sandbox and I replicated it here a few days ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
In my circuit, I have CS (pin #4) pulled directly to 3.3V. I'm only connected to 5 & 6 for Data & SCLK. I was not able to run Pin 2 to 3.3V, it needed 5V for mine to work.
I used the sample code provided and it works pretty good.
Sorry guys if I haven't gotten back to anyone yet, I'm still having a bit of a holiday and I'm staying smack bang in the middle of Times Square, NYC, what a city.
My original code showed CS but I never hooked it up. All the example software except the actual PASM driver is just that, an example. When I get back in a couple of weeks I will code up the font routines etc and post it to the OBEX. I'm not sure about 3.3V operation so I will have a look into that as well. Thanks for the feedback.
Now if your boss was a little more understanding, she would have let you take your prop & laptop with you [noparse]:)[/noparse] Mine lets me but I often do get those funny looks! *grin*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Now if your boss was a little more understanding, she would have let you take your prop & laptop with you [noparse]:)[/noparse] Mine lets me but I often do get those funny looks! *grin*
Well it so happens that I had to take a netbook with me and I snuck a few prop boards into the bag though I haven't had much time to do anything and my "boss" has mostly commandeered the lappy for her photos and emails. She didn't bring hers because she said "one's enough" but tomorrow I will buy another and give her this one. If she catches me with a prop board she will say "you're not working are you?" to which I would say "it's too much fun to be work".
I've made the PCB and assembled it. It isn't working, though. There isn't anything wrong with the connections - just to make sure I wired it up exactly as in Peter's table, and I've checked continuity between the two boards. The only difference is that I'm running it from 3.3V. Perhaps I need to apply 5V as Jim has done.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I'd guess when running on lower than 5v the initialization and data transfer rates need to slow down some, maybe lots. As I stated above, I was trying to start with about 4v on the display with it not running, but does at 4.8v.
Some experimenting will be required to get it going at 3.3v. I eventually wish to run lower voltage too, but first things first.
I'm in the process of wiring it up to my very much hacked about Proto Board and powering it from 5V. If that works I'll try varying the voltage with my bench supply to see how it behaves. Something else just struck me - I have several PowerTip character LCDs and they do work at 3.3V, but require a negative contrast voltage. At 5V the contrast pin can simply be grounded.
Here's a shot of my module connected to a Protoboard. Ribbon connector on opposite side lets module lie in fairly convenient position for now. Second module shows COB parts on back side; quite flat backside. those black jobbers are really thin.
Don't yet have my code and the driver properly interfaced yet to show-n-tell an image. Though have used Peter's demos which ran properly to let me know it's not a wiring problem; just my 'head-scratching' problem to work out. Right now it looks like it is going through memory to display; lots of Chinese-looking characters at times. Feel I'm getting close.
Using your ST7920 LCD 'updater' I've been trying to get my code to work with yours. The demos worked fine, but my program doesn't, so I must not be understanding your code properly. Here is my commented source of your updater. I trust I'm not too far off on what the code is doing.
What I think is the 'missing link' is what is the last portion of code doing, especially the wloop? At the moment I am dumping some values into the 'screen' buffer. On the LCD I see the outside lit up from the backlight, the 128x64 pixels dark except where the data is being held, but a portion of that data appears only partially. That is, the updater is showing my data only partially; takes like 4-6 flashes of the data to appear starting from the top to half-way down, my data. I'd think it should all appear, and be steady; not displaying only a portion of the data.
Just yesterday I realized I had your wloop commented out. By including it and adding to my Spin code byte[noparse][[/noparse]atr] |= $10 did I have it working as just described. What are the value that atrptr needs to 'hold' until changed to another value? I assume it is used to allow the updater to run once until a new value is provided; right? Thanks for any assistance in this matter. Hopefully I don't need too much hand-holding to resolve my problem.
' The LCD is placed into graphics mode and updated continuously from the buffer so that
' it behaves similar to any refreshed display such as a TV or VGA. The buffer size is 1K
' mapped from start to end over to top left to right, top to bottom on the LCD.
' The msb of a byte is left-most.
ST7920 andn outa,_load
andn outa,_sck
or dira,_load
or dira,_sck
or dira,_sdo
mov udly,cnt
add udly,_udly
mov r0,#$01 ' Clear
call #txcmdl
mov r0,#$06 ' Entry mode
call #txcmd
mov r0,#$0C ' Display mode
call #txcmd
mov r0,#$18 ' Cursor display control
call #txcmd
mov r0,#$24 ' Function set - Extended instr. set
call #txcmd
mov r0,#$22 ' Extended function set - graphics
call #txcmd ' Basic instruction set
mov r0,#$02 ' Home ???(DDRAM = 00h)
call #txcmd
mov r0,#$36 ' Function set
call #txcmd
' mov atr,par
' add atr,lcdsz
lcd_loop
mov bufptr,par ' set start address of screen
mov yptr,#0 ' pointer at top (@ $7000)
lcd_loopy mov r0,yptr ' read line
and r0,#$1F ' only lower 5 bits
or r0,#$80 ' Y addr - set byte msb
call #txcmd
mov r0,#$80 ' X = 0 (start of line)
cmp yptr,#32 wc ' in bottom half of display?
if_nc or r0,#$08 ' offset X to access bottom half with mirrored Y
call #txcmd
mov xcnt,#16 ' 16 bytes per line (16 x 8 = 128 pixels/line)
lcd_loopx rdbyte r0,bufptr ' get a byte from HUB RAM
rev r0,#24 ' reverse lower 24 bits
call #txdat ' serially output byte to LCD
add bufptr,#1 ' incre pointer
djnz xcnt,#lcd_loopx ' loop until done with line
add yptr,#1 ' incr Y-pointer
cmp yptr,#64 wz ' test for 64 lines done
if_ne jmp #lcd_loopy ' next line
rdbyte r0,atrptr
or r0,#2
wrbyte r0,atrptr
'{
wloop rdbyte r0,atrptr
test r0,#1 wz
if_nz jmp #wloop
Harley, I'm playing catch-up on so many things at the moment but it just so happens that I need to hook-up and test the display today so I can focus on it I guess. The wloop just synchs the display refresh with the drawing etc so by setting bit 0 it would stop the display from updating. Synchronization is important otherwise the display could be updating with half-erased and half-drawn graphics etc. I'm trying to make this more transparent to the application code though as this is only a demo.
The code byte[noparse][[/noparse] atr ] |= $10 will inhibit the display updating. The original version just had a delay. Perhaps if you post your complete code I can see if it is beneficial for me to add some additional features to my driver. Since I'm spending some time on it today maybe I might polish it up a bit more.
I have the same LCD and Propeller but I do not understand how the two are connected! The manual I got for the LCD is this: http://www.pic16.com/soft/12864_jhd529.pdf
Can anybody describe the circuit diagram? (Since there are only 4 connections it would be easier just to describe.)
Here's my source. Hopefully it copies OK; I'm on an iMac w/Parallels to run Windows and some 'movements' aren't the easiest for me; I prefer the Mac to PC any day.
This version isn't using the 'scale' PASM code. The A/D code is being dumped directly into the 'screen' buffer. Doesn't plot this way, but bypasses 'scale' which might not be working properly.
The comments hopefully describe it sufficiently to understand it.
Here's my source. Hopefully it copies OK; I'm on an iMac w/Parallels to run Windows and some 'movements' aren't the easiest for me; I prefer the Mac to PC any day.
This version isn't using the 'scale' PASM code. The A/D code is being dumped directly into the 'screen' buffer. Doesn't plot this way, but bypasses 'scale' which might not be working properly.
The comments hopefully describe it sufficiently to understand it.
I had some problems getting my display to work too until I realized that the crystal was missing from my demo board!! From what I can see and test from your code there aren't any problems but maybe you are trying to write to the screen buffer faster than the display updates. If you enable wloop you can set bit 0 ( byte[noparse][[/noparse]atr] := 1 ) and then wait for bit 1 (ready) which means that the display is now finished and waiting for you to update the screen buffer. Once you are done you can release the hold by writing a zero the atr byte. Maybe that's all you need unless you are expecting to update too fast.
atr
bit0 hold set by application software to hold display while screen buffer is written to so display is synchronized with drawing (used by wloop)
bit1 ready Set as soon as the screen buffer has been written to the display.
bit4 Invert pixels
I'm working on some new routines tonight to turn it into a complete working object.
Peter, I'm looking forward to it !
I bought one of this and have played around with it during the last weekends. It's a really priceworthy display, both in money and number of used pins !
I had some problems getting my display to work too until I realized that the crystal was missing from my demo board!! From what I can see and test from your code there aren't any problems but maybe you are trying to write to the screen buffer faster than the display updates. If you enable wloop you can set bit 0 ( byte[noparse][[/noparse]atr] := 1 ) and then wait for bit 1 (ready) which means that the display is now finished and waiting for you to update the screen buffer. Once you are done you can release the hold by writing a zero the atr byte. Maybe that's all you need unless you are expecting to update too fast.
atr
bit0 hold set by application software to hold display while screen buffer is written to so display is synchronized with drawing (used by wloop)
bit1 ready Set as soon as the screen buffer has been written to the display.
bit4 Invert pixels
I'm working on some new routines tonight to turn it into a complete working object.
Thanks for this information. I'll go through my code to check if I have it right for what I want.
This LCD item has been removed from ebay!
Does it mean it is no longer manufactured?
I was looking for a similar serial graphic LCD but physically the same size as a typical 2x16 LCD.
Anybody knows if such a smaller sized graphic LCD is available?
That's news to me but ebay stuff varies. I am just confirming now with the manufacturer but you have to buy carton lots so you won't be able to get it from them but I can sell them to you if you want.
There is a smaller graphic display although the resolution is less:
Size : 76.4 x 29.1 x 6.0
Viewing area: 61.0 x 21.0
Controller: SED1520
Comments
I've been looking at your code for the ST7920 assembly coding. Looking at the St7920 data sheet, it appears the initialization might be as listed here:
Byte 'my comment
$01 clear
$06 entry mode
$0C display mode
$18 cursor display control
$24 function set - extended instruction set
$22 extended function set - graphics ON, basic instruction
$02 home? DDRAM - 00h
$36 function set???
I've dealt with non-graphic LCD initialization before. Not always clear from the oriental data sheets. This one is a bit more involved because of the graphics mode. I'm trying to add comments to your code so I can understand what all is being done. Can decipher most instructions to comment them. Thanks for any aid you can provide.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 11/28/2009 5:29:29 AM GMT
I've just got my displays, but I can't identify the serial connections from the JHD520 data sheet or the Sitronix data sheet for the ST7920 controller chip. What pins correspond to CS, SCLK and SID (scs, sck and sdo in your software)?
Edit:
From the ST9720 data sheet it looks like it's these:
SID = R/W (pin 5)
SCLK = E (pin 6)
CS = D/I (pin 4)
Which seems logical as they are contiguous.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/3/2009 2:23:38 PM GMT
I also got mine and have them up and running. Using the serial interface and doing the fonts in SPIN it's pretty slow, but I think it could be made to be sped up quite a bit. And for $22 and only 2 I/O pins, I'm not complaining.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
I've designed a simple PCB for the display with a 2x3 IDC connector. The connections are similar to Peter's table, but I've tied RST high, and am using CS.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/3/2009 10:16:05 PM GMT
I received my displays, provided a header on a Prop Proto board, wired per Peter's information, but it wouldn't initialize. Well, found I had it connected to the 5v regulator output, but forgot that I'm using a 5v switching module which outputs about 4.8v. All is well now that I have the display connected to the power input. Though I will have to be careful when using any other higher power source.
Originally I had about 3 feet of ribbon cable and thought that was the problem, but wasn't. I did however cut about 3-1/2" off one end add a connector which allows the display to lie on the ribbon cable nicely. I'd prefer to have the display right over the proto board, but had added three momentary switches on the right side which now would have been overlapped. Difficult to plan far ahead when one doesn't know such a LCD module would become available. Now wish I'd ordered more than two modules to get a lower price/unit. Cheap ole me.
@Peter, probably delays would have to be added in the init and data passing routines to run at 3.3v, right? I wonder if anyone had tried to run so low. On 3.3v it wasn't as bright, obviously, but appeared to be sufficient for ambient room lighting. I wonder how much slower the device needs to run on lower voltages. Anyone tried running it on 3.3v? At least it appears the spec indicates it can run down to 2.7v.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Here is my schematic:
www.leonheller.com/JHD529/JHD529.pdf
and here is the PCB layout:
www.leonheller.com/JHD529/JHD529_pcb.gif
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/3/2009 10:27:47 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
In my circuit, I have CS (pin #4) pulled directly to 3.3V. I'm only connected to 5 & 6 for Data & SCLK. I was not able to run Pin 2 to 3.3V, it needed 5V for mine to work.
I used the sample code provided and it works pretty good.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
My original code showed CS but I never hooked it up. All the example software except the actual PASM driver is just that, an example. When I get back in a couple of weeks I will code up the font routines etc and post it to the OBEX. I'm not sure about 3.3V operation so I will have a look into that as well. Thanks for the feedback.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Now if your boss was a little more understanding, she would have let you take your prop & laptop with you [noparse]:)[/noparse] Mine lets me but I often do get those funny looks! *grin*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Well it so happens that I had to take a netbook with me and I snuck a few prop boards into the bag though I haven't had much time to do anything and my "boss" has mostly commandeered the lappy for her photos and emails. She didn't bring hers because she said "one's enough" but tomorrow I will buy another and give her this one. If she catches me with a prop board she will say "you're not working are you?" to which I would say "it's too much fun to be work".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/4/2009 8:43:43 PM GMT
I'd guess when running on lower than 5v the initialization and data transfer rates need to slow down some, maybe lots. As I stated above, I was trying to start with about 4v on the display with it not running, but does at 4.8v.
Some experimenting will be required to get it going at 3.3v. I eventually wish to run lower voltage too, but first things first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
That got it working!
I've updated my PCB design:
www.leonheller.com/JHD529
and added a photo of the PCB interfaced to the Proto board.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/10/2009 7:50:34 AM GMT
Don't yet have my code and the driver properly interfaced yet to show-n-tell an image. Though have used Peter's demos which ran properly to let me know it's not a wiring problem; just my 'head-scratching' problem to work out. Right now it looks like it is going through memory to display; lots of Chinese-looking characters at times. Feel I'm getting close.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Do we have some newer code that works?
I go my displays today and just might get to have a play before Christmas, so rather than start from scratch....
Thanks in advance...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 12/10/2009 7:52:40 AM GMT
Using your ST7920 LCD 'updater' I've been trying to get my code to work with yours. The demos worked fine, but my program doesn't, so I must not be understanding your code properly. Here is my commented source of your updater. I trust I'm not too far off on what the code is doing.
What I think is the 'missing link' is what is the last portion of code doing, especially the wloop? At the moment I am dumping some values into the 'screen' buffer. On the LCD I see the outside lit up from the backlight, the 128x64 pixels dark except where the data is being held, but a portion of that data appears only partially. That is, the updater is showing my data only partially; takes like 4-6 flashes of the data to appear starting from the top to half-way down, my data. I'd think it should all appear, and be steady; not displaying only a portion of the data.
Just yesterday I realized I had your wloop commented out. By including it and adding to my Spin code byte[noparse][[/noparse]atr] |= $10 did I have it working as just described. What are the value that atrptr needs to 'hold' until changed to another value? I assume it is used to allow the updater to run once until a new value is provided; right? Thanks for any assistance in this matter. Hopefully I don't need too much hand-holding to resolve my problem.
' The LCD is placed into graphics mode and updated continuously from the buffer so that ' it behaves similar to any refreshed display such as a TV or VGA. The buffer size is 1K ' mapped from start to end over to top left to right, top to bottom on the LCD. ' The msb of a byte is left-most. ST7920 andn outa,_load andn outa,_sck or dira,_load or dira,_sck or dira,_sdo mov udly,cnt add udly,_udly mov r0,#$01 ' Clear call #txcmdl mov r0,#$06 ' Entry mode call #txcmd mov r0,#$0C ' Display mode call #txcmd mov r0,#$18 ' Cursor display control call #txcmd mov r0,#$24 ' Function set - Extended instr. set call #txcmd mov r0,#$22 ' Extended function set - graphics call #txcmd ' Basic instruction set mov r0,#$02 ' Home ???(DDRAM = 00h) call #txcmd mov r0,#$36 ' Function set call #txcmd ' mov atr,par ' add atr,lcdsz lcd_loop mov bufptr,par ' set start address of screen mov yptr,#0 ' pointer at top (@ $7000) lcd_loopy mov r0,yptr ' read line and r0,#$1F ' only lower 5 bits or r0,#$80 ' Y addr - set byte msb call #txcmd mov r0,#$80 ' X = 0 (start of line) cmp yptr,#32 wc ' in bottom half of display? if_nc or r0,#$08 ' offset X to access bottom half with mirrored Y call #txcmd mov xcnt,#16 ' 16 bytes per line (16 x 8 = 128 pixels/line) lcd_loopx rdbyte r0,bufptr ' get a byte from HUB RAM rev r0,#24 ' reverse lower 24 bits call #txdat ' serially output byte to LCD add bufptr,#1 ' incre pointer djnz xcnt,#lcd_loopx ' loop until done with line add yptr,#1 ' incr Y-pointer cmp yptr,#64 wz ' test for 64 lines done if_ne jmp #lcd_loopy ' next line rdbyte r0,atrptr or r0,#2 wrbyte r0,atrptr '{ wloop rdbyte r0,atrptr test r0,#1 wz if_nz jmp #wloop▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
The code byte[noparse][[/noparse] atr ] |= $10 will inhibit the display updating. The original version just had a delay. Perhaps if you post your complete code I can see if it is beneficial for me to add some additional features to my driver. Since I'm spending some time on it today maybe I might polish it up a bit more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Can anybody describe the circuit diagram? (Since there are only 4 connections it would be easier just to describe.)
I am very new to MCU programming!
TIA
www.leonheller.com/JHD529/
It actually needs a 5V supply.
Here are the connections you need for Peter's software (I've added them to the schematic):
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 1/4/2010 7:35:51 AM GMT
It has a 20 pin interface, am I right?
EDIT: I am able to match your schematic with the pin layout I have in the manual. I will try that tonight. Thank you.
Post Edited (hasukuma) : 1/4/2010 2:22:43 PM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Here's my source. Hopefully it copies OK; I'm on an iMac w/Parallels to run Windows and some 'movements' aren't the easiest for me; I prefer the Mac to PC any day.
This version isn't using the 'scale' PASM code. The A/D code is being dumped directly into the 'screen' buffer. Doesn't plot this way, but bypasses 'scale' which might not be working properly.
The comments hopefully describe it sufficiently to understand it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I had some problems getting my display to work too until I realized that the crystal was missing from my demo board!! From what I can see and test from your code there aren't any problems but maybe you are trying to write to the screen buffer faster than the display updates. If you enable wloop you can set bit 0 ( byte[noparse][[/noparse]atr] := 1 ) and then wait for bit 1 (ready) which means that the display is now finished and waiting for you to update the screen buffer. Once you are done you can release the hold by writing a zero the atr byte. Maybe that's all you need unless you are expecting to update too fast.
atr
bit0 hold set by application software to hold display while screen buffer is written to so display is synchronized with drawing (used by wloop)
bit1 ready Set as soon as the screen buffer has been written to the display.
bit4 Invert pixels
I'm working on some new routines tonight to turn it into a complete working object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I bought one of this and have played around with it during the last weekends. It's a really priceworthy display, both in money and number of used pins !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Does it mean it is no longer manufactured?
I was looking for a similar serial graphic LCD but physically the same size as a typical 2x16 LCD.
Anybody knows if such a smaller sized graphic LCD is available?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
There is a smaller graphic display although the resolution is less:
Size : 76.4 x 29.1 x 6.0
Viewing area: 61.0 x 21.0
Controller: SED1520
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*