PCF85176 and PCF8576 compatibility

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PCF85176 and PCF8576 compatibility

1,742 Views
MircoCpt
Contributor I

Good morning,

I've made a display which uses PCF85176 instead of PCF8576. From the datasheet I didn't find any difference in the communication protocol, but when I use them alongside I see that the character bytes are "mirrored" on the display that uses the new driver. Also, the character is in a different place than expected.

E.g. writing 0 in the first row on the right results in writing gibberish (abcdefgDP instead of DPgfedcba) in the wrong position.

On the datasheet, ram access seems the same, so I'm starting to think that I have to redo the pcb.

Are the ICs compatible or there is any difference that I didn't catch reading the datasheet?

0 Kudos
Reply
9 Replies

1,708 Views
MircoCpt
Contributor I

Last update:

The chip is working as if the pins were numbered in inverse fashion (S39 instead of S0, S38 instead of S1 and so on).

Loading the ram from address 0 in static mode, according to the images, should put MSB to LSB the byte in the RAM (MSB address 0, LSB address 7) and so on with an automatic increment of 8. This happens in the old PCF8576.

On the PCF85176, with the same command and data sent, what happens is that it's like we put the mirrored byte starting from the end of the row (MSB address 39, LSB address 32) with an automatic decrement of 8. Situation that could be caused by the wrong segment numbering on the datasheet.

If S0 (pin 4) would be S39, S1 -> S38, S2 -> S37 and so on, it would all make sense.

0 Kudos
Reply

1,474 Views
MircoCpt
Contributor I

Hello!

@ErikaC , do you have any insights on this hypothesis?

In the meantime, we're redesigning the display pcb with the pin numbers inverted and give it a try.

Thank you.

0 Kudos
Reply

1,427 Views
ErikaC
NXP TechSupport
NXP TechSupport

Hello,

Sorry for the delay in replying I was checking this with the applications team.

Could you help me with the following information?

  • Are you using the same display in both scenarios? I assume yes.
  • If you replace the PCF8576 with a PCF85176 (in the same board) do you see the same behavior?
  • Can you share your LCD datasheet? To understand how the connections are made internally.
  • Could you provide your schematic?
  • Is this only 1 PCF85176 device? Or all of them show the same behavior?
  • Can you share logic analyzer capture of the data being transmitted to the LCD controller?

Thanks!

1,417 Views
MircoCpt
Contributor I

Hi, thank you for your update! I'll answer some of the question now and some other as soon as i have data.

  • Are you using the same display in both scenarios? I assume yes. Yes, we're using the same LCD display
  • If you replace the PCF8576 with a PCF85176 (in the same board) do you see the same behavior? I think we cannot do this test for two reasons: the different pinout of the two ICs would make the driver not work at all (I2C pins, power pins etc), and also the package is different (We have TSSOP56 PCF85176 and VSO56 PCF8576)
  • Can you share your LCD datasheet? To understand how the connections are made internally. I'll look for it and send it. From what I remember there is nothing special about it. They are assembled in the correct orientation and, if mounted on an old PCB with the old drivers, they work as expected. They work as expected also in the new PCB provided that i mirror the bytes, as described.
  • Could you provide your schematic? I'll ask if this is possible! Maybe I can submit a ticket with the schematic. I'll describe it below to make you understand better.
  • Is this only 1 PCF85176 device? Or all of them show the same behavior? I'll briefly describe the schematic: there are four PCF85176 connected to three displays. We drive them without any kind of multiplexing (static). Some PCF drive full digits across multiple displays, but it's all managed in software (e.g. two digits of one display, three of another display). All of the PCF85176 seem to behave like I described earlier.
  • Can you share logic analyzer capture of the data being transmitted to the LCD controller? I'll do it as soon as I can, in the meantime here are the bytes I send:
    • Mode set: 1100 1001
    • Blink: 1111 0000
    • Bank Select: 1111 1000
    • Driver: 1110 0000
    • Memory address (with C = 0) 0000 0000
    • Five bytes of data which vary from transmission to transmission (we connected the segments like "a b c d e f g DP" and write the ram accordingly in the correct order: a is the MSB and DP is the LSB, hence S0 = a and S7 = DP, and so on)
0 Kudos
Reply

1,703 Views
MircoCpt
Contributor I
We're using TSSOP56 package
0 Kudos
Reply

1,727 Views
ErikaC
NXP TechSupport
NXP TechSupport

Hello,

The PCF85176 is compatible with the PCF8576, and I don't see any significant differences between them in terms of RAM access. Could you clarify which drive mode you're using?

 

0 Kudos
Reply

1,720 Views
MircoCpt
Contributor I

Thanks for the fast answer.

I'm using static mode.

If the hardware designer did his job right (and from the schematics it seems so, but i'll triple check), the segments are connected at the same outputs as before, obviously adjusted for the different pinout (i mean, S0-S0, S1-S1 etc).

0 Kudos
Reply

1,717 Views
MircoCpt
Contributor I

I'm attaching 2 images of two PCBs with old and new driver, supposedly connected in the right way.

As you can see, the segments are inverted (DP=a, d=e, g=b, f=c) and the position is also wrong.

It screams "hardware issue", but the hw designer is confident.

Display OKDisplay OKDisplay FaultyDisplay Faulty

0 Kudos
Reply

1,713 Views
MircoCpt
Contributor I

For info, if I mirror the segment data byte (e.g. 11001001 -> 10010011) the character is displayed correctly, albeit in the wrong place.

0 Kudos
Reply