I2CWRITE not writing anything on PIC18F45K80

[tumbleweed]

XINST changes the way some instructions work, so unless you have a compiler that supports it (like almost none), always set it off.

You're not missing out on anything.

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