I would agree but for the moment I have plenty of space left on my pics and its saving me many many hours in time. Im thinking of getting some 18F's as ic-prog supports them and they really dont cost much more but im not sure if it will work with my jdm programmer? (olimex pg2c) The equ statement was added below a #define statement near the top but Im sure I tryed it right at the top too becuase I was thinking the same thing, although it was 6am.. Ill try again.
Code: asm hex Found quite a few more errors, current ones: the loop in main_loop/RefreshLCD is bugged, so instead off copying a string from memory to the screen, it repeats one character across the screen. SetCGRAM function is bugged, causing 'P' (inverted so background is black) to be repeated across the screen instead of sending data to cgram. I think this 'p' character is in cg ram at power-on. However SetDDRAM function seems to work perfectly.
so.... heres a tiny bit of code that I think I dont understand.. Code: loop: bcf PORTA, LCD_RS ;instruction mode movlw b'00000010' ;move cursor home call send_w ;output character to lcd bsf PORTA, LCD_RS; ;data mode call delay_1ms ;.........repeat from 0x50 to 0x6f movlw 0x50 movf INDF, 0 call send_w ;......... goto loop assuming 0x50-0x6f each have different ascii character values... (as they do in the code.asm) why does this code repeat the same character?
If it's repeating that same inverted P character, it's usually a timing issue - either during initialisation or the timing constraints set out in the datasheet are not met. Any other character and it'd be more likely something else wrong.
I corrected the P (part of the cgram code), its now the first character I send out. Should I put a delay between sending characters? There is already a delay in the send_w function but might be too short. I couldnt find anything in the datasheet about it.
There should be a timing diagram in the datasheet which shows you the minimum time periods for everything. There is definitely a delay between sending characters in particular the hold time for the enable line and the set up time for the next set of inputs.
the code had 4 nop's (at 4mhz) as the duration for enable-line high. I added a 1ms delay and it made no difference. Did you look at the code above? I tryed again, original source from http://www.piclist.com/techref/io/lcd/pic.htm I made a few small changes: commented out LCD_RW as the pin is not used, lcd always in write mode. I then tested the code and it works fine, showing 'Hello!' on display. I commented out Code: ; movlw 'H' ; call send_w ; movlw 'e' ; call send_w ; movlw 'l' ; call send_w ; movlw 'l' ; call send_w ; movlw 'o' ; call send_w ; movlw '!' ; call send_w from main loop, and replaced calls to setram, and sendram Code: setram movlw 0x50 movwf FSR movlw 'H' movwf INDF incf FSR,1 movlw 'e' movwf INDF movlw 'l' incf FSR,1 movwf INDF movlw 'l' incf FSR,1 movwf INDF movlw 'o' incf FSR,1 movwf INDF movlw '!' incf FSR,1 movwf INDF return sendram movlw 0x50 movf INDF, 0 call send_w movlw 0x51 movf INDF, 0 call send_w movlw 0x52 movf INDF, 0 call send_w movlw 0x53 movf INDF, 0 call send_w movlw 0x54 movf INDF, 0 call send_w movlw 0x55 movf INDF, 0 call send_w return This results in the lcd showing 7x '!' characters on the first line, with the rest of the screen blank.
In the senddram call you have not incremented FSR so it still points at the same location it was left at in the setram call - when it pointed to the ! character. As you have not incremented FSR it always points to 0x55 and thus the character at that location (!) is repeatedly recovered and sent the the LCD. Try: senddram movlw 0x50 movwf FSR movf INDF, 0 call send_w incf FSR, 1 movf INDF, 0 call send_w incf FSR, 1 movf INDF, 0 call send_w incf FSR, 1 movf INDF, 0 call send_w incf FSR, 1 movf INDF, 0 call send_w incf FSR, 1 movf INDF, 0 call send_w return I think that that should resolve your problem.
