Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

GLCD migration from PIC16F to PIC18F

Status
Not open for further replies.

chrischris

Member
Hi, I have managed to get the GLCD working with PIC 16F877A and now trying to migrate the code on 18F45k80, but the LCD just lights up, I can adjust the contrast but nothing else happens. All I have changed is data port to PORTB from PORTD on 16F and Control Port from PORTB on 16F to PORTD on 18F. The library I am using is from https://en.radzio.dxp.pl/ks0108/

Everything works smoothly on PIC16F but 18F is just blank screen. Compiler is XC8 using MPLABx.

PIC16 circuit is on vero board but the PIC18 circuit is on a PCB, so the crude circuit works but not the PCB one !!. I have attached the schematic and also the C file for LCD driver. I am using the same file for both PICs except for the changes described above and the config. The config in the attached file is for PIC18F.

I also tried initializing the PORTS at the beginning of the main() function as

TRISD = 0x00;
TRISB = 0x00;
PORTD = 0X00;
LATD = 0x00;
PORTB = 0x00;
LATB = 0x00;

PSPCONbits.PSPMODE = 0;
INTCON2bits.RBPU =1;
PADCFG1bits.RDPU =0;
INTCONbits.RBIE =0 ;
ADCON0 = 0;
ADCON1 = 0;


I think it has to be something simple as not setting the PORTS correctly but I can't figure it out. Can anybody please help me on this ?

P.S. I tried setting all the PORTs HIGH to see if they function as I/O and it all seems to be ok.


Thanks,
Chris
 

Attachments

  • Schematic.png
    Schematic.png
    54.2 KB · Views: 420
  • KS0108-PIC16.c
    6.6 KB · Views: 431
Just an update, I tried changing to "read from PORT and write to LTACH" in the driver
#define KS0108_DATA_PORT LATB
#define KS0108_DATA_DIR TRISB
#define KS0108_DATA_PIN PORTB

#define KS0108_CTRL_PORT LATD
#define KS0108_CTRL_DIR TRISD

#define KS0108_RS (1 << 3)
#define KS0108_RW (1 << 5)
#define KS0108_EN (1 << 2)

#define KS0108_CS1 (1 << 1)
#define KS0108_CS2 (1 << 0)
#define KS0108_CS3 (1 << 1)
#define KS0108_RST (1 << 4)

and adding these at the start of main

PSPCONbits.PSPMODE = 0;
INTCON2bits.RBPU =1;
PADCFG1bits.RDPU =0;
INTCONbits.RBIE =0 ;
ADCON0 = 0;
ADCON1 = 0;
CCP1CONbits.CCP1M = 0x00;
CCP5CONbits.CCP5M = 0x00;


but no luck , can anyone please suggest something else ?

I also tried changing the PIN definitions as suggested by Ian Rogers but no change .

Thanks,
Chris
 
I did some basic troubleshooting, made a simple code to check the PORT values and it is completely unexpected, I am not setting the PORT functions/configs correctly. Please see the attached image. I was giving +5V to each pins of PORTB and PORTD but as it shows in the image, they remained 0x00. Also when I set the PORTS to output and make LATB and LATD 0xFF, the PORT values are 0x2C and something else not 0XFF.

I think I need to get by basics right, can anyone tell me how to correctly set PORT directions and functions for GPIO with PIC18F45K80 ?
 

Attachments

  • debug.png
    debug.png
    40.6 KB · Views: 398
I don't use C but did you clear the ANSEL registers?
The initial default setting is all ports analogue.
Also see Initializing ports in the manual.
Max.
 
Last edited:
Hola Chrischris,

I am not conversant in C.

I am using the same file for both PICs except for the changes described above and the config. Chris

Most probably, at this stage, a good way of having a non working project. Keep it aside until you learn the differences. You could realize easily just by comparing the respective instruction sets. Could you?

Even if it looks excesive (which is not), those families made for different micros. The worst mistake you could do is to expect they are (almost) the same.

Maybe your difficulty lies in the correct configuration of the new micro. What I say could not help but, if you start with the minimum, that is, all peripherals disabled, you should be setting very few functions, pins, etc through the configuration.

Even if it means extra work, be patient, RTFM and try to just blink a LED. For the first test, try to use a port, if available, where the pins are not commited with other functions (not common anymore with current micros but worth to tray).

Points I would go straight to check:

a) Oscillator settings. Recent 18F are much much more complex than before. Did not check yours but I suspect it has way too many options.

b) As posted by Max above, that desired pins are set as digital. The most common trap in PIC micros, ever.

c) Use of the TRIS registers. (No idea how C deals with them).

And, please, before that GLCD, blink a LED; that is, blink a LED. Fight small battles and win the war.
 
And, please, before that GLCD, blink a LED; that is, blink a LED. Fight small battles and win the war.
Yes that's what I am trying now, and this PIC seems very difficult to configure. Outputs seem to be ok, but Input (TRIS = 0xFF) seems to be not working at all. It's always helpful when someone reminds you basics so thanks Agustín Tomás and MaxHeadRoom78.
This is my entire code now

#pragma config FOSC = HS1 // Oscillator Selection bits (HS oscillator)
#pragma config WDTEN = OFF // Watchdog Timer Enable bit (WDT enabled)
#pragma config PWRTEN = OFF // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOREN = ON // Brown-out Reset Enable bit (BOR enabled)

#pragma config CPD = OFF // Data EEPROM Memory Code Protection bit (Data EEPROM code protection off)
#pragma config WRTC = OFF // Flash Program Memory Write Enable bits (Write protection off; all program memory may be written to by EECON control)
#pragma config CP0 = OFF // Flash Program Memory Code Protection bit (Code protection off)
#pragma config CP1 = OFF // Flash Program Memory Code Protection bit (Code protection off)
#pragma config CP2 = OFF // Flash Program Memory Code Protection bit (Code protection off)
#pragma config CP3 = OFF // Flash Program Memory Code Protection bit (Code protection off)
#pragma config XINST = OFF

#pragma config CANMX = PORTC // ECAN Mux bit (ECAN TX and RX pins are located on RC6 and RC7, respectively)

void main()
{
PSPCONbits.PSPMODE = 0;
INTCON2bits.RBPU =1;
PADCFG1bits.RDPU =0;
INTCONbits.RBIE =0 ;
ADCON0 = 0;
ADCON1 = 0;
ANCON0 = 0;
ANCON1 = 0;
PORTB=0;
LATB=0;


TRISB = 0xFF;
int i;


while(1)
{
i = i+1;
}
}


and I can't see PORTB changing when giving +5V to it ???

P.S. For some reason I can use "insert code" function on this forum, so excuse me, I 'll try different browser next time.

Thanks,
Chris
 
Hi, I managed to get the PORTs working , both for Input and Output
this is the setup for PORTS

PSPCONbits.PSPMODE = 0;
INTCON2bits.RBPU =1;
PADCFG1bits.RDPU =0;
INTCONbits.RBIE =0 ;
CCP2CON=0x00;
CCP1CON=0x00;

ADCON0 = 0x00; //
ADCON1 = 0x00; // turn off all analog channels.
ANCON0 = 0x00; // turn off analog channels
ANCON1 = 0x00;
ECCP1ASbits.ECCP1AS = 0x00;
INTCONbits.PEIE_GIEL = 0X00;
INTCONbits.GIE_GIEH = 0x00;
INTCONbits.INT0IE = 0x00;

But still no luck with GLCD, I increased the delay GLCD_delay to 500uS but nothing has changed. :( . I have attached the updated driver. Any advise will be appreciated.


EDIT:
Please refer to attached ZIP file it has a complete "helloworld" of my LCD code. In th file pic_select.h I select which PIC to use, the code works with 16F but not with 18F ??

Thanks,
Chris
 

Attachments

  • KS0108-PIC16.c
    6.6 KB · Views: 368
  • GLCD_Test.X.zip
    809.8 KB · Views: 354
Last edited:
You could check the code for the Picdem2 ver2 board on the pic site as they include the S/W for both 16f & 18f using a 2 line LCD , albeit an older version of the 18f but the code is supplied in C as well as assembly.
Max.
 
Hola Chrischris,

Now that the proverbial LED is blinking (congratulations - you are in the race track now), I would stop and verify what are ALL the micro's pins going to the GLCD.

Precisely when having problems with a 2x16 LCD (using a 16F micro and when implementing my first with a 18F one) I learnt to check things this way:

I could be flamed by this: I use a logic probe for those that send few or just one single pulse for a command.
For those involved with data I use the scope. Have you got one?

If no scope, then, with patience (it pays in the short term, trust me) do the blinking thing for every single pin and see which one is not responsive.

The idea is to find if any of the required pins, for a reason yet to discover, is set committed to some unexpected function. Recent 18F micros have options in the configuration that you cannot neglect. Once you find a suspicious one, go straight to the datasheet to see what it is involved with.

Finally (or upfront) make sure the data (or control) pins are not reversed or in the wrong nibble. Been there for both counts

/EDIT

Text in bold added

EDIT/
 
Last edited:
Just for your reference, I am showing the settings of a 18F4585 used to control a 128x64 GLCD. (The Conway's LIFE game worked like a charm and was fun to program).

Since it is in Assembler the idea is you to see which ones I had involved. Buena suerte.

Abstract for CHRCHR.png
 
I can't run your example... However!!! If you are getting a blank screen, the problem is almost definately the call to
GLCD_writestring(); You have passed a rom pointer and it expects a ram pointer.. Try this to cast the "HELLO" to a ram pointer..

GLCD_WriteString((char*)"HELLO", SMALL_FONT, 0, 0);
 
You could check the code for the Picdem2 ver2 board on the pic site as they include the S/W for both 16f & 18f using a 2 line LCD

That looks like a character LCD, I am using a Graphic LCD.

I would stop and verify what are ALL the micro's pins going to the GLCD.

I did that , I checked each pin for Input and Output. I will double check it again once I get back to it from work.

This is what I have done in the driver file, I don't think GLCD_CTRL_PORT in above code is of any use, isn't control port always an output ?

GLCD_WriteString((char*)"HELLO", SMALL_FONT, 0, 0);


Will try it once I get home, though I wonder if this was an issue why does it work with PIC16F ?

Thanks all
 
I can't run your example.

Hi Ian, I manually packaged the project not through MPLABx, Please find the attached zip file you should be able to run this. I tried casting "HELLO" with (char*) but no difference.

I would stop and verify what are ALL the micro's pins going to the GLCD.

I did this again, with LED and in the Watch window of debugger, all seems to be fine.

I am running out of things to look into now :( . having Four hour sleep since last one week !!!:banghead::arghh:.
If nothing else is left then I would change the LCD, I'll have to desolder the one from PIC16F877A, the one which works fine.

Thanks,
Chris
 

Attachments

  • GLCD_Test.zip
    14.1 KB · Views: 354
This is what I have done in the driver file, I don't think GLCD_CTRL_PORT in above code is of any use, isn't control port always an output ?

Thanks all

Through that port precisely, is where you control the GLCD, using the so many specific pins. Nothing better than giving it the right name.
 
Through that port precisely, is where you control the GLCD, using the so many specific pins. Nothing better than giving it the right name.
I meant GLCD_CTRL_PORT can be used only when that "PORT" is input and Control PORT is always output for GLCD, so we would rahter use GLCD_CTRLl_LAT and not GLCD_CTRL_PORT.
 
I meant GLCD_CTRL_PORTcan be used only when that "PORT" is input and Control PORT is always output for GLCD, so we would rahter use GLCD_CTRLl_LAT and not GLCD_CTRL_PORT.

Yes, if one day you read RAM (inside the GLCD module) you will use the data PORT.

The name GLCD_CTRL_PORT is not precisely wrong but rather useless. You could delete that line with no mercy.
 
Last edited:
We have had a generic ks0108 glcd working with a 18F4520 using assembler code ; just wonder if your 18F45K80 is the root of the problems ?

Though your C complier should take care of things, seems those chips have a lot of registers outside the Access area and have so many other functions /options wonder if its something like that thats causing your problems ; perhaps trying a simpler 18F chip like the 4520 might prove the point ?
 
So I tried Proteus simulation and it seems to be working fine with it. I have attached the file here.

So what could be the problem ? The schematic is exactly the same the only difference is the RST is pulled HIGH in Simulation, but I have tried that with the circuit and it doesn't make any difference.

perhaps trying a simpler 18F chip like the 4520 might prove the point ?
Unfortunately I already have the PCB done, so can't change the PIC
 

Attachments

  • 18F_GLCD.zip
    17.8 KB · Views: 348
  • GLCD_Test.X.production18.hex
    8.6 KB · Views: 331
So Finally it is solved :D , I was trying to put RESET pin to HIGH through a pull up, and the RESET was also connected to a GPIO (which I was pulling HIGH in firmware, but for some reason it wasn't going HIGH before init routine of LCD), so out of frustration I decided to pull RESET HIGH without pull up and, it did the trick. I knew it must be something stupid. !!!!. After 8 years of experience with electronics/software, it still continues to give me curve balls. !!
Thanks everybody for trying to help !!
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top