16-segment displays are another longtime standard configuration.

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

Agreed. "Just use a pixel matrix display" sounds an awful lot like, "Just use an Arduino."

There are plenty of places where a simple and small microcontroller paired with a 4-digit segment display is the cheapest, simplest, and most defensible design decision.

It appears we live in a universe where embedded systems aren't assumed to be a mission critical device by default.

I'm not going to bother using a microcontroller to solve a problem if isn't a use case where the solution needs to be as simple and robust as possible.

The market is flooded with 128x64 1.3" or 0.96" OLED displays. You can pick them up for anywhere from $1-$5, probably less if you bulk order.

Sure, they bring some complexity. Instead of just driving some pins you now need a display library and at least some bitmap font. But they provide a lot more fidelity, are vastly more readable, and fail in more obvious ways without needing periodic test patterns (the flashing 8's or snakes mentioned in the paper so you can detect failed segments)

For larger displays the choice becomes more interesting between OLED, LED matrices or 16 segment displays, but for small devices like those shown in the paper cheap OLEDs make the choice easy

> The market is flooded

Yes, I'd also like to note, the market is flooded with crap. Multiple devices I've owned with these "cheap" displays have been on crappy, battery-intensive devices. The devices with simpler segment (or dot matrix) displays last longer and work better.

I get some of the points where extreme legibility trumps (nearly) all other concerns, however I'd propose the issue could have been solved more simply with more specialized segment displays.

Dot-matrix LED display panels seem bulletproof, but I just checked the catalog for the 5x7 display driver I know and use and it costs $30 per. I guess the people who have reliability and legibility concerns like those expressed in the article aren't worried about spending $15 per digit.

I think the point would be, you don't need a driver, you need a decoder. Those are very cheap.

"display library"

bold of you to assume i have enough memory to drive the thing.

The most common models of small OLED displays (SSD1306, etc) have a (write-only) framebuffer in the display controller, and can be written to incrementally. If you structure your visual interface with certain simple constraints in mind, you can update it without using any additional dynamic memory.

That would probably be 100x more complicated than the actual business logic on a small microcontroller and there are limits to program memory for the "streaming this string to the screen by constantly computing if a given pixel is on one at a time" algorithm.

edit addendum; If it was using a 7-segment display, it is either really cheap or really simple "a graphical GUI on a screen" IS NOT A REASONABLE NEXT STEP.

I think we have radically different expectations of a simple embedded system.

> That would probably be 100x more complicated than the actual business logic on a small microcontroller

It really isn't. I've implemented simple GUIs on SSD1306 displays, and it's very easy to work with. The hardware is specifically set up to optimize for rows of 8px tall text (or multiples of that with a bit more effort). Once you have row/column addresses set up, each byte you write to the display writes one 8px column of pixels to a row and moves the column pointer over by a pixel. Printing text is a matter of streaming a sequence of bytes to the display.

You can get something like a rp2040 for a couple of $. And let a graphic library do the hard work. Eg https://slint.dev/blog/porting-slint-to-microcontrollers

RP2040 should cost $0.70 in some quantity (https://www.digikey.com/en/products/detail/raspberry-pi/SC09...) and in low-quantity it's $1 from places like CanaKit. That's actually shockingly cheap for an ARM Cortex M0; I was assuming your ATmegas and PIC18s with a similar pin count (40, 48, 64) would be a bit cheaper, but they seem to be around $2-4 in similar low-production quantity. Power efficiency won't be anywhere near as good with the ARM part, but if you're making a battery-powered device, you might be able to use the extra dollar or so to make it rechargable, then people care a bit less if it eats batteries.

Power consumption on the RP2040 is quite poor, actually; there's much better parts to use if you care about that.

If you just want a really cheap ARM microcontroller, Puya has some parts like the PY32F002A in the <$0.10 range. Single core, lower Fmax, and fewer peripherals than the RP2040, but the price is hard to argue with.

They also wear out quite quickly.

They are cheap enough now, that they are appearing on disposable vapes (?!)

There is: https://www.sparkfun.com/products/18566

That display is really hard to read.

I would say that if you're going to use a 7-segment display, it would be helpful to add a "test/diagnostic" button that does a pattern in which all segments are lit up in a predictable order, does a TOP pattern in which only the top segments are lit (to allow for device orientation), and then goes back to displaying exactly what was on the display prior to pressing the button.

> That display is really hard to read.

Most of that is just due to a lack of contrast. Add a slightly-tinted window in front of it to reduce the contrast between unlit segment & background, and it becomes a lot easier to read.

Yes, that is most likely the cause.

Some subways have 111 segmented displays, I really like them, the refresh rate is stunning. Here is a page selling them [0] and here is how they look [1], [2].

[0] http://www.reitberger.de/English/Large%20displays/Alphanumer...

[1] https://www.reddit.com/r/whatisthisthing/comments/6zsezx/thi...

[2] https://www.reddit.com/r/whatisthisthing/comments/e19uaz/wha...

Boo, only rated for 22 years of nonstop use :P