I2CWRITE not writing anything on PIC18F45K80

[CuriousOne]

But people are making fast update to these screens via U8G and other libraries. Check this video from 7th minute.
I want similar speed, but with PBP.

[CuriousOne]

Link to video.

[HenrikOlsson]

As long as you send the display DATA it will be sort of fast (35us per data byte according to your own information). But each time you send a command it will take 900us - and you do that two times per pass thru the inner loop.

Your FOR/NEXT loop:

GCODER:
FOR X=0 TO 17 step 2	'READ ARRAY INTO VARIABLE, ARRAY MEMBER CHAR=EEPROM OFFSET	
  Y=(topline[x]-65)*8
  Z=(topline[x+1]-65)*8 'READ  INTO VARIABLE AS TWINS

  FOR I=0 TO 7	'HELPER LOOP FOR CHARACTER READING
    READ Y+I,A 'READ EEPROM BYTES INTO VAR
    READ Z+I,B
    LCDOUT $FE,$80+i+c 'UPDATE Y POSITION    ' 900us + some
    LCDOUT $FE,$80+x/2 'UPDATE X POSITION    ' 900us + some
    if topline[x]=32 then a=0
    if topline[x+1]=32 then b=0 'blanker
    LCDOUT a                                                  ' 35us + some
    LCDOUT b 'WRITE TO SCREEN                      35us + some
  NEXT I

NEXT X
return

Each time thru the inner loop takes 1870us + whatever time the READ and the IF and all the other statementes takes, let's call it 2000us in total. Your doint the inner loop 8 times for each pass thru the outer loop which in turn you do 9(?) times for a total of 72 times. 72*2000us is 144ms and this does not include any time spent outside of these two nested loop. Measure it yourself and see how much time it takes.

I don't know the ST7920 at all and I'm surprised it, being a graphical display controller, are "compatible" with HD44780 but are you sure you need to perform the "update position" commands each iteration thru the loop? Doesn't the controller increment position automatically, like the HD44780?

[HenrikOlsson]

Looking at this datasheet it looks like all commands except clear executes in 72us which is like 1/12 of the 900us you're telling the compiler it takes. Obviously you'd need to add additional delays to any CLEAR SCREEN command, like

LCDOUT $FE, 1
PAUSEUS 1500   ' Extra delay for this specific command which takes 1600us instead of 72us like all other commands.

If the two "command statements" in the inner loop took 72us each instead of 900us each the the whole thing would take 5.2ms instead of 144ms.

[richard]

Your doint the inner loop 8 times for each pass thru the outer loop which in turn you do 9(?) times for a total of 72 times. 72*2000us is 144ms and this does not include any time spent outside of these two nested loop. Measure it yourself and see how much time it takes.

as i pointed out a year ago
https://www.picbasic.co.uk/forum/sho...923#post148923
post #7

there are much better ways indicated in that post too

[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....