Thank you for viewing my posting.
I am using a PIC16F690 with MPLAB X version 3.45 in assembly language. In my work recently with a LCD (EA DIPS082-HN) I noticed something I had not seen before and wanted to post it here to get some feedback.

What I noticed:
I use PORTC to send my data to the lcd in 4 bit mode and have rs, r/w and e on bits 4,5,6 respectfully. I am using (PORTA) a 5 position joystick tactile switch which allows me to control movement of the cursor and to increment and decrement a number value(0-9) at a ddram address accordingly. I have had no problem writing my assembly line code to do this at one ddram address. I then was able to expand my program to move the cursor between 2 addresses and increment/ decrement a number. I have all of the switch positions debounced in my program. BUT, when I move between the 2 addresses in ddram I am not able to put my saved value (cblock 0x40) that I saved, into the PORTC register, as I move the 0x40 contents into the W reg. and then into PORTC. I actually simulated it in MPLABX and it simulated perfectly but in the actual application it gives me garbage and shifts the lcd, cursor, etc.. Now if I replace that line in (putting the 0x40 contents into W then into PORTC) my code with a hex or binary value placed into the w register and then into PORTC I get correct results.
I need to store the value that will go into PORTC in a variable location (because it changes depending on user input) and need to then place it into the PORTC.
I do not think that this is a read-modify-write common problem but I have never seen my situation before. Has anyone seen this before, and is there a way for me to do what I want possibly another way? I also tried using the FSR/ INDR indirect addressing but had the same negative results.

Thank you for your future help.

P

 

What was the value in 0x40 when transferring it to PORTC didn't work?
If the value is greater than 0x0F then you are also changing the LCD control signals and you should AND the value with 0x0F before transferring to PORTC.

 

What was the value in 0x40 when transferring it to PORTC didn't work?
If the value is greater than 0x0F then you are also changing the LCD control signals and you should AND the value with 0x0F before transferring to PORTC.

AlbertHall, Thank you for your reply. Yes the value is greater than 15 dec(0x0f hex) for example, since I use bits 4,5, 6 as my control bits (rs,r/w, and e in that order) if I was to send the lsb in a value of 4, I would send 0x54, we are in 4 bit mode here, then I would be sending this: b'01010100 with bit 6 being 'e', bit 4 being 'rs' and bit 2 being the value of 4.
Thank you for your insight into my issue. I will apply your suggestion and follow up here w/ my findings.

P

 

You need to set the data (lower four bits) and set rs and r/w then after a short delay set e then a short delay then clear e.
See the waveforms below:

 

Looking at the data sheet on the PIC16F690 you will start C block at location 0x40 so C block + 0x40 will be location 0x80 which does not exist. On some other PICs I have used the has been general purpose register space in other memory banks but there is not on the PIC16f690.

Les.

 

Looking at the data sheet on the PIC16F690 you will start C block at location 0x40 so C block + 0x40 will be location 0x80 which does not exist. On some other PICs I have used the has been general purpose register space in other memory banks but there is not on the PIC16f690.

Les.

cblock starts memory assignment at the address following it. So cblock 0x40 will assign memory starting at 0x40. There is no problem there.

 

Cold you isolate the code that does not do what you want? Please tag it as "code".