低遅延性を重視したオープンソース eInk モニター Glider
(github.com/Modos-Labs)- Glider は 低遅延・高リフレッシュレート EPD モニターのためのオープンソースプロジェクトで、このリポジトリにはハードウェア設計とファームウェアが含まれ、FPGA 上で動作するゲートウェアには別のオープンソースである Caster EPDC 設計を使用する
- 対応対象はパラレルインターフェースを持つ 電気泳動ディスプレイパネルで、白黒パネルと Kaleido のようなカラーフィルターアレイベースのカラー画面の両方を扱える
- ボードは Xilinx Spartan-6 LX16 FPGA、DDR3-800 フレームバッファ、STM32H750 MCU、USB-C DisplayPort Alt Mode または DVI 入力、最大 ±15V レールで 1A のピーク電流を出せる E-paper 電源を備える
- Caster は各ピクセルを独立した更新領域のように扱い、early cancellation を適用することで、処理遅延を 20µs 未満まで下げ、バイナリー・4 段階グレースケールモードで低遅延を目指す
- 低遅延設計はより大きな メモリ帯域幅と DVI・DisplayPort のような実際の低遅延映像インターフェースを要求し、1080p の例では従来方式の 120MB/s に対して Caster 方式は 540MB/s が必要
Glider と Caster の役割
- Glider は 低遅延 EPD モニターのためのオープンソースハードウェアプロジェクト
- このリポジトリにはハードウェア設計とファームウェアソースがあり、FPGA 上で動作する RTL は別リポジトリの Caster EPDC 設計
- README には Glider だけでなく、E Ink パネル、波形、カラー表示、ディザリング、互換画面に関する内容も含まれている
- ボード購入に興味があるユーザーは Modos Paper Monitor Crowd Supply 製品ページ を確認できる
- E Ink 関連の商標や内容は E Ink Corporation の保証を受けたものではなく、公開情報と独自研究に基づくため、誤りや不正確さが含まれる可能性がある
主な機能
- Glider/Caster の組み合わせは 低遅延・高リフレッシュレート EPD モニターのための完成形ソリューションを目指す
- 対応機能
- パラレルインターフェースを持つ EPD パネルをサポート
- E Ink、OED、DES 系パネルをサポート
- 白黒画面と Kaleido のような CFA ベースのカラー画面をサポート
- 20µs 未満の処理遅延
- バイナリー、4 段階グレースケール、16 段階グレースケール出力モード
- 遅延最適化バイナリー・4 段階グレースケール駆動モード
- 自動バイナリー・16 段階グレースケールハイブリッドモード
- ホストソフトウェアがランタイムで領域更新とモード切り替えを制御可能
- 追加遅延なしのハードウェア Bayer ディザリング、blue-noise ディザリング、誤差拡散ディザリング
- 標準 HVsync 入力
- ボードレベルで USB-C DisplayPort Alt Mode と DVI 入力をサポート
ハードウェア構成
- ボードは KiCad で設計されており、ソースファイルを開くには最新の安定版 KiCad が必要な場合がある
- 主な構成
- Xilinx Spartan-6 LX16 FPGA で Caster を実行
- DDR3-800 フレームバッファメモリ
- PTN3460 DP-LVDS ブリッジによる Type-C DisplayPort Alt Mode 入力
- ADV7611 デコーダによる microHDMI コネクタベースの DVI 入力
- 大型パネルをサポートする E-paper 電源部
- ±15V レールで最大 1A のピーク電流
- VCOM kick-back 電圧測定をサポート
- USB 通信とファームウェア更新のための STM32H750 MCU
- 誤差拡散ディザリング有効時に最大 133MP/s の処理レート
- ディザリング無効時に 200MP/s 超の処理レート
E Ink パネルとコントローラー構造
- E Ink は紙のような 電気泳動ディスプレイ系のブランドで、粒子に電場をかけて白黒または中間状態を作る方式で動作する
- EPD は LCD と異なり、電場が除去された後も状態を保持する 双安定性を持ち、ピクセルが完全に駆動されるまでだけ更新すればよい
- EPD の長所と短所
- 光を発しない反射型のため消費電力が低く、屋外で使用できる
- 電源を切っても画像を保持する
- 現代の IPS LCD と比べると表示品質、色域、応答時間の面で不利
- 例示値では白黒 EPD は約 17:1 のコントラスト、約 150ms の応答時間を持つ
- CFA ベースのカラー EPD は約 14:1 のコントラスト、約 1.5% の sRGB 色域、約 150ms の応答時間を持つ
- E Ink コントローラーは LCD システムのディスプレイコントローラーやタイミングコントローラーに近い役割を担い、元画像データをパネル駆動信号に変換する
- コントローラーは現在のピクセル状態と目標状態に応じて電圧を決定し、通常は波形（waveform）と呼ばれる LUT を使って状態遷移ごとの駆動シーケンスを選ぶ
コントローラー内蔵パネルと非内蔵パネル
- E-paper パネルはコントローラー内蔵の有無によって大きく二種類に分けられる
- コントローラー内蔵パネル
- SPI や I2C のような一般的なインターフェースで MCU に接続可能
- 電源部が統合されていることが多く、システムコストが低い
- 全体の更新遅延は 100ms から数秒に及ぶことがある
- コントローラーなしパネル
- 専用コントローラー、E Ink コントローラー内蔵 SoC、高速 MCU/SoC のソフトウェア TCON で駆動可能
- 専用コントローラーは IoT、電子書籍、携帯電話、E Ink モニター、E Ink ノート PC の可能性まで幅広く適用できる
- 高速な駆動構造を設計できるが、システム設計が低遅延を保証する必要がある
- 既存のオープンソース専用コントローラーの例には Caster + Glider、Paperback デスクトップ E-paper モニター、FPGA E Ink コントローラーが含まれる
- Caster + Glider は FPGA ベースのコントローラーで、複数の更新モード、超低遅延処理、広い画面サポート範囲を提供する
波形とグレースケール
- 波形（waveform） は E Ink コントローラーがピクセルをどう駆動するかを決めるルックアップテーブル
- LUT の入力はフレーム番号、開始グレースケールレベル、目標グレースケールレベルで構成される
- コントローラーはすべてのピクセルに対して毎フレーム LUT を参照し、ピクセルが完全に駆動されるまでフレームカウンターを増やしながら繰り返す
- 波形ファイルは単一ピクセルの遷移だけを扱うため、解像度には依存しない
- リポジトリは複数の波形形式を扱うためのツールを提供する
iwfから i.MX6/7 EPDC 用fwへ変換:./mxc_wvfm_asm v1/v2 input.iwf output.fwfwからiwfへ変換:./mxc_wvfm_dump v1/v2 input.fw output_prefixwbfからiwfへ変換:./wbf_wvfm_dump input.wbf output_prefix
- E Ink と DES パネルはベンダー提供の波形を基準に、通常は最大 16 段階グレースケールをサポートする
- グレースケールはフレーム時間を変えるか、固定フレームレートで適用フレーム数を変える方法で作れる
- 商用実装のグレースケール駆動は白黒表示より遅く、更新中にちらつきが生じる場合がある
カラー EPD とディザリング
- カラー EPD の実装は主に カラーフィルターアレイ（CFA） または多顔料カラー表示に分かれる
- CFA 方式
- E Ink Kaleido、E Ink Triton、color DES がこの方式に属する
- 低レベル駆動はグレースケールパネルと同じで、100〜200ms 程度の更新時間と 16 段階グレースケールを利用できる
- 16 段階グレースケールは 16³ = 4096 色につながる
- カラーフィルターが光を遮るため画面が暗くなる欠点がある
- Glider/Caster は color DES、E Ink Triton、E Ink Kaleido をサポートする
- 多顔料カラー表示
- E Ink Gallery と E Ink Spectra 系が含まれる
- CFA がないため解像度低下や光損失がなく、より高い反射率と彩度を得られる
- 駆動はより難しく遅く、Gallery 第1・第2世代は 30 秒更新、Spectra 6 Plus 機器は 7 秒更新と紹介されている
- ディザリングは限られたグレースケールやバイナリー表示でより良い画像を作るために使われる
- ordered dithering は画像に事前計算されたテクスチャやノイズを加えた後にしきい値処理を行う
- error-diffusion dithering は丸め誤差を周囲のピクセルへ伝播させる
- Bayer、blue-noise、Floyd-Steinberg、Stucki、Sierra のような方式が扱われる
- CFA ベースのカラー画面では、隣接ピクセルの色を考慮しない一般的な誤差拡散が適さないことがあり、同じ色のピクセルへ誤差を送るようカーネルを調整できる
- ガンマ補正も重要で、sRGB 空間で単純に丸めると最も近い色の選択や誤差計算が誤る可能性がある
Caster/Glider アーキテクチャ
- FPGA ゲートウェアはいくつかのモジュールに分かれており、
caster.vが EPDC コアの最上位設計 - 全体の画像処理システムは
top.vの下で追加コンポーネントを接続して構成する - 主なクロックドメイン
clk_vi: 入力ビデオクロックドメイン、ピクセルレートの 1/2clk_epdc: EPDC クロックドメイン、ピクセルレートの 1/4clk_mem: メモリクロックドメイン、メモリ転送レートの 1/4
- ピクセル処理フロー
memifが DDR SDRAM からローカルピクセル状態を読み出してbi_fifoに入れる- 入力映像ストリームは
vi_fifoに入る - EPDC のローカルタイミングジェネレーターがピクセル出力を準備すると、映像入力と状態値を一緒に取り出して処理する
- 8 ビット入力画像は 1 ビットと 4 ビットにディザリングされる
- 16 段階グレースケールモードで波形参照が行われる
- 新しい状態と電圧選択値が決定される
- 新しい状態は
bo_fifoに入り、電圧選択値は画面へ送信される
- EPDC はクロックごとに常に 4 ピクセルを処理し、画面インターフェース幅が異なる場合は出力後段に rate adapter が付く
MCU ファームウェア機能
- MCU は FreeRTOS を使ってボードの housekeeping 機能を担当する
- EPD 電源管理
- 共通電源、ソース電源、ゲート電源を供給する
- VCOM 電圧調整と、装着されたパネルの最適な VCOM 電圧測定を行う
- 電源監視
- 複数レールの電圧と電流を監視し、想定範囲内か確認する
- FPGA ビットストリーム読み込み
- FPGA には専用フラッシュがなく、電源投入時に MCU が SPI でビットストリームを FPGA に送る
- FPGA ビットストリームと MCU ファームウェアをまとめて更新できる
- USB-C ネゴシエーション
- USB-C DisplayPort Alt Mode でボード電源と映像入力をサポートする
- USB PD プロトコルで映像入力機能をソース機器に通知する
- ケーブル向きに応じて Type-C 信号 mux を制御する
- ビデオデコーダ初期化
- FPGA は DisplayPort や DVI のような高速映像インターフェースに直接接続するための高速 deserializer を持たないため、専用デコーダチップを初期化する
- PC 通信
- Caster は更新モードと強制更新・クリアをピクセル単位で適用できる
- MCU は TinyUSB を使って HID デバイスとして動作し、ホスト PC と FPGA の間でメッセージを中継する
低遅延駆動方式
- 既存の基本駆動方式はグローバルカウンターで波形テーブルを参照するため、前の更新が終わった後でないと新しい画像を受け取れない制約がある
- 更新に約 100ms かかる場合、画像レートは 10Hz となり、新しい画像がコントローラーで処理されるまで最大 100ms 待つ可能性がある
- Caster はすべてのピクセルを独立した更新領域のように扱う
- ソフトウェアが文字境界に合わせて領域を設定したり、限られた領域数を再割り当てしたりする必要がない
- すでに更新中のピクセルが再び変化した場合、early cancellation を適用する
- ピクセルが完全に駆動されるまで待たない
- 新しい要求状態の方向へ駆動し、新たに計算した駆動時間に応じてフレームカウンターを更新する
- 2 つの手法を組み合わせ、低遅延バイナリーおよび 4 段階グレースケールモードを実現する
- Caster はフレームレートとコントラスト比のトレードオフももはや関係せず、高いフレームレートと高いコントラスト比を自動的に達成するとしている
ハイブリッドグレースケールモードと限界
- Caster は高速バイナリーモードと低速グレースケールモードを ピクセル単位で自動切り替えする
- 入力画像が変化したときはバイナリーモードで更新し、画像がしばらく変化しなければグレースケールで再レンダリングする
- この方式はより大きなメモリ帯域幅を要求する
- 1080p パネルの例では約 120MP/s と計算される
- 従来方式はピクセルあたり 1 バイト読み出しで 120MB/s が必要
- Caster はピクセル状態バッファだけでピクセルあたり 2 バイト読み出しと 2 バイト書き込みが必要で、新しい画像値の読み出しにピクセルあたり 0.5 バイトがさらに必要
- 結果として 120MP/s × 4.5B/pixel = 540MB/s が必要
- Glider ハードウェアはより高い解像度のために DDR3-800 メモリを使用する
- コントローラーが PC の CPU/GPU の一部ではなくモニター内部にある場合、USB や I80/SPI のような単純だが遅いインターフェースではなく、DVI や DP のような実際の低遅延映像インターフェースが必要となる
- こうした手法は読書のような用途には役立たないため、商用電子書籍ソリューションがこれを実装する理由は少ないとしている
ビルドとフラッシング
- PCB は KiCad 8.0 で設計されており、推奨 4 層スタックアップは 1080 PP レイヤー
- FPGA ビットストリームのビルド
- Xilinx ISE 14.7 が必要
- 最新 OS は公式サポートされておらず、Xilinx の公式 RHEL 仮想マシンの利用が推奨される
- Caster リポジトリは
git clone --recursive https://gitlab.com/zephray/Caster.gitで取得できる rtl/spartan6/top.vのCOLORMODEはMONO、RGBW、DESから選択するrtl/defines.vhのOUTPUT_16Bは 16 ビットパネル使用時に定義する- Modos 6 インチと 13 インチキットはデフォルトの
MONO、8 ビット設定が適している
- MCU ファームウェアのビルド
- STM32CubeIDE が必要
- Glider リポジトリは
git clone --recursive https://gitlab.com/zephray/Glider.gitで取得できる Glider/fwを STM32CubeIDE プロジェクトとして開いてビルドする
- フラッシング
dfu-utilをインストールし、USB ポート近くのボタンを押したまま USB ケーブルを接続する- 提供されるフラッシングツールは Python 3 と
hidapiパッケージを使用する - 手動方式では
dfu-utilで MCU ファームウェアを書き込み、ボードシェルで XMODEM により FPGA ビットストリームを送信する
互換画面と性能制限
- Modos Dev Kit は 13.3 インチ 1600×1200 と 6 インチ 1404×1072 の画面オプションを提供する
- ボードは他のパネルも駆動できるが、画面ごとにコネクタが異なるためアダプターが必要
- メインボードは 50 ピン + 16 ピンコネクタを使用する
- 単一の 50 ピンコネクタは 8 ビット・16 ビット画面に十分
- 16 ピンコネクタは LVDS 画面と 32 ビット・64 ビット画面対応を追加する
- 対応可能な画面は入力プロトコル、処理レート、メモリインターフェースに制約される
- ディザリング有効時の処理レート: 133MP/s
- ディザリング無効時の処理レート: 280MP/s
- 8-wide 設計の推定処理レート: 500MP/s
- ADV7611 ベース DVI の最大ピクセルレート: 165MP/s
- PTN3460 ベース DisplayPort の最大ピクセルレート: 224MP/s
- DDR2/3-800 ×16 メモリインターフェース例: 360MP/s
- 一般的な解像度ごとのピークピクセルレート例
- 1600×1200 13.3 インチ 60Hz: 125MP/s
- 1600×1200 13.3 インチ 85Hz: 178MP/s
- 2200×1650 13.3 インチ 60Hz: 232MP/s
- 2560×1920 13.3 インチ 60Hz: 313MP/s
- 3200×1800 25.3 インチ 60Hz: 364MP/s
- グレースケールレンダリングでは画面を 85Hz でリフレッシュする必要があり、85Hz は E Ink がサポートするリフレッシュ周波数
- ボードは接続された画面解像度を自動検出できないため、ボードシェルで手動設定するか、構成生成ツールを使う必要がある
- 手動計算には Video Timings Calculator by Tom Verbeure を利用できる
ライセンスと参考資料
- ドキュメントは、別途ライセンスが明示された参考資料を除き パブリックドメインとして公開される
- ハードウェア設計は CERN Open Source Hardware License strongly-reciprocal variant である CERN-OHL-S で公開される
- ファームウェアコードは MIT ライセンスで、USB PD ライブラリは Chromium OS プロジェクトと reclamier labs に由来し、BSD ライセンスに従う
- 参考資料には EPD 駆動のリバースエンジニアリング資料、初期の E Ink DIY プロジェクト、STM32 ベースのグレースケールドライバー、ESP32 ベースの EPDiy、WBF ファイル形式ツールとパーサーが含まれる
1件のコメント
Hacker News の意見
どの電子インクコントローラーもいまひとつだったので、この人は自分で直すことにし、その成果をオープンソースハードウェアとして公開した。今では最先端レベルになっている。
こういう人とプロジェクトは本当にいい。
README を見るだけでも、情報の幅と深さが印象的。
こういう資料がこのように公開されると、コミュニティから速いイノベーションや破壊的な変化が生まれそう。
Discord を追っているが、進行はかなり遅く、基本的な部分でもかなり苦労している。
動作する物理理論まで扱っているほど、予想よりはるかに詳しい。
Kindle を10年以上使ってきたが、反応性の不足はずっと気になっていた。
ハードウェアの問題なのかソフトウェアの問題なのかは分からないが、このプロジェクトがハードウェア側で遅延を減らすことに注力しているというのはうれしい。
Kindle がなぜこんなにいまひとつな製品なのか、分かる人がいるのか気になる。電子インクが良く、電子書籍市場が包括的だから使っているが、実際に良いデバイスだとは思わない。
ほかのこともできなくはないが、そう作られたりマーケティングされたりした製品ではないので、反応性の革新ではなくコストを低く保っている。
その代わり、持ち方、ナビゲーション、バックライトのようなほかの使いやすさを改善している。
Kindle は常に電子書籍端末の基準点であり、実際に買える最も一般的な電子インク技術の製品だ。
ビジネスの観点で重要な尺度から見ると、悪い製品とはほとんど言いにくい。
その後は Calibre で本を入れることも、SFTP で入れることもできる。
ある端末は数日でバッテリーがなくなり、長いバッテリー駆動時間という約束を守れなかったし、あるものは品質がひどく、数カ月で壊れた。
Kindle は自分の使用量、つまり1日1〜2時間の読書なら1回の充電で数週間持ち、防水なので浴槽でも読めてありがたい。特別な問題に遭遇したことはない。
UI は Amazon Store の宣伝に合わせて作られているように見えるが、自分は使わず、メールで本を送って読んだら削除しているので問題ない。
ライブラリにフォルダーがあるとよいし、ほかの電子書籍端末のように USB メモリのようにつないで PC から自由に整理できるとよいが、必須ではない。
Kindle が悪い製品なのかもしれないが、ほかはもっと悪いように思う。Amazon 規模の電子書籍端末ブランドを一つも知らないし、どれも品質と評判に投資していない中国の無名ブランドのように見える。
リフレッシュ速度、遅延、演算性能、反応性など、ほぼあらゆる面で改善している。
名前が Glider なのは面白い偶然。
かなり多くのグライダー、つまりセールプレーンのパイロットが、強い日差しの下での可読性が高いので電子インク画面を使っており、たいていはルート化した Kobo や Kindle で XCSoar のようなものを動かしている: https://www.xcsoar.org/hardware/
ニッチな乗り物の中で、ほかにどんな技術が再利用されているのか気になってくる。
目の疲れとドライアイのため、長い間電子インクのソリューションに関心があった。
実はごく軽い乱視があった。眼科医は矯正を勧めなかったが、矯正したらドライアイと目の疲れが完全になくなった。
だから眼科医の最小処方度数の慣行とは別に、コンピューター用メガネで軽い乱視を矯正してみるとよい。
右目にごく軽い乱視があるが、一般的な老眼鏡の代わりにカスタムの読書用メガネで矯正したら、目の疲れと頭痛の面でまったく違った。
安いメガネでも体感上は悪くなかったが、差がどれほど大きいか分かって本当に驚いた。
ドライアイと目の疲れはしばしば一緒に起きるし、LED ベースの画面による目の疲れを扱うフォーラムも別にある。
似た問題がある人は訪れてみる価値がある: https://ledstrain.org/
zephray が頭の中にあった E Ink の知識をこうしてオープンソースで公開してくれて本当にありがたい。
README には電子インク関連の素晴らしい情報が多く、すでにかなり読んだし、今後何年も参照することになりそう。
本当に素晴らしい資料。
学習目的で電子インクディスプレイを使うデバイスをずいぶん前から作りたいと思っていたが、ソフトウェアしかやってこなかったので、どこから始めればよいか分からなかった。
この資料はその学習にかなり役立ちそう。
リンクされている GitHub は、元の GitLab リポジトリのミラー: https://gitlab.com/zephray/glider
電子インクディスプレイにフィードバック制御を追加するアイデアを調べた人がいたのか気になる。
電子インクのちらつきと遅延は、完全にコントローラーがオープンループ方式だからではないかという気がする。
こういう電子インクディスプレイで Compact Mac クローンを作りたい。
どれほど格好よく見えるか想像できる。
ただ、動くカーソルをこなせるほどの電子インクのリフレッシュ速度はまだ見たことがない。今なら適切なドライバーがあれば可能かもしれない。
[1] https://engineersneedart.com/systemsix/systemsix.html
バッテリー駆動時間もおそらく数週間単位になりそう。