Hacker News new | past | comments | ask | show | jobs | submit
mananaysiempre | on: I learned PCB design, 3D printing and C just to listen to music
> Once I had the design [of the enclosure], I tried to 3D print it on my brand new 3D printer, which turned out to be a disaster. Took me some time to learn more about designing for manufacturing, especially for 3D printing.

Would have been nice to hear how specifically it was made to work in the end.

> Turns out, cross-fading two 4MP images at 60 frames per second on a moderately powerful single board computer is not so easy.

Yeah, at first it feels stupid that every pretty LCD screen for bus or train stops, ads or whatnot has a full computer behind it, but then you ballpark the memory bandwidth and realize you need a ~ 1 GHz device anyway just to be able to chew through the pixels fast enough. (1920² px × 24 bpp × 60 Hz = 620 MB/s.) You also realize why “fill rate” used to be such a buzzword 20 years ago and why it took a while until true color became ubiquitous.

On the flip side of the O(n²), you can easily drive a watch-sized display with pretty good ppi using a 32-bit MCU, which is why the Apple/Google/Samsung battery-guzzling approach to smartwatches seems wrongheaded to me compared to Pebble/Zepp/etc.

markb139 | parent | next
Way back in time (1980s) I worked in the broadcast tv industry. We used to used digital still stores. A single frame of PAL took up 1MB of RAM. The machines had 2MB fitted. The board had a hardware cross fade function implemented in discrete logic chips. They also had a 20 or 40MB scsi drive. It was all controlled by a 6809 cpu. Quite impressive for the time
skippyfish | parent
Large displays are not driven by a general-purpose CPU that bit-bangs a single serial data line, and never were. They're driven by separate circuitry with direct memory access, often integrated on the die of chips meant for these applications. The actual bus to the display controller may be a parallel dot-clock RGB bus, or an ultra-speed differential multi-lane serial (MIPI DSI, HDMI, etc).

And train stop displays certainly don't need 60 fps.

The main constraint for high-resolution displays is memory, not CPU clock speed. Your (odd) 1920x1920x24bpp frame buffer takes up more than 10 MB.