LK204-25: Version / character set / I/O delay questions

pk · Post by pk » Fri May 04, 2007 1:35 pm

Hi,

We have been using various models of your LCDs for a few months. There are a few problems we would like to resolve before we go into production:

1) I have an LK204-25 display. It reports model code PK204-25 (0x4D).
The revision number reported is 0x56 but there's no mention of that
in the latest manual.

2) The character set it appears to display is that defined for a 2041 not
for a 204-25. Is this a documentation error or do the character sets
for the various 204 models vary?

I am using characters 0xF5, 0xF6, .. 0xF8. However, instead of the
arrows defined for those character values in the manual, I see an
umlout (spelling?), summation side, pi, x-bar, etc. These correspond
to the characters of the same value but for a 2041.

3) I have noticed that I need to place an I/O delay after various commands
such as set curor x/y or it won't work reliably. I have seen from the
postings in a number of threads that you have a list of required delay
times for the various commands. Is that published on-line somewhere?
If not, could I please obtain a copy of it?

We are using RS-232 communications with display at 19,200 baud.

Thanks in advance for any help you can give us!
-- Paul

Raquel · Post by **Raquel** » Fri May 04, 2007 1:51 pm

Hello Paul,

Thank you for your post.

You are right, the LK204-25 should be replying with a 0x09 for the model type. As per the firmware version number, this is not mentioned in the manual. 0x56 though is a valid firmware version for the LK204-25. I am worried that maybe your uC is programmed for a PLED display, not for an LCD. If I can get you to please send the display the command 254/212. It should reply with a 4-byte value. Can I get you to please tell me these values?

As per the character set, can you please do a test for me? If you send the display a 0xFF (255) what does it display? I am expecting either a full block or an (inverted) 'P'.

There should be no necessary delays needed when communicating to an alphanumeric display using RS232. Most likely, the delays you see on the forums refer to I2C implementation, specially on graphic displays. By the way, not sure of an I/O delay on your end, could this be a limitation on your end?

Thanks,

pk · Post by pk » Fri May 04, 2007 2:54 pm

Hi Raquel,

Wow, thanks for the speedy reply!

In response to your questions:
1) The 254/212 command returned these hex values:
56 03 BF 47.

2) The character displayed when I send 255 is a full block. This is
what I expected given the LCD *appears* the be using the 2041
character set.

3) WRT the I/O delays: We initially used I2C to communicate with
the LCD and I observed that I needed to use them there. Then we
switched to RS-232 and things improved but I occasionally see issues
among different displays.

It's certainly possible there could be a problem on our end. But I use this
SIO driver for other devices at higher rates of speed and I don't see any
problems there. It seems to be primarily a speed issue in issuing
commands. If I place small delays after I send it commands (not
display data/text), it works reliably.

I realize (from reading thru the forums) that the display seems
to require ~1sec to initialize. If I start communicating with it
sooner it doesn't seem to operate reliably. So I hold off before I try
to send anything to it 1 second after power up.

I thought I'd seem similar behavior with some of the commands but
I verify. We have numerous types of Matrix Orbital displays and I don't
remember which ones I had observed these problems.

Again, thank you for your support!
-- Paul

Raquel · Post by **Raquel** » Fri May 04, 2007 3:41 pm

Hello Paul,

I am certain now that the LK204-25 you have has been programmed for a PK204-25 display. Do you have only 1 of these displays (LK204-25 LCD displays that return a 0x4D when queried for its module type)? I would like to get it back here for reprogramming.

We used to have the Japanese character set on our alphanumeric displays before and we have moved to the European character set now. When you see a full block for 0xFF (255), this means that the character set is Japanese. Attached here is the Japanese character. I hope this explains the issues regarding some characters (arrow, etc).

Yes, please verify and investigate some more on the issue of delays, I have not really had issues with alphanumerics before.

Also, if you need your display to be European, please specify when you send the display back.

Thanks,

pk · Post by pk » Fri May 04, 2007 4:00 pm

Thanks, Raquel.

I'll have to investigate both issues. I am a contractor and work off-site. I'll see if I can collect all the displays that we have and see who's who.

I'll let you know as soon as I can gather the data; by Monday for sure.

pk · Post by pk » Mon May 07, 2007 1:32 pm

Hi Raquel,

It looks like that one display is the only 'bad boy' of the bunch. We'll modify our mfg test to identify displays as a future safe guard.

My client doesn't want to bother w/reprogramming it -- it's just not worth it to them.

WRT the serial timing issues, I've removed all of the delays except for the startup delay and will see how things go.

Thank you very much for all of your help and quick replies!
-- pk