המסך הוא רק הזכוכית: מה באמת קורה כשמוסיפים תצוגה למוצר Embedded

כדי להבין את המערכת, עקבו אחרי פיקסל אחד. קוד ה־GUI מחליט שכפתור צריך להיות כחול, מנוע הציור מחשב את ערכי הצבע וכותב אותם לזיכרון, בקר התצוגה קורא את הזיכרון שורה אחרי שורה, וממשק התצוגה מעביר את הביטים אל הפאנל בתזמון מדויק. במקביל בקר המגע שולח קואורדינטות בכיוון ההפוך, ודרייבר התאורה האחורית קובע כמה אור ייצא מן ה־LCD. אם אחת החוליות אינה עומדת בקצב או אינה מדברת את אותו ממשק, המסך עלול להיות שחור גם כשהאפליקציה עצמה רצה מצוין.

לפני הממשקים צריך לסדר שלושה שמות שמופיעים בהצעות מחיר: Display Panel, ‏Display Module ו־Smart Display. אלה אינם מונחים אחידים לחלוטין בין היצרנים, ולכן לא קונים לפי הכותרת אלא לפי תרשים הבלוקים. לצורך התכנון נוח לחשוב עליהם כשלוש דרגות של אינטגרציה: פאנל שמצפה לקבל פיקסלים, מודול שמוסיף אלקטרוניקה מסביב לפאנל, ומסך חכם שמקבל מן המוצר מידע או פקודות ומצייר חלק מן הממשק בעצמו.

פאנל LCD גולמי יחסית כולל את הזכוכית, מערכי הפיקסלים והאלקטרוניקה הנמוכה שמניעה שורות ועמודות. לעיתים הוא כולל גם תאורה אחורית ו־Timing Controller, אבל אין בו זיכרון שמחזיק תמונה מלאה ואין בו הבנה של כפתורים, גרפים או טקסט. המעבד חייב לספק זרם פיקסלים רציף גם כשהתמונה אינה משתנה. לכן פאנל שנראה זול דורש מן המערכת בקר תצוגה, Framebuffer, תזמון מדויק וממשק שתואם לכניסה שלו.

Display Module מוסיף שכבה שימושית: הוא עשוי לכלול בקר תצוגה עם GRAM — זיכרון גרפי מקומי — רכיב Touch, דרייבר Backlight או Bridge שממיר ממשק. במודול עם GRAM המעבד יכול לשלוח אזור שהשתנה ולתת למודול להמשיך לרענן את הזכוכית בעצמו. במודול עם Bridge המעבד עדיין מצייר את כל התמונה, אך אינו חייב לדבר בממשק החשמלי המקורי של הפאנל. המילה Module לבדה אינה אומרת איזו מן האפשרויות קיבלתם.

Smart Display עולה עוד מדרגה ומוסיף MCU או MPU, זיכרון, Runtime ולעיתים כלי עיצוב. במקום להעביר מיליוני פיקסלים בכל שנייה, הבקר הראשי יכול לשלוח ב־UART, ‏CAN או Ethernet פקודה כמו 'הטמפרטורה עכשיו 74' והמסך החכם יעדכן את המחוון. זה מוריד דרישות מן המעבד הראשי ומקצר Bring-up, אבל מעביר עלות ושליטה אל המודול: יש עוד קושחה, פרוטוקול, כלי ספק, זמן אתחול ושאלת עדכונים. מבחינת הארכיטקטורה זה כבר מחשב קטן שמחובר למוצר, לא רק מסך.

אחרי שהבנו מי מחזיק את התמונה, מגיעה שאלת ההתאמה: מה המעבד יודע להוציא ומה המסך דורש לקבל. אם לשניהם יש אותו ממשק ובאותם מתחים, אפשר לחבר אותם ישירות בתכנון נכון. אם המעבד מוציא RGB והפאנל מקבל LVDS, או שה־SoM מוציא MIPI-DSI והמסך שנבחר הוא eDP, חסרה חוליה באמצע. אותה אי־התאמה היא אחת הסיבות הנפוצות לכך שמסך זול יוצר מערכת יקרה.

RGB מקבילי, שנקרא גם DPI, ‏DOTCLK ולעיתים TTL RGB, הוא המסלול הישיר ביותר. המעבד מוציא בדרך כלל 16, 18 או 24 קווי צבע, ולצדם Pixel Clock, ‏HSYNC, ‏VSYNC ו־DE שמסמן מתי הנתונים תקפים. בפורמט RGB888 יש שמונה ביטים לאדום, שמונה לירוק ושמונה לכחול, ולכן עם אותות הבקרה מגיעים בקלות לכ־28 קווים. בקר כמו LTDC קורא את ה־Framebuffer ומניח בכל פעימת שעון את צבע הפיקסל הבא על הקווים.

המילה TTL עלולה להטעות. בעולם המסכים משתמשים בה לעיתים כשם לאותות מקביליים Single-Ended, לא כהבטחה לרמות מתח של רכיב TTL ישן; בפועל הפאנל עשוי לעבוד ב־1.8 או ב־3.3 וולט. צריך לבדוק מתחי I/O, קוטביות, קצה הדגימה וזמני Setup ו־Hold בשני דפי הנתונים. היתרון של RGB הוא שאין בהכרח רכיב המרה. המחיר עובר לפינים, למחבר רחב, ל־Routing של עשרות קווים, ל־Skew בין אותות ול־EMI שעולה יחד עם ה־Pixel Clock.

LVDS נולד בדיוק מן הכאב הזה. Serializer מקבל את קווי ה־RGB והסנכרון במקביל, אורז אותם לקצב סריאלי ומוציא כמה זוגות דיפרנציאליים ועוד זוג שעון. בדוגמה נפוצה, 28 אותות מקביליים הופכים לארבעה זוגות נתונים וזוג Clock. מפני שכל זוג נושא הפרש מתח קטן ושני המוליכים שלו נעים יחד, הממשק מקרין פחות, עמיד יותר לרעש ונוח יותר להעברה בכבל מאשר עשרות קווי RGB חד־קוטביים.

גם כאן אין קסם. יש התאמות מיפוי כמו JEIDA מול VESA, עומק צבע של שישה או שמונה ביטים לערוץ, קוטביות, טרמינציה ומגבלת Skew בין הזוגות. LVDS של פאנל מתאים בדרך כלל למרחק גדול יותר מ־RGB על לוח, אך הוא אינו הבטחה לכל כבל ולכל אורך; בקצב גבוה המחבר, איכות הכבל ותקציב ה־Jitter קובעים. במערכות רכב או מצלמות מרוחקות משתמשים לעיתים ב־SerDes ייעודי כמו FPD-Link, שהוא משפחה אחרת ולא שם חלופי אוטומטי ל־LVDS של מסך.

MIPI-DSI מצמצם עוד יותר את מספר הקווים, אך מוסיף פרוטוקול. בצד המעבד יש DSI Host שאורז פקודות ונתוני תמונה למנות, ומתחתיו D-PHY שמטפל בשכבה החשמלית, ב־lanes ובמעבר בין מצבי Low-Power ל־High-Speed. לכן סימון DSI בדף המוצר של המעבד אינו מספיק: צריך לבדוק כמה lanes קיימים, מה הקצב שלהם, אילו מצבים נתמכים והאם ה־PHY משולב. DSI תוכנן בעיקר לקישור קצר בתוך המוצר, לא כתחליף כללי לכבל תעשייתי ארוך.

ב־DSI Video Mode המערכת מתנהגת בדומה ל־RGB רציף. ה־Framebuffer נמצא בצד המעבד, בקר התצוגה מייצר את התזמון, וה־DSI Host שולח את הווידאו כמנות בקצב שמחזיק את הפאנל חי. היתרון הוא פחות פינים ורוחב פס גבוה על זוגות מהירים. המחיר הוא שזיכרון המערכת וה־display pipeline ממשיכים לעבוד בכל Refresh גם כאשר מוצג לוגו שאינו זז.

ב־DSI Command Mode המעבד שולח פקודות וגושי פיקסלים לבקר שבתוך מודול התצוגה, בדרך כלל אל GRAM מקומי. אם רק הספרה של הטמפרטורה השתנתה, אפשר לעדכן מלבן קטן במקום להזרים מחדש את כל המסך. זה חוסך תעבורה והספק ומתאים ל־Partial Framebuffer, אך רק כאשר הפאנל והבקר הספציפיים תומכים בכתיבת חלון, ב־GRAM ובסנכרון מתאים כמו TE — אות Tearing Effect. DSI כשלעצמו אינו מבטיח אף אחת מן היכולות האלה, ולא כל פאנל תומך גם ב־Video וגם ב־Command Mode.

eDP — ‏Embedded DisplayPort — נפוץ יותר ליד MPU, ‏SoM ו־Linux ובמסכים בעלי רזולוציה גבוהה. הוא אינו רק 'עוד זוגות מהירים': ה־Main Link נושא את הווידאו, ערוץ AUX דו־כיווני משמש לקריאת יכולות ולבקרה, ו־HPD יכול לדווח על נוכחות או אירוע של הפאנל. לפני שמתחיל וידאו, המקור והמסך מבצעים Link Training כדי לבחור מספר lanes, קצב, Swing ו־Pre-emphasis שעובדים יחד. כאשר ה־controller וה־PHY אינם משולבים ב־SoC, התכונות האלה עוברות ל־Bridge חיצוני ולדרייבר שצריך להפעיל אותו.

כאן חשוב להפריד בין שלושה תפקידים שנוטים להתערבב. PHY הוא השכבה החשמלית: משדרים, מקלטים, רמות מתח, טרמינציה ו־lanes. Serializer משנה ייצוג מקבילי לסריאלי, כמו אריזת RGB לכמה זרמי LVDS. Bridge מסיים ממשק אחד ומייצר ממשק אחר, למשל RGB ל־LVDS או DSI ל־eDP; לכן הוא מבין פרוטוקול, שעונים ולעיתים גם שומר כמה שורות ב־Buffer. רכיב Bridge יכול להכיל בתוכו גם PHY וגם Serializer, כך שמדובר בפונקציות ולא בהכרח בשלושה שבבים נפרדים.

Interface Mismatch הוא המקום שבו המחיר מתחיל לגדול בשקט. Bridge מוסיף רכיב, מארז, מסילות מתח, Clock, רכיבי עזר, כתובת I²C ורצף אתחול. הוא מוסיף גם שני צדדים מהירים ל־PCB במקום אחד, ולעיתים מחייב יותר שכבות, Impedance Control ובדיקות Signal Integrity. ב־Bring-up כבר לא שואלים רק 'האם הפאנל מציג', אלא 'האם המקור מייצר Timing נכון, האם ה־Bridge ננעל, האם הצד היוצא עבר Training והאם הכבל שומר על איכות האות'.

לפני בחירת המסך אני רוצה לראות טבלה אחת עם ארבעה שדות: יציאת התצוגה המדויקת של המעבד, כניסת הפאנל המדויקת, קצב הפיקסלים עם כל זמני ה־Blanking, ומתחי ה־I/O. לידם אני מוסיף מי מאתחל את הפאנל, מי שולט ב־Reset וב־Backlight, והיכן נמצאים GRAM ו־Framebuffer. אם אחד השדות כתוב כ־'בערך DSI' או 'מסך LVDS רגיל', התכנון עדיין לא התחיל. התרשים המצורף מראה מדוע אותן תמונות דורשות מערכות שונות לגמרי בדרך אל הזכוכית.

Framebuffer הוא אזור זיכרון שבו כל תא מייצג צבע של פיקסל. הנוסחה הראשונית היא Width × Height × Bytes per pixel, אבל ב־Bring-up מוסיפים עוד מילה: Storage. ‏RGB888 הוא 24 ביטים מבחינה לוגית, אך בקר מסוים עשוי לשמור כל פיקסל בארבעה בתים לצורך יישור, וכל שורה עשויה לקבל Padding שנקרא Stride או Pitch. לכן את החישוב הסופי עושים לפי פורמט האחסון וה־Stride של הבקר, לא רק לפי שם הצבע בחוברת השיווקית.

RGB565 שומר חמישה ביטים לאדום, שישה לירוק וחמישה לכחול בתוך שני בתים. הוא חוסך חצי מן הזיכרון והתעבורה לעומת פורמט של 32 ביט, אך מעברי צבע עדינים עלולים להראות מדרגות. RGB888 נותן שמונה ביטים לכל צבע ובאחסון Packed צורך שלושה בתים, ואילו ARGB8888 צורך ארבעה בתים ומוסיף שמונה ביטים של Alpha לשקיפות ול־Blending. ה־Alpha אינו מצייר שקיפות לבדו; מנוע ציור או Compositor חייב לקרוא אותו ולשלב שתי שכבות. חשוב גם שפאנל RGB888 יכול לקבל תמונה שמקורה ב־Framebuffer מסוג RGB565 — יציאת הפאנל ופורמט הזיכרון הן החלטות קשורות, אך אינן אותה החלטה.

נחשב מסך נפוץ של 800 על 480. ב־RGB565 מתקבלים 768,000 בתים, כלומר 750 ‏KiB ל־Framebuffer אחד וכ־1.46 ‏MiB לשניים. ב־RGB888 Packed מתקבלים 1,152,000 בתים, וב־ARGB8888 כבר 1,536,000 בתים, כמעט 1.47 ‏MiB לתמונה אחת וכ־2.93 ‏MiB לשתיים. זה עוד לפני פונטים, תמונות, Stack, ‏Heap, Buffer למגע, קושחה ונתוני המוצר. אם ל־MCU יש מגה־בייט אחד של SRAM, הכותרת 'עד 800×480' עדיין אינה אומרת שהיישום הרצוי נכנס בו.

Double Buffering נותן שני דפים: בקר התצוגה סורק את ה־Front Buffer בזמן שה־CPU, ‏DMA או GPU מציירים את הפריים הבא ב־Back Buffer. כאשר הציור הסתיים מחליפים ביניהם, אבל ההחלפה חייבת להתרחש ב־VSync או בזמן ה־Vertical Blanking, כשהסריקה סיימה את התמונה. אם משנים את הכתובת באמצע, גם שני Buffers יכולים להציג Tearing — קו שמעליו רואים פריים חדש ומתחתיו ישן. אם הציור לא הסתיים בזמן, עדיף להציג שוב את הפריים הקודם מאשר לבצע החלפה באמצע; התוצאה תהיה גמגום קטן במקום תמונה קרועה.

Partial Framebuffer הוא שם לכמה שיטות שונות. במסך עם GRAM אפשר להחזיק רצועה או כמה Tiles, לצייר רק את האזורים שהשתנו ולשלוח אותם לבקר התצוגה; זה מתאים במיוחד ל־SPI, ל־DSI Command Mode ול־Smart Display. אם רוב המסך מונפש, עדיין צריך להעביר כמעט את כל הפיקסלים והחיסכון נשאר בעיקר ב־RAM, לא בזמן. במסך ללא GRAM, שדורש Scan-out רציף, Buffer חלקי רגיל אינו יכול להיעלם באמצע שורה; נדרש מנגנון מיוחד כמו GFXMMU שמדמה Framebuffer, או תזמון הדוק שמעלה עומס וסיכון לקריעה.

עכשיו מגיע הנתון שנשכח ליד גודל הזיכרון: Memory Bandwidth. סריקת הפיקסלים הפעילים בלבד במסך 800×480 ב־60 הרץ דורשת בערך 46 מגה־בייט לשנייה ב־RGB565 וכ־92 מגה־בייט לשנייה בפורמט של ארבעה בתים. אלה רצפות חישוב, לא תקציב סופי; ה־Pixel Clock כולל גם מרווחי Blanking, והציור מוסיף כתיבות וקריאות. פעולת Alpha Blending מלאה על שני Buffers של 32 ביט קוראת שני מקורות וכותבת יעד, ולכן יכולה להוסיף לבדה כ־276 מגה־בייט לשנייה בקצב של 60 פריימים.

הזיכרון אינו צינור פרטי של המסך. באותו רגע בקר התצוגה קורא, ה־CPU מעדכן Widgets, ‏DMA2D מעתיק תמונה, GPU קורא Texture, מצלמה כותבת Frame ו־Ethernet או USB מפעילים DMA משלהם. רוחב הפס התיאורטי של SDRAM אינו מה שנשאר לאחר Arbitration, ‏Refresh, ‏Latency, ‏Cache וגבולות Burst. כאשר ה־FIFO של בקר התצוגה מתרוקן מתקבל Underrun, והוא נראה כמו קווים, הבהובים או תמונה פגומה. לכן בודקים את מסך ה־Worst Case על החומרה האמיתית ומנטרים את דגלי ה־Underrun, לא מסתפקים בכך שסכום ה־RAM עבר את הנוסחה.

SRAM פנימי הוא המקום הנוח ביותר ל־Framebuffer: זמן הגישה קצר, אין פינים חיצוניים וה־PCB פשוט. הוא מתאים למסכים קטנים, לפורמט חסכוני או למערכת שמשתמשת ב־Buffer חלקי. ברגע שנוספים Double Buffer, רזולוציה גבוהה, פונטים רבים, Assets, אנימציות, וידאו או מערכת הפעלה, הנפח נגמר מהר. לפני שבוחרים זיכרון חיצוני צריך גם לבדוק שכל ה־Bus Masters — בקר התצוגה, DMA והמאיץ — יכולים בכלל לגשת לאזור הזה; לא כל SRAM שקרוב ל־CPU נגיש לכל Peripheral.

SDRAM מקבילי נותן Bus רחב ורוחב פס טוב, אך צורך פינים ומסלולים ומחייב תכנון Clock ו־Timing. DDR נותן צפיפות וקצב גבוהים ומתאים ל־MPU ול־Linux, אבל מביא Controller ו־PHY, ‏Power Sequencing, ‏Layout ו־Bring-up של זיכרון מהיר. PSRAM הוא DRAM שמבצע Refresh פנימי ונראה למארח דומה יותר ל־SRAM. ‏HyperRAM הוא סוג נפוץ של PSRAM על Bus סריאלי DDR עם מעט פינים; הוא יכול להיות פתרון מצוין ל־MCU גרפי, אך ה־Latency, אורך ה־Burst ואיכות בקר הזיכרון קובעים אם רוחב הפס באמת מספיק. אין זיכרון 'הכי טוב' בלי למדוד את התנועה של המערכת.

LTDC של ST, ‏LCDIF של NXP ו־GLCDC של Renesas הם Display Controllers. התפקיד המרכזי שלהם הוא לקרוא Buffer מוכן, לייצר Pixel Clock ו־Sync, לטפל בשכבות קבועות או בהמרת פורמט ולהוציא Scan-out רציף. הם עשויים לתמוך ב־Planes, ‏CLUT, ‏Dithering, ‏Gamma ו־Alpha בין שכבות, אבל הם אינם מבינים Widget ואינם מציירים עיגול לפי פקודת אפליקציה. לקרוא להם GPU יוצר ציפייה לא נכונה; הם הסורק שמוציא את הדף, לא הצייר שמכין אותו.

Graphics Accelerators נמצאים בצד הציור. DMA2D, שנקרא ב־STM32 גם Chrom-ART, מאיץ פעולות חוזרות כמו Fill, ‏Copy, המרת פורמט ו־Alpha Blending. ‏PXP של NXP מוסיף בגרסאות המתאימות Scaling, ‏Rotation ו־Composition, ומנועי 2D של Renesas מטפלים בקבוצה משלהם של פעולות. אלה אינם שמות חלופיים לאותו בלוק, ולכן בודקים במפורש אם הפעולה הכבדה ב־UI — למשל סיבוב תמונה, Rasterization של וקטור או שינוי גודל — באמת נתמכת. מאיץ שאינו יודע לבצע את הפעולה מחזיר אותה ל־CPU גם אם בדף המוצר כתוב Graphics Accelerator.

גם המילים GPU2D, ‏2.5D ו־3D אינן סולם תקני אחד. מנוע 2D קלאסי מטפל ב־Bitmaps, מילוי, העתקה, Blending ולעיתים Paths ו־Fonts. ‏NeoChrom של ST נקרא 2.5D מפני שהוא מוסיף Scaling, סיבוב חופשי, Texture Mapping והקרנה עם Perspective בלי להפוך ל־GPU תלת־ממדי כללי. GPU 3D כבר מביא צינור Vertex ו־Fragment, ‏OpenGL ES או Vulkan, ניהול זיכרון ודרייברים ב־Kernel וב־User Space. הוא מתאים ל־Qt עשיר, Android, ממשקי Web וגרפיקה תלת־ממדית, אך המחיר הוא BSP וערימת תוכנה שחייבים להתאים לחומרה.

רק עכשיו נכון לבחור Framework. קודם מגדירים רזולוציה, קצב שינוי, זמן עלייה, מספר שכבות, גרפים, וידאו, עברית ואנימציות; אחר כך בודקים איזו תוכנה מתאימה למשאבים ולידע של הצוות. Framework אינו מייצר רוחב פס ואינו מוסיף GRAM לפאנל. הוא יכול לנצל Buffer חלקי, DMA או GPU רק אם ה־Port, הדרייבר והחומרה שמתחתיו בנויים לכך.

LVGL הוא מנוע GUI ב־C שמתאים גם ל־MCU ו־RTOS וגם ל־MPU ול־Linux. הוא יכול לעבוד עם Draw Buffer קטן ממסך מלא, ולכן הוא נקודת פתיחה טובה כשאין מקום לשני Framebuffers. הרישיון הפתוח והניידות בין יצרנים הם יתרון, אך האחריות על Display Driver, ‏Flush, ‏Cache, ‏DMA, ‏Touch ותזמון נשארת אצל צוות המוצר. LVGL קטן אינו הופך SPI איטי או SDRAM עמוס למהירים.

TouchGFX מכוון ל־STM32 ומשלב Designer, מחולל קוד, מנוע C++ ותבניות ללוחות. כאשר החומרה מתאימה, הוא יודע לנצל LTDC, ‏DMA2D, ‏NeoChrom ואסטרטגיות Framebuffer של ST. זה יכול לקצר מאוד את הדרך על לוח נתמך. בלוח מותאם עדיין צריך לבצע Board Bring-up אמיתי: זיכרון חיצוני, כתובת Framebuffer, ‏Accelerator, ‏Touch, ‏Flash Loader, ‏Backlight ותזמוני הפאנל. המילה 'חינם' מתארת את רישיון הכלי ל־STM32, לא את שעות האינטגרציה.

Qt המלא נפוץ ב־MPU עם Embedded Linux, ‏DDR ו־GPU. יישום יחיד יכול לעבוד במסך מלא דרך EGLFS או DRM, ומערכת מרובת תהליכים יכולה להשתמש ב־Wayland. חשוב לדייק: קיים גם Qt for MCUs עם Qt Quick Ultralite, מוצר אחר שמכוון למיקרו־בקרים ובעל דרישות ורישוי משלו. לכן השאלה אינה 'האם Qt כבד', אלא איזו משפחת Qt, איזו חומרה, איזה Backend והאם ה־BSP מספק האצה גרפית שעובדת בגרסה שנבחרה.

Web UI מכניס למוצר מנוע Browser כמו WPE WebKit או Chromium, יחד עם HTML, ‏CSS ו־JavaScript. הוא מאפשר לצוות Frontend לעבוד בכלים מוכרים, אך צריך Renderer, ‏GPU או ציור תוכנתי, מנגנון IPC אל לוגיקת המוצר, תיקוני אבטחה וניהול תלויות לאורך שנים. Flutter מגיע עם Engine ו־Embedder שמספקים Surface, קלט, Event Loop ו־Threads לרינדור; התיעוד הרשמי מגדיר את ה־Embedded API כנמוך־רמה ולא כנקודת פתיחה למתחילים. בשני המקרים המסלול המעשי הוא בדרך כלל MPU עם Linux או Android וזיכרון חיצוני, לא MCU קטן עם RTOS, אף שיש Ports ופתרונות מותאמים.

בלינוקס המילה Framebuffer מתארת שלושה דברים שונים: זיכרון פיקסלים, ממשק fbdev הישן כמו ‎/dev/fb0, ואובייקט Framebuffer בתוך DRM. ‏fbdev נותן דרך פשוטה למפות זיכרון ולכתוב פיקסלים, אך מתאים בעיקר למסלול בסיסי ותוכנתי. ‏DRM/KMS מנהל Modes, ‏Connectors, ‏Planes, ‏CRTCs ו־Page Flips — כלומר את חומרת ה־Scan-out. ‏Wayland יושב מעליו כפרוטוקול בין אפליקציות ל־Compositor: כל Client מצייר ל־Surface, וה־Compositor מחליט היכן ובאיזה סדר להציג את ה־Surfaces. Wayland אינו דרייבר מסך ו־DRM אינו ספריית כפתורים.

באנדרואיד האפליקציה אינה כותבת ישירות לפאנל. היא מציירת בעזרת Canvas, ‏OpenGL ES או Vulkan אל Surface, שמזין BufferQueue. ‏SurfaceFlinger אוסף את ה־Buffers של השכבות הנראות סביב VSync ושואל את Hardware Composer אילו שכבות אפשר להרכיב בחומרת התצוגה ואילו צריך לחבר בעזרת GPU. לכן גם SoC חזק יכול להיתקע אם ה־HAL, ה־GPU Driver, מספר ה־Overlay Planes או ה־Buffer Synchronization אינם מתאימים. SurfaceFlinger מנהל Composition; הוא אינו מחליף את הצורך ב־display pipeline תקין מתחתיו.

ועכשיו לפרק שנוטים לגלות רק אחרי שה־Prototype עובד: לאן הכסף הולך. הצעת המחיר של הפאנל היא רק שורה אחת בארכיטקטורת HMI. אין יחס עלות אוניברסלי בין השורות, מפני שכמות הייצור, טווח הטמפרטורה, בהירות, אורך חיי אספקה, תקינה ודרישות מכניות משנים הכול. הדרך הנכונה היא לבנות Cost Tree שמתחיל בזכוכית ומסתיים בתחנת הבדיקה במפעל.

בצד האופטי משלמים על הפאנל, על Touch ועל Backlight. פאנל תעשייתי בהיר עם זמינות ארוכה עולה אחרת מפאנל צרכני, ומגע קיבולי מוסיף Sensor, ‏Controller, ‏FPC, ‏Cover Lens ולעיתים Optical Bonding. ב־LCD התאורה האחורית דורשת מחרוזות LED, דרייבר Boost, ‏PWM, הספק ופיזור חום; השגת בהירות בשמש מעלה גם צריכה וטמפרטורה. צריך לשאול במפורש אם הצעת המחיר כוללת Touch, דרייבר תאורה, כבל, מסגרת ועדשה, ולא להניח שהמילה Module כוללת הכול.

בצד האלקטרוני משלמים על Bridge IC, זיכרון חיצוני ו־PMIC או ספקי כוח. סביבם מגיעים Crystal או Reference Clock, מסילות 1.2/1.8/3.3 וולט, Reset ו־Sequencing, רכיבי טרמינציה והגנות. RGB רחב יכול לדרוש מארז MCU גדול, מחבר רחב ויותר שכבות PCB; ‏LVDS, ‏DSI ו־eDP דורשים זוגות מבוקרי Impedance, מחברים וכבלים מתאימים. כל מחבר מוסיף גם זמן הרכבה, מנגנון נעילה, בדיקת אמינות וסיכון של ספק נוסף.

בצד התוכנה משלמים על רישוי Framework, כלי Designer, פונטים, Codecs או Browser, אבל לעיתים הרישיון הוא החלק הקטן. BSP Bring-up כולל תזמוני פאנל, Bridge, ‏RAM, ‏Cache, ‏DMA, ‏Touch, ‏Backlight ו־Power State. אחריו מגיעים פיתוח המסכים, אנימציות, עברית ו־RTL, טיפול בשגיאות, עדכונים ותחזוקה מול גרסאות Kernel ו־GPU Driver. Demo של היצרן מוכיח שהצירוף שלו עובד; הוא אינו מוכיח שהפאנל, הזיכרון וה־PCB שלכם יעבדו באותה תצורה.

במפעל משלמים שוב, הפעם על ודאות. צריך לבדוק פיקסלים תקועים, תאורה, Touch בכל הפינות, כיול, כבל, Boot קר וחם, Resume, ניתוק מתח באמצע עדכון וגרסת קושחה. לפני ייצור בודקים גם EMI, ‏ESD, חום, שמש, כפפות, לחות ו־Worst-Case Bandwidth בזמן ש־Ethernet או מצלמה פעילים. תחנת הייצור צריכה לצרוב, להציג Pattern, לקרוא Touch ולשמור תוצאה. Yield נמוך או Rework של FPC עדין יכולים למחוק במהירות את החיסכון שהושג בפאנל זול יותר.

סדר ההחלטות המעשי הוא הפוך מקטלוג מסכים. מתחילים במה שהמשתמש צריך לראות ובקצב שבו הוא משתנה, מחשבים זיכרון ורוחב פס, בוחרים ארכיטקטורת Buffer, ורק אז מתאימים מעבד, ממשק ופאנל. לאחר מכן בונים מסך Worst Case עם גרף, עברית, שקיפות ואנימציה, מודדים Boot, ‏Frame Time, ‏Underrun, עומס CPU וצריכת חשמל, ומבצעים בדיקת EMI מוקדמת. אם התכנון עובד רק כאשר מכבים את הרשת ומציגים מסך סטטי, הוא עדיין לא עבר Bring-up.

החלק המעניין פה הוא שמסך מכריח את כל המערכת להסכים על אותה שרשרת של זמן, זיכרון וחשמל. פיקסל מתחיל כהחלטה בתוכנה, הופך לבתים ב־RAM, עובר דרך מנוע ציור ובקר Scan-out, נארז לממשק ונגמר כאור. כל שלב יכול לחסוך רכיב או להוסיף סיכון, ולכן העלות האמיתית של HMI אינה המסך בלבד — היא הארכיטקטורה שמסביבו. מי שבוחר קודם את מסלול הפיקסל יכול לבחור אחר כך את הזכוכית בשקט; מי שמתחיל מן הזכוכית מגלה לעיתים שהמוצר כולו צריך להיבנות סביבה מחדש.