Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I just glanced, they still want about 500 bucks for the 13" screen and half of that for the board to drive it. While I have no clue what making the screen at a low scale might cost, the board cannot possibly be five times more expensive than a Raspberry Pi, can it?


No, simple driver boards aren't super complicated. Nor are the chips on them manufactured on the fanciest nodes. They're not super-high-volume either though and as a result somewhat expensive on a BoM.

Here's the data sheet for the ITE IT8951, a frequently-used ASIC for this purpose that supports basic partial updates as well: https://www.waveshare.net/w/upload/1/18/IT8951_D_V0.2.4.3_20...

Here's a sourcing price: https://www.win-source.net/products/detail/ite/it8951e-64-dx...

It's basically a fairly simple SPI interface (or here a SPI wrapper around an internal Z80 protocol). The rest of the board is power supply handling and a DRAM framebuffer chip, external to the driver ASIC on SPI as well. I wrote a custom driver for this in Rust for my project, and it only took about a day despite a few leaky-abstractions oddities in how it communicates over SPI.

The chip itself is basically buffer handling, image processing (features like JPEG decode, resampling and some LUT mechanisms) and a waveform generator. Others will have some IP blocks for, say, a HDMI frontend. Any decent chip company can crank this out pretty quick. There's easily 10+ product lines on the market.

For simple things you may not even need one and can drive the panel from an MCU directly.

There are more expensive, more advanced drivers that implement more complicated and higher-performance (say, refresh rate) update schemes or I/O though.


Realistically you’re not paying for the hardware when you buy the driver board, but rather the software baked into those boards.

The waveforms, and the algorithms that create waveforms, used to drive eInk displays at reasonable speeds and produce high quality images are highly proprietary and very difficult to develop. In theory it’s easy to make an eInk display an image, but doing that in a reasonable period of time, when transitioning from potentially any starting state, and handling the crosstalk between pixels, makes creating good images on an eInk display pretty hard to get right.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: