I2CWRITE not writing anything on PIC18F45K80

[CuriousOne]

I've compared this code on 16F1939 @ 16 Mhz and 18F45K80 @ 64 Mhz and see zero improvement in speed (screen redraw time). I'm doing something wrong, or it should be that way? Here's config for 18F:

OSCTUNE.6 = 1 ; Enable 4x PLL
OSCCON = %01110000
ANCON1=0 'DISABLE ADC D3-D2-D1-D0-
ANCON0=0
ADCON0=0
TRISC=%00000000 'set PORTC as output all
TRISD=%00000000 'set PORTD as output all
TRISB=%00000000 'set PORTB as output all
TRISA=%00000000 'set PORTA 2 as input, others as output
TRISE=%0000000  'set PORTE as output all
define OSC 64

And this is the main code (ST7920 library with custom fonts)

topline	var byte [18]
arraywrite topline, ["SOMETEXT HERE  123"]
C=0
gosub GCODER
arraywrite topline, ["SOMETEXT HERE  567"]
c=8
gosub gcoder
arraywrite topline, ["SOMETEXT HERE  890"]
c=16
gosub gcoder
C=24
arraywrite topline, ["SOMETEXT HERE  XXX"]
GOSUB GCODER
stop




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
LCDOUT $FE,$80+x/2 'UPDATE X POSITION
if topline[x]=32 then a=0
if topline[x+1]=32 then b=0 'blanker
LCDOUT a
LCDOUT b 'WRITE TO SCREEN
NEXT I
NEXT X
return

[tumbleweed]

It could be that the LCDOUT dominates the execution time, although I'd be surprised if it's "0 difference"

Do you still have CONFIG FOSC = INTIO1?
With that, you can measure the CLKOUT on the RA6/OSC2 pin just to verify the settings.

[CuriousOne]

I make a pin high when this code starts and make it low when it ends. Length of the pulse is measured with scope.
By setting
DEFINE LCD_COMMANDUS 900
DEFINE LCD_DATAUS 35

instead of default 1500/50, additional speed gains can be achieved, but it works same way on both MCU.

I will check the CLKOUT later. I have not measured it, but I did some PAUSE loops and times were correct, so I assume, chip is running at 64mhz.

[Ioannis]

LCD's are very slow. What are you expecting in terms of speed?

Ioannis

[HenrikOlsson]

Of course it's the same.
You tell the compiler: "Look, the LCD controller I have connected needs 35us to process data and 900us to process commands, please give me code for that". The compiler will give you code for that, making sure that it gives the LCD controller 35us to process data and 900us to process commands.

Running at 4MHz* or 64MHz makes no difference, each datatransfer WILL take 35us and each command WILL take 900us because that IS what you, the programer, have told the compiler that you WANT it to take.

I can assure you that if run:

LATB.0 = 1
arraywrite topline, ["SOMETEXT HERE  XXX"]
LATB.0 = 0

and

LATB.0 = 1
LCDOUT $FE,$80+i+c 'UPDATE Y POSITION
LATB.0 = 0

at both 16MHz and 64MHz you'll be able to measure a considerable increase in speed on the first but very tiny on the second (because, as explained, most time spent executing that statement is spent doing nothing).

* At 4MHz it MIGHT not be able to stick to 35us, it MIGHT take slightly longer, I don't know for sure.

[CuriousOne]

Average blue/white LCD can do 10 fps. Yellow-black can do 20 fps. Special, color persistence LCD (with RGB backlight), can do 200 fps.

Currently I'm getting 1 fps on 128x64 display and about 2 fps on 144x32 display. This is very slow, when updating screen or navigating thru on screen menu.

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