Glider จอภาพ eInk โอเพนซอร์สที่เน้นค่าหน่วงต่ำ

 (github.com/Modos-Labs)
2 คะแนน โดย GN⁺ 2024-05-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Glider เป็นโครงการโอเพนซอร์สสำหรับ จอภาพ EPD ที่มีค่าหน่วงต่ำและรีเฟรชเรตสูง โดยรีโพซิทอรีนี้มีทั้งแบบฮาร์ดแวร์และเฟิร์มแวร์ ส่วนเกตแวร์ที่ทำงานบน FPGA ใช้ดีไซน์โอเพนซอร์ส Caster EPDC แยกต่างหาก
  • รองรับ แผงจอ electrophoretic display ที่ใช้อินเทอร์เฟซแบบขนาน และรองรับทั้งแผงขาวดำกับจอสีที่อิง color filter array เช่น Kaleido
  • บอร์ดประกอบด้วย FPGA Xilinx Spartan-6 LX16, เฟรมบัฟเฟอร์ DDR3-800, MCU STM32H750, อินพุต USB-C DisplayPort Alt Mode หรือ DVI และภาคจ่ายไฟ E-paper ที่ให้กระแสพีก 1A ที่รางไฟสูงสุด ±15V
  • Caster ประมวลผลพิกเซลแต่ละจุดเสมือนเป็นพื้นที่อัปเดตอิสระ และใช้ early cancellation เพื่อลดค่าหน่วงการประมวลผลให้ต่ำกว่า 20µs โดยมุ่งเป้าค่าหน่วงต่ำในโหมดไบนารีและเกรย์สเกล 4 ระดับ
  • การออกแบบแบบค่าหน่วงต่ำต้องการ แบนด์วิดท์หน่วยความจำ ที่สูงขึ้น และอินเทอร์เฟซวิดีโอค่าหน่วงต่ำจริงอย่าง DVI และ DisplayPort โดยในตัวอย่าง 1080p วิธีดั้งเดิมต้องใช้ 120MB/s ขณะที่วิธีของ Caster ต้องใช้ 540MB/s

บทบาทของ Glider และ Caster

  • Glider คือโครงการฮาร์ดแวร์โอเพนซอร์สสำหรับ จอภาพ EPD ค่าหน่วงต่ำ
  • รีโพซิทอรีนี้มีซอร์สของฮาร์ดแวร์และเฟิร์มแวร์ ส่วน RTL ที่รันบน FPGA คือดีไซน์ Caster EPDC จากรีโพซิทอรีแยก
  • README ไม่ได้ครอบคลุมแค่ Glider แต่รวมถึงเนื้อหาเกี่ยวกับแผง E Ink, waveform, การแสดงผลสี, dithering และจอที่เข้ากันได้ด้วย
  • ผู้ใช้ที่สนใจซื้อบอร์ดสามารถดูได้ที่ หน้าผลิตภัณฑ์ Modos Paper Monitor บน Crowd Supply
  • เครื่องหมายการค้าและเนื้อหาที่เกี่ยวข้องกับ E Ink ไม่ได้รับการรับรองจาก E Ink Corporation และอาจมีข้อผิดพลาดหรือความคลาดเคลื่อนเพราะอิงจากข้อมูลสาธารณะและการวิจัยของผู้จัดทำเอง

คุณสมบัติหลัก

  • ชุด Glider/Caster มุ่งเป็นโซลูชันครบวงจรสำหรับ จอภาพ EPD ค่าหน่วงต่ำและรีเฟรชเรตสูง
  • ฟีเจอร์ที่รองรับ
    • รองรับแผง EPD ที่ใช้อินเทอร์เฟซแบบขนาน
    • รองรับแผงตระกูล E Ink, OED, DES
    • รองรับทั้งจอขาวดำและ จอสีแบบ CFA เช่น Kaleido
    • ค่าหน่วงการประมวลผลต่ำกว่า 20µs
    • โหมดเอาต์พุตแบบไบนารี, เกรย์สเกล 4 ระดับ, เกรย์สเกล 16 ระดับ
    • โหมดขับแบบไบนารีและเกรย์สเกล 4 ระดับที่ปรับแต่งเพื่อลดค่าหน่วง
    • โหมดไฮบริดอัตโนมัติระหว่างไบนารีและเกรย์สเกล 16 ระดับ
    • ซอฟต์แวร์ฝั่งโฮสต์ควบคุมการอัปเดตพื้นที่และสลับโหมดระหว่างรันไทม์ได้
    • Bayer dithering, blue-noise dithering และ error diffusion dithering แบบฮาร์ดแวร์โดยไม่เพิ่มค่าหน่วง
    • อินพุต HVsync มาตรฐาน
    • รองรับอินพุต USB-C DisplayPort Alt Mode และ DVI ที่ระดับบอร์ด

องค์ประกอบฮาร์ดแวร์

  • บอร์ดออกแบบด้วย KiCad และอาจต้องใช้ KiCad เวอร์ชันเสถียรล่าสุดในการเปิดไฟล์ซอร์ส
  • องค์ประกอบหลัก
    • รัน Caster บน FPGA Xilinx Spartan-6 LX16
    • หน่วยความจำเฟรมบัฟเฟอร์ DDR3-800
    • อินพุต Type-C DisplayPort Alt Mode ผ่านบริดจ์ PTN3460 DP-LVDS
    • อินพุต DVI ผ่านคอนเนกเตอร์ microHDMI และดีโค้ดเดอร์ ADV7611
    • ภาคจ่ายไฟ E-paper สำหรับรองรับแผงขนาดใหญ่
      • กระแสพีกสูงสุด 1A ที่รางไฟ ±15V
    • รองรับการวัดแรงดัน VCOM kick-back
    • MCU STM32H750 สำหรับสื่อสารผ่าน USB และอัปเกรดเฟิร์มแวร์
    • อัตราประมวลผลสูงสุด 133MP/s เมื่อเปิดใช้ error diffusion dithering
    • อัตราประมวลผลเกิน 200MP/s เมื่อปิด dithering

โครงสร้างของแผง E Ink และคอนโทรลเลอร์

  • E Ink เป็นแบรนด์ในกลุ่ม electrophoretic display แบบคล้ายกระดาษ ทำงานโดยสร้างสนามไฟฟ้ากับอนุภาคเพื่อให้เกิดสถานะขาวดำหรือสถานะกึ่งกลาง
  • ต่างจาก LCD, EPD มีคุณสมบัติ bistability ที่คงสถานะไว้ได้แม้ตัดสนามไฟฟ้าแล้ว จึงต้องอัปเดตเพียงจนกว่าพิกเซลจะถูกขับครบถ้วน
  • ข้อดีและข้อเสียของ EPD
    • ใช้พลังงานต่ำและใช้งานกลางแจ้งได้ เพราะเป็นจอสะท้อนแสงไม่เปล่งแสงเอง
    • คงภาพได้แม้ปิดไฟเลี้ยง
    • ด้านคุณภาพการแสดงผล ช่วงสีกับเวลาตอบสนองยังด้อยกว่า IPS LCD สมัยใหม่
    • ตัวอย่างเชิงตัวเลข แผง EPD ขาวดำมีคอนทราสต์ราว 17:1 และเวลาตอบสนองราว 150ms
    • EPD สีแบบ CFA มีคอนทราสต์ราว 14:1, ช่วงสีประมาณ 1.5% sRGB และเวลาตอบสนองราว 150ms
  • คอนโทรลเลอร์ E Ink ทำหน้าที่ใกล้เคียง display controller และ timing controller ในระบบ LCD โดยแปลงข้อมูลภาพต้นฉบับให้เป็นสัญญาณขับแผง
  • คอนโทรลเลอร์จะกำหนดแรงดันตามสถานะปัจจุบันและสถานะเป้าหมายของพิกเซล โดยทั่วไปใช้ LUT ที่เรียกว่า waveform เพื่อเลือกซีเควนซ์การขับของแต่ละการเปลี่ยนสถานะ

แผงที่มีคอนโทรลเลอร์ในตัวและไม่มีในตัว

  • แผง E-paper แบ่งกว้าง ๆ ได้เป็นสองกลุ่มตามการมีคอนโทรลเลอร์ในตัวหรือไม่
  • แผงที่มีคอนโทรลเลอร์ในตัว
    • เชื่อมต่อกับ MCU ได้ผ่านอินเทอร์เฟซทั่วไปอย่าง SPI หรือ I2C
    • มักรวมภาคจ่ายไฟมาด้วย ทำให้ต้นทุนระบบต่ำ
    • ค่าหน่วงการอัปเดตทั้งระบบอาจอยู่ตั้งแต่ 100ms ไปจนถึงหลายวินาที
  • แผงที่ไม่มีคอนโทรลเลอร์
    • ขับได้ด้วยคอนโทรลเลอร์เฉพาะ, SoC ที่มีคอนโทรลเลอร์ E Ink ในตัว หรือ software TCON บน MCU/SoC ที่เร็วพอ
    • คอนโทรลเลอร์เฉพาะนำไปใช้ได้กว้าง ตั้งแต่ IoT, e-reader, โทรศัพท์, จอ E Ink ไปจนถึงความเป็นไปได้ของโน้ตบุ๊ก E Ink
    • ออกแบบโครงสร้างให้ขับได้เร็วกว่าได้ แต่การออกแบบระบบต้องรับประกันค่าหน่วงต่ำด้วย
  • ตัวอย่างคอนโทรลเลอร์เฉพาะแบบโอเพนซอร์สเดิม ได้แก่ Caster + Glider, จอ E-paper เดสก์ท็อป Paperback และคอนโทรลเลอร์ E Ink บน FPGA
  • Caster + Glider เป็นคอนโทรลเลอร์บน FPGA ที่รองรับหลายโหมดการอัปเดต การประมวลผลหน่วงต่ำมาก และรองรับช่วงขนาดจอได้กว้าง

Waveform และเกรย์สเกล

  • waveform คือ lookup table ที่คอนโทรลเลอร์ E Ink ใช้ตัดสินใจว่าจะขับพิกเซลอย่างไร
  • อินพุตของ LUT ประกอบด้วยหมายเลขเฟรม ระดับเกรย์สเกลต้นทาง และระดับเกรย์สเกลเป้าหมาย
  • คอนโทรลเลอร์จะ lookup LUT ทุกเฟรมสำหรับทุกพิกเซล แล้วเพิ่มตัวนับเฟรมและทำซ้ำไปจนกว่าพิกเซลจะถูกขับครบ
  • ไฟล์ waveform จัดการเฉพาะการเปลี่ยนสถานะของพิกเซลเดี่ยว จึงไม่ขึ้นกับความละเอียด
  • รีโพซิทอรีมีเครื่องมือสำหรับทำงานกับฟอร์แมต waveform หลายแบบ
    • แปลงจาก iwf เป็น fw สำหรับ i.MX6/7 EPDC: ./mxc_wvfm_asm v1/v2 input.iwf output.fw
    • แปลงจาก fw เป็น iwf: ./mxc_wvfm_dump v1/v2 input.fw output_prefix
    • แปลงจาก wbf เป็น iwf: ./wbf_wvfm_dump input.wbf output_prefix
  • แผง E Ink และ DES โดยทั่วไปตาม waveform ที่ผู้ผลิตให้มาจะรองรับเกรย์สเกลได้สูงสุด 16 ระดับ
  • เกรย์สเกลอาจสร้างได้โดยเปลี่ยนเวลาเฟรม หรือเปลี่ยนจำนวนเฟรมที่ใช้ภายใต้รีเฟรชเรตคงที่
  • การขับเกรย์สเกลในระบบเชิงพาณิชย์มักช้ากว่าการแสดงผลขาวดำ และอาจเกิดการกะพริบระหว่างอัปเดต

EPD สีและ dithering

  • การทำ EPD สีแบ่งหลัก ๆ เป็น color filter array (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 รุ่นแรก ๆ ถูกระบุว่าอัปเดต 30 วินาที และ Spectra 6 Plus อัปเดต 7 วินาที
  • dithering ใช้เพื่อให้ภาพดีขึ้นบนการแสดงผลที่มีเกรย์สเกลจำกัดหรือเป็นไบนารี
    • ordered dithering คือการเติม texture หรือ noise ที่คำนวณไว้ล่วงหน้าลงในภาพก่อนทำ threshold
    • error-diffusion dithering คือการส่งต่อค่าความผิดพลาดจากการปัดเศษไปยังพิกเซลข้างเคียง
    • มีการกล่าวถึงวิธีอย่าง Bayer, blue-noise, Floyd-Steinberg, Stucki, Sierra
  • ในจอสีแบบ CFA การทำ error diffusion ทั่วไปที่ไม่คำนึงถึงสีของพิกเซลข้างเคียงอาจไม่เหมาะ และสามารถปรับ kernel ให้ส่ง error ไปยังพิกเซลสีเดียวกันได้
  • การแก้แกมมาก็สำคัญ เพราะถ้าปัดค่าใน sRGB ตรง ๆ อาจเลือกสีที่ใกล้ที่สุดและคำนวณ error ได้ไม่ถูกต้อง

สถาปัตยกรรม Caster/Glider

  • เกตแวร์ FPGA ถูกแบ่งเป็นหลายโมดูล โดย caster.v เป็นดีไซน์ระดับบนสุดของคอร์ EPDC
  • ระบบประมวลผลภาพทั้งหมดประกอบขึ้นใต้ top.v โดยเชื่อมคอมโพเนนต์เพิ่มเติมเข้าไป
  • clock domain หลัก
    • clk_vi: clock domain ของวิดีโอขาเข้า ที่ 1/2 ของความเร็วพิกเซล
    • clk_epdc: clock domain ของ EPDC ที่ 1/4 ของความเร็วพิกเซล
    • clk_mem: clock domain ของหน่วยความจำ ที่ 1/4 ของอัตรารับส่งหน่วยความจำ
  • ลำดับการประมวลผลพิกเซล
    • memif อ่านสถานะพิกเซลภายในจาก DDR SDRAM แล้วใส่ลงใน bi_fifo
    • สตรีมวิดีโอขาเข้าถูกป้อนไปยัง vi_fifo
    • เมื่อ local timing generator ของ EPDC เตรียมเอาต์พุตพิกเซลพร้อม จะดึงวิดีโอขาเข้าและค่าสถานะออกมาประมวลผลร่วมกัน
    • ภาพอินพุต 8 บิตจะถูก dither เป็น 1 บิตและ 4 บิต
    • มีการ lookup waveform ในโหมดเกรย์สเกล 16 ระดับ
    • จากนั้นกำหนดสถานะใหม่และค่าเลือกแรงดัน
    • สถานะใหม่ถูกส่งเข้า bo_fifo และค่าเลือกแรงดันถูกส่งไปยังจอ
  • EPDC ประมวลผล 4 พิกเซลต่อ clock ตลอดเวลา และหากความกว้างของอินเทอร์เฟซจอแตกต่างกัน จะมี rate adapter ต่ออยู่ที่ปลายทางเอาต์พุต

ความสามารถของเฟิร์มแวร์ MCU

  • MCU ใช้ FreeRTOS เพื่อดูแลงาน housekeeping ของบอร์ด
  • การจัดการไฟเลี้ยง EPD
    • จ่ายไฟ common, source และ gate
    • ปรับแรงดัน VCOM และวัดค่าแรงดัน VCOM ที่เหมาะสมที่สุดของแผงที่ติดตั้ง
  • การมอนิเตอร์ไฟเลี้ยง
    • เฝ้าดูแรงดันและกระแสของหลายรางไฟ และตรวจสอบว่าอยู่ในช่วงที่คาดไว้
  • การโหลดบิตสตรีม FPGA
    • FPGA ไม่มีแฟลชในตัว และเมื่อเปิดเครื่อง MCU จะส่งบิตสตรีมไปยัง FPGA ผ่าน SPI
    • สามารถอัปเดตบิตสตรีม FPGA และเฟิร์มแวร์ MCU พร้อมกันได้
  • การเจรจา USB-C
    • รองรับทั้งไฟเลี้ยงบอร์ดและอินพุตวิดีโอผ่าน USB-C DisplayPort Alt Mode
    • ใช้โปรโตคอล USB PD เพื่อประกาศความสามารถด้านอินพุตวิดีโอไปยังอุปกรณ์ต้นทาง
    • ควบคุมสัญญาณ Type-C mux ตามทิศทางการเสียบสาย
  • การเริ่มต้นวิดีโอดีโค้ดเดอร์
    • เนื่องจาก FPGA ไม่มี high-speed deserializer สำหรับต่อกับอินเทอร์เฟซวิดีโอความเร็วสูงอย่าง DisplayPort หรือ DVI โดยตรง จึงต้องเริ่มต้นชิปดีโค้ดเดอร์เฉพาะ
  • การสื่อสารกับพีซี
    • Caster สามารถใช้โหมดอัปเดตและคำสั่งบังคับอัปเดต/ล้างแบบระดับพิกเซลได้
    • MCU ใช้ TinyUSB ทำงานเป็นอุปกรณ์ HID และส่งต่อข้อความระหว่างโฮสต์พีซีกับ FPGA

วิธีขับแบบค่าหน่วงต่ำ

  • วิธีขับพื้นฐานแบบเดิมใช้ตัวนับส่วนกลางในการ lookup ตาราง waveform จึงมีข้อจำกัดว่าต้องรอให้อัปเดตก่อนหน้าจบก่อนจึงจะรับภาพใหม่ได้
  • หากการอัปเดตใช้เวลาราว 100ms อัตราภาพจะอยู่ที่ 10Hz และอาจต้องรอนานถึง 100ms ก่อนที่ภาพใหม่จะถูกประมวลผลในคอนโทรลเลอร์
  • Caster ปฏิบัติต่อทุกพิกเซลเสมือนเป็นพื้นที่อัปเดตอิสระ
    • ซอฟต์แวร์ไม่ต้องกำหนดพื้นที่ให้ตรงขอบตัวอักษรหรือคอยจัดสรรพื้นที่จำนวนจำกัดใหม่
  • หากพิกเซลที่กำลังอัปเดตอยู่มีการเปลี่ยนอีกครั้ง จะใช้ early cancellation
    • ไม่ต้องรอจนพิกเซลถูกขับครบ
    • จะขับต่อไปทางสถานะที่ร้องขอใหม่ และอัปเดตตัวนับเฟรมตามเวลาขับที่คำนวณใหม่
  • การรวมสองเทคนิคนี้ทำให้ได้โหมดไบนารีและเกรย์สเกล 4 ระดับแบบค่าหน่วงต่ำ
  • Caster ระบุว่าจุดแลกเปลี่ยนระหว่างเฟรมเรตกับคอนทราสต์ไม่เกี่ยวข้องอีกต่อไป และสามารถได้ทั้งเฟรมเรตสูงและคอนทราสต์สูงโดยอัตโนมัติ

โหมดเกรย์สเกลไฮบริดและข้อจำกัด

  • Caster สลับอัตโนมัติระดับพิกเซล ระหว่างโหมดไบนารีที่เร็วกับโหมดเกรย์สเกลที่ช้า
  • เมื่อภาพอินพุตเปลี่ยน จะอัปเดตด้วยโหมดไบนารี และเมื่อภาพหยุดเปลี่ยนช่วงหนึ่ง จะเรนเดอร์ใหม่เป็นเกรย์สเกล
  • วิธีนี้ต้องการแบนด์วิดท์หน่วยความจำมากขึ้น
    • ในตัวอย่างแผง 1080p คำนวณได้ราว 120MP/s
    • วิธีดั้งเดิมต้องอ่าน 1 ไบต์ต่อพิกเซล จึงใช้ 120MB/s
    • Caster ต้องอ่าน 2 ไบต์และเขียน 2 ไบต์ต่อพิกเซลสำหรับบัฟเฟอร์สถานะพิกเซล และต้องอ่านค่าภาพใหม่เพิ่มอีก 0.5 ไบต์ต่อพิกเซล
    • รวมแล้วต้องใช้ 120MP/s × 4.5B/pixel = 540MB/s
  • ฮาร์ดแวร์ Glider ใช้หน่วยความจำ DDR3-800 เพื่อรองรับความละเอียดที่สูงขึ้น
  • เมื่อตัวคอนโทรลเลอร์ไม่ได้เป็นส่วนหนึ่งของ CPU/GPU ในพีซี แต่ฝังอยู่ภายในจอภาพ จำเป็นต้องใช้อินเทอร์เฟซวิดีโอค่าหน่วงต่ำจริงอย่าง DVI หรือ DP แทนอินเทอร์เฟซง่ายแต่ช้าอย่าง USB หรือ I80/SPI
  • ผู้พัฒนาระบุว่าเทคนิคเหล่านี้ไม่ช่วยกับกรณีใช้งานอย่างการอ่านหนังสือ จึงมีเหตุผลน้อยที่โซลูชัน e-reader เชิงพาณิชย์จะนำไปใช้

การบิลด์และแฟลช

  • PCB ออกแบบด้วย KiCad 8.0 และ stackup 4 ชั้นที่แนะนำคือ 1080 PP layer
  • การบิลด์บิตสตรีม FPGA
    • ต้องใช้ Xilinx ISE 14.7
    • ไม่รองรับระบบปฏิบัติการใหม่อย่างเป็นทางการ และแนะนำให้ใช้เครื่องเสมือน RHEL อย่างเป็นทางการของ Xilinx
    • รับรีโพซิทอรี Caster ได้ด้วย git clone --recursive https://gitlab.com/zephray/Caster.git
    • COLORMODE ใน rtl/spartan6/top.v เลือกได้ระหว่าง MONO, RGBW, DES
    • กำหนด OUTPUT_16B ใน rtl/defines.vh เมื่อใช้แผง 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
    • วิธีแมนนวลคือเขียนเฟิร์มแวร์ MCU ด้วย dfu-util แล้วส่งบิตสตรีม FPGA ผ่าน XMODEM จากบอร์ดเชลล์

จอที่เข้ากันได้และข้อจำกัดด้านประสิทธิภาพ

  • Modos Dev Kit มีตัวเลือกจอ 13.3 นิ้ว 1600×1200 และ 6 นิ้ว 1404×1072
  • บอร์ดสามารถขับแผงอื่นได้เช่นกัน แต่เนื่องจากแต่ละจอใช้คอนเนกเตอร์ต่างกันจึงต้องมีอะแดปเตอร์
  • เมนบอร์ดใช้คอนเนกเตอร์ 50 พิน + 16 พิน
    • คอนเนกเตอร์ 50 พินเดี่ยวเพียงพอสำหรับจอ 8 บิตและ 16 บิต
    • คอนเนกเตอร์ 16 พินเพิ่มการรองรับจอ LVDS และจอ 32 บิตกับ 64 บิต
  • จอที่รองรับได้ถูกจำกัดโดยโปรโตคอลอินพุต อัตราประมวลผล และอินเทอร์เฟซหน่วยความจำ
    • อัตราประมวลผลเมื่อเปิด dithering: 133MP/s
    • อัตราประมวลผลเมื่อปิด dithering: 280MP/s
    • อัตราประมวลผลโดยประมาณของดีไซน์ 8-wide: 500MP/s
    • อัตราพิกเซลสูงสุดของ DVI ที่อิง ADV7611: 165MP/s
    • อัตราพิกเซลสูงสุดของ DisplayPort ที่อิง PTN3460: 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 หรือ CERN-OHL-S
  • โค้ดเฟิร์มแวร์ใช้สัญญาอนุญาต MIT ส่วนไลบรารี USB PD ดัดแปลงมาจากโครงการ Chromium OS และ reclamier labs ภายใต้ BSD license
  • เอกสารอ้างอิงรวมถึงข้อมูล reverse engineering การขับ EPD, โครงการ E Ink DIY ยุคแรก, ไดรเวอร์เกรย์สเกลบน STM32, EPDiy บน ESP32 และเครื่องมือกับ parser สำหรับฟอร์แมตไฟล์ WBF

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-15
ความเห็นจาก Hacker News

  • คอนโทรลเลอร์ eInk ทั้งหมดนั้นแย่มาตลอด แต่คนนี้ตัดสินใจลงมือแก้เอง แล้วก็ปล่อยผลงานออกมาเป็นฮาร์ดแวร์โอเพนซอร์ส ซึ่งตอนนี้ถือว่าทันสมัยมาก
    ชอบคนและโปรเจกต์แบบนี้จริง ๆ

  • แค่อ่าน README ก็ประทับใจกับทั้ง ความกว้างและความลึก ของข้อมูลแล้ว
    ถ้าเอกสารแบบนี้ถูกเปิดเผยออกมา ก็น่าจะทำให้ชุมชนเกิดนวัตกรรมเร็ว ๆ และการเปลี่ยนแปลงแบบพลิกวงการได้

    • อยากให้คนฝั่ง Pine Note มาเห็นสิ่งนี้
      ตามอ่านใน Discord อยู่ แต่ความคืบหน้าค่อนข้างช้า และยังลำบากแม้แต่กับเรื่องพื้นฐาน
    • อย่างน้อยอันนี้ก็เป็น กระดาษอิเล็กทรอนิกส์ ของจริง ไม่ใช่ของแบบเมื่อก่อนที่เอา LCD ขาวดำมาพูดว่าเป็น ePaper หน่วงต่ำ
    • ไม่ได้พูดเกินจริงเลย
      ละเอียดกว่าที่คิดมาก ถึงขั้นอธิบายทฤษฎีฟิสิกส์ที่ทำให้มันทำงานได้

  • ใช้ Kindle มานานกว่าสิบปีแล้ว แต่ ความไม่ตอบสนองฉับไว เป็นสิ่งที่รำคาญใจมาตลอด
    ไม่แน่ใจว่าเป็นปัญหาฮาร์ดแวร์หรือซอฟต์แวร์ แต่ก็ดีใจที่โปรเจกต์นี้โฟกัสที่การลด latency ฝั่งฮาร์ดแวร์
    สงสัยว่ามีใครรู้ไหมว่าทำไม Kindle ถึงเป็นผลิตภัณฑ์ที่ไม่ค่อยดีแบบนี้ ฉันใช้มันเพราะ eInk ดีและตลาดอีบุ๊กมีหนังสือครอบคลุม แต่ไม่เคยคิดว่ามันเป็นอุปกรณ์ที่ดีจริง ๆ

    • Kindle มีความตอบสนองเพียงพอสำหรับจุดประสงค์ที่มันถูกสร้างมามาตั้งแต่แรก นั่นคือ การอ่านหนังสือ
      มันทำอย่างอื่นได้ด้วย แต่ไม่ได้ถูกออกแบบหรือทำการตลาดมาแบบนั้น เลยเลือกคุมต้นทุนแทนที่จะปฏิวัติด้านความตอบสนอง
      ส่วนที่ปรับปรุงคือเรื่องการจับถือ วิธีนำทาง และไฟหน้าจอ เป็นต้น
    • อยากรู้ว่าใช้งานแบบไหนถึงทำให้ตัดสินว่า Kindle เป็น ผลิตภัณฑ์ที่แย่ เพราะเวลารีเฟรชช้า
      Kindle เป็นเหมือนมาตรฐานอ้างอิงของเครื่องอ่านอีบุ๊กมาโดยตลอด และก็เป็นผลิตภัณฑ์ eInk ที่พบเห็นและซื้อได้ง่ายที่สุด
      ถ้ามองในมิติที่สำคัญต่อธุรกิจ ก็แทบเรียกได้ยากว่าเป็นผลิตภัณฑ์ที่แย่
    • ถ้า jailbreak แล้วลงอะไรอย่าง KOReader จะกลายเป็นอุปกรณ์ที่เสถียรกว่ามาก
      หลังจากนั้นก็ใส่หนังสือผ่าน Calibre หรือ SFTP ได้
    • เคยใช้เครื่องอ่านอีบุ๊กมาหลายรุ่น แต่มีแค่ Kindle ที่ทำงานได้ตามที่คาดหวังจริง ๆ
      บางเครื่องแบตหมดในไม่กี่วันจนไม่สมกับคำโฆษณาเรื่องแบตอึด บางเครื่องคุณภาพแย่จนพังในไม่กี่เดือน
      Kindle อยู่ได้หลายสัปดาห์ต่อการชาร์จหนึ่งครั้งสำหรับการอ่านวันละ 1–2 ชั่วโมงตามการใช้งานของฉัน และกันน้ำได้ เลยมีค่ามากเพราะอ่านในอ่างอาบน้ำได้ ไม่เคยเจอปัญหาอะไรเป็นพิเศษ
      UI ดูเหมือนออกแบบมาเพื่อโปรโมต Amazon Store แต่ฉันไม่ค่อยใช้ ฉันส่งหนังสือเข้าไปทางอีเมล อ่านเสร็จก็ลบ เลยโอเค
      ถ้ามีโฟลเดอร์ในไลบรารีก็คงดี และถ้าเชื่อมต่อแบบ USB storage เพื่อให้จัดการไฟล์จาก PC ได้อิสระเหมือนเครื่องอ่านอีบุ๊กอื่นก็คงดี แต่ไม่ถึงกับจำเป็น
      Kindle อาจเป็นผลิตภัณฑ์ที่แย่ก็ได้ แต่ที่เหลือดูเหมือนจะแย่กว่า ฉันไม่รู้จักแบรนด์เครื่องอ่านอีบุ๊กเจ้าไหนที่มีขนาดระดับ Amazon เลย และที่เหลือก็ดูเหมือนแบรนด์จีนไม่มีชื่อที่ไม่ได้ลงทุนกับคุณภาพหรือชื่อเสียง
    • ในช่วงสิบปีที่ผ่านมา อุปกรณ์ eInk โดยรวมดีขึ้นมาก
      ทั้ง ความเร็วในการรีเฟรช, latency, สมรรถนะการประมวลผล, ความตอบสนอง และแทบทุกด้านล้วนดีขึ้น

  • ที่มันชื่อว่า Glider นี่เป็นความบังเอิญที่น่าสนุก
    นักบินเครื่องร่อนหรือ sailplane จำนวนไม่น้อยใช้หน้าจอ eInk เพราะอ่านได้ชัดในแสงแดดจัด และมักรันอะไรอย่าง XCSoar บน Kobo หรือ Kindle ที่รูตแล้ว: https://www.xcsoar.org/hardware/

    • เรือดำน้ำบังคับด้วยคอนโทรลเลอร์ Logitech ส่วนเครื่องร่อนใช้เครื่องอ่าน eInk เป็นจอแสดงผล
      ชวนให้สงสัยว่าในยานพาหนะเฉพาะทางอื่น ๆ ยังมีเทคโนโลยีอะไรที่ถูกนำกลับมาใช้ใหม่อีกบ้าง
    • นักบินพาราไกลเดอร์ก็ใช้ชุดแบบเดียวกันเป๊ะ

  • สนใจโซลูชัน eInk มานานเพราะอาการตาล้าและตาแห้ง
    สุดท้ายพบว่าตัวเองมี สายตาเอียง เล็กน้อยมาก จักษุแพทย์ไม่ได้แนะนำให้แก้ แต่พอแก้แล้วอาการตาแห้งและตาล้าหายไปหมดเลย
    เพราะงั้นไม่ว่าจะแนวทางการสั่งจ่ายขั้นต่ำของจักษุแพทย์จะเป็นอย่างไร ก็ควรลองแก้สายตาเอียงเล็กน้อยด้วยแว่นสำหรับคอมพิวเตอร์ดู

    • เห็นด้วยกับเรื่องนี้
      ฉันมีสายตาเอียงนิดหน่อยที่ตาขวา แล้วพอแก้ด้วยแว่นอ่านหนังสือแบบสั่งตัดแทนแว่นสำเร็จรูปธรรมดา ความต่างในแง่ตาล้าและปวดหัวชัดเจนมาก
      แว่นราคาถูกก็พอช่วยได้ในระดับหนึ่งตามความรู้สึก แต่พอรู้ว่าความต่างมันมากแค่ไหนก็ประหลาดใจจริง ๆ
    • ดีใจที่คุณหาวิธีแก้ได้
      ตาแห้งกับตาล้ามักมาคู่กันบ่อย ๆ และยังมีฟอรัมเฉพาะสำหรับจัดการอาการล้าตาจากหน้าจอที่ใช้ LED ด้วย
      ถ้าใครมีปัญหาคล้ายกันก็น่าลองเข้าไปดู: https://ledstrain.org/
    • สงสัยว่า “แว่นสำหรับคอมพิวเตอร์” คืออะไร

  • ขอบคุณ zephray มากที่เอา ความรู้เรื่อง E Ink ที่มีอยู่ในหัวมาเปิดเผยเป็นโอเพนซอร์สแบบนี้
    ใน README มีข้อมูลดี ๆ เกี่ยวกับ eInk เยอะมาก ฉันอ่านไปแล้วพอสมควร และคิดว่าน่าจะได้ใช้อ้างอิงไปอีกหลายปี

  • เป็นเอกสารที่ยอดเยี่ยมมาก
    ฉันอยากทำอุปกรณ์ที่ใช้จอ eInk เพื่อการเรียนรู้มานานแล้ว แต่ที่ผ่านมาเคยทำแต่ซอฟต์แวร์เลยไม่รู้จะเริ่มจากตรงไหน
    เอกสารนี้น่าจะช่วยการเรียนรู้นั้นได้มากทีเดียว

  • GitHub ที่ลิงก์ไว้จริง ๆ แล้วเป็นมิเรอร์ของ repository บน GitLab ต้นฉบับ: https://gitlab.com/zephray/glider

  • สงสัยว่าเคยมีใครสำรวจแนวคิดการเพิ่ม feedback control ให้กับจอ eInk บ้างไหม
    รู้สึกว่าอาการกะพริบและความหน่วงของ eInk นั้นเกิดจากการที่คอนโทรลเลอร์ทำงานแบบ open-loop ล้วน ๆ

  • อยากเอาจอ eInk แบบนี้ไปทำ Compact Mac clone
    นึกภาพออกเลยว่ามันจะดูเท่แค่ไหน

    • มันอาจดูดีได้ [1]
      แค่ยังไม่เคยเห็นจอ eInk ที่รีเฟรชเร็วพอจะรับมือกับเคอร์เซอร์ที่กะพริบได้ แต่ทุกวันนี้ถ้ามีไดรเวอร์ที่เหมาะสมก็คงอาจทำได้
      [1] https://engineersneedart.com/systemsix/systemsix.html
    • ถ้ามีอุปกรณ์ทรง 12-inch MacBook ที่ใส่จอ eInk เปิดไฟเรืองแสงสีส้มตอนกลางคืนได้ตามต้องการ และรันอะไรที่คล้าย Classic Mac OS ก็น่าจะเป็น เครื่องสำหรับเขียน ที่นิ่งสงบและพกพาง่ายมาก
      แบตก็น่าจะอยู่ได้เป็นสัปดาห์ด้วย
    • แค่มี Newton แบบ eInk ฉันก็พอใจแล้ว
    • หรือจะชุบชีวิต Palm Pilot ขึ้นมาใหม่ก็ยังดี