Display types: Difference between revisions

From Helpful
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Many-element=
=Few-element=
==Backlit flat-panel displays==
==Lighting==
 
===Nixie tubes===
[[Image:Nixie2.gif|thumb|right|]]
<!--
<!--
Nixie tubes were some of the earliest outputs of computers


We may call them LCD, but that was an early generation
They have been a inefficient solution since the transistor or so.
LCD and TFT and various other acronyms are all the same idea, with different refinements on how the pixels work exactly.


There are roughly two parts of such monitors you can care about: How the backlight works, and how the pixels work.
But they're still pretty.


[[Lightbulb_notes#Nixie_tubes]]
-->
<br style="clear:both">


But almost all of them come down to
* pixels will block light, or less so.
* put a bright lights behind those
: in practice, they are on the side, and there is some trickery to try to reflect that as uniformly as possible


===Eggcrate display===


There are a lot of acronyms pointing tou
<!--
: TN and IPS is more about the crystals (and you mostly care about that if you care about viewing angle),
An eggcrate display is a number of often-incandescent, often-smallish lighbulbs in a grid (often 5 by 7),
: TFT is more about the electronics, but the two aren't really separable,
named for the pattern of round cutouts
: and then there are a lot of experiments (with their own acronyms) that


https://en.wikipedia.org/wiki/TFT_LCD


TFT, UFB, TFD, STN
These were bright, and primarily used in gameshows, presumably because they would show up fine even in bright studio lighting.
Note that when showing $0123456789, not all bulbs positions are necessary.




-->
-->


===CCFL or LED backlight===
==Mechanical==
 
===Mechanical counter===
 
https://en.wikipedia.org/wiki/Mechanical_counter
 
 


===Split-flap===
[[Image:Split-flap diagram.png|thumb|right]]
<!--
<!--
Both refer to a global backlight.
It's only things like OLED and QLED that do without.


If you're over thirty or so, you'll have seen these at airports. There's a few remaining now, but only a few.


CCFLs, Cold-Cathode Fluorescnt Lamps, are a variant of [[fluorescent lighting]] that (surprise) runs a lot colder than some other designs.
They're somehow satisfying to many, and that rustling sound is actually nice feedback on when you may want to look at the board again.


CCFL backlights tend to pulse at 100+ Hz{{verify}}, though because they necessarily use phosphors, and those can easily made to be slow, it may be a ''relatively'' steady pulsing.


They are also high voltage devices.
They are entirely mechanical, and only need to be moderately precise -- well, assuming they only need ~36 or so characters.




LED backlights are often either
https://www.youtube.com/watch?v=UAQJJAQSg_g
* [[PWM]]'d at kHz speeds{{verify}},
* current-limited{{verify}}, which are both smoother.
 




-->
-->


https://nl.wikipedia.org/wiki/CCFL
https://en.wikipedia.org/wiki/Split-flap_display
<br style="clear:both"/>


==Self-lit==


===OLED===
{{stub}}


While OLED is also a thing in lighting, OLED ''usually'' comes up in the context of OLED displays.
===Vane display===


It is mainly contrasted with backlit displays (because it is hard to get those to block all light).
OLEDs being off just emit no light at all. So the blacks are blacker, you could go brighter at the same time,
There are some other technical details why they tend to look a little crisper.


Viewing angles are also better, ''roughly'' because the light source is closer to the surface.
===Flip-disc===


https://en.wikipedia.org/wiki/Flip-disc_display


OLED are organic LEDs, which in itself party just a practical production detail, and really just LEDs.
{{comment|(...though you can get fancy in the production process, e.g. pricy see-through displays are often OLED with substate trickery{{verify}})}}


===Other flipping types===


<!--


PMOLED versus AMOLED makes no difference to the light emission,
-->
just to the way we access them (Passive Matrix, Active Matrix).
AMOLED can can somwhat lower power, higher speed, and more options along that scale{{verify}},
all of which makes them interesting for mobile uses. It also scales better to larger monitors.


POLED (and confusingly, pOLED is a trademark) uses a polymer instead of the glass,
==LED segments==
so is less likely to break but has other potential issues


===7-segment and others===
{{stub}}
[[File:Segment displays.png|thumb|right|200px|7-segment,
9-segment display, 14-segment, and 16-segment display. If meant for numbers will be a dot next to each (also common in general), if meant for time there will be a colon in one position.]]


<!--


'''Confusion'''
These are really just separate lights that happen to be arranged in a useful shape.


Very typically LEDs (with a common cathode or anode), though similar ideas are sometimes implemented in other display types - notably the electromechanical one, and also sometimes VFD.


"Isn't LED screen the same as OLED?"


No.  
Even the simplest, 7-segment LED involves a bunch of connectors so are
Marketers will be happy if you confuse "we used a LED backlight instead of a CCFL" (which we've been doing for ''ages'')
* often driven multiplexed, so only one of them is on at a time.
with "one of those new hip crisp OLED thingies", while not technically lying,
* often done via a controller that handles that multiplexing for you<!--
so they may be fuzzy about what they mean with "LED display".
: which one depends on context, e.g. is it a BCD-style calculator, a microcontroller; what interface is more convenient for you
:: if you're the DIY type who bought a board, you may be looking at things like the MAX7219 or MAX7221, TM1637 or TM1638, HT16K33, 74HC595 (shift register), HT16K33 
-->


You'll know when you have an OLED monitor, because it will cost ten times as much - a thousand USD/EUR, more at TV sizes.
The cost-benefit for people without a bunch of disposable income isn't really there.


Seven segments are the minimal and classical case,
good enough to display numbers and so e.g. times, but not really for characters.


More-than-7-segment displays are preferred for that.


"I heard al phones use OLED now?"


Fancier, pricier ones do, yes.


Cheaper ones do not, because the display alone might cost on the order of a hundred bucks.{{verify}}
https://en.wikipedia.org/wiki/Seven-segment_display


==DIY==


===LCD character dislays===


Character displays are basically those with predefined (and occasionally rewritable) fonts.


-->


===QLED===
====Classical interface====
<!--
It's quantum, so it's buzzword compatible. How is it quantum? Who knows!


The more barebones interface is often a 16 pin line with a pinout like


It may surprise you that this is LCD-style, not OLED-style,
* Ground
but is brighter than most LCD style,


they're still working on details like decent contrast.
* Vcc


* Contrast
: usually there's a (trim)pot from Vcc, or a resistor if it's fixed


Quantum Dot LCD  https://en.wikipedia.org/wiki/Quantum_dot_display


* RS: Register Select (character or instruction)
: in instruction mode, it receives commands like 'clear display', 'move cursor',
: in character mode,


-->
* RW: Read/Write
: tied to ground is write, which is usually the only thing you do


==On image persistence / burn-in==
* ENable / clk (for writing)
<!--
CRTs continuously illuminating the same pixels would somewhat-literally cook their phosphors a little,
leading to fairly-literal image burn-in.


* 8 data lines, but you can do most things over 4 of them


Other displays will have similar effects, but it may not be ''literal'' burn in, so we're calling it image persistence or image retention now.


* backlight Vcc
* Backlight gnd


'''LCD and TFT''' have no ''literal'' burn-in, but the crystals may still settle into a preferred state.
: there is limited alleviation for this


'''Plasma''' still has burn-in.


'''OLED''' seems to as well, though it's subtler.
The minimal, write-only setup is:
* tie RW to ground
* connect RS, EN, D7, D6, D5, and D4 to digital outs




Liquid crystals (LCD, TFT, etc.) have an persisting-image effect because
====I2C and other====
of the behaviour of liquid crystals when held at the same state ''almost always''.
<!--
Basically the above wrapped in a controller you can address via I2C or SPI (and usually they then speak that older parallel interface)


You can roughly describe this as having a preferred state they won't easily relax out of -- but there are a few distinct causes, different sensitivity to this from different types of panels, and different potential fixes.
Sometimes these are entirely separate ones bolted onto the classical interface.


Also, last time I checked this wasn't ''thoroughly'' studied.




Unplugging power (/ turning it off) for hours (or days, or sometimes even seconds) may help, and may not.
For DIY, you may prefer these just because it's less wiring hassle.


A screensaver with white, or strong moving colors, or noise, may help.
-->


There are TVs that do something like this, like jostling the entire image over time, doing a blink at startup and/or periodically, or scanning a single dot with black and white (you probably won't notice).
===Matrix displays===




===(near-)monochrome===


https://en.wikipedia.org/wiki/Image_persistence


http://www.jscreenfix.com/
====SSD1306====


http://gribble.org/lcdfix/
OLED, 128x64@4 colors{{vierfy}}


{{search|statictv screensaver}}
https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf


-->
====SH1107====


==VFD==
OLED,
<gallery mode="packed" style="float:right" heights="200px">
VFD.jpg|larger segments
VFD-dots.jpg|dot matrix VFD
</gallery>


[[Vacuum Fluorescent Display]]s are vacuum tubes applied in a specific way - see [[Lightbulb_notes#VFDs]] for more details.
https://datasheetspdf.com/pdf-file/1481276/SINOWEALTH/SH1107/1


<br style="clear:both"/>
===Small LCD/TFTs / OLEDs===
{{stub}}


=Few-element=
Small as in order of an inch or two (because the controllers are designed for a limited resolution?{{verify}}).
==Lighting==


===Nixie tubes===
[[Image:Nixie2.gif|thumb|right|]]
<!--
Nixie tubes were some of the earliest outputs of computers


They have been a inefficient solution since the transistor or so.
{{zzz|Note that, like with monitors, marketers really don't mind if you confuse LED-backlit LCD with OLED,
and some of the ebays and aliexpresses sellers of the world will happily 'accidentally'
call any small screen OLED if it means they sell more.


But they're still pretty.
This is further made more confusing by the fact that there are
* few-color OLEDs (2 to 8 colors or so, great for high contrast but ''only'' high cotnrast),
* [[high color]] OLEDs (65K),
...so you sometimes need to dig into the tech specs to see the difference between high color LCD and high color OLED.
}}


[[Lightbulb_notes#Nixie_tubes]]
<!--
[[Image:OLED.jpg|thumb|300px|right|Monochrome OLED]]
[[Image:OLED.jpg|thumb|300px|right|High color OLED]]
[[Image:Not OLED.jpg|thumb|400px|right|Not OLED (clearly backlit)]]
-->
-->
<br style="clear:both">




===Eggcrate display===
When all pixels are off they give zero light pollution (unlike most LCDs) which might be nice in the dark.
These seem to appear in smaller sizes than small LCDs, so are great as compact indicators.


<!--
An eggcrate display is a number of often-incandescent, often-smallish lighbulbs in a grid (often 5 by 7),
named for the pattern of round cutouts


'''Can it do video or not?'''


These were bright, and primarily used in gameshows, presumably because they would show up fine even in bright studio lighting.
If it ''does'' speak e.g. MIPI it's basically just a monitor, probably capable of decent-speed updates, but also the things you ''can'' connect to will (on the scale of microcontroller to mini-PC) be moderately powerful, e.g. a raspberry.
Note that when showing $0123456789, not all bulbs positions are necessary.


But the list below don't connect PC video cables.


-->
Still, they have their own controller, and can hold their pixel state one way or the other, but connect something more command-like - so you can update a moderate amount of pixels with via an interface that is much less speedy or complex.


==Mechanical==
You might get reasonable results over SPI / I2C for a lot of e.g. basic interfaces and guages.
By the time you try to display video you have to think about your design more.


===Mechanical counter===
For a large part because amount of pixels to update times the rate of frames per second has to fit through the communication (...also the display's capabilities).
There is a semi-standard parallel interface that might make video-speed things feasible.
This interface is faster than the SPI/I2C option, though not always ''that'' much, depending on hardware details.


https://en.wikipedia.org/wiki/Mechanical_counter


Even if the specs of the screen can do it in theory, you also have to have the video ready to send.
If you're running it from an RP2040 or ESP32, don't expect to libav/ffmpeg.


Say, something like the {{imagesearch|tinycircuits tinytv|TinyTV}} runs a 216x135 65Kcolor display from a from a [[RP2040]].


===Split-flap===
Also note that such hardware won't be doing decoding and rescaling arbitrary video files.
[[Image:Split-flap diagram.png|thumb|right]]
They will use specifically pre-converted video.
<!--


If you're over thirty or so, you'll have seen these at airports. There's a few remaining now, but only a few.


They're somehow satisfying to many, and that rustling sound is actually nice feedback on when you may want to look at the board again.
In your choices, also consider libraries.
Things like [https://github.com/Bodmer/TFT_eSPI TFT_eSPI] has a compatibility list you will care about.




They are entirely mechanical, and only need to be moderately precise -- well, assuming they only need ~36 or so characters.




https://www.youtube.com/watch?v=UAQJJAQSg_g
====Interfaces====
{{stub}}


<!--
* 4-line SPI
* 3-line SPI ([[half duplex]], basically)
* I2C
* 6800-series parallel
* 8080-series parallel interface


-->
https://en.wikipedia.org/wiki/Split-flap_display
<br style="clear:both"/>


The last two are 8-bit parallel interfaces. ''In theory'' these can be multiples faster,
though notice that in some practice you are instead limited by the display's controller,
your own ability to speak out data that fast, and the difference may not even be twice
(and note that [[bit-banging]] that parallel may take a lot more CPU than dedicated SPI would).


The numbers aren't about capability, they seem to purely references then Intel versus Motorola origins of their specs{{verify}})
They are apparently very similar - the main differences being the read/write and enable, and in some timing.
: If they support both, 8080 seems preferable, in part because some only support that?{{verify}}


===Vane display===


There are others that aren't quite ''generic'' high speed moniutor interfaces yet,
but too fast for slower hardware (e.g. CSI, MDDI)


===Flip-disc===
https://forum.arduino.cc/t/is-arduino-6800-series-or-8080-series/201241/2


https://en.wikipedia.org/wiki/Flip-disc_display
-->


====ST7735====


===Other flipping types===
LCD, 132x162@16bits RGB


<!--
<!--
* SPI interface (or parallel)


-->
* 396 source line (so 132*RGB) and 162 gate line
* display data RAM of 132 x 162 x 18 bits
 
* 2.7~3.3V {{verify}}


==LED segments==


===7-segment and others===
Boards that expose SPI will have roughly:
{{stub}}
: GND: power supply
[[File:Segment displays.png|thumb|right|200px|7-segment,
: VCC: 3.3V-5.0V
9-segment display, 14-segment, and 16-segment display. If meant for numbers will be a dot next to each (also common in general), if meant for time there will be a colon in one position.]]


: SCL: SPI clock line
: SDA: SPI data line


These are really just separate lights that happen to be arranged in a useful shape.
: RES: reset


Very typically LEDs (with a common cathode or anode), though similar ideas are sometimes implemented in other display types - notably the electromechanical one, and also sometimes VFD.
: D/C: data/command selection
: CS: chip Selection interface


: BLK: backlight control (often can be left floating, presumably pulled up/down)


Even the simplest, 7-segment LED involves a bunch of connectors so are
* often driven multiplexed, so only one of them is on at a time.
* often done via a controller that handles that multiplexing for you<!--
: which one depends on context, e.g. is it a BCD-style calculator, a microcontroller; what interface is more convenient for you
:: if you're the DIY type who bought a board, you may be looking at things like the MAX7219 or MAX7221, TM1637 or TM1638, HT16K33, 74HC595 (shift register), HT16K33 
-->


Lua / NodeMCU:
* [https://nodemcu.readthedocs.io/en/release/modules/ucg/ ucg]
* [https://nodemcu.readthedocs.io/en/release/modules/u8g2/ u8g2]
* https://github.com/AoiSaya/FlashAir-SlibST7735


Seven segments are the minimal and classical case,
good enough to display numbers and so e.g. times, but not really for characters.


More-than-7-segment displays are preferred for that.
Arduino libraries
* https://github.com/adafruit/Adafruit-ST7735-Library
* https://github.com/adafruit/Adafruit-GFX-Library


These libraries may hardcode some of the pins (particularly the SPI ones),
and this will vary between libraries.




https://en.wikipedia.org/wiki/Seven-segment_display


==DIY==
'''ucg notes'''


===LCD character dislays===


Character displays are basically those with predefined (and occasionally rewritable) fonts.
Fonts that exist:    https://github.com/marcelstoer/nodemcu-custom-build/issues/22
fonts that you have:  for k,v in pairs(ucg) do print(k,v) end




====Classical interface====
http://blog.unixbigot.id.au/2016/09/using-st7735-lcd-screen-with-nodemcu.html


The more barebones interface is often a 16 pin line with a pinout like
-->


* Ground
====ST7789====


* Vcc
LCD, 240x320@16bits RGB


* Contrast
https://www.waveshare.com/w/upload/a/ae/ST7789_Datasheet.pdf
: usually there's a (trim)pot from Vcc, or a resistor if it's fixed


====SSD1331====


* RS: Register Select (character or instruction)
OLED, 96x 64, 16bits RGB
: in instruction mode, it receives commands like 'clear display', 'move cursor',
: in character mode,  


* RW: Read/Write
https://cdn-shop.adafruit.com/datasheets/SSD1331_1.2.pdf
: tied to ground is write, which is usually the only thing you do


* ENable / clk (for writing)


* 8 data lines, but you can do most things over 4 of them
====SSD1309====


OLED, 128 x 64, single color?


* backlight Vcc
https://www.hpinfotech.ro/SSD1309.pdf
* Backlight gnd


====SSD1351====


OLED, 65K color


The minimal, write-only setup is:
https://newhavendisplay.com/content/app_notes/SSD1351.pdf
* tie RW to ground
* connect RS, EN, D7, D6, D5, and D4 to digital outs


 
====HX8352C====
====I2C and other====
LCD
<!--
<!--
Basically the above wrapped in a controller you can address via I2C or SPI (and usually they then speak that older parallel interface)  
240(RGB)x480, 16-bit
-->
https://www.ramtex.dk/display-controller-driver/rgb/hx8352.htm


Sometimes these are entirely separate ones bolted onto the classical interface.




====HX8357C====


For DIY, you may prefer these just because it's less wiring hassle.
====R61581====


<!--
240x320
-->
-->


===Matrix displays===
====ILI9163====
LCD, 162x132@16-bit RGB


http://www.hpinfotech.ro/ILI9163.pdf


===(near-)monochrome===
====ILI9341====


<!--
240RGBx320, 16-bit
-->
https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf


====SSD1306====
====ILI9486====
 
LCD, 480x320@16-bit RGB
OLED, 128x64@4 colors{{vierfy}}


https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf
https://www.hpinfotech.ro/ILI9486.pdf


====SH1107====
====ILI9488====
LCD
<!--
320(RGB) x 480
-->


OLED,
https://www.hpinfotech.ro/ILI9488.pdf


https://datasheetspdf.com/pdf-file/1481276/SINOWEALTH/SH1107/1
====PCF8833====
LCD, 132×132 16-bit RGB


===Small LCD/TFTs / OLEDs===
https://www.olimex.com/Products/Modules/LCD/MOD-LCD6610/resources/PCF8833.pdf
{{stub}}


Small as in order of an inch or two (because the controllers are designed for a limited resolution?{{verify}}).
====SEPS225====
LCD


https://vfdclock.jimdofree.com/app/download/7279155568/SEPS225.pdf


{{zzz|Note that, like with monitors, marketers really don't mind if you confuse backlit LCD with OLED,
and some of the ebays and aliexpresses sellers of the world will happily 'accidentally'
call any small screen OLED if it means they sell more.
This is further made more confusing by the fact that there are
* few-color OLEDs (2 to 8 colors or so, great for high contrast but ''only'' high cotnrast),
* [[high color]] OLEDs (65K),
...so you sometimes need to dig into the tech specs to see the difference between high color LCD and high color OLED.
}}


====RM68140====
LCD
<!--
<!--
[[Image:OLED.jpg|thumb|300px|right|Monochrome OLED]]
320 RGB x 480
[[Image:OLED.jpg|thumb|300px|right|High color OLED]]
[[Image:Not OLED.jpg|thumb|400px|right|Not OLED (clearly backlit)]]
-->
-->


https://www.melt.com.ru/docs/RM68140_datasheet_V0.3_20120605.pdf


When all pixels are off they give zero light pollution (unlike most LCDs) which might be nice in the dark.
====GC9A01====
These seem to appear in smaller sizes than small LCDs, so are great as compact indicators.


LCD, 65K colors, SPI


'''Can it do video or not?'''
Seem to often be used on round displays{{verify}}


If it ''does'' speak e.g. MIPI it's basically just a monitor, probably capable of decent-speed updates, but also the things you ''can'' connect to will (on the scale of microcontroller to mini-PC) be moderately powerful, e.g. a raspberry.
https://www.buydisplay.com/download/ic/GC9A01A.pdf


But the list below don't connect PC video cables.
[[Category:Computer‏‎]]
[[Category:Hardware]]


Still, they have their own controller, and can hold their pixel state one way or the other, but connect something more command-like - so you can update a moderate amount of pixels with via an interface that is much less speedy or complex.
===Epaper===


You might get reasonable results over SPI / I2C for a lot of e.g. basic interfaces and guages.
====SSD1619====
By the time you try to display video you have to think about your design more.


For a large part because amount of pixels to update times the rate of frames per second has to fit through the communication (...also the display's capabilities).
https://cursedhardware.github.io/epd-driver-ic/SSD1619A.pdf
There is a semi-standard parallel interface that might make video-speed things feasible.
This interface is faster than the SPI/I2C option, though not always ''that'' much, depending on hardware details.


<!--
====UC8151====


Even if the specs of the screen can do it in theory, you also have to have the video ready to send.  
https://www.orientdisplay.com/wp-content/uploads/2022/09/UC8151C.pdf
If you're running it from an RP2040 or ESP32, don't expect to libav/ffmpeg.


Say, something like the {{imagesearch|tinycircuits tinytv|TinyTV}} runs a 216x135 65Kcolor display from a from a [[RP2040]].


Also note that such hardware won't be doing decoding and rescaling arbitrary video files.
-->
They will use specifically pre-converted video.
 
=Many-element - TV and monitor notes (and a little film)=
==Backlit flat-panel displays==
<!--


We may call them LCD, but that was an early generation
LCD and TFT and various other acronyms are all the same idea, with different refinements on how the pixels work exactly.


In your choices, also consider libraries.
There are roughly two parts of such monitors you can care about: How the backlight works, and how the pixels work.
Things like [https://github.com/Bodmer/TFT_eSPI TFT_eSPI] has a compatibility list you will care about.




But almost all of them come down to
* pixels will block light, or less so.
* put a bright lights behind those
: in practice, they are on the side, and there is some trickery to try to reflect that as uniformly as possible




====Interfaces====
There are a lot of acronyms pointing tou
{{stub}}
: TN and IPS is more about the crystals (and you mostly care about that if you care about viewing angle),
: TFT is more about the electronics, but the two aren't really separable,
: and then there are a lot of experiments (with their own acronyms) that


<!--
https://en.wikipedia.org/wiki/TFT_LCD
* 4-line SPI
* 3-line SPI ([[half duplex]], basically)
* I2C
* 6800-series parallel
* 8080-series parallel interface


TFT, UFB, TFD, STN


The last two are 8-bit parallel interfaces. ''In theory'' these can be multiples faster,
though notice that in some practice you are instead limited by the display's controller,
your own ability to speak out data that fast, and the difference may not even be twice
(and note that [[bit-banging]] that parallel may take a lot more CPU than dedicated SPI would).


The numbers aren't about capability, they seem to purely references then Intel versus Motorola origins of their specs{{verify}})
-->
They are apparently very similar - the main differences being the read/write and enable, and in some timing.
: If they support both, 8080 seems preferable, in part because some only support that?{{verify}}


===CCFL or LED backlight===


There are others that aren't quite ''generic'' high speed moniutor interfaces yet,
<!--
but too fast for slower hardware (e.g. CSI, MDDI)
Both refer to a global backlight.  
It's only things like OLED and QLED that do without.


https://forum.arduino.cc/t/is-arduino-6800-series-or-8080-series/201241/2


-->
CCFLs, Cold-Cathode Fluorescnt Lamps, are a variant of [[fluorescent lighting]] that (surprise) runs a lot colder than some other designs.


====ST7735====
CCFL backlights tend to pulse at 100+ Hz{{verify}}, though because they necessarily use phosphors, and those can easily made to be slow, it may be a ''relatively'' steady pulsing.


LCD, 132x162@16bits RGB
They are also high voltage devices.


<!--
* SPI interface (or parallel)


* 396 source line (so 132*RGB) and 162 gate line
LED backlights are often either
* display data RAM of 132 x 162 x 18 bits
* [[PWM]]'d at kHz speeds{{verify}},
* current-limited{{verify}}, which are both smoother.


* 2.7~3.3V {{verify}}




Boards that expose SPI will have roughly:
-->
: GND: power supply
: VCC: 3.3V-5.0V


: SCL: SPI clock line
https://nl.wikipedia.org/wiki/CCFL
: SDA: SPI data line


: RES: reset
==Self-lit==


: D/C: data/command selection
===OLED===
: CS: chip Selection interface
{{stub}}


: BLK: backlight control (often can be left floating, presumably pulled up/down)
While OLED is also a thing in lighting, OLED ''usually'' comes up in the context of OLED displays.


It is mainly contrasted with backlit displays (because it is hard to get those to block all light).
OLEDs being off just emit no light at all. So the blacks are blacker, you could go brighter at the same time,
There are some other technical details why they tend to look a little crisper.


Lua / NodeMCU:
Viewing angles are also better, ''roughly'' because the light source is closer to the surface.
* [https://nodemcu.readthedocs.io/en/release/modules/ucg/ ucg]
* [https://nodemcu.readthedocs.io/en/release/modules/u8g2/ u8g2]
* https://github.com/AoiSaya/FlashAir-SlibST7735




Arduino libraries
OLED are organic LEDs, which in itself party just a practical production detail, and really just LEDs.
* https://github.com/adafruit/Adafruit-ST7735-Library
{{comment|(...though you can get fancy in the production process, e.g. pricy see-through displays are often OLED with substate trickery{{verify}})}}
* https://github.com/adafruit/Adafruit-GFX-Library


These libraries may hardcode some of the pins (particularly the SPI ones),
and this will vary between libraries.




PMOLED versus AMOLED makes no difference to the light emission,
just to the way we access them (Passive Matrix, Active Matrix).
AMOLED can can somwhat lower power, higher speed, and more options along that scale{{verify}},
all of which makes them interesting for mobile uses. It also scales better to larger monitors.


'''ucg notes'''
POLED (and confusingly, pOLED is a trademark) uses a polymer instead of the glass,
so is less likely to break but has other potential issues




Fonts that exist:    https://github.com/marcelstoer/nodemcu-custom-build/issues/22
<!--
fonts that you have:  for k,v in pairs(ucg) do print(k,v) end


'''Confusion'''


http://blog.unixbigot.id.au/2016/09/using-st7735-lcd-screen-with-nodemcu.html


-->
"Isn't LED screen the same as OLED?"


====ST7789====
No.
Marketers will be happy if you confuse "we used a LED backlight instead of a CCFL" (which we've been doing for ''ages'')
with "one of those new hip crisp OLED thingies", while not technically lying,
so they may be fuzzy about what they mean with "LED display".


LCD, 240x320@16bits RGB
You'll know when you have an OLED monitor, because it will cost ten times as much - a thousand USD/EUR, more at TV sizes.
The cost-benefit for people without a bunch of disposable income isn't really there.


https://www.waveshare.com/w/upload/a/ae/ST7789_Datasheet.pdf


====SSD1331====


OLED, 96x 64, 16bits RGB
"I heard al phones use OLED now?"


https://cdn-shop.adafruit.com/datasheets/SSD1331_1.2.pdf
Fancier, pricier ones do, yes.


Cheaper ones do not, because the display alone might cost on the order of a hundred bucks.{{verify}}


====SSD1309====


OLED, 128 x 64, single color?


https://www.hpinfotech.ro/SSD1309.pdf


====SSD1351====
-->


OLED, 65K color
===QLED===
<!--
It's quantum, so it's buzzword compatible. How is it quantum? Who knows!


https://newhavendisplay.com/content/app_notes/SSD1351.pdf


====HX8352C====
It may surprise you that this is LCD-style, not OLED-style,
LCD  
but is brighter than most LCD style,
<!--
240(RGB)x480, 16-bit
-->
https://www.ramtex.dk/display-controller-driver/rgb/hx8352.htm


they're still working on details like decent contrast.




====HX8357C====
Quantum Dot LCD  https://en.wikipedia.org/wiki/Quantum_dot_display


====R61581====


<!--
240x320
-->
-->


====ILI9163====
==On image persistence / burn-in==
LCD, 162x132@16-bit RGB
<!--
CRTs continuously illuminating the same pixels would somewhat-literally cook their phosphors a little,
leading to fairly-literal image burn-in.


http://www.hpinfotech.ro/ILI9163.pdf


====ILI9341====
Other displays will have similar effects, but it may not be ''literal'' burn in, so we're calling it image persistence or image retention now.


<!--
240RGBx320, 16-bit
-->
https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf


====ILI9486====
'''LCD and TFT''' have no ''literal'' burn-in, but the crystals may still settle into a preferred state.
LCD, 480x320@16-bit RGB
: there is limited alleviation for this


https://www.hpinfotech.ro/ILI9486.pdf
'''Plasma''' still has burn-in.


====ILI9488====
'''OLED''' seems to as well, though it's subtler.
LCD
<!--
320(RGB) x 480
-->


https://www.hpinfotech.ro/ILI9488.pdf


====PCF8833====
Liquid crystals (LCD, TFT, etc.) have an persisting-image effect because
LCD, 132×132 16-bit RGB
of the behaviour of liquid crystals when held at the same state ''almost always''.


https://www.olimex.com/Products/Modules/LCD/MOD-LCD6610/resources/PCF8833.pdf
You can roughly describe this as having a preferred state they won't easily relax out of -- but there are a few distinct causes, different sensitivity to this from different types of panels, and different potential fixes.


====SEPS225====
Also, last time I checked this wasn't ''thoroughly'' studied.
LCD


https://vfdclock.jimdofree.com/app/download/7279155568/SEPS225.pdf


Unplugging power (/ turning it off) for hours (or days, or sometimes even seconds) may help, and may not.


====RM68140====
A screensaver with white, or strong moving colors, or noise, may help.
LCD
<!--
320 RGB x 480
-->


https://www.melt.com.ru/docs/RM68140_datasheet_V0.3_20120605.pdf
There are TVs that do something like this, like jostling the entire image over time, doing a blink at startup and/or periodically, or scanning a single dot with black and white (you probably won't notice).


====GC9A01 (round)====


LCD, 65K colors, SPI


https://www.buydisplay.com/download/ic/GC9A01A.pdf
https://en.wikipedia.org/wiki/Image_persistence
 
http://www.jscreenfix.com/
 
http://gribble.org/lcdfix/
 
{{search|statictv screensaver}}
 
-->
 
==VFD==
<gallery mode="packed" style="float:right" heights="200px">
VFD.jpg|larger segments
VFD-dots.jpg|dot matrix VFD
</gallery>
 
[[Vacuum Fluorescent Display]]s are vacuum tubes applied in a specific way - see [[Lightbulb_notes#VFDs]] for more details.
 
<br style="clear:both"/>
 


[[Category:Computer‏‎]]
[[Category:Hardware]]


=TV and monitor notes (and a little film)=
<!--
<!--
==Capabilities==
==Capabilities==
Line 667: Line 684:


-->
-->
==On reproduction==
==Some theory - on reproduction==


====Reproduction that flashes====
====Reproduction that flashes====
Line 675: Line 692:
'''Mechanical film projectors''' flash individual film frames while that film is being held entirely still, before advancing that film to the next (while no light is coming out) and repeating.
'''Mechanical film projectors''' flash individual film frames while that film is being held entirely still, before advancing that film to the next (while no light is coming out) and repeating.


{{comment|(see e.g. [https://www.youtube.com/watch?v%3dCsounOrVR7Q this] and note that it moves so quickly that you see ''that'' the film is taken it happens so quickly that you don't even see it move.  Separately, if you slow playback you can also see that it flashes ''twice'' before it advances the film - we'll get to why)}}
(see e.g. [https://www.youtube.com/watch?v%3dCsounOrVR7Q this] and note that it moves so quickly that you see ''that'' the film is taken it happens so quickly that you don't even see it move.  Separately, if you slow playback you can also see that it flashes ''twice'' before it advances the film - we'll get to why)


This requires a shutter, i.e. not letting through ''any'' light a moderate part of the time (specifically while it's advancing the film).
We are counting on our eyes to sort of ignore that.


This requires a shutter, i.e. not letting through any light a moderate part of the time (specifically while it's advancing the film).
We are counting on our eyes to sort of ignore that.


One significant design concept very relevant to this type of reproduction is the '''flicker fusion threshold'''[https://en.wikipedia.org/wiki/Flicker_fusion_threshold], the "frequency at which intermittent light stimulus appears to be steady light" to our eyes.
One significant design concept very relevant to this type of reproduction is the [https://en.wikipedia.org/wiki/Flicker_fusion_threshold '''flicker fusion threshold'''], the "frequency at which intermittent light stimulus appears to be steady light" to our eyes because separately from actual image it's showing, it appearing smooth is, you know, nice.


Research shows that this varies somewhat with conditions, but in most conditions practical around showing people images, that's somewhere between 50Hz and 90Hz.
Research shows that this varies somewhat with conditions, but in most conditions practical around showing people images, that's somewhere between 50Hz and 90Hz.




Since people are sensitive to flicker, some more than than others, and this can lead to eyestain and headaches,  
Since people are sensitive to flicker to varying degrees, and this can lead to eyestain and headaches,  
we aim towards the high end of that range - whenever that's not hard to do.
we aim towards the high end of that range whenever that is not hard to do.


In fact, while film is 24fps and was initially shown at 24Hz flashes, movie projectors soon introduced two-blade and then three-blade shutters, showing each image two or three times before advancing, meaning that while they still only show 24 distinct images per second, they flash it twice or three times for a ''regular'' 48Hz or 72Hz flicker, for a lot less eyestrain.
In fact, we did so even with film. While film is 24fps and was initially shown at 24Hz flashes, movie projectors soon introduced two-blade and then three-blade shutters, showing each image two or three times before advancing, meaning that while they still only show 24 distinct images per second, they flash it twice or three times for a ''regular'' 48Hz or 72Hz flicker.
No more detail, but a bunch less eyestrain.






An arguably even more basic constraint to moving pictures is the point at which rate of images we accept animation as '''fluid movement'''.  
As to what is actually being show, an arguably even more basic constraint is the rate of new images that we accept as '''fluid movement'''.  
: Anything under 10fps looks jerky and stilted or at least like a ''choice'' (western and eastern animation were rarely higher than 12, or 8 or 6 for the simpler ones),
: Anything under 10fps looks jerky and stilted
:: or at least like a ''choice''.
:: western ''and'' eastern animations were rarely higher than 12, or 8 or 6 for the simpler/cheaper ones
: around 20fps we start readily accepting it as continuous movement,  
: around 20fps we start readily accepting it as continuous movement,  
: above 30 or 40fps it looks smooth,
: above 30 or 40fps it looks smooth,
: and above that it keeps on looking a little better ''yet'' also becomes quickly diminishing returns.
: and above that it keeps on looking a little better yet, with quickly diminishing returns




Early movies on film were approximately 24fps, some faster, various slower.
The number 24 was a chosen balance between barious things, like the fact that that's enough for fluid movement and relatively few scenes need higher,
and the fact that film stock is expensive, and a standard for projection (adaptable or even multiple projectors would be too expensive for most cinemas).




The reason we ''still'' use 24fps it now is more varied and doesn't really have a one-sentence answer.
'''So why 24?'''


But part of it is that making movies go faster is only sometimes well received.  
Film's 24 was not universal at the time, and has no strong significance then or now.
It's just that when a standard was needed, the number 24 was a chosen balance between various aspects, like the fact that that's enough for fluid movement and relatively few scenes need higher, and the fact that film stock is expensive, and a standard for projection (adaptable or even multiple projectors would be too expensive for most cinemas).
 
 
The reason we ''still'' use 24fps ''today'' is more faceted, and doesn't really have a one-sentence answer.
 
But part of it is that making movies go faster is not always well received.  


It seems that we associated 24fps to feels like movies, 50/60fps feels like shaky-cam home movies made by dad's camcorder (when those were still a thing) or sports broadcasts (which we did even though it reduced detail) with their tense, immediate, real-world associations.
It seems that we associated 24fps to feels like movies, 50/60fps feels like shaky-cam home movies made by dad's camcorder (when those were still a thing) or sports broadcasts (which we did even though it reduced detail) with their tense, immediate, real-world associations.
Line 717: Line 740:


<!--
<!--
 
'''when more both is and isn't better'''
 
'''when more is and isn't better'''


And you can argue that cinematic language evolved not only with the technical limitations, but also the limitations of how much new information you can show at all.
And you can argue that cinematic language evolved not only with the technical limitations, but also the limitations of how much new information you can show at all.
Line 746: Line 767:
CRT monitors do something ''vaguely'' similar to movie projectors, in that they light up an image so-many times a second.
CRT monitors do something ''vaguely'' similar to movie projectors, in that they light up an image so-many times a second.


Where with film you spend a least some of the time with the entire image being lit up continuously (and some time with the shutter coming in and out).
 
with a CRT there is a constantly-flowing beam of electrons lighting whatever phosphor it hits,
Where with film you light up the entire thing at once {{comment|(maybe with some time with the shutter coming in and out, ignore that for now)}}.
and that beam that is being dragged line-by-line along the screen - look at [https://youtu.be/3BJU2drrtCM?t=137 slow motion footage like this].
a CRT light up one spot at a time - there is a beam constantly being dragged line by line across the screen -- look at [https://youtu.be/3BJU2drrtCM?t=137 slow motion footage like this].


The phosphor will have a softish onset and retain light for some while,
The phosphor will have a softish onset and retain light for some while,
Line 780: Line 801:
{{stub}}
{{stub}}


Film projectors and CRTs don't matter directly to the discussion of 'what rate do you need',
Flatscreens do not reproduce by blinking things at us.
because the flatscreens that most of us use do not flicker like that {{comment|(except some do, and ''intentionally so'', but we'll put that aside)}}.


While in film, and in CRTs, the mechanism that lights it up and the mechanism that shows the image is the same mechanism, so inseparable,
While in film, and in CRTs, the mechanism that lights up the screen is the is the same mechanism as the one that shows you the image,
in LCD-style flatscreens (including QLED) they are separate - there is a global CCFL or LED backlight, and the pixels are light ''blockers''.
in LCD-style flatscreens, the image updates and the lighting are now different mechanisms.
{{comment|(In QLED there are the same again, though with some new footnotes)}}


Basically, there's one overall light behind the pixely part of the screen, and each screen pixel blocks light.


And global backlights tend to be lit fairly continuously.
There is still variation in backlights, mind, and some will still give you a little more eye strain than others.


When a backlight is CCFL, its phosphors are intentionally be made to decay slowly so even if the panel is a mere 100Hz,
That global backlights tends to be lit ''fairly'' continuously.
that CCFL would look much less blinky than e.g. CRT at 100Hz.
Sure there is variation in backlights, and some will still give you a little more eye strain than others.
 
CCFL backlight phosphors seem intentionally made to decay slowly,
so even if the panel is a mere 100Hz, that CCFL ''ought'' to look look much less blinky than e.g. CRT at 100Hz.
 


LED backlights are often [[PWM]]'d at kHz speeds{{verify}}, or current-limited{{verify}}, which are both smoother.
LED backlights are often [[PWM]]'d at kHz speeds{{verify}}, or current-limited{{verify}}, which are both smoother.
If you take a high speed camera, you may still not see it flicker [https://youtu.be/3BJU2drrtCM?t=267 this part of the same slow motion video] {{comment|(note how the backlight appears constant even when the pixel update is crawling by)}} until you get really fast and specific.
If you take a high speed camera, you may still not see it flicker [https://youtu.be/3BJU2drrtCM?t=267 this part of the same slow motion video] {{comment|(note how the backlight appears constant even when the pixel update is crawling by)}} until you get really fast and specific.




So the difference between, say, a 60fps and 240fps monitor isn't in the lighting, it's how fast the light-blocking pixels in front of that constant backlight change.
So the difference between, say, a 60fps and 240fps monitor isn't in the lighting, it's how fast the light-blocking pixels in front of that constant backlight change.
A 60fps monitor changes its pixels every 16ms (1/60 sec), a 240fps the latter every 4ms (1/240 sec).
A 60fps monitor changes its pixels every 16ms (1/60 sec), a 240fps the latter every 4ms (1/240 sec). The light just stays on.
 


A CRT at 30Hz would look very blinky and be hard on the eyes. A flatscreen at 30fps updates looks choppy but the lighting would be constant.
As such, while a cRT at 30Hz would look very blinky and be hard on the eyes,
a flatscreen at 30fps updates looks choppy but not like a blinky eyestrain.


So in one way, it's more about the fps, but at the same time, the Hz rating usually ''is'' its physical fps.


<!--
<!--
Line 935: Line 957:




'''Would it be technically possible to update all this-many million pixels at the same time? '''
'''Would it not be technically possible to update all this-many million pixels at the same time? '''


In theory yes, but even if that didn't imply an insane amount of wires (it does), it may not be worth it.
In theory yes, but even if that didn't imply an insane amount of wires (it does), it may not be worth it.


Transferring millions of numbers takes time, meaning that to update everything at once you need to wait until you've stored all of it,
Transferring millions of numbers takes time, meaning that to update everything at once you need to wait until you've stored all of it,
and you've gained nothing in terms of speed. You're arguably losing speed because instead of updating lines as the data comes in, you're choosing to wait until you have it all.
and you've gained nothing in terms of speed.
 
You're arguably losing speed because instead of updating lines as the data comes in, you're choosing to wait until you have it all.


You would also need to get communication that can go much much faster (and sits idle most of the time).
You would also need to get communication that can go so much faster that it moves a frame multiples faster and sits idle most of the time.
 
That too is possible - but would only drive up cost.




Line 1,153: Line 1,179:
-->
-->


====What Vsync adds====
====Vsync====


<!--
<!--
What vsync adds




Line 1,386: Line 1,414:
And a game will have a bunch of, well, game logic, and often physics that needs to be calculated before we're down to purely ''visual'' calculations.
And a game will have a bunch of, well, game logic, and often physics that needs to be calculated before we're down to purely ''visual'' calculations.


Point is that with that involved, you can now also be CPU-limited. Maybe the GPU can ''draw'' what it gets at 200fps but the CPU can only figure out new things to draw at around 40fps. Which means a mix of 60 and 30fps as just mentioned. And your GPU won't get very warm because it's idling most of the time.  
Point is that with that involved, you can now also be CPU-limited. Maybe the GPU can ''draw'' what it gets at 200fps but the CPU can only figure out new things to draw at around 40fps. Which means a mix of 60 and 30fps as just mentioned. And your GPU won't get very warm because it's idling most of the time.  
Games try to avoid this, but [some people take that as a challenge].
Games try to avoid this, but [some people take that as a challenge].
 
 
 
 
 
 
-->
-->
 
 
====Adaptive sync====
====Adaptive sync====
<!--
<!--
 
{{stub}}
Where most monitors keep a regular schedule (and set it themselves).
 
 
For context, most monitors keep a regular schedule (and set it themselves{{verify}}).
Nvidia G-sync and AMD Freesync treats frame length them as varying.
 
 
Nvidia G-sync and AMD Freesync treats frame length them as varying.
 
 
Note that doing this requires both a GPU and monitor that support this.  
 
Basically, the GPU sending a new frame will make the monitor start updating it as it comes in,
rather than on the next planned interval.
 
 
Manufacturer marketing as well as reviewers seem very willing to imply
: vague "increases input lag dramatically" and the way they say it is often just ''wrong'', or
: "do you want to solve tearing ''without'' the framerate cap that vsync implies" and it's a pity that's pointing out the ''wrong'' issue about vsync,
: "G-Sync has better quality than FreeSync", whatever that means
 
A more honest way of putting it might be
"when frames come in slower than the monitor's maximum,
we go to the actual render rate, without tearing"
 
...rather than the integer-division ''below'' the actual render rate (if you have vsync on)
or sort of the actual render rate but with tearing (with vsync on).
 
There's absolutely value to that, but dramatic? Not very.
 
 
 
Note that doing this requires both a GPU and monitor that support this.  
 
Which so far, for monitors, is a gamer niche.
 
 
And the two mentioned buzzwords are not compatible with each other.
 
For some reason, most articles don't get much further than
"yeah G-sync is fancier and more expensive and freesync is cheaper and good enough (unless you fall under 30fps which you want to avoid anyway)"
 
...and tend to skip ''why'' (possibly related that the explanation behind stuttering is often a confused ''mess'').
 
 
 
Note that while it can show frames as soon as your GPU has them, it doesn't go beyond a maximum rate.
So that Hz rate is essentially its ''maximum'', and it will frequently go slower.
 
It seems to mean that the PC can instruct the monitor to start a new frame whenever it wants.
The monitor's refresh rate is now effectively the ''maximum''.
 
 
This in particular avoids the 'unnecessary further drop when frames come in slower than the monitor refresh rate'


Which so far is a gamer niche.
And the two mentioned buzzwords are not compatible with each other,
but for some reason, most articles don't get much further than
"yeah G-sync is fancier and more expensive and freesync is cheaper and good enough (unless you fall under 30fps which you want to avoid anyway)" and tend to completely forego ''why'' (possibly related that the explanation behind stuttering is often a confused ''mess'').
G-sync and freesync are neat ''but'' the marketing and the typical complete lack of explanation is suspect.
Producers and reviewers seem very willing to imply
: vague "increases input lag dramatically" which is so vague that it's basically just ''wrong'', or
: "do you want to solve tearing ''without'' the framerate cap that vsync implies" and it's a pity that's pointing out the ''wrong'' issue about vsync,
: "G-Sync has better quality than FreeSync", whatever that means
Note that this also implies such a monitor's Hz rate is now a maximum, so it can show frames as soon as your GPU has them.
It seems to mean that the PC can instruct the monitor to start a new frame whenever it wants.
The monitor's refresh rate is now effectively the ''maximum''.
This in particular avoids the 'unnecessary further drop when frames come in slower than the monitor refresh rate'




Line 2,163: Line 2,211:


[[Visuals_DIY#Analog_video_notes]]
[[Visuals_DIY#Analog_video_notes]]


==Monitor mounts==
==Monitor mounts==

Latest revision as of 00:48, 29 April 2024

Few-element

Lighting

Nixie tubes



Eggcrate display

Mechanical

Mechanical counter

https://en.wikipedia.org/wiki/Mechanical_counter


Split-flap

https://en.wikipedia.org/wiki/Split-flap_display


Vane display

Flip-disc

https://en.wikipedia.org/wiki/Flip-disc_display


Other flipping types

LED segments

7-segment and others

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.
7-segment, 9-segment display, 14-segment, and 16-segment display. If meant for numbers will be a dot next to each (also common in general), if meant for time there will be a colon in one position.


These are really just separate lights that happen to be arranged in a useful shape.

Very typically LEDs (with a common cathode or anode), though similar ideas are sometimes implemented in other display types - notably the electromechanical one, and also sometimes VFD.


Even the simplest, 7-segment LED involves a bunch of connectors so are

  • often driven multiplexed, so only one of them is on at a time.
  • often done via a controller that handles that multiplexing for you


Seven segments are the minimal and classical case, good enough to display numbers and so e.g. times, but not really for characters.

More-than-7-segment displays are preferred for that.


https://en.wikipedia.org/wiki/Seven-segment_display

DIY

LCD character dislays

Character displays are basically those with predefined (and occasionally rewritable) fonts.


Classical interface

The more barebones interface is often a 16 pin line with a pinout like

  • Ground
  • Vcc
  • Contrast
usually there's a (trim)pot from Vcc, or a resistor if it's fixed


  • RS: Register Select (character or instruction)
in instruction mode, it receives commands like 'clear display', 'move cursor',
in character mode,
  • RW: Read/Write
tied to ground is write, which is usually the only thing you do
  • ENable / clk (for writing)
  • 8 data lines, but you can do most things over 4 of them


  • backlight Vcc
  • Backlight gnd


The minimal, write-only setup is:

  • tie RW to ground
  • connect RS, EN, D7, D6, D5, and D4 to digital outs


I2C and other

Matrix displays

(near-)monochrome

SSD1306

OLED, 128x64@4 colorsTemplate:Vierfy

https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf

SH1107

OLED,

https://datasheetspdf.com/pdf-file/1481276/SINOWEALTH/SH1107/1

Small LCD/TFTs / OLEDs

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Small as in order of an inch or two (because the controllers are designed for a limited resolution?(verify)).


💤 Note that, like with monitors, marketers really don't mind if you confuse LED-backlit LCD with OLED,

and some of the ebays and aliexpresses sellers of the world will happily 'accidentally' call any small screen OLED if it means they sell more.

This is further made more confusing by the fact that there are

  • few-color OLEDs (2 to 8 colors or so, great for high contrast but only high cotnrast),
  • high color OLEDs (65K),

...so you sometimes need to dig into the tech specs to see the difference between high color LCD and high color OLED.



When all pixels are off they give zero light pollution (unlike most LCDs) which might be nice in the dark. These seem to appear in smaller sizes than small LCDs, so are great as compact indicators.


Can it do video or not?

If it does speak e.g. MIPI it's basically just a monitor, probably capable of decent-speed updates, but also the things you can connect to will (on the scale of microcontroller to mini-PC) be moderately powerful, e.g. a raspberry.

But the list below don't connect PC video cables.

Still, they have their own controller, and can hold their pixel state one way or the other, but connect something more command-like - so you can update a moderate amount of pixels with via an interface that is much less speedy or complex.

You might get reasonable results over SPI / I2C for a lot of e.g. basic interfaces and guages. By the time you try to display video you have to think about your design more.

For a large part because amount of pixels to update times the rate of frames per second has to fit through the communication (...also the display's capabilities). There is a semi-standard parallel interface that might make video-speed things feasible. This interface is faster than the SPI/I2C option, though not always that much, depending on hardware details.


Even if the specs of the screen can do it in theory, you also have to have the video ready to send. If you're running it from an RP2040 or ESP32, don't expect to libav/ffmpeg.

Say, something like the TinyTV runs a 216x135 65Kcolor display from a from a RP2040.

Also note that such hardware won't be doing decoding and rescaling arbitrary video files. They will use specifically pre-converted video.


In your choices, also consider libraries. Things like TFT_eSPI has a compatibility list you will care about.



Interfaces

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


ST7735

LCD, 132x162@16bits RGB


ST7789

LCD, 240x320@16bits RGB

https://www.waveshare.com/w/upload/a/ae/ST7789_Datasheet.pdf

SSD1331

OLED, 96x 64, 16bits RGB

https://cdn-shop.adafruit.com/datasheets/SSD1331_1.2.pdf


SSD1309

OLED, 128 x 64, single color?

https://www.hpinfotech.ro/SSD1309.pdf

SSD1351

OLED, 65K color

https://newhavendisplay.com/content/app_notes/SSD1351.pdf

HX8352C

LCD https://www.ramtex.dk/display-controller-driver/rgb/hx8352.htm


HX8357C

R61581

ILI9163

LCD, 162x132@16-bit RGB

http://www.hpinfotech.ro/ILI9163.pdf

ILI9341

https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

ILI9486

LCD, 480x320@16-bit RGB

https://www.hpinfotech.ro/ILI9486.pdf

ILI9488

LCD

https://www.hpinfotech.ro/ILI9488.pdf

PCF8833

LCD, 132×132 16-bit RGB

https://www.olimex.com/Products/Modules/LCD/MOD-LCD6610/resources/PCF8833.pdf

SEPS225

LCD

https://vfdclock.jimdofree.com/app/download/7279155568/SEPS225.pdf


RM68140

LCD

https://www.melt.com.ru/docs/RM68140_datasheet_V0.3_20120605.pdf

GC9A01

LCD, 65K colors, SPI

Seem to often be used on round displays(verify)

https://www.buydisplay.com/download/ic/GC9A01A.pdf

Epaper

SSD1619

https://cursedhardware.github.io/epd-driver-ic/SSD1619A.pdf


Many-element - TV and monitor notes (and a little film)

Backlit flat-panel displays

CCFL or LED backlight

https://nl.wikipedia.org/wiki/CCFL

Self-lit

OLED

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

While OLED is also a thing in lighting, OLED usually comes up in the context of OLED displays.

It is mainly contrasted with backlit displays (because it is hard to get those to block all light). OLEDs being off just emit no light at all. So the blacks are blacker, you could go brighter at the same time, There are some other technical details why they tend to look a little crisper.

Viewing angles are also better, roughly because the light source is closer to the surface.


OLED are organic LEDs, which in itself party just a practical production detail, and really just LEDs. (...though you can get fancy in the production process, e.g. pricy see-through displays are often OLED with substate trickery(verify))


PMOLED versus AMOLED makes no difference to the light emission, just to the way we access them (Passive Matrix, Active Matrix). AMOLED can can somwhat lower power, higher speed, and more options along that scale(verify), all of which makes them interesting for mobile uses. It also scales better to larger monitors.

POLED (and confusingly, pOLED is a trademark) uses a polymer instead of the glass, so is less likely to break but has other potential issues


QLED

On image persistence / burn-in

VFD

Vacuum Fluorescent Displays are vacuum tubes applied in a specific way - see Lightbulb_notes#VFDs for more details.



Some theory - on reproduction

Reproduction that flashes

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Mechanical film projectors flash individual film frames while that film is being held entirely still, before advancing that film to the next (while no light is coming out) and repeating.

(see e.g. this and note that it moves so quickly that you see that the film is taken it happens so quickly that you don't even see it move. Separately, if you slow playback you can also see that it flashes twice before it advances the film - we'll get to why)

This requires a shutter, i.e. not letting through any light a moderate part of the time (specifically while it's advancing the film). We are counting on our eyes to sort of ignore that.


One significant design concept very relevant to this type of reproduction is the flicker fusion threshold, the "frequency at which intermittent light stimulus appears to be steady light" to our eyes because separately from actual image it's showing, it appearing smooth is, you know, nice.

Research shows that this varies somewhat with conditions, but in most conditions practical around showing people images, that's somewhere between 50Hz and 90Hz.


Since people are sensitive to flicker to varying degrees, and this can lead to eyestain and headaches, we aim towards the high end of that range whenever that is not hard to do.

In fact, we did so even with film. While film is 24fps and was initially shown at 24Hz flashes, movie projectors soon introduced two-blade and then three-blade shutters, showing each image two or three times before advancing, meaning that while they still only show 24 distinct images per second, they flash it twice or three times for a regular 48Hz or 72Hz flicker. No more detail, but a bunch less eyestrain.


As to what is actually being show, an arguably even more basic constraint is the rate of new images that we accept as fluid movement.

Anything under 10fps looks jerky and stilted
or at least like a choice.
western and eastern animations were rarely higher than 12, or 8 or 6 for the simpler/cheaper ones
around 20fps we start readily accepting it as continuous movement,
above 30 or 40fps it looks smooth,
and above that it keeps on looking a little better yet, with quickly diminishing returns



So why 24?

Film's 24 was not universal at the time, and has no strong significance then or now. It's just that when a standard was needed, the number 24 was a chosen balance between various aspects, like the fact that that's enough for fluid movement and relatively few scenes need higher, and the fact that film stock is expensive, and a standard for projection (adaptable or even multiple projectors would be too expensive for most cinemas).


The reason we still use 24fps today is more faceted, and doesn't really have a one-sentence answer.

But part of it is that making movies go faster is not always well received.

It seems that we associated 24fps to feels like movies, 50/60fps feels like shaky-cam home movies made by dad's camcorder (when those were still a thing) or sports broadcasts (which we did even though it reduced detail) with their tense, immediate, real-world associations. So higher, while technically better, was also associated with a specific aesthetic. It mat works well for action movies, yet less for others.

There is an argument that 24fps's sluggishness puts us more at ease, reminds us that it isn't real, seems associated with storytelling, a dreamlike state, memory recall.

Even if we can't put our finger on why, such senses persist.


CRT screens

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Also flashing

CRT monitors do something vaguely similar to movie projectors, in that they light up an image so-many times a second.


Where with film you light up the entire thing at once (maybe with some time with the shutter coming in and out, ignore that for now). a CRT light up one spot at a time - there is a beam constantly being dragged line by line across the screen -- look at slow motion footage like this.

The phosphor will have a softish onset and retain light for some while, and while slow motion tends to exaggerate that a little (looks like a single line), it's still visible for much less than 1/60th of a second.

The largest reason that these pulsing phosphors don't look like harsh blinking is that our persistence of vision (you could say our eyes framerate sucks, though actually this is a poor name for our eyes's actual mechanics), combined with the fact that it's relatively bright.


Flatscreens

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Flatscreens do not reproduce by blinking things at us.

While in film, and in CRTs, the mechanism that lights up the screen is the is the same mechanism as the one that shows you the image, in LCD-style flatscreens, the image updates and the lighting are now different mechanisms.

Basically, there's one overall light behind the pixely part of the screen, and each screen pixel blocks light.


That global backlights tends to be lit fairly continuously. Sure there is variation in backlights, and some will still give you a little more eye strain than others.

CCFL backlight phosphors seem intentionally made to decay slowly, so even if the panel is a mere 100Hz, that CCFL ought to look look much less blinky than e.g. CRT at 100Hz.


LED backlights are often PWM'd at kHz speeds(verify), or current-limited(verify), which are both smoother.

If you take a high speed camera, you may still not see it flicker this part of the same slow motion video (note how the backlight appears constant even when the pixel update is crawling by) until you get really fast and specific.


So the difference between, say, a 60fps and 240fps monitor isn't in the lighting, it's how fast the light-blocking pixels in front of that constant backlight change. A 60fps monitor changes its pixels every 16ms (1/60 sec), a 240fps the latter every 4ms (1/240 sec). The light just stays on.

As such, while a cRT at 30Hz would look very blinky and be hard on the eyes, a flatscreen at 30fps updates looks choppy but not like a blinky eyestrain.



On updating pixels
On pixel response time and blur

Vsync

Adaptive sync

On perceiving

The framerate of our eyes

arguments for 60fps / 60Hz in gaming

On reaction time

On end-to-end latency

Tracking objects?

On intentional motion blur

On resolution

On contrast ratio / dynamic range

see also

Visuals_DIY#Analog_video_notes

Monitor mounts

VESA mounts

The sizes are often one of:

  • 7.5 cm x 7.5 cm (2.95 inches), 8kg max
  • 10 cm x 10 cm (3.94 inches), 12kg max
  • 20 cm x 20 cm (7.87 inches), 50kg+

...though there are smaller and larger variants, and also non-square ones.

Most products will have holes to fit more than one.

10cm was apparently the original, 7.5cm was added for smaller displays, though note that lightish displays could use either.


See also:

Monitor faults

Permanent lines on monitor