Graphic LCD 96x64 w/ SED1565 Controller

[ThermalRunaway]

Well, the parallel port test is out because I've discovered that there is no parallel port on my PC's motherboard!!!

So, in the interests of proving this one way or another, I copied your code over and modified it to suit my compiler.

It compiles okay, and when I scope the clock and data lines I can see... well... clock and data, but still there is no response on the LCD.

So now, more than ever, I am doubting the display. Time to swap it out, I think.

Damn.

Bri

 

[AtomSoft]

Sorry to hear that. If i was you i would get a older laptop at least with a parallel port. Will run you about $100 if you look around. Install XP on it and use it as a testing PC.

Well worth it. I bought me a laptop like that...

 

[ThermalRunaway]

Yeah I think you're right. The bizarre thing is, they've gone to the trouble to include an RS232 port but not a parallel port. I wonder if there is actually a parallel port on the motherboard but they've not bothered to provide a connector for it... might be worth a look.

Anyway, I've swapped the LCD out, and STILL there is no response. So either there is something inherently wrong with what I'm doing, or I've got two faulty displays in a row.

I'm beaten for the moment. Think I need to come away from it for a bit! I need to confirm that my display is definitely okay before I go any further I think, otherwise I'm just going to keep going round in circles.

Bri

 

[AtomSoft]

Draw a full schematic and take a picture if possible and show put all your code up here and ill see what i can find

 

[ThermalRunaway]

I'm getting somewhere!

I managed to get hold of a known good LCD and with it I've determined the following:

My code doesn't work

Your code does work

Previous LCDs were faulty

So all I need to do now is figure out why my code is failing. Mine is written quite different to yours because I'm using the internal SSP module. I'm betting that it'll be some quirk in the way I've set up the SSP module to communicate that's causing the problem. I know that my code sends out the correct data because I've checked it on my DSO, but perhaps there's a problem with the way the normal logic level for the clock is set (high or low), or whether the data is sent on the rising or falling edge, or some silly setting like that.

I'm now going to capture the data sent when I load your code, and compare it to the data sent when I load my code.

Back later!

Brian

 

[ThermalRunaway]

My code is now working

I analysed the difference between the data captured with your working code and my failing code and I saw that although both our software was set up for data to be clocked on a rising edge, yours was set to normally high data & clock lines, where as mine was set to normally low!

See pictures. The data between the two systems is the same (the capture shows the first command, A6, being sent) but my lines are active low. Doh!

This was easily fixed with a simple bit change in the SSPCON register. After that all is well with my code.

If only those faulty LCDs hadn't clouded the issue I'd have had this figured out yesterday!



Brian

 

[AtomSoft]

Cool please report how it goes... I would like to see results with the hardware SPI

 

[ThermalRunaway]

Yep no problem. Once I have everything up and running the way I like, I shall upload the code and also maybe a video of it working

Thanks for your help Jason!

Brian

 

[AtomSoft]

Heh no problem. Thank you too for posting your code when ready. Putting your source code here not only helps others but may help you one day if you experience data loss on your pc.

 

[Sceadwian]

Yeah, this is one of those weird forums (gotta love Electromaster) that never delete attachments.

 

[ThermalRunaway]

Okay here's my first attempt. All this version does is initialise the LCD, turn all pixels on for about 1 second, and then clear the screen.

Jason - I used your initialisation commands because I could make no sense of the Power Supply commands that would be required! How did you find all that out?!

Next step is to make a font, or see if I can find some pre-made fonts somewhere that will be suitable. Then use the font to write some text on the screen.

Brian

 

[AtomSoft]

um ill post you a link to a secret i found and shared:

https://www.electro-tech-online.com/threads/glcd-font-creator-read-all.97027/

 

[AtomSoft]

Here is a video of how it works heh: (i didnt crack or hack anything ok) this is a glitch they didnt notice maybe:

**broken link removed**

 

[ThermalRunaway]

Yeah I've had a look at it and to be honest I can't see how that "feature" would be anything other than intentional. The person who wrote that program must surely have been aware that it was possible to create a complete font in this way, because otherwise it really is a glaring bug to have left behind!

I just think it's there as a continual annoyance to convince you to register.

I reckon I'd register and pay for the app, if they improved the font import functionality.

Brian

 

[AtomSoft]

yeah ... hope you enjoy it for now. I doubt they are upgrading it at all

 

[ThermalRunaway]

Here's a version of my program that includes a simple font and allows you to print text to the screen using lcd_print ("put text here") ;

There are several problems with this version, though:

1. The BoostC Compiler does not allow multi-dimensional Arrays in ROM space, so I had to implement it with rom char *Font {........}; instead, and then come up with a function that would calculate the x and y coordinates depending on the ascii value of the character being processed.

2. This would have been fine, but then I found out that the BoostC compiler only supports 8-bit Arrays in ROM space, which means that a maximum of 31 characters can be utilised per array (8 bytes per character)

I thought I might be able to get around this by having a separate array for upper-case, lower-case and special characters (making 3 arrays in total) and then writing a function that would access the correct array depending upon the character currently being processed. But this is messy and I don't like it. It also begs the question, "what about bitmap images"?

So clearly something has to be done about it. It has been suggested that I could just store the font data in the ROM using #pragma DATA and access it that way, thereby bypassing the need for an Array (and it's associated limits). I'm going to look into this and see what I can come up with. I also want to be able to pass line and column data to my function and let the function do the rest, so that data can be printed using something like lcd_print ("text to be printed", line, column) ;

I'll work on that and report back when I have a better program! For now, please find attached my progress to date.

 

[ThermalRunaway]

Oh, and here's a picture of it in action:

**broken link removed**

 

[AtomSoft]

Nice!! you got it off a acutal Phone heh. I have like 15 of these LCDs. All new. I barely use them heh i have to send a few out to some people tho. Lets see if i have a contest of my own soon. not sure on what and lets see who wins some LCDs heh

 

[ThermalRunaway]

I did buy a big bunch of these LCDs from some guy state-side, but it looks like they might all be faulty (I've tried three and they were all dead). The only way to confirm if I had a problem with my code or the displays was to nab one from a working phone

 

[VISN]

Dead? I bought a few of ebay and have not touched them as yet. Still in the factory trays - but you have now got me worried. I was planning on making some test equipment - fancy LCF, VIR - and mp3 player - I get frustrated with even the fancy ones because I don't like the interface. (I need winamp type navigation & an IR remote).

What is the current draw on these, with/out backlight?