PDA

View Full Version : Nokia COLOR LCD PicBasicPro 2.50a example code



skimask
- 16th February 2008, 10:33
Some basic example code for the Nokia Color LCDs found in a lot of cellphones.
Basic code, prints text, in up 256 colors (out of 4096 possible, and the controller/firmware is actually capable of 18 bit color, but I can't tell the difference), clear screen, a method for printing variables (bits, bytes, words, and longs), x/y plotting, etc.

The code with all of the neat graphic functions like circles, lines, boxes, waves, etc. will be here eventually.

Cut and paste this into eBay's search bar to find LCDs that are compatible with this code:

nokia -6620 -6230 -6061 -3220 -73* -n9* -52* -77* -6500 -57* -53* -88* -6101 -6126 -6265 -6680 -e6* -6288 -n7* -6133 -8600 -6300 -6230i -6010 -5610 -9300 -3310 -5110 -8810 -n8* -3250 -5500 -6111 -6280 -8850 -6120 -3360 -6360 -6600 -3230 -8210 -e90 -n93 -e5* -1110 -8910

Sparkfun also has these displays:
http://www.sparkfun.com/commerce/product_info.php?products_id=569

And check out sparkfun for adapter boards to plug it in:
http://www.sparkfun.com/commerce/product_info.php?products_id=600

And the connector if you want to plug it in yourself somehow: (also available at Digikey and Mouser, just have to search for it)
http://www.sparkfun.com/commerce/product_info.php?products_id=570
Code is originally written for a PIC18F4620 running at 40Mhz. If the LCD is mounted close, and you're relatively sure the signal is strong, you can get rid of the extra sdata lines in the togglesclock block to make writing to the LCD much faster. I had to add the extra 'delay' because my LCD was connected to the PIC on a 6ft cable.

The font table requires a PIC with 1K of EEPROM (the basic font table will fit in 512 bytes, ASCII 0 thru 127), so the PIC choices are a bit limited in that respect. This font table is copied into RAM on startup so it can be easily modified if needed. Or I suppose a person could easily change the code to put the table into program memory easily enough and read it out from there.

skimask
- 18th February 2008, 09:23
Picture of my Nokia color LCD mounted (ok, zip-tied) in an old, dead, handheld GPS unit.
Only basic text is shown in this picture along with a few colors. The program the PIC is running at this moment only displays white, blue, and green. It would display some reds if the parameters were out of tolerance, it's in simulation mode so everything is good.
The white blob in the middle is actually reversed text, supposed to read 'MIL', but you can't see it because of the camera angle. It's readable, just not to the camera. :) The white blob towards the bottom right is a better view of reversed text, somewhat visible. In this case it says P0999, a test code for my program.
The graphics routine code is coming along, just not fast. The code I've got now is one big kludge of math and takes entirely too long to execute, even with an 18F4620 @ 40Mhz.
After I get that sorted out, I'm going to try a bit of 3D. A bit tough with the ram limitations of a PIC, but we'll see what happens.
<IMG SRC="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2370&stc=1&d=1203322868">

(In case anybody's wondering (top to bottom, left to right), that's: Intake Air Temp, Coolant Temp, Manifold Air Pressure, Timing Advance, RPM, Air/Fuel Ratio, Calculated Load Value, Miles per Hour, Volumetric Efficiency, Throttle Position, Fuel System Status, Battery Voltage, Engine Size, OBD PID mask for $01-$20, short/long term trims, 3 test characters, MIL indicator, system run time, keypress, loop count, current menu, event record, engine run time, odometer, mpg (mass air), mpg average (mass air), mpg (calculated from map/iat/rpm/cid), mpg average (calculated from map/iat/rpm/cid), mpg calculated from odo vs. fuel used, mass air flow from sensor, mass air flow (calculated from map/iat/rpm/cid), gallons per hour, fuel used total, cost per minute, cost per gallon, miles remaining on tank, fuel tank level, vehicle weight, diagnostic/information messages...... A lot of information for one screen. Can anybody guess what I'm building and how many colons it took to write the code? :) )

duncan303
- 18th February 2008, 12:03
and how many colons it took to write the code? )


well……..as a guide there are 336 characters on the screen of which some 25 are :colons… roughly about 8%

so with a couple of thousand words …….


I wasn’t expected to actually count them……………… was I? :D I’m not falling for that trick again.

Anyway I am on for ripping some phones apart, so thanks for the insight, to drive these units.
Although at the moment I am in the middle of part mining an autofeeder minolta colour photocopier.
Does that laser scanner motor really spin at 165,000rpm. What can I use that for? A colon detector maybe??


I am thinking of a colon expander/compounder reformatting macro…., for printing purposes :)

Look after your health… look after your colons :D

Wouldn't be able to cope without mine!

skimask
- 19th February 2008, 05:33
well……..as a guide there are 336 characters on the screen of which some 25 are :colons… roughly about 8%
so with a couple of thousand words …….
I wasn’t expected to actually count them……………… was I? I’m not falling for that trick again.

In my last bit of code that runs that particular program shown in the picture, the code has 2,057 lines as it stands right now....and 2,324 colons! (I used MS WORD, did a Cntrl-H replace for the colons and that's the number that WORD said it replaced.


Anyway I am on for ripping some phones apart, so thanks for the insight, to drive these units.
Although at the moment I am in the middle of part mining an autofeeder minolta colour photocopier.
Does that laser scanner motor really spin at 165,000rpm. What can I use that for? A colon detector maybe??
I am thinking of a colon expander/compounder reformatting macro…., for printing purposes :)
Look after your health… look after your colons
Wouldn't be able to cope without mine!
Ripping - I've got a few 'dead' phones that I've collected myself. Those LCDs are pretty much the same, slightly different, pretty much based on the same coding. But the Nokia types are the cheapest by far.
Scanner motor - 165,000 rpm? I'd doubt that. Maybe if the mirror is multi-faceted, they're actually multiplying the RPM times the number of facets... But yes, I suppose you could use it for a combination colon detector/driller... :D
Colon Expander/Compounder - I was at a local truck stop over the weekend. I think I was fed a combination 'Colon Expander/Compounder', although I didn't become aware of it until a day or two later. :D

srspinho
- 21st February 2008, 17:17
Hi Skimask,

about one year ago I bought SparkFun´s Nokia COlo LCD + Adapter Board (plus aditional connectors). The board is nice, but the Connector soldered into it is really fragile. after some use, the connector broke up and I had to solder a new one on the board. An Advice for new buyers : use a double-sided tape to hold your display on the board.

After some fails trying to put it working (just got de backlight on and nothing) I gave up for a while.

I was using a 16F877 @ 10 Mhz justo to make some testes.

Last Monday I saw your post here. So, I got it and tried to compile it (setting the MCSP to work with the 18F4620), but got some errors due to some missing variables, like "font", "digcount" and "offset" for example.

Is this source to be used as an Include and I have to do some work to complement it or I am missing something else ?

I´m sorry for this stupid (?) question...

skimask
- 21st February 2008, 18:31
Last Monday I saw your post here. So, I got it and tried to compile it (setting the MCSP to work with the 18F4620), but got some errors due to some missing variables, like "font", "digcount" and "offset" for example.
Is this source to be used as an Include and I have to do some work to complement it or I am missing something else ?
I´m sorry for this stupid (?) question...

That's what I get for shaving down another program and posting it, in a hurry no less...
I'll check what I posted and get a new file up there when I get a chance...figure by the weekend for sure.

In the meanwhile,

font var byte[1024]
used to hold the whole font which is copied out of eeprom into internal ram. If your PIC doesn't have 1024 available RAM, you can't use this example. In fact, your PIC MUST have 1024 RAM and at least 512 EEPROM available. When I get a chance, I'll post a 2nd version that won't require copying the font out of EEPROM, thereby won't require 1024 free ram.

digcount var byte
used in the clcddigout routine to output a number, sorta like "lcdout DEC variable"
if the number in the variable is $ffff, and you used digcount = 5, the output will be 65535, if you used digcount = 4, the output will be 5535, digcount = 2, output will be 35, and so on.

offset var byte
used in the clcddigout routine to specify a starting digit to output,
offset=0 means the whole thing,
offset=1 means starting from the 10's digit,
offset=2 means starting from the 100's digit, and so on...

Let me know if/when you get it working for you...and like I said, I'll double-check that file I posted.

skimask
- 21st February 2008, 20:35
Re-Post of the code in Post #1...with a few fixes and more comments...
(again, untested, I'm not at my home PC, but it should be good as long as you've got your LCD hooked up correctly)

srspinho
- 21st February 2008, 22:08
Hi SkiMask,

thank you !

I´m trying to find a 18F with 1024 bytes of Ram and 512 bytes of eeprom here in Brazil (no success yet . . .)

I think I´ll need to reduce the amount of available ASCII characters and use a smaller PIC than 18F4620.

skimask
- 21st February 2008, 22:15
Hi SkiMask,
thank you !
I´m trying to find a 18F with 1024 bytes of Ram and 512 bytes of eeprom here in Brazil (no success yet . . .)
I think I´ll need to reduce the amount of available ASCII characters and use a smaller PIC than 18F4620.

Reducing the character set might work, you'll have to figure out how many characters you can support and change MAXCHAR to fit (5 bytes per character, the font follows the ASCII standard fairly closely).

I guess I'll work on rewriting the code again to put the character set into program memory.
That way all that'll be needed is a few bytes of ram for parameter support, about 1K of program space, and some space for the supporting code itself. Should be able to fit that into practically any PIC ('cept for the 10F series, not enough pins :D )

Which PIC are you using in particular at the moment right now as it stands at this time :) ?

srspinho
- 21st February 2008, 23:05
Hi Skimask,

well, the unique 18F i have at home right now is the 18F2520.

I have, also a lot of 16F877 and 876 (pretty small for this application isn´t it ?)

My first tests (long time ago) were done in a 877 when I just try to set pixels on / off

I think I did something really wrong in the LCD initialization.

Another doubt : The LCD´s datasheet says that it works with 3.3 v but, the pic and it´s ports works with 5 V is there any problem on hooking up the LCD´s data pins directly to the PIC running with 5Volts ?

skimask
- 22nd February 2008, 00:15
Hi Skimask,
well, the unique 18F i have at home right now is the 18F2520.
I have, also a lot of 16F877 and 876 (pretty small for this application isn´t it ?)
My first tests (long time ago) were done in a 877 when I just try to set pixels on / off
I think I did something really wrong in the LCD initialization.
Another doubt : The LCD´s datasheet says that it works with 3.3 v but, the pic and it´s ports works with 5 V is there any problem on hooking up the LCD´s data pins directly to the PIC running with 5Volts ?

I think it'll run just fine, even inside a 12Fxxx, once I modify the code to put the basic font in program memory. Sure, it would be limited in what you can see on the screen, but it should work.

3.3v vs. 5v. - I'm using the Sparkfun adapter board shown in the link in Post#1. I put a 100ohm series resistor inline with each of the control/data lines. Seems to work ok. The 3.3v line is getting an actual 3.3v thru a LDO regulator tapped off the PIC 5v. At first I was running it from 5v thru 3 diodes for a ~1.8v drop for the LCD power, giving about 3.2v on the output. It's still alive. And it's even still alive after literally thousands of improper power downs. The LCD controller datasheet says you should power it down in a specific sequence. I've just been killing power, again, seems to work.
And I'm connected to the 6 pin header at the one end, with a 100uF elec. cap across Vdisp and ground at the other end.

srspinho
- 22nd February 2008, 01:43
Hi Skimask,

I´m using the same Sparkfun´s adapter board (I bought 2 boards one year ago) and a ATX power supply (converted into a workbench PSU) to get 5V, 3.3 V and 12 V (when I need it).
Untill now, this PSU did not have problems and Í have been powering my circuits with it without problems.

But, as you told in your last post, I will tie thr resistors before turning my lcd on. I dont´t want to fry my board and the LCD.
Buying those things from Brazil takes about 3~4 weeks to get the products delivered and we have to pay 60% of total value as Import Tax :( . . .

skimask
- 22nd February 2008, 01:50
But, as you told in your last post, I will tie thr resistors before turning my lcd on. I dont´t want to fry my board and the LCD
In my case, with power applied correctly, and only power, no code is running, no nothing, the LCD has a bluish background on it. The initialization has to command the backlight to come up. If it doesn't, you won't see anything on the screen unless you've got great eyes and tilt the thing at just the right angle, then you might barely see shadows of something on the screen...if you've written something to it... Other than that, it'll be blank.

skimask
- 24th February 2008, 03:00
Just like the title says...
The 'font' stays in eeprom (need a PIC with a minimum of 512 bytes, otherwise characters will get dropped) and minimal ram is needed (37 bytes).
If you're tacking this program onto something else, pay attention to the variable names. Maybe go back and pre-pend them all with CGLCD or something to keep them from getting overwritten or overwriting something important to you...

Next up...the font goes into program memory instead of ram or eeprom. Should open up the code to practically every PIC out there with at 2K of program memory and more than 37 bytes of ram (most PICs except for the 10Fxxx and some of the 12F series)...

After that, the shape drawing routines, and maybe some 3D functions I've been playing with...

EDIT: Found a bug...pulled the code for now...will have new stuff up later tonight...

skimask
- 24th February 2008, 08:19
This time the font goes in program memory at the high end.
Pay attention to the notes in the code. You have to change a couple of values based on the PIC you are using, then you may have to do some math if you are using a bootloader, so you don't overwrite the bootloader with the font.

The basic code and the few examples I added take up 3,223 words along with 640 words (1280 bytes) for the font itself.
So, you now need a PIC with at least 4.4K free of program memory and 37 bytes of free ram. And if you cut the font down from 256 to 128 characters, only 3.8K of free program space is needed...even less if you cut the font down even farther.

I pre-pended all of the variable names with CLCD, so you shouldn't have a problem with variables overwriting each other unless you've got a variable that starts out with CLCD.

I wrote this code to run on a PIC18F4620 'cause that's about all I use these days and I'm fairly sure it'll run on any PIC18Fxxx(x) series, as long as the person using it changes the requisite registers as required (READ THE DATASHEET for the PIC!!!).

I'm not sure if it'll run on 'lesser' PICs, i.e. 16F, 16C...it should with a few changes. It may even run on a 12Fxxx series if the code is cut down to an absolute bare minimum, the font cut down to practically nothing...but there probably won't be any useful code space leftover. PIC10Fxxx types are definitely out of the question.

Enjoy... Graphics routines are in work and will be posted when I'm done with them...

srspinho
- 9th April 2008, 18:58
Hi Skimask,

I just received my Color LCD and the breadboard from SparkFun.

I´m trying to convert your source code to run on a 16F877 (8 Kb, 368 byts of RAM, 256 bytes of EEPROM)
I´m doing that just because I can not find the 18F4620 here in Brazil.

So, I did some modifications as you suggested :

1) Changed de OSC to 10 (Mhz)

2) The line :
clcdENDFLASH con $FFFF 'IMPORTANT - change this value to the size of the PICs program space - 1
was changed to :
clcdENDFLASH con $1FFF 'IMPORTANT - change this value to the size of the PICs program space - 1

3) At the end of the code, the Org value was changed to org 0x1F60

4) Removed the 13 last lines used for the modified ASCII characters

But, when I try to compile, the PBP returns some strange error messages :

Warning[207] d:\teste_~1\nokia~2.asm 188 : Found Label after column 1. (bra)
Error[122] d:\teste_~1\nokia~2.asm 188 : Illegal opcode (clcdoverstr)
Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (5465)
Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (7374)
Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (7472)
Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (696E)
Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (6723)

I don´t understand why the code doesn´t fit in my 877, since the same source compiled for the 18F4620 takes less than 3 Kb...

Do you have any idea or any tip to fit it on a 877 ?

Thank you !

skimask
- 9th April 2008, 19:46
I´m doing that just because I can not find the 18F4620 here in Brazil.
They're available practically everywhere else in the world... You've obviously got internet access...Get one...


Warning[207] d:\teste_~1\nokia~2.asm 188 : Found Label after column 1. (bra)
Error[122] d:\teste_~1\nokia~2.asm 188 : Illegal opcode (clcdoverstr)
Because there isn't a 'bra' opcode in the 16F877. The 2nd error is probably a result of the first.
Change the bra to goto in the macro and see what happens...


Message[303] d:\teste_~1\nokia~2.asm 190 : Program word too large. Truncated to core size (5465)

I don´t understand why the code doesn´t fit in my 877, since the same source compiled for the 18F4620 takes less than 3 Kb...
There's a number of different reasons. 18F registers don't multiple bank bit setting instructions every time you want to access a variable, 16F's do. Every time you want to access a register in an 18F, you just access it, period. With the 16F, you have to set either 1,2, or 3 bank bits first, then you can access it. So, for every variable access with an 18F, one word, for every variable access with a 16F, could be up to 3 instructions just to get to it. (see section 2.4 of the 16F877A datasheet and/or section 5 of the 18F4620 datasheet)

16F877 or 16F877A?

mister_e
- 9th April 2008, 20:06
CHK?RP do it for you :D

16F compile results is in WORDS while 18F is in BYTES

srspinho
- 10th April 2008, 14:40
Thank you guys !

well, I´m trying to buy the 4620 from the Brazilian Microchip official vendor. They say that the 4620 is not an usual item (?) and they have to import it and it will take a long time.

So, I decided to move my project to a 4550. I think this model will do the job.

Thank you again !

Regards

Sérgio

DaveC3
- 10th April 2008, 22:47
srspinho

Here is some code for the same display. I used some of Skimask's code for text manipulation. I am also sending pictures via USB from the PC. You will also see an encoder input to adjust the contrast of the display. Hope it helps.

Dave

srspinho
- 11th April 2008, 14:18
Thank you Dave !

sure it will help !

Just a doubt : What PIC have you used with this code ?

Finally, today I will receive my first 18F´s (one 18F4550 (really expensive) and 2 18F2520).

Thank you again !

DaveC3
- 11th April 2008, 14:28
srspinho

I use 18F4550 with USB boot-loader (slightly modified). I also made a VB6 program to send color pictures to the display via USB. If you are interested I can send you all the source codes.

Dave

srspinho
- 11th April 2008, 15:16
Hi Dave !

sure !

Would you like to post it here or send it by e-mail ?

I think some other people here would like to check it out also !

regards !

Sérgio

DaveC3
- 11th April 2008, 22:36
Sérgio

I have attached the PBP files, VB6 file and a program to convert BMP pictures to data files. For all this to work together you will need to download MicroChip's USB Boot-loader, Mecanique's EasyHid (both free). If you use the attached Boot-loader HEX file you will not have to add or change any configuration bits in your project. You may want to edit the 18F4550.inc file to remove the configuration settings so it will not try to overwrite the configs.

In the boot-loader setup, I changed the program switch assignment to PortC.2 and the two LEDs to PortC.0 and PortC.1.

I am not a programmers so please forgive the lack of comments or poor program protocall. All I can tell you is it works.

Dave

Sorry the zip file was to large to send. Give me your e-mail address and I will send it to you.

DAve

srspinho
- 13th April 2008, 00:55
Hello Dave,

sorry for my alte response (I had a small car accident yesterday).

Thank you very much for your response. If you want, you can send it to [email protected]

I think gmail can handle big atached files !

Don't worry about the Code comments :)

First, I will try everything without USB connection. After that I will try to implement everything together !

Thank you again !

regards.

Sérgio

DaveC3
- 15th April 2008, 03:56
Sérgio

Did you get the files I sent you?

Thanks

Dave

srspinho
- 15th April 2008, 14:21
Hi Dave,

Thak you for your reply.

Yes, I receive your e-mail on my gmail account, but, the files were received by gmail as plain text... strange... is the zip files bigger than 2 Mbytes each ?

regards.

Sérgio

DaveC3
- 15th April 2008, 17:31
Sérgio

I took out some of the supporting files, here is the VB6 code and the PBP files. Again, I am using the microchip USB Boot-loader, EasyHid so you will need to load the drivers for these programs. I also use a BMP to HEX editor to produce the color Images on the display. I send them via USB 64 bytes at a time so the picture loads fairly fast.

Good luck

Dave

mister_e
- 15th April 2008, 17:47
Out of curiosity, which BMP to HEX software are you using?

skimask
- 15th April 2008, 17:52
Sounds like the beginnings of one of those mini- LCD picture viewer things...

srspinho
- 15th April 2008, 18:26
Hi Dave,

thank you very much for these files !

Well, last weekend I changed your first code removing the USB stuf and the picture download.

It worked very well !

I bought 1 LCD and 2 breakout boards from SparkFun. One of the boards are not working (the LCD keep the backlight lit and nothing happens). Checked the connector and discovered that 2 connector´s legs are short circuited.

So, the LCD was installed in the another board and everything worked fine.
My board is running with a 20 Mhz crystal, but I think it is a bit slow. So, I will change it to full speed and check if it gets better.

Well, I will check your new files and see what I will need to change here !

Tahnk you Again !

PS. Did some one here successful on buying some Lib from ComSys1 ? I have been trying to contact them to buy the KS0108 Graphic lib but they never answer the e-mails!

Regards

skimask
- 15th April 2008, 18:36
My board is running with a 20 Mhz crystal, but I think it is a bit slow. So, I will change it to full speed and check if it gets better.
Mine is running with an 18F4620 @ 40Mhz.
Using bare bones code, just sending black and white picture data as fast as possible with the LCD directly connected (well as close as possible, about .2") to the PIC, I'm only able to get about 6 complete screen refreshes per second (switching back and forth from black to white).
Those LCDs aren't the fastest thing in the world...

mister_e
- 15th April 2008, 18:41
And i guess they're not going to appreciate faster communication with the MSSP as well?

but 6 screen/second is a bit more than enough... unless you read really fast :D

skimask
- 15th April 2008, 18:52
And i guess they're not going to appreciate faster communication with the MSSP as well?
That's why I never bothered rewriting the code to use the MSSP, just wasn't worth the code space and/or effort at the time.
The LCD spec's at 6Mhz SPI rate, but I can't seem to get it much higher than 2.5Mhz. Probably an extra Tcycle delay somewhere in the datasheet that I missed. Might need to have a small delay after each byte or group of bytes is sent or something. Don't know, don't care, works for me.

And working from that same rate of 6 screen refreshes per second...
With straight text, I can send about 2K characters per second to the screen, actually a bit more.
Plenty fast...

srspinho
- 15th April 2008, 20:53
Hi guys,

6 pages / Second ?

I´m starting to think that´s something wrong with my tests...

First, the init process takes around 40 seconds (?), so, the screen lights up with a random pattern (white background with random colored dots).

The speed is pretty far from what Skimask and Dave got on their tests.

skimask
- 15th April 2008, 21:20
Random dots - pretty much normal. I get them every time, but the screen is usually cleared straight away so I don't see but a flicker upon startup.
Speed out in the weeds - maybe... 18F is probably a bit less than twice as efficient as a 16F at the same clock speed. You're running 20Mhz vs. 40Mhz. Still that's only 4x difference at the very most.
The init process on my setup takes about 2 seconds, give or take...and that's a big give or take...
Me thinks you've got something wrong with your OSC settings...
Time for a 1 second blinky LED test...
Just a thought here...
40 seconds to start up..............
DEFINE'd OSC 20Mhz vs DEFINE'd OSC 40Mhz, 2x difference = 4 seconds
PIC18F vs PIC16F, 2x difference = 8 seconds
Actually running at 4Mhz vs. 20Mhz... 5x difference = 40 seconds...
2 x 2 x 5 = 20x difference = 40 seconds vs 2 seconds...
Something to think about...

srspinho
- 16th April 2008, 02:03
Hi Skimask,

actually, I'm using a 18F2520 with a 20 Mhz ressonator and a DEFINE OSC 20 at the begining.

The data Sheet says that the clock runs at 4x by default. It means that I can use a 10 Mhz crystal with a DEFINE OSC 40 ?

I'm going to do some changes in the source code and try to check what's happening.

Regards.

Sérgio

skimask
- 16th April 2008, 03:13
What I was getting at was that maybe you should run a test blinking an LED, one second on, one second off, make sure your OSC is actually running at 20Mhz. If you've define'd it correctly, and your CONFIG is correct, it'll blink once per second.
If your define doesn't work, and it's running at 20Mhz, it'll blink 5x per second.
If your define is correct, and you're running on the internal 4Mhz or something, it'll blink something like once every 5 seconds.

10Mhz running 40Mhz...
Re-Read the datasheets...
Enabling the 4XPLL allows the PIC to effectively multiply some clock sources by 4x, 10Mhz crystal w/ 4xPLL enabled = 40Mhz internal. 4Mhz internal + 4xPLL = 16 Mhz internal.

Or, you might be talking about the instruction rate.
The instruction rate is the effective clock rate /4. Each instruction takes 4 clock cycles to execute. If you're running a 20Mhz oscillator, the PIC will execute instructions at the rate of 5 million per second (except for double cycle instructions like jumps, branches, skips, returns, etc)....

srspinho
- 16th April 2008, 03:27
Thank You Skimask !

I will check all your suggestions this weekend, since I'm going on a busines travel tomorrow (not related to electronics...)

thank you again.

Sérgio

mister_e
- 16th April 2008, 03:28
HPWM, PAUSEUS, HSEROUT a scope are some tricks ;)

DaveC3
- 16th April 2008, 15:20
mister-e

The converter I am using is NOKIA 6100 BMP Converter v1 I found it at http://www.picbasic.org/forum/showthread.php?t=8649

Also, as far as speed is concerned, a full picture rendering via USB using eight byte buffers was very slow. I increased the buffer size to 64 bytes and it now loads a picture fairly fast.

Dave

skimask
- 16th April 2008, 15:30
I never did get that BMP converter to work right...but I didn't try very hard...

USB buffer - oh yeah...way less overhead with 64 bytes. I suppose once you get a buffer size much bigger, the speed doesn't increase so much......that whole 'law of diminishing returns' thing.

Is your code based on the 8 bit color coding?

I'm in the process of rewriting some code to incorporate the full 262K color mode (18 bit). It'll kill performance by a factor of at least 3, but it'll be cool....right?

DaveC3
- 16th April 2008, 21:37
Skimask

The splash screen is 8bit but the picture is 12bitB. When I played with it I tried all three possibilities. All worked you just need to change the configuration command on the display.

It took me a while to get the VB6 program to read the file from the converter. The problem was at the end of each line of data VB6 tried to send a "0" which caused the display to be skewed. I finally sorted it out and all was well.

I did not try an external eeprom yet. The color picture was to big to fit into the PBP code. Or at least I could not figure out how to get it in without exceeding the size limit.

It would be easy enough to make a photo album that changes the image every so many seconds/minutes. Maybe someone will put a compact flash or SD ram with this display. I do not think it would be that hard.

I have no real practical application for this screen, I just wanted to see if I could get it to work.

Dave

By the way, I used your text macro. Thanks it worked great!

mister_e
- 16th April 2008, 21:48
mister-e
The converter I am using is NOKIA 6100 BMP Converter v1 I found it at http://www.picbasic.org/forum/showthread.php?t=8649


Thanks Dave

skimask
- 17th April 2008, 01:23
By the way, I used your text macro. Thanks it worked great!

Don't blame me for that one! :D
That's mostly DT's work (or was it Mr_E?, I forget).
I only modified it a bit to work with my application.

skimask
- 8th June 2008, 08:31
I found this little bug today while working with my 18F4685, trying to use the functions in code space above 64K...and it ONLY applies to PBP 2.50A (and above I'm sure whenever it comes out) and will most likely apply to most other little routines like this running on PICs with more than 64K (i.e. 18F4685, 18F8722, and so on), like the @printstr, @copystr, whatever, whether sending to a graphic LCD, serial port, whatever.



ASM ;printstr to color LCD macro, '@ printstr x,y, "string to lcd at x,y"
printstr macro clcdx, clcdy, clcdstr
local clcdthestring, clcdoverstr
bra clcdoverstr
clcdthestring
data clcdstr,0
clcdoverstr
MOVE?CB clcdx, _clcdpx
MOVE?CB clcdy, _clcdpy
MOVE?CW clcdthestring, _clcdaddr
L?CALL _clcdstringout
endm
ENDASM

The 3rd line from the end: MOVE?CW clcdthestring, _clcdaddr won't grab the upper bit of the PC and ends up reading the codespace at the lower 64K block instead of the upper 64K block.
The fix is simple enough.
Declare clcdaddr as LONG rather than WORD, and change MOVE?CW to MOVE?CN. All it does it changes moving a WORD to moving a LONG.
All better...

jchandir
- 22nd November 2008, 21:54
I just bought a Nokia Color knock-off lcd from sparkfun. I am using a pic 18f452 at 4Mhz and pic basic pro compiler and the LCD has a green board (Epson). So far I got it to initialize and all I am trying to do is clear the LCD since its all random pixels when the screen turns on. I have it running in 12bit mode, and I can select every pixel and make them white.

The problem is when I choose any other color like green or red or
anything other then $FFF. The screen begins the clearing process but it
gets stuck mid way threw at different locations every time.. Its like the LCD freezes. I have read the forums and did lots of searching and heard of someone else with the same problem but no one knew how to fix it. Also, when i change the OSC to 20 or 40 Mhz, the lcd never works. I hook up everything to an oscilloscope and I can see the data, but the LCD dosn't even blink.. Could there be something wrong with the controller? Or am I missing something. I was wondering if someone could shine some light on this problem. Thank you.

Archangel
- 22nd November 2008, 22:25
Try feeding data to it a little slower, maybe you are overrunning it's input buffer.

jchandir
- 22nd November 2008, 23:33
I am using a 4 mhz xtal, its painfully slow already.. I don't think speed is the problem. I am using shiftout command and sending a C/D bit and then the data. Any other suggestions? I have even tried Daves color lcd program, compiled it, and it works really weird. The colors are not right in 8 bit mode, and the text comes up as just small little lines where the letters should be. I just bough two of these lcds and both do the same thing. Is it possible that epson came out with a new controller. I am using the data sheet that sparkfun supplys and it works in 12 bit mode, besides the freezing but 8 bit sucks. I am also using a resistor divider circuit to step it down from 5v to 3.3.
.
http://www.sparkfun.com/datasheets/LCD/S1D15G10D08BE_TM_MF1493_03.pdf (datasheet)

diegoulman
- 28th September 2011, 02:43
HELLO, anyone is aware that nokia6101 lcd controller has it, 5200, this file is used for this lcd? I think it is compatible with the 6100, Best regards diego