Full bitmap display on USB GLK

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

Moderators: Henry, Mods

Post Reply
Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Full bitmap display on USB GLK

Post by Fiery » Wed Jul 09, 2014 2:53 pm

Hi,

Is it possible to display full-screen 240x128 bitmap images on GLK LCDs, without the update rate falling to 0.1 FPS or such? My best idea about getting around the slow communication is using direct draw pixel commands, but only on the pixels that's changed since the last update (last frame). However, that could still be quite a few pixels, and as far as I can tell, drawing pixels is very slow on Matrix Orbital displays due to interface constraints/bottleneck. Would it be better to try finding adjacent pixels (in both horizontal and vertical direction) and where it's possible draw lines instead of individual pixels? Would it bring a considerable improvement in performance?

The ideal update rate for my application would be at least 2 FPS, except for the initial screen display which could take longer than 1 second. I'm wondering if there's any way to achieve my goals, or I'd better try finding alternative solutions like minimizing the used active pixels to minimize the amount of changed pixels between frames...

Thanks,
Tamas

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: Full bitmap display on USB GLK

Post by Tino » Thu Jul 10, 2014 8:39 am

Hi Tamas,

Unfortunately there is no faster way to Draw Directly to the display.
Drawing a line could improve the speed slightly.

The fastest way to draw a image would be to display a previously loaded image.
If you were to run an animation you can get about 3 to 4 FPS. I'd suggest you create an animation file with the images you are using.

Thank you
Martino
Martino DeLeon
Matrix Orbital
Technical Support Representative

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: Full bitmap display on USB GLK

Post by Fiery » Thu Jul 10, 2014 9:53 am

Thank you for your reply. I'm afraid I cannot upload the image or an animation to the device, since what I'm building is a dashboard-like bitmap with gauges, graphs, bars (etc), and any part of that bitmap could change between frame updates. Usually only a small portion of the bitmap changes, so I'm hoping that I can reach an acceptable update rate. Quite frankly, my initial tests showed a poor update rate, but I was using the default baud rate of 19200, so upping that to 115k should improve things dramatically. In case the mentioned 3 to 4 FPS could become reality, then I'll be a happy camper :) So far I'm loving your products, especially since they raise new challenges for me as a software developer :) :)

Tino
Matrix Orbital
Matrix Orbital
Posts: 158
Joined: Wed May 22, 2013 9:04 am
Location: Matrix Orbital
Contact:

Re: Full bitmap display on USB GLK

Post by Tino » Thu Jul 10, 2014 11:38 am

Hi Tamas,

The 3 to 4 FPS is with running an animation.

You may get a little benefit from raising the Baud Rate but not much.
The reason is the data goes to memory then writes to the display. If you previously loaded the images then it would be a lot faster than drawing directly.

A suggestion could be to create the images and upload them. Set in the program to have the display show the image that is set to the value of the read data.
Ex.
Have a image that shows a gauge at 50% show when the read data is at 50%.


Thank you
Martino
Martino DeLeon
Matrix Orbital
Technical Support Representative

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: Full bitmap display on USB GLK

Post by Fiery » Fri Jul 11, 2014 5:31 am

Thank you for your reply. I've done more test runs on and measured the performance of drawing pixels vs. drawling lines vs. drawing filled rectangles (on EGLK19264A-7T-USB), and I could see dramatic performance increase when going for drawing lines instead of pixels. At the default 19200 baud rate I managed to draw 480 pixels per second, while I could draw 320 horizontal 192-pixel wide lines per second. Drawing a full-screen (192x64) filled rectangle was also faster than messing with pixels, I've managed to draw 4.2 filled rectangles per second that way. It seems to me that the real bottleneck is not the memory bandwidth, but more the serial communications protocol or the memory latency. So drawing individual pixels is very costly, but drawing more of them right next to each other is much faster than drawing them to random places on the screen?

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: Full bitmap display on USB GLK

Post by Fiery » Mon Aug 04, 2014 12:02 am

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 command: starting from a specific x,y location the device could update 8 adjacent pixels at once, with the 8 pixels residing in a single Byte data after the command. Updating 8 pixels at once would be a huge boost (IMHO) for the GLK, and may not bring a dramatic change to the current protocol. The 8 adjacent pixels could be in a single row or a single column, in any direction. Another proposed GLK command could update a whole row or a whole column in a single call.

2) An even better, and potentially much more useful solution to the bitmap display problem would be to allow sending commands and data directly to the display controller. It would have to be controller-dependent, so the running application would need to use different protocol (over the GLK protocol) to handle KS0108, SED1520 and T6963C displays, including chip select. It may also be necessary to introduce a "switch" in the GLK protocol to enable or disable the low-level access facility.

I'd personally be very interested in the 2nd (low-level) solution, since in my software -- apart from altering the brightness and contrast and drawing individual pixels -- I don't use any functions of the GLK protocol. And right now my software is heavily bottlenecked by the low performance of draw pixel commands :(

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

Re: Full bitmap display on USB GLK

Post by Clark » Tue Aug 05, 2014 12:39 pm

Hi Tamas,

Communication speed will be the biggest bottleneck for the GLK; it's really designed as a user interface as opposed to a real-time display. Anything that is saved in display memory will be drawn significantly faster than data transmitted over the serial port, simply because the speed at which the GLK can fetch local data is much faster than the 115,200 bps allowed via serial protocol.

I appreciate the ideas provided and can shed a little more light on the algorithms used by the GLK series. First, raw screen data is saved as 8 bits. Anytime a Draw Pixel command is executed, our controller fetches the appropriate block of 8 pixels from screen memory, edits the required pixel, and writes the new block of 8 pixels back. Our line commands preform some optimization by writing to as many of the 8bits in a given block as possible at one time. A direct draw bitmap will also be optimized.

However, the display controller must wait for data from the serial port as it is drawing. The worst case is the Draw Pixel command which has the most overhead, then the Draw Bitmap Directly command which optimizes pixel data into bytes, and finally more advanced drawing commands, such as Draw a Line, which require minimal data. The fastest way to display an image, is to use the Draw a Bitmap from Memory command as it requires the least number of bytes to be sent over the serial port.

I put together a quick C# demo to show the speed differences using a simple 30x20 pixel gauge on a GLT24064R-1U-USB-TCI that displays min, half, max, then half values within a 10 iteration loop. Using code timings only (it is difficult to time visual changes to the millisecond) I have the following results:
  • Pixel Drawing (Needle Only): 3,153ms
  • Line Drawing (Needle Only): 670ms
  • Direct Drawing (Needle Only): 400ms
  • Bitmap Drawing (Complete Gauge): 159ms
I've attached the code and a video of the demo below. If you have any questions, please don't hesitate to ask.

For the GLK line, if a large variety of different visual updates are required, I would recommend uploading static elements to memory and drawing dynamic portions using advanced drawing commands (lines, rectangles, circles...). If visual elements can simply be reused to create dynamic effects, all can be uploaded to memory. The trick will be finding a balance between available memory and drawing speeds.

To draw directly to the screen, a different piece of hardware will be required. For instance, the GX is able to handle significantly more data due to the fact that it can operate on the USB bus at 12Mbps (as opposed to 115.2Kbps). If you have a relatively large volume application for a custom display, please contact me directly, tclark@matrixorbital.ca, and I'd be happy to discuss your needs.

Cheers,
Troy
Attachments
IMG_1128.zip
Gauge Demo Video
(1.29 MiB) Downloaded 88 times
DrawingTest.txt
C# Code to Test Drawing Speeds
(6.94 KiB) Downloaded 78 times
Troy Clark
Design & Development
Matrix Orbital

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: Full bitmap display on USB GLK

Post by Fiery » Wed Aug 06, 2014 2:57 pm

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 less commands to issue through the slow bus, and the memory controller would have to read and write less bytes as well. Writing 8 adjacent pixels as a single byte would be very convenient to use, as long as the software's developer has a clear knowledge on the pixels layout/map.

As for the issued commands limitation, you're right, there's a clear ceiling of that which we have to take into account. Problem is: our software provides such a flexible configuration of the LCD layout that we simply cannot predict how many dynamically changing items (like labels, graphs, gauges, bars, etc) the user would place on the LCD. We measured a maximum of roughly 500 commands that we can execute per second on a 19200 bps GLK. Obviously, when you want to change all pixels one by one using the current protocol, even on the GLK19264 it could be cca. 24 seconds to update the whole screen. By being able to update 8 pixels via a single command, I _think_ that value could be just around 3 seconds. Which is still quite high for our needs, but much closer to the "bearable" range (by our software's customers). By implementing 16 or even more pixels updating with a single command, our goals would be easily attainable :) With the current protocol all we could do is redraw only those pixels (one by one) that changes between frame updates, but it still doesn't look as great as we'd like.

I of course am perfectly aware of the GX, which is -- to me at least -- the ultimate and best Matrix Orbital product so far, mostly because it can do proper full-screen updates very quickly :) If you could make a GX with a 5-inch true-colour touch display, that would be an absolutely awesome product. I know, there's the GTT 2.0, but with that we face the same challenges about full-screen updates as with the GLK. The only difference is: due to the RGB pixels and the high resolution, with the GTT there's absolutely no hope to update the whole screen with a slow connection (115k baud) in a timely manner. With the GLK, with some firmware enhancements it _may_ be possible to update the whole screen quickly. We can adjust our software to any crazy protocols, so if you e.g. implement a different technique on SED1520-based GLKs than on the T6963C-based GLKs, it's okay, we can follow those tricks as long as they're documented in the relevant GLK technical manuals.

I'm perfectly aware that my proposed ideas may be interesting to too few applications and too few customers of the GLK to let you allocate development and validation resources on this. But, with my previous issues you've been so helpful and provided such professional assistance, that I somehow felt that it would be best to express my hopes about the future GLK protocol improvement possibilities ;)

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

Re: Full bitmap display on USB GLK

Post by Clark » Thu Aug 07, 2014 4:05 pm

Hi Tamas,

By all means, please express your specific needs, your input guides our future design process. As requested, I've added a direct draw bitmap into the demo, and updated my previous post.

The Draw Bitmap Directly command does as you've mentioned, it is optimized to update a block of 8 pixels in one display memory read/write cycle. For this small demo, it was far faster than drawing pixels, but a bit slower than drawing an entire bitmap from memory. Obviously, drawing times will increase with larger dynamic areas, and conversion of an image into direct draw format is not free (time-wise).

The trick that makes the GX so fast is that we were able to attach a blazing fast LPC2141 (compared to an Atmega164P on the GLK) with native USB support to a relatively simple screen. Unfortunately, the standard serial protocol typically slows us down, and our standard GLK line depends heavily on RS232, TTL, and RS422 protocols.

The GTT offers more flexibility. Onboard memory has increased to a default 2GB over the 256KB, at most, of the GLK line. And again, we have a significant processor upgrade. We're asking the GTT to do more natively, to minimize the number of commands required, and provide faster visual responses. Advanced features such as scripts, especially attached to buttons, and graphing with traces have provided significant speed improvements for interface design, and we continue to experiment with other features, such as gauges, to provide an enhanced customer experience.

I don't expect significant upgrades for the GLK or GX lines in the very near future, but if you'd like to start on a custom project or work with the GTT, please don't hesitate to contact us directly.

Cheers,
Troy
Troy Clark
Design & Development
Matrix Orbital

Fiery
LCD Geek
Posts: 36
Joined: Wed Jul 09, 2014 2:38 pm
Location: Budapest, Hungary
Contact:

Re: Full bitmap display on USB GLK

Post by Fiery » Tue Aug 12, 2014 11:39 am

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 bit more, but I still cannot increase the baud rate for some reason (discussed in a different topic already here). I'm starting to think it's due to a bug in FTDI drivers or such :(

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

Re: Full bitmap display on USB GLK

Post by Clark » Tue Aug 12, 2014 1:53 pm

No worries Tamas,

Good to see you've found a solution that permits the drawing speeds you require (or at least speeds you can tolerate). I've added an update to your other post. If you have any further questions, please don't hesitate to ask.

Cheers,
Troy
Troy Clark
Design & Development
Matrix Orbital

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 4 guests