EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Kronkulus on September 06, 2022, 04:32:03 am
-
I'm working on a power supply design for my little garage lab. I don't really have much experience with displays outside of the 16x2 LCDs that come with some electronics kits. Out of the available display technologies what would be the best bang for buck? Taking into account ease of development, cost including any driving circuitry, longevity, etc. The big things you'd consider when designing something. I'm not super worried about ease of development, this is mainly for my own education anyway. I'm also wondering if there are displays better suited to cold environments, I'm in one of those pesky northern places that gets way too much snow and my garage isn't heated or insulated.
Thanks!
-
I think the 16x2 displays are hard to beat. Downside is they are certainly not well suited for low temperatures. (But low temps are also a problem for electrolytic caps. Be sure to check the specs.)
Depending on what exactly you want to display, I'd go with LED. Dirt cheap and support chips readily available for decades. Even LED maxtrix displays are not that expensive.
-
Really depends on what your display needs to, you know...display. Also what sort of physical format is appropriate to the project.
In general, though, if "bang" means ability to display a wide range of information, then I would say either monochrome OLEDs for small displays or TFTs for larger displays. You can find all manner of these one ebay, aliexpress, etc, for a few bucks a piece for development/testing/one-offs, and then for production quantities: https://www.buydisplay.com/. (https://www.buydisplay.com/.)
Generally these displays will all use one of a handful of different controllers, with I2C, SPI, or parallel interfaces. The controller typically has an internal framebuffer that can be written to in various ways by the host. Note that there are also TFTs with 24-bit RGB+sync interfaces, these have drivers but not controllers built in, these will require an external controller and framebuffer. Some MCUs have these TFT controllers built in, but will usually need external memory to hold the framebuffer unless the display is pretty small.
For displays with built-in controllers, the controller defines the interface (many TFT controllers allow you to select between SPI/parallel interfaces by strapping a couple of IO pins) and command set, so as long as you're using the same controller you can swap between manufacturers/sizes of display quite easily. Just be aware that some panel-specific values often need to be programmed into the controller as part of the startup sequence, hopefully the display manufacturer will specify these. Whether you want to use SPI or parallel will depend on the number of IOs and peripheral types you have available as well as your desired update speed. Parallel interfaces will generally allow for MUCH faster updates, at the expense of needing more IOs. If your MCU has an external memory controller, this can be a great way to implement a parallel display interface--you would map the required number of data lines between the memory controller and the display interface, and then map one address line to the command/data select line on the display, so that writing to one external memory address will be interpreted as a command and writing to another address will be interpreted as data by the display controller. (There are some traps here on more sophisticated MCUs, like Cortex M7s, that have caches and/or do not guarantee that memory accesses happen exactly as programmed, but this can generally be worked around via the MPU.)
There are tons of libraries out there for most of the common controllers, I think the adafruit ones are generally pretty well regarded? But once you get the basic data interface working, with some experience it should be possible to write some basic "draw a rectangle" or "draw this bitmapped character" functions in a day or so. One downside to both OLEDs and TFTs of this type is that it's bring-your-own fonts, so you will have to account for that in terms of memory allocation. I'm not sure what the popular libraries use as far as fonts, but for my own work I've used The Dot Factory to convert standard fonts to an MCU-friendly format: http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/ (http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/)
-
The small OLED displays are nice, and they are cheap, especially ones with the I2C interface. But they do have pixel degradation, which can be very noticeable. Here's a link to some tests: https://hackaday.com/2019/04/23/a-year-long-experiment-in-oled-burn-in/ (https://hackaday.com/2019/04/23/a-year-long-experiment-in-oled-burn-in/)
I have some of these displays on small projects, and one where I had usually-unchanging text displayed at 100% intensity, after a couple years of continuous running shows huge variations in pixel intensity. I've got a test running now where a display is running a fixed pattern at minimum intensity (still quite viewable), and one second out of 60 I switch to "all pixels on". After about six months running I can see faint ghosting. So reducing the intensity helps, as do screensaver images (that even out the pixel wear). My screensaver is a simple sinewave image that scrolls horizontally -- very few pixels on but still shows that the unit is operating.
I'm using the Adafruit libraries for the display.