Second I2C address not responding

[Art]

Except that I fell for your mistake, and that's not how I2CWRITE works:

I2CWRITE DataPin,ClockPin,Control,{Address,}[valvue{,Value...}]{,Label}

ie.

I2CWRITE PORTC.4,PORTC.3,$ao,0,[STR a\8]

I think you set the command to look for another I2C device on the bus rather than incremented the address index for the same device.

[Art]

PAUSE 10 for the first write to complete because you used two I2CWRITE commands.
(page 86).

[Amoque]

It may be that I have not been clear or perhaps I do not understand your comment. There are two devices, one address $70, one $7C (ones digit and tens digit) on the same bus. I have several of the modules and have tried several different addresses... always the first executes (and displays) perfectly; the other never. Do you suggest that there is some parameter missing from the I2CWRITE statement?

I tried adding ,[$00] in the case another tick was required to complete the "ACK", but no... error. In fact, everything I tried there failed. I thought I understood the syntax, but now I doubt.

[Amoque]

I added a PAUSE 250 between... and no. Still no joy.

[Art]

I didn't understand you were talking to two different devices.
I thought it was supposed to be writing the least significant digit to the right of the display,
and then the tens digit in the position to the left, on the same display.

The I2CWRITE still looks incomplete:

I2CWRITE SDA,SDL,I2CDEVICESELECT,ADDRESSONDEVICE,DATA

[aratti]

You should post the data sheet for your single character LCDs. Very likely you need to set the new address on each LCD (one at the time) before using them on a I2C bus.

Cheers

Al.

[Amoque]

Al, thanks for the reply. The LCDs are dumb; I'm using a PCF8574 port expander to control the segments. I did look again at that datasheet and all seems well in that the I2C seems to be a very standard implimentation.

At this pint I'm exploring Art's assertion that its in the I2CWrite syntax - I think he's right; I just don't understand the "control byte" thing well enough to fix it. Lining up the commas...

I2CWRITE SDA, SCL, $70, ,OUTP <- my code
I2CWRITE SDA, SDL, I2CDEVICESELECT, ADDRESSONDEVICE, DATA <- Art's

Shows I've missed something. Art calls it the ADDRESSONDEVICE, but since I have no clue what the control byte would be on the chip I'm using (I read and understand the examples given for memory chips), I'm pretty sure thats where the problem lies.

Off, armed with a hint, in search of an answer.

[Archangel]

If you are using NXP data sheet it's hard to understand address, the T I data sheet is more clear the link below to that data sheet
See page 6
http://www.google.com/url?q=http://w...0Ee8TD_UJQnvOw

[Amoque]

I was so impatient to try the suggestions made that I took the rest of the day off.

Below is the modified code. I added another digit in hopes that the change might reveal the problem...

#CONFIG
   __config _CONFIG1, _INTRC_IO & _WDT_OFF & _PWRTE_OFF & _MCLR_ON & _BODEN_OFF & _LVP_OFF & _CPD_OFF & _WRT_PROTECT_OFF & _DEBUG_OFF 
   __config _CONFIG2, _FCMEN_OFF & _IESO_OFF  
#ENDCONFIG

OSCCON = %01110000      'SET OSC OPTIONS
DEFINE OSC 8 
ANSEL = %00000011       'SET ANALOG TO DIGITAL
TRISA = %00000000       'SET PORTS OUTPUT
TRISB = %00000000

SDA VAR PORTB.1
SCL VAR PORTB.4
OUTP VAR BYTE
LP VAR BYTE
CHP100 VAR BYTE
CHP010 VAR BYTE
CHP001 VAR BYTE
CHP100 = $74
CHP010 = $72
CHP001 = $78
mainloop:
  FOR LP = 0 TO 9
    READ LP, OUTP
    I2CWRITE SDA, SCL, CHP001, CHP001, OUTP	'WRITE 1's
    PAUSE 250
    I2CWRITE SDA, SCL, CHP010, CHP010, OUTP	'WRITE 10's 
    PAUSE 250
    I2CWRITE SDA, SCL, CHP100, CHP100, OUTP	'WRITE 100's 
    PAUSE 250
  NEXT LP	
Goto mainloop                           'LOGICAL END

DATA 63, 6, 91, 79, 102, 109, 124, 7, 127, 103  
End

I think there is some progress in that now, at least, each digit will work independently. Applying power with all three modules plugged in, one (random) will work. Pulling the functioning digit, one of the others begins to cycle. Regardless of which digit I remove, one will always work; the others do not. It doesn't matter which spot they occupy - as long as they have a valid address.

In addition, I tried changing the value of the I2C resistors: 3K3, 4K7, 10K0 - no change in function. The circuit is run from adequate supply and is well filtered...

I still don't understand the "control" byte well, but RTFM indicates the class should match the fixed part of the address (MSBs) and the LSB should be zero; the addresses satisfy those requirements and beyond that I don't understand well enough to make an intelligent correction.

[Amoque]

Sorry... double post

[aratti]

Do you have pullup resistors on each module? If so you should remove them otherwise you parallel them, and if the pullup value on the I2C bus become too low hardy it will work. A recommended value for bus pullup is 4.7K to 10K.

Cheers

Al.

[Amoque]

Currently have 4K7s only. Doubled checked to be sure.

[LinkMTech]

Okay, try inserting brackets around your OUTP variable this way:

mainloop:
  FOR LP = 0 TO 9
    READ LP, OUTP
    I2CWRITE SDA, SCL, CHP001, [OUTP]	'WRITE 1's
    PAUSE 250
    I2CWRITE SDA, SCL, CHP010, [OUTP]	'WRITE 10's 
    PAUSE 250
    I2CWRITE SDA, SCL, CHP100, [OUTP]	'WRITE 100's 
    PAUSE 250
  NEXT LP	
Goto mainloop                           'LOGICAL END

I just tried removing the brackets on a short test program I've been playing with and it didn't work right anymore until I put them back.

[Amoque]

Wow... How dumb do I feel? It works perfectly now! I've been sitting here scratching a bald spot behind my right ear as I review every comma, wire, and word on the manual page - all the while looking right past the missing brackets.

Thanks, Louie. I guess I just don't know how to say it more plainly than that. I really appreciate the help.

I just did a little more extensive testing... moved the digits around and fiddled with the timing some... it is rock solid now, every digit works in every position - fast - without skipping or cogging. Very nice! Thank you ALL again for your attention, time, and effort.

[Art]

Congrats

I'm confused how the 1st I2C address is even responding.

I'm also still stuck on this, and thought I still must be misunderstanding something.
It shouldn't have worked at all as far as I can tell.

Pictures of display device?