How would I learn how to write pixels to a graphics display for GPSDO - Page 1
Forum section: electronics / projects

author: cdev
author_rank: Super Contributor
timestamp: August 26, 2017, 02:51:47 am
content: I would like to use my GPSDO project as a way to learn about writing information in a fairly dense manner to a small inexpensive graphics display, and also have some LEDs that can be seen unambiguously at a distance which can stay on. Where would I start with this? I can design a screen in GIMP, do I treat it like a bitmap? Presumably it would be better to just update it with what changes maybe storing that in a long string that gets updated?I have a fairly good idea of how to tackle the state machine part, and code snippets and even beta software from others that seem likely to be very helpful too, but no idea where to start on the graphics part. But I'm a fast learner. I just dont want to reinvent the wheel if it already exists.I am on Linux if it matters.

author: cdev
author_rank: Super Contributor
timestamp: August 26, 2017, 04:04:36 am
content: Thank you, this is a lot of useful info!I'd like to use the old SGI sans-serif terminal font for the text. It just has a nice modern look to it.

author: MarkF
author_rank: Super Contributor
timestamp: August 26, 2017, 04:19:30 am
content: Take a look at the libraries Adafruit supplies for their small displays.They basically have routines for drawing pixels, lines, ellipses and text.Their font is stored in 5 bytes for each character (5x8 pixels). Each byte is 8 rows for one column. With 5 bytes for 5 columns. Drawing each pixel in the character.I re-did their font using the Verdana font. A bit of a pain but works well for my PIC microcontrollers.

author: ajb
author_rank: Super Contributor
timestamp: August 26, 2017, 02:39:53 pm
content: LCD user interfaces are graphic design problems first, and software engineering problems second.I would start by sketching out wireframes for the interface, indicating what information you want to display on each screen in relative scale, and what sort of visual hints you need to give to the user. Then convert a couple of these wireframes to full graphical mockups and see how they look. Ideally these should be done at 1:1 pixel scale, because things like antialiasing make a big difference to how things look, especially on low pixel count displays (or portions of displays), so you'll have to keep that in mind as you create the mockups. Once you have something you like, you can start figuring out how to implement it on the LCD. Maybe you just need fonts and a couple of icons, that's pretty easy. Maybe you want to do some nice borders and backgrounds or diagrams, so you have to look at how you might carve up a border into corners and edges so you can render it at different sizes, or figure out how you can simply draw it parametrically.Of course getting into those sorts of details requires knowing how you'll be rendering different basic elements to the LCD, so at some point you'll need to get some basic drawing routines working. A simple function that takes two corner positions and a color and draws a rectangle is a good place to start. Then you'll want something that takes a position, foreground color, and background color and draws out a monochrome bitmap. Once you have that, you can extend it to rendering a string using a monochrome font. If you want nice-looking icons, grayscale or color bitmaps are the way to go--monochrome bitmaps can look pretty jagged and terrible, especially at low pixel counts, so being able to display nice antialiased bitmaps will look much nicer. If you have a fairly fast MCU and you're using an external LCD controller, the interface between the MCU and the LCD controller may be the limiting factor in terms of update speed, so there can be some scope for fancy on-the-fly rendering and parametric drawing, but that's not the sort of thing you'd need very much of.If you want to get really fancy, there are microcontrollers with built-in TFT controllers with hardware acceleration that can do much more complicated graphics (although you quickly wind up needing external memory).The Dot Factoryis a useful little tool for rendering truetype fonts as header files for LCDs. Supports variable character widths, which is nice, and you can select which specific characters are rendered out, so you're not wasting flash on characters you'll never use. It will also render out monochrome bitmaps, but even on a small LCD monochrome bitmaps tend not to look very good. If you have the storage space, antialiased grayscale or color bitmaps will look much better. The same goes for fonts, really, but the storage penalty for going to an antialased font could be substantial.This websitewill convert bitmaps to a handful of different common RGB LCD pixel formats, although it won't produce grayscale, which would be nice for doing symbols that you'd want to display in variable color.Quote from: evb149 on August 26, 2017, 03:06:36 amJust keep in mind that even a 240x320x16b LCD is 1.2Mb, so that's a fair bit of data to stream. Hopefully your PC-side software is only sending deltas and not full screen refreshes. It would be quite useful for a quick "how does this mockup image look on the actual LCD", but trying to create a GUI using a PC-oriented library and then translating that to an MCU sounds like more trouble than simply creating the GUI on the MCU in the first place.

author: rstofer
author_rank: Super Contributor
timestamp: August 26, 2017, 10:07:04 pm
content: And the whole thing gets a lot more complicated when drop down boxes cover portions of the screen. What do you do when the box closes? Redraw the screen from scratch? How many layers deep is the image? Do you even remember what was on the underlying screen? Or do you save the overwritten pixels in a separate buffer so you can just put them back. This approach depends on knowing the rectangular dimensions of the overlaying box and where is was placed but doesn't care what was displayed. It's a pixel buffer. You will probably need several...At some point, the number of overlays can become stupid for an embedded processor. You probably have very good control of the depth of overlays. This isn't the case for something like a PC or cell phone. They get by with LOTS of memory.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: August 29, 2017, 04:11:14 pm
content: I used a Mega (multiple HW UARTS) and a simple TFT for mine...https://gitlab.com/NivagSwerdna/SymmetricomUCCMDisplayI only write text but the libraries allow you to paint your own pixels if you can put up with the time it takes.In practice you probably will not look at the display after a while, a status LED is probably enough.

author: cdev
author_rank: Super Contributor
timestamp: August 30, 2017, 03:02:22 am
content: You're right, its probably unnecessary, fun but unnecessary if all I need to do is plug in a console to get more info when I need it.