I2CWRITE not writing anything on PIC18F45K80

[CuriousOne]

Ok, here are the answers.

ST7920 based display modules have great advantages over any common LCD controllers:

1. They are physically and pin to pin compatible with common 1602 LCD modules, HD44780 based.
2. In most applications they work as a drop in replacement for 1602 display (no need for code change), providing better visual appearance on screen, due to having far higher number of pixels - 144x32 vs 80x16 on common 1602 LCD
3. They have built-in 8192 characters for Chinese language, so whenever you need to use them, you don't need to mess with the graphics statements at all, just send an unicode code of char to display.
4. They have graphical mode, which also has hardware overlay and scroll function - text output (and CGRAM) in standard 1602 mode and graphics data are stored in separate areas of memory, which allows many fancy things to be done, like smooth parallax scrolling at different speeds, without need of software overlay calculation.
5. Due to high pixel density, in size of 1602 LCD, where you have 16 chars @ 2 rows, with 5x7 pixel fonts, here you can have 18 chars @ 4 rows, with 8x8 pixel fonts.

For the timing, datasheet shows nanosecond grade timings for writing the display. However, the above mentioned LCDOUT delays are practical observations - if I reduce them further, display gets garbled. So most likely, PBP is messing something up.

The datasheet mentions following way of graphic data sending, which I'm following in my code:

Graphic display RAM supports 64x256 bits bit-mapped memory space. GDRAM address is set by writing 2
consecutive bytes for vertical address and horizontal address. Two-bytes data write to GDRAM for one address.
Address counter will automatically increase by one for the next two-byte data. (This appears to be not working in the way you think it does) The procedure is as followings.
1. Set vertical address（ Y） for GDRAM
2. Set horizontal address（ X） for GDRAM
3. Write D15〜D8 to GDRAM 中(first byte)
4. Write D7〜D0 to GDRAM 中(second byte)


Yes I know there are other graphical displays there, including OLED and color TFTs, but no matter how hard I tried, I was never able to use any code provided here - 99% not compiling, giving some errors, and ones that compile, will never work. So I have to "develop" my own code for Graphic displays. So far these are for ST7920 and WS0010.

[HenrikOlsson]

So most likely, PBP is messing something up.

Of course it does...
Me thinks it's far more likely that the particular controller that's on your display doesn't live up to the specifications in the datasheet. Quite common on cheap HD44780 compatible displays as well so I would no be surprised if this is the case. It could also be electrical, crosstalk, capacitive loading of the outputs due to long wires between PIC and display, RMW issues etc. Have you looked at the signals (with a scope) as they enter the display?

Again, the datasheet specifies 72us for all commands except clear. You're using 900us and executing a LOT of commands so it takes a LOT of time.

[CuriousOne]

Well, default values of 1500/50 are in PBP manual and I guess they had reasons to write so.
I have tested different brands/makers of 1602 LCD, including genuine hitachi made modules. Some show slightly better results, some - worse.
Have not checked it with scope, by the way....

[HenrikOlsson]

The original Hitachi datasheet specifies 1.52ms for the HOME command and 37us for data and that's likely where the 1500/50 comes from.

[CuriousOne]

I don't remember exactly, but if not mistaken, the fastest display with HD44780 interface I tested with PBP was VFD module from Noritake - 1500 was reduced to 300 without any issues.

[CuriousOne]

Found another bug/issue.

Here's simple code:

topline	var byte [16]  'top part of the screen array
botline var byte [16] 'bottom part of screen


arraywrite topline,["0123456789ABCDEF"]
arraywrite botline,["0123456789ABCDEF"]






FOR X=0 TO 30 step 2	'READ ARRAY INTO VARIABLE, ARRAY MEMBER CHAR=EEPROM OFFSET	
if X<=15  then
Y=(botline[x]-48)*8
Z=(botline[x+1]-48)*8 'READ  INTO VARIABLE AS TWINS
endif




FOR I=0 TO 7	'HELPER LOOP FOR CHARACTER READING
LCDOUT $FE,$80+c+i 'UPDATE Y POSITION
LCDOUT $FE,$80+x/2 'UPDATE X POSITION
READ Y+I,A 'READ EEPROM BYTES INTO VAR
READ Z+I,B


if topline[x]=32 or botline[x]=32 then a=0
if topline[x+1]=32 or botline[x+1]=32 then b=0 'blanker


if atrib=1 and X<16 then
a=A^%11111111
b=b^%11111111
endif


if a=$FE then a=0
if b=$fe then b=0




LCDOUT a
LCDOUT b 'WRITE TO SCREEN
NEXT I
NEXT X

It should display 0123456789ABCDEF on LCD screen. It does, but there's an issue.

If reading text from 1st declared array (topline), then it is displayed correctly. However, if reading from 2nd declared array (botline), one of characters will be randomly missing in displayed text. This is not issue of my code, because if I do not declare "topline" array, then "botline" reading works fine.

So what this means, 18F45K80 can't handle two 16 byte arrays at same time?

[tumbleweed]

Your arrays are declared as 'var byte[16]'

topline var byte [16]
botline var byte [16]

That means a valid array index is from 0-15

This code here will fail when x=15

if X<=15  then
Y=(botline[x]-48)*8
Z=(botline[x+1]-48)*8 'READ  INTO VARIABLE AS TWINS

Z will try and access botline[x+1] = botline[16], which is invalid