Read Customer Data over I2C

LK/ELK/VK/PK/OK/MX/GLK/EGLK/GVK/GLT Series

Moderators: Henry, Mods

Post Reply
skassan
LCD?
Posts: 4
Joined: Tue Apr 22, 2014 6:41 am

Read Customer Data over I2C

Post by skassan »

I'm having trouble reading the customer data area over I2C (LK202-25). After writing the command 0x35, subsequent reads return only zeros. But I have noticed that after initialization, when I go into my poll keypress loop, the first 16 key presses return what appears to be the customer data. As an experiment, I tried reading back the version number and module type. Similar results: reads immediately following the write 0x36 and 0x37 return zeros. But the first two key presses return what appear to be the version number (0x62) and the module type (0x08). I've confirmed that my keypress routing is working correctly: it returns the appropriate key value when a key is pressed.

My initialization sequence consists of: Protocol Select, Unlock All, Auto Scroll Off, Auto Transmit Keypress Off, Auto Repeat Mode 0, Clear Screen.

I've tried reading all 16 bytes in one transaction, as well as reading a single byte per transaction 16 times. (By the way, do I need to read all 16 bytes if I only care about the first one?)

Clark
Matrix Orbital
Matrix Orbital
Posts: 881
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: Read Customer Data over I2C

Post by Clark »

Hello Skassan,

I understand your LK202-25 is responding to key presses over I2C, but not customer data, firmware version, or module type. Given some responses are transmitted, I'd say your initialization is correct, but you may require some delays. It sounds like the host is reading from the display before any information is available.

Using a simple Arduino Uno and a GLK19264A-7T-1U, I've experimentally found that a 10ms delay between each byte written and a 50ms delay after each write cycle provides reliable results when continuously requesting the module type from the display. These delays may change from one host to another, especially when I2C functions are abstracted into higher libraries as they are for the Uno. When reading in I2C, a common approach is to begin with a large delay, then experimentally reduce it while communication remains successful.

With regard to reading customer data, the display will put all 16 bytes into the output buffer upon receiving a command requesting the information. Bytes are only pulled out of the buffer as they are read, so if just one byte of the customer data information is read immediately, the next time a byte is read it will be the second byte of customer data, and any requested data will be added on top of the existing information still in the buffer. I would recommend reading all requested bytes right away.

Cheers,
Troy
Troy Clark
Design & Development
Matrix Orbital

skassan
LCD?
Posts: 4
Joined: Tue Apr 22, 2014 6:41 am

Re: Read Customer Data over I2C

Post by skassan »

Troy,
Thanks for the quick reply. I'm sorry I didn't mention this in my original post. I had already thought of that, and went as high as a 250 ms delay between the write and the subsequent read, with no success. I should also mention that the key polling begins about 35 ms after the initialization sequence completes. The first key poll begins returning the customer data. So it appears that the data is available in as little as 35 ms, but only if I ask for key poll data first.

In summary:
[Start] Write 0x50 / 0xFE / 0x35 [Stop] / Large Delay / [Start] Read 0x51 / (16 bytes of clock pulses) - returns all zeros
followed by some writing to the screen (cursor position commands and plain characters), followed by
[Start] Write 0x50 / 0xFE / 0x26 [Stop] / 150 us Delay / [Start] Read 0x51 / (1 byte of clock pulses) - returns first byte of customer data

I can capture screen shots from a logic analyzer if you think that might help.

skassan
LCD?
Posts: 4
Joined: Tue Apr 22, 2014 6:41 am

Re: Read Customer Data over I2C

Post by skassan »

Troy,
Further investigation revealed that my earlier tests with delays were invalid. Apparently, once it gets behind, it needs to be power cycled to get back in sync. Inserting a power cycle in between test runs allowed the delay to work. I was able to get the delay down to 2.5 ms.

Thanks for your help.

Clark
Matrix Orbital
Matrix Orbital
Posts: 881
Joined: Fri Aug 17, 2007 10:58 am
Location: Matrix Orbital
Contact:

Re: Read Customer Data over I2C

Post by Clark »

Hello Skassan,

Good to hear the problem was resolved once both units were sync'd. If you can narrow down what command causes the units to drift out of sync, I can investigate further here.

Hopefully, the units stay in sync while testing, but if necessary you may be able to send the bytes 0xFE 0xFD to reset the display through software. This is an undocumented command for second generation alphanumeric displays, meaning PCB Rev2.0 for the LK202-25, that kicks the watchdog timer of the interface controller, resulting in a reboot after about 3 seconds.

Cheers,
Troy
Troy Clark
Design & Development
Matrix Orbital

Post Reply