Matrix Orbital Corp

I'm having serious trouble uploading bitmaps to a GLK-12232-SM. It's hooked up to a Linux system, so I've not been able to test it with mogd.exe, and the Linux system being a headless server doesn't have the stuff required to run the Java software available from the site, so I can't test it with that either unfortunately.

I've tried using the Perl scripts available from http://mo-bitmaps.sourceforge.net which another forum user wrote. From what I can tell, the upload script is perfect, and does exactly the same thing as a sample of C++ code posted by Henry which I found while searching. However, the panel doesn't seem to be responding as expected. If uploading to position 1 (the intent is to replace the power-on splash image), things get as far as sending the low byte of the size before they go wrong - the panel sends back 0x01 instead of echoing the size as it apparently should.

If uploading to position 2, it doesn't do anything once the low byte's been sent, and just sits there (although once I was patient and patient and very, very patient and it eventually sent back 0x01 again).

Does anyone have any ideas what might be going on here? It's talking through a serial port, and I've had the same problem with three panels so far.

In theory it would be possible to hook the thing up to a Windows box and test it that way, but since I can see what's going in and out of the panel and it's not conforming to the docs, I can't see how that would work unless the docs are wrong.

And yes, the baud rate settings are correct. Displaying text and graphics, receiving keypresses etc. all work perfectly.

Hi MattW,
If you hook up your display to a system with a monitor (including Linux systems) and try uploading the bitmaps using LCD Tester, you might get better feedback as to what is going on from LCD Tester's log window.

What is the low byte that you are sending to the display? Make sure that this byte is unsigned, because sometimes the sign bit causes this kind of problems.

The low byte is definitely unsigned, at least as far as Perl lets me be positive of it. It's being sent the only way that seems to make sense, as a single byte by encoding it as a character with Perl's Unicode capabilities switched off.

Thus something like:

printf LCD "%c",$low_byte;

it works for everything else, and if it was a signed/unsigned problem surely 254 wouldn't send properly for any commands at all?

(edit: no, it wouldn't be that, because this is a 32-bit system not an 8-bit one so the sign bit wouldn't be anywhere near there. hmm. Still, it's definitely a positive number being sent).

As for hooking it up to a monitor, that's not a problem, but installing the Java runtimes and X11 to display the LCD tester GUI is. Is there any documentation anywhere of what a return of 1 instead of an echo might actually mean? Or is it just some kind of generic error value?

Before you try downloading a new bitmap, can you try purging the memory... Just another thought, since you can communicate to the unit, can you try changing the contrast to something obvious and saving it...? Power the unit off, then on and let me know if the contrast changed?? By doing this we can test the functionality of the memory chip...We know we can read from it by displaying a start-up screen and sending text, but I'm curious if we can write to it!!

It seems I've been misreading the traffic between my program and the serial port. I am sending an extra 0x01 before the low byte of the size, although I'm not yet sure why, but it seems the unit is correctly echoing it so that's not a concern anymore.

Sorry to bother you with a stupid problem on my side.

OHH no worries, that's what we're here for!!! I'm just glad that you got the problem resolved.