I2CWRITE not writing anything on PIC18F45K80

Hello.
I have PCF8574 connected to PIC18F45K80.
The timings and configs are correct, tried to generate some pulses and frequencies are correct.
Tried just to pull up and down SDA/SCL pins and check result with scope, while having PCF8574 connected - I can see proper pulses on the scope.
However, when I try to I2CWRITE, I see no activity at all on either SDA or SCL pins, and sure does not work. Adding I2C SLOW does not change anything.

Here's my code:

Code:

---

#config
CONFIG RETEN = OFF       
CONFIG INTOSCSEL = HIGH
CONFIG SOSCSEL = DIG
CONFIG XINST = ON            ;Enabled
CONFIG FOSC = INTIO1
CONFIG PLLCFG = OFF
CONFIG FCMEN = OFF            ;Disabled
CONFIG PWRTEN = OFF            ;Disabled
CONFIG BOREN = OFF            ;Disabled in hardware, SBOREN disabled
CONFIG WDTEN = OFF            ;WDT disabled in hardware; SWDTEN bit disabled
CONFIG CANMX = PORTB
CONFIG MCLRE = OFF


#endconfig


'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 16
DEFINE I2C_SLOW 1
ADR VAR BYTE
ADR=$48


SDA VAR PORTD.3
SCL VAR PORTD.2


'dfe:
'high sda
'pause 1
'low sda
'pause 1
'goto dfe


FEDO:
I2CWRITE SDA,SCL,ADR,[%11111111]
PAUSE 50
I2CWRITE SDA,SCL,ADR,[%00000000]
PAUSE 50
GOTO FEDO

---

I think you are missing the control before the address of the I2C commands.

Also DEFINE I2C_SLOW 1 is NOT needed.

try this

Cont = %01000000

I2CWRITE SDA,SCL,Cont,[%11111111]
PAUSE 500
I2CWRITE SDA,SCL,Cont,[%00000000]
pause 500


Ioannis

And where to put address?
I have several PCFs....

OK, in the cont constant will be the address. What chip do you have? Is it the "A" type?

The "A" type needs cont=%0111AAA0

The plain PCF8574 needs cont=%01000AAA0

where AAA is the address bits.

Ioannis

provided it is wired correctly and the chip is pcf8574 the original code works just fine
although technically
TRISD=%00000000 'set PORTD as output all
should be
TRISD=%00001100 'set PORTD

Attachment 9339

The chips are PCF8574T.
I have pull up resistors 4.7K and SDA and SCL pins of 3 pcs. PCF chips are in parallel.
I tried adding that cont variable and changing TRIS for D port pins. Still nothing.
On the startup, SCL gets high and that's all, there is no activity on these pins.
But if I run simple high/low statements for those pins, then I can see these pins getting high or low on scope.

By the way, I have DS3231 hooked to another pins of same CPU.
It also not working - no activity on SDA/SCL pins while performing I2CREAD.
So maybe some config error?

Quote:

---

So maybe some config error?

---

if you mean its wiring error or the chips aren't what you say , probably

schematic ?

No, there is no wiring error and when using HIGH or LOW statements, I can pull these pins up and down as normal.
I mean, maybe there is some config error for 18F, which prevents I2CREAD/I2CWRITE from working?

to be clear

provided it is wired correctly and the chip is pcf8574 the original code works just fine

Change CONFIG XINST setting to OFF.

Very few compilers are compatible with ON

Yes, you were right!
Also XINST messes with LCDOUT.
When XINST=ON, then DEC/HEX/BIN etc. modifiers of LCDOUT statement do not work.

But why this is not mentioned in manual?
Also, turning off XINST means we're turning off these extended instructions of 18F, so loosing all advantages these series have?

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.

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:

Code:

---

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)

Code:

---

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

---

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.

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.

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

Ioannis

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:

Code:

---

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

---

and

Code:

---

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.

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.

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.

https://www.youtube.com/watch?v=aACOC9XBBks
Link to video.

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:

Code:

---

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?

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

Code:

---

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.

Quote:

---

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

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.

Quote:

---

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.

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

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.

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.

Found another bug/issue.

Here's simple code:

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?

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

Code:

---

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

Code:

---

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

X is being incremented in steps of 2, so it will never be 15.
I even modified code so that X will never exceed 14 - issue is still here, but there is some logic in it.

I tried to add code in loop and look at output.
it changes in the following way based on loop step:

012345 789ABCDEF
0123456789 BCDEF
012345678 ABCDEF
01234567 9ABCDE

Did a test with various size of arrays.
If both arrays do not exceed 24 bytes total, then everything is fine. As they exceed 24 bytes, issues start to appear.

Fair enough, but what about this when x >= 16

Code:

---

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

---

I don't see any relation :)
I modified code and X now changes from 0 to 14 - still same issue.

You've been using x, y, and z to get values to set a and b.
You've been shoving invalid data out to the lcd and wondering why the display is wrong.

It's probably still wrong.

LOL.
I'm trying to explain that if I add one extra array definition, another array gets screwed. How this is related to LCD?
I just wrote another code, which simply reads values of array and writes data on 1602LCD.
Issue still exists - data in array gets damaged, if total array length exceeds 24 bytes.

I just did this with an 18F45K80

Code:

---

' device = 18F45K80

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

ix var byte
ct var byte
cb var byte

' clear arrays
for ix = 0 to 15
    topline[ix] = 0
    botline[ix] = 0
next ix

' read array data
arraywrite topline,["0123456789ABCDEF"]
arraywrite botline,["0123456789ABCDEF"]

ix = 0

'read array char by char
for ix = 0 to 15
    ct = topline[ix]
    cb = botline[ix]
next ix

ix = 0

---

When it gets to the end, topline and botline arrays are exactly as specified... each is 16 chars "0"-"F"
Reading the arrays byte by byte also does as expected.
I even added a third array of 16 chars... works too.

Your problem is elsewhere... not with the arrays themselves.

Thanks, have you tried to read the same array several times?
Problem is definitely in arrays, because if I make say topline 4 bytes and botline 16 bytes (even without writing anything to any of them) - there are no problems, but as soon their total "length" exceeds 24 bytes, issues start to appear.

Quote:

---

Originally Posted by tumbleweed

Your problem is elsewhere... not with the arrays themselves.

---

code snippets , a complete waste of time and effort