Hi,
We are using the I2C CFA533 and while we have it "working" we are running into some problems that the datasheet isn't too clear about so hopeuflly you can help us.
We are running the device off 5V and 5V I2c with 4K pullups on both the clock and data line. We generate the Clock via an FPGA, and its fastest setting is 60 kHz.
Basically what we are seeing is that the packets we send down don't always get properly handled. Basically it might take us 2 or 3 times to send the "clear LCD" command before it works. So we know the packet is "right" but it isn't always getting there properly. In looking on the scope it appears that the LCD is NACKing us at various times during our transfer of the data packet. When it doesn't happen, the command is processed and the action performed.
So..
Our questions....
Do we have to read the read buffer after sending a command packet? Is this a requirement, or just a way to check that the packet was actually properly sent.
The datasheet says that a NACK can occur "upon receiving the last byte for which storage is available". What size is the write buffer and how could a 4 byte packet like "clear lcd" actually over flow it.
Is there a way to flush / clear this buffer?
As I mentioned before our clock is roughly 60 kHz. The datasheet says 50 kHz or 100kHz. Is this an absolute requirement, or does the LCD not care as long as the clock is less than 100 kHz??
I think that is all the questions I have right now. We have an aardvark on order to try that out, but I was hoping you might have some insight / clarifications to the datasheet.
Thanks,
Will
We are using the I2C CFA533 and while we have it "working" we are running into some problems that the datasheet isn't too clear about so hopeuflly you can help us.
We are running the device off 5V and 5V I2c with 4K pullups on both the clock and data line. We generate the Clock via an FPGA, and its fastest setting is 60 kHz.
Basically what we are seeing is that the packets we send down don't always get properly handled. Basically it might take us 2 or 3 times to send the "clear LCD" command before it works. So we know the packet is "right" but it isn't always getting there properly. In looking on the scope it appears that the LCD is NACKing us at various times during our transfer of the data packet. When it doesn't happen, the command is processed and the action performed.
So..
Our questions....
Do we have to read the read buffer after sending a command packet? Is this a requirement, or just a way to check that the packet was actually properly sent.
The datasheet says that a NACK can occur "upon receiving the last byte for which storage is available". What size is the write buffer and how could a 4 byte packet like "clear lcd" actually over flow it.
Is there a way to flush / clear this buffer?
As I mentioned before our clock is roughly 60 kHz. The datasheet says 50 kHz or 100kHz. Is this an absolute requirement, or does the LCD not care as long as the clock is less than 100 kHz??
I think that is all the questions I have right now. We have an aardvark on order to try that out, but I was hoping you might have some insight / clarifications to the datasheet.
Thanks,
Will
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.