I'm writing a driver for lcdproc (linux) to support the GLK19264 and found that the bar graph functionality works great for displaying vertical and horizontal bars. The only drawback is that documentation states only 16 bar graphs can be used at one time.
One of the screens from the lcdproc client displays 32 vertical bars across the bottom and I can imagine that someone wanting to display an equalizer or something similar would like more than 16 bars.
So... I wanted to find out if there were any plans to increase the limit with firmware updates or is this something that's fixed and can't be changed.
I haven't tried using a ref greater than 16 ... don't want to mess something up.
My plan is to use solid rectangles once the max of 16 bar graphs have been used... this way I can make them look the same and change the color to "erase" them. However, I've found that the solid rectangle drawing can draw rectangles all over the place (even fill most of the screen) if the buffer doesn't have enough space and you draw several of them too quickly. I would MUCH rather use bar graphs.
Thanks
GLK19264 Bar Graph Limit
Hello Lynx28,
Unfortunately, the reference parameter used in the initialize bargraph command is anded with 0x0F, so only values from 0 to 15 decimal will be valid. Sending a value such as 16 should only result in the bargraph defined by 0 being overwritten, nothing catastrophic.
There are no specific plans to upgrade the GLK19264 firmware to add more graph slots, but if we do look to make changes in the future this may be something we consider.
As for drawing rectangles, this is basically what the bargraph command does, automatically and with error checking. It sounds like you may be overflowing the buffer with your commands, resulting in bytes being thrown out, command strings changing at the display, and ultimately incorrect boxes being drawn. You could investigate delays to remedy this; start relatively high at maybe 100ms after each command and decrease. You might also look into more intricate flow control.
Should you have any further questions as you develop GLK19264 support for lcdproc, please don't hesitate to post.
Thanks,
~Troy
Unfortunately, the reference parameter used in the initialize bargraph command is anded with 0x0F, so only values from 0 to 15 decimal will be valid. Sending a value such as 16 should only result in the bargraph defined by 0 being overwritten, nothing catastrophic.
There are no specific plans to upgrade the GLK19264 firmware to add more graph slots, but if we do look to make changes in the future this may be something we consider.
As for drawing rectangles, this is basically what the bargraph command does, automatically and with error checking. It sounds like you may be overflowing the buffer with your commands, resulting in bytes being thrown out, command strings changing at the display, and ultimately incorrect boxes being drawn. You could investigate delays to remedy this; start relatively high at maybe 100ms after each command and decrease. You might also look into more intricate flow control.
Should you have any further questions as you develop GLK19264 support for lcdproc, please don't hesitate to post.
Thanks,
~Troy
Troy Clark
Design & Development
Matrix Orbital
Design & Development
Matrix Orbital
Hello Troy,
Thanks for the reply! I had a feeling this wouldn't be something too easy to change... would definitely be something nice to have in the future.
Flow control is definitely the way to go with drawing the rectangles. I had originally implemented it with a separate routine that would check the buffer first with the full setting at 42... but was still overflowing the buffer like crazy. Not positive but it lookes like the client opens multiple sockets to communicate with the driver and using a separate function wasn't working.
I moved the flow control checks into the functions that write to the device (only two) and that resolved the overflow issues. I've had it running for several hours now with no weird characters showing up.
I had originally tried configuring flow control with termios and that just dropped characters without returning appropriate error codes.
Anyway... I finally have the bars working along with decent graphics for the different icons. Should have the driver done pretty soon.
I've also figured how to upload bitmaps and found that there's an error in the documentation. After sending the initial command with size and getting the ACK back the document shows sending an ACK back to the device. However, you should send the width after the first ACK, from there you do need to send the ACK after each character is echoed back. I'll post another topic with more details ... I've seen other posts asking how to do it in code.
Thanks!
Thanks for the reply! I had a feeling this wouldn't be something too easy to change... would definitely be something nice to have in the future.
Flow control is definitely the way to go with drawing the rectangles. I had originally implemented it with a separate routine that would check the buffer first with the full setting at 42... but was still overflowing the buffer like crazy. Not positive but it lookes like the client opens multiple sockets to communicate with the driver and using a separate function wasn't working.
I moved the flow control checks into the functions that write to the device (only two) and that resolved the overflow issues. I've had it running for several hours now with no weird characters showing up.
I had originally tried configuring flow control with termios and that just dropped characters without returning appropriate error codes.
Anyway... I finally have the bars working along with decent graphics for the different icons. Should have the driver done pretty soon.
I've also figured how to upload bitmaps and found that there's an error in the documentation. After sending the initial command with size and getting the ACK back the document shows sending an ACK back to the device. However, you should send the width after the first ACK, from there you do need to send the ACK after each character is echoed back. I'll post another topic with more details ... I've seen other posts asking how to do it in code.
Thanks!
Hello Lynx28,
I appreciate the update, flow control can be complicated to implement but if you can get over the hurdles it will pay dividends in the end. Good to hear the bars are up and working!
As for the upload protocol, you are correct there is a mistake in the GLK19264 manual. It is not necessary to return a confirmation byte after one has been received from the display indicating the file will fit. This has been resolved in our newest documents such as the GLK24064-16-1U manual, and will be corrected in the 19264 manual.
Anyway, all the best with the driver, if you run into any further questions, by all means, please throw up a post.
Thanks,
~Troy
I appreciate the update, flow control can be complicated to implement but if you can get over the hurdles it will pay dividends in the end. Good to hear the bars are up and working!
As for the upload protocol, you are correct there is a mistake in the GLK19264 manual. It is not necessary to return a confirmation byte after one has been received from the display indicating the file will fit. This has been resolved in our newest documents such as the GLK24064-16-1U manual, and will be corrected in the 19264 manual.
Anyway, all the best with the driver, if you run into any further questions, by all means, please throw up a post.
Thanks,
~Troy
Troy Clark
Design & Development
Matrix Orbital
Design & Development
Matrix Orbital