Searching \ for '[PIC] s1d13700 glcd display skips lines' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/lcd/pic.htm?key=lcd
Search entire site for: 's1d13700 glcd display skips lines'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] s1d13700 glcd display skips lines'
2011\09\17@072802 by Mark Hanchey

flavicon
face
I have a 320x240 glcd with an epson s1d13700 display controller that is paired with a 18lf45k200 chip. The problem I am having is that whatever I display graphically only shows every 7/8th pixel. If I draw pixels using a loop in the code to draw from 0,0 to 0,240 and increment that to 1,0 to 1,240 so that it forms lines on the display ,the lines are drawn properly but the only lines on the display are every 8th row. I can see the lines being drawn on the display but it looks like they are being erased as soon as they are drawn , except for every 8th row.

I tried different libraries, so far it does the same thing whether I use swordfish basic, CCS, or Microchip c18. This was using sample code I found on the net and not code I wrote myself so I can't see how code can be the problem.

More what I am focusing on is the 18LF45k22 chip is running off a 3V supply and the display is running off 5.0V supply. I'm wondering if there  might be some problems with logic levels or maybe it is a timing issue with this specific pic chip. I 'm doubtful on the logic levels because the commands are clearly getting through to the display because it can display text and draws the lines, they just don't seem to remain on the display.

Thanks
Mark

2011\09\17@075754 by IVP

face picon face
> This was using sample code I found on the net and not code I
> wrote myself so I can't see how code can be the problem

Don't count it out. More than once I've found code that purports
to do something but find it just doesn't and never will

> issue with this specific pic chip

That's a problem with downloaded code. It may have worked for
the author in a particular situation but isn't robust enough to work
anywhere else

> the 18LF45k22 chip is running off a 3V supply and the display
> is running off 5.0V supply

Can you try a 5V PIC to rule that in/out ? Or raise PIC Vcc
and lower LCD Vcc to get them closer ?

Every 8th line sounds like it might be a paging issue if your display
has 8-pixel high pages. Might there be some portion of the code
which clears the page just before the 8th line is drawn ?

Jo

2011\09\17@082107 by Kerry Wentworth

flavicon
face
Is it a monochrome display/mode?

Here is what it sounds like to me:

Byte 0 of display RAM is 8 pixels, 0,0 to 0,7, byte 1 is 1,0 to 1,7, etc.
Drawing a line from 0,0 to 0,240 sets bytes 0 to 239 to 0x01
Drawing a line from 1,0 to 1,240 sets bytes 0 to 239 to 0x02, erasing the first line.
Drawing a line from 2,0 to 2,240 sets bytes 0 to 239 to 0x04, erasing the second line.
..
..
Drawing a line from 7,0 to 7,240 sets bytes 0 to 239 to 0x80, erasing the seventh line.
Drawing a line from 8,0 to 8,240 sets bytes 240 to 479 to 0x01, leaving the eighth line intact.
etc.

Kerry



Mark Hanchey wrote:
{Quote hidden}

>

2011\09\17@083744 by IVP

face picon face
> Drawing a line from 1,0 to 1,240 sets bytes 0 to 239 to 0x02, erasing
> the first line

If I understand you, the new data should be IORed with or added to
the existing ? Or 8 lines should be drawn at once with FF ?

Jo

2011\09\17@084257 by Kerry Wentworth

flavicon
face
IVP wrote:
>> Drawing a line from 1,0 to 1,240 sets bytes 0 to 239 to 0x02, erasing
>> the first line
>>    
>
> If I understand you, the new data should be IORed with or added to
> the existing ? Or 8 lines should be drawn at once with FF ?
>
> Joe
>   Assuming that my assumptions are correct, yes.  IORed, that is, not literally added.

Kerry

2011\09\17@101939 by Kerry Wentworth

flavicon
face
IVP wrote:
>> Drawing a line from 1,0 to 1,240 sets bytes 0 to 239 to 0x02, erasing
>> the first line
>>    
>
> If I understand you, the new data should be IORed with or added to
> the existing ? Or 8 lines should be drawn at once with FF ?
>
> Joe
>  
Assuming that his demo code does actually write to 0 to 239 for the first 8 lines (as opposed to having an actual line algorithm), then he could write a 1 to those locations, then a 3, then a 7, then 0x0F, 0x1F, 0x3F, 0x7F and finally 0xFF, then move to the next 8 lines at 240 to 479.  This would draw the lines 1 at a time, preserving previously drawn lines and confirming that this is, indeed, the problem.

Kerry

2011\09\18@092730 by Mark Hanchey

flavicon
face
On 9/17/2011 10:17 AM, Kerry Wentworth wrote:
>
> Assuming that his demo code does actually write to 0 to 239 for the
> first 8 lines (as opposed to having an actual line algorithm), then he
> could write a 1 to those locations, then a 3, then a 7, then 0x0F, 0x1F,
> 0x3F, 0x7F and finally 0xFF, then move to the next 8 lines at 240 to
> 479.  This would draw the lines 1 at a time, preserving previously drawn
> lines and confirming that this is, indeed, the problem.
>
> Kerry
>

It turned out not to be a problem with the demo code drawing routines but was a simple error on my part.
I wasn't used to the pic 18lf45k22 and didn't realize that on it PortD, the port I used for my data lines , are used for analog ports 20-27. All the pics I used previously were smaller chips and only had ports A-C, with port B being the main analog ports. Adding one line to the program fixed the issue ,  ANSELD=0 . Foolish me, but now I know to read the datasheet more thoroughly.   I still wonder what was going on electronically to make every 8th pixel show , if anyone can explain why leaving analog on with the data pins caused every 8th pixel I would be interested in knowing.

Thanks for all the suggestions and maybe this will help someone else out of this awkward error.
Mark

2011\09\18@105835 by Kerry Wentworth

flavicon
face
Mark Hanchey wrote:
> It turned out not to be a problem with the demo code drawing routines
> but was a simple error on my part.
> I wasn't used to the pic 18lf45k22 and didn't realize that on it PortD,
> the port I used for my data lines , are used for analog ports 20-27. All
> the pics I used previously were smaller chips and only had ports A-C,
> with port B being the main analog ports. Adding one line to the program
> fixed the issue ,  ANSELD=0 . Foolish me, but now I know to read the
> datasheet more thoroughly.   I still wonder what was going on
> electronically to make every 8th pixel show , if anyone can explain why
> leaving analog on with the data pins caused every 8th pixel I would be
> interested in knowing.
>
> Thanks for all the suggestions and maybe this will help someone else out
> of this awkward error.
> Mark
>
>   Setting an I/O bit involves a read/modify/write of the entire port.  When a pin is set to analog, reading the pin returns a 0, regardless of the setting of the pin.  So if portb is set to all analog, then PORTB.7=1 will set pin 7 to 1, but a subsequent PORTB.6 will set pin 6 to 1 and will set pin 7 to 0.

Is that what you were seeing?

Kerry

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...