Thank you for trying to help me, but I'm on the verge of giving up now :( No matter which way I try (Vrtual COM Port or FTD2xx), my EGLK stops working properly as soon as I change the baud rate to any value other than 19200 bps. At the default 19200 bps it works perfectly though. Just to make sure I...

Thank you for the suggestion. I've implemented an alternative code path, to use Virtual COM Ports. Sadly, it acts absolutely similarly to the FTD2xx method: once I change the baud rate from 19200 to any other value, the EGLK stops responding to commands. It's a bit like it was hard-wired to work onl...

Thank you for your reply. We've checked the Draw a Bitmap Directly method, and its performance is adequate, at least on our 192x64 resolution GLK. It takes cca 765 milliseconds to update the whole screen at 19200 bps. Now I only wish I could up the baud rate to accelerate the screen update a little ...

Thank you for your detailed reply and insight on the inner workings of the GLK. You sort of mentioned the exact same thing that I proposed as a possible low(er) level enhacement of the firmware: writing multiple pixels at once. It would dramatically improve the performance, since it would take much ...

I'm still interested in somehow resolving the bitmap display bottlenecks on the GLK. I have 2 ideas, one may not work at all, and the other may be something you're not interested in to hassle with: 1) In another manufacturer's LCD protocol I've seen a trick to update multiple pixels via a single com...

Thank you for your reply. One more issue about fonts: I don't think the Get String Extents command works properly, at least not for me. As a test, I've put a text of "CPU gauge" on the top left corner of the LCD, using the standard Windows True Type font of Tahoma, with 16 pt font size, bl...

Edit: Nevermind, I've found the required info to calculate dpi for GTT LCDs in the hardware manuals. You just have to scan for Dot Pitch in there, and divide 25.4 by the value :) Using that for font scaling makes the text look exactly how I wanted it to. I'm facing more GTT issues now :) What I'm t...

Thank you for the fix you've sent me, it works just fine now. I appreciate your fast response and efficient way of sorting out issues.

Hi Tamas, If you're looking for an alternative to the Get Module command, specifically for the GTT, you might consider adding an Echo command at the end of your autoexec file. That way, once the GTT has finished booting and executing all other autoexec commands, it can echo a response of your choos...

Thank you, Martino!

Should I add more delays between the GTT_LoadBitmap procedure calls, or between the FT_Write and FT_Read calls? I'm a bit confused though, since I assumed after the display returns either eErrorCode_Success or an error code after issuing the Load A Bitmap command, it is safe to do anything with the ...

Thank you for looking into this. Here are the two PNG files that fails to load. My test code is above, and here's the GTT_LoadBitmap function: Function GTT_LoadBitmap(by_idx:Byte;sa_filename:AnsiString):Boolean; Var d_amount,d_len,d_read,d_written : DWord; i : Integer; bu_out : Array [0..1023] Of By...

My GTT50A reports a Module Version of 2.0, and a Firmware Version of 2.1. It was purchased a mere 3 weeks ago, so I assume it is running the very latest firmware. Is it possible to check the firmware build number as well, or only 2.1 is available via GTT protocol calls? I've tried it with a single, ...

Thank you for your reply. The code above is only a test code. My regular code works erratically due to this issue, and I've had to make a test code to pinpoint the actual issue. My regular code simply cannot display PNG images after the LCD gets updated by issuing a Clear All Buffers and loading all...

Hi, Is there a full list of module type codes? I've tried to collect a full list, but it's not easy, since you have to download and check every technical manuals for current and legacy products :( It would be great if you could post a full chart containing every Matrix Orbital module type codes ever...