ข้อมูลจำเพาะทางเทคนิคของบอร์ดพัฒนากล่องทีวี Linux และ Android Dual-OS

เหตุใดสถาปัตยกรรม Dual-OS จึงมีความสำคัญในบอร์ดพัฒนากล่องทีวี

บอร์ดอ้างอิง Android TV Box ทั่วไปมักได้รับการปรับให้เหมาะกับกรณีการใช้งานของผู้บริโภคเพียงรายเดียว วิธีการดังกล่าวจะกลายเป็นข้อจำกัดเมื่อแพลตฟอร์มฮาร์ดแวร์เดียวกันต้องรองรับมิดเดิลแวร์ IPTV, แอปพลิเคชันป้ายดิจิทัล, อินเทอร์เฟซทางอุตสาหกรรม, การเล่นสื่อในเครื่อง หรือปริมาณงานการประมวลผลแบบ Edge

บอร์ดพัฒนาระบบปฏิบัติการคู่ Linux และ Android มอบสถาปัตยกรรมทางวิศวกรรมที่ยืดหยุ่นมากขึ้น

โดยทั่วไปแล้ว Android เป็นที่นิยมเมื่อแอปพลิเคชันต้องการ:

• ความเข้ากันได้ของแอปพลิเคชัน Android
• หน้าจอสัมผัสหรืออินเทอร์เฟซ HMI แบบกำหนดเอง
• แอปพลิเคชัน IPTV และ OTT
• สภาพแวดล้อมแอปพลิเคชันที่เข้ากันได้กับ Google หากมี
• ตัวเรียกใช้งานที่กำหนดเองและ UI/UX ที่มีตราสินค้า
• แอปพลิเคชั่นเครื่องเล่นสื่อเชิงพาณิชย์

Linux จะมีคุณค่าเมื่อโครงการต้องการ:

• บริการฝังตัวที่มีน้ำหนักเบา
• นักเทียบท่าหรือแอปพลิเคชันคอนเทนเนอร์
• อินเทอร์เฟซการควบคุมทางอุตสาหกรรม
• เกตเวย์เครือข่าย
• ปริมาณงานการประมวลผลแบบ Edge
• สภาพแวดล้อมแอปพลิเคชัน Python/C/C++
• การปรับแต่งระดับระบบโอเพ่นซอร์ส
• บริการพื้นหลังที่ทำงานยาวนาน

คำถามทางวิศวกรรมที่สำคัญไม่ใช่แค่ว่าบอร์ดสามารถ "รัน Android และ Linux" ได้หรือไม่ บอร์ดจะต้องมีสถาปัตยกรรมการบูตที่เสถียร การรองรับ BSP ที่เหมาะสม ไดรเวอร์เคอร์เนล การเร่งความเร็ว GPU/VPU ไดรเวอร์อุปกรณ์ต่อพ่วง และชุดซอฟต์แวร์ที่สามารถบำรุงรักษาได้สำหรับระบบปฏิบัติการทั้งสอง

สำหรับโครงการ B2B ความแตกต่างนี้ส่งผลโดยตรงต่อต้นทุนการพัฒนาและวงจรชีวิตผลิตภัณฑ์

ข้อมูลจำเพาะทางเทคนิคหลักในการประเมิน

ควรเลือกโปรเซสเซอร์ตามปริมาณงานที่ต้องการ แทนที่จะเลือกคะแนนเกณฑ์มาตรฐานเพียงอย่างเดียว

คณะกรรมการพัฒนาเชิงมัลติมีเดียสมัยใหม่ควรได้รับการประเมินตามสถาปัตยกรรมต่อไปนี้:

SoC และสถาปัตยกรรมวิดีโอ

สำหรับบอร์ดพัฒนามัลติมีเดีย สถาปัตยกรรมวิดีโอมักจะมีความสำคัญมากกว่าความถี่ดิบของ CPU

แพลตฟอร์มควรได้รับการประเมินสำหรับการถอดรหัสแบบเร่งด้วยฮาร์ดแวร์มากกว่าการถอดรหัสซอฟต์แวร์ H.265/HEVC และ VP9 ยังคงมีความสำคัญสำหรับสื่อที่มีความละเอียดสูง ในขณะที่การรองรับ AV1 มีความเกี่ยวข้องมากขึ้นสำหรับแอปพลิเคชันสตรีมมิ่งและการกระจายเนื้อหารุ่นใหม่

ตัวอย่างเช่น SoC ที่รองรับ 8K อาจสนับสนุนการผสมผสานที่แตกต่างกันอย่างมากของ:

• ถอดรหัส 8K
• เข้ารหัส 8K
• เอาต์พุต 4K60
• ถอดรหัส AV1
• การประมวลผล HDR
• เอาต์พุตการแสดงผลหลายรายการ
• ฮาร์ดแวร์ deinterlacing
• วิดีโอหลังการประมวลผล

ข้อมูลจำเพาะเหล่านี้ควรได้รับการตรวจสอบในระดับซิลิคอนและ BSP การอ้างเอกสารข้อมูลของ "การสนับสนุน 8K" ไม่ได้หมายความว่าแอปพลิเคชันสามารถรักษาการเล่น 8K ไว้ได้โดยอัตโนมัติภายใต้บิลด์ Linux หรือ Android ที่ปรับแต่งเอง

การกำหนดค่าหน่วยความจำและที่เก็บข้อมูล

การเลือกหน่วยความจำควรสะท้อนถึงสถาปัตยกรรมซอฟต์แวร์

เทอร์มินัล IPTV พื้นฐานอาจทำงานได้อย่างมีประสิทธิภาพด้วย RAM 2GB หรือ 4GB ในขณะที่เทอร์มินัลป้ายดิจิทัลที่ใช้ Chromium บริการที่หลากหลาย ซอฟต์แวร์การจัดการระยะไกล และการแคชเนื้อหาในเครื่องอาจต้องใช้หน่วยความจำเพิ่มเติม

พื้นที่จัดเก็บควรได้รับการประเมินเกินความจุด้วย

การเลือก eMMC ส่งผลต่อ:

• ความน่าเชื่อถือในการบูต
• การติดตั้งแอพพลิเคชั่น
• กลยุทธ์การอัพเดต OTA
• การบันทึก
• เขียนความอดทน
• ความน่าเชื่อถือของสนามในระยะยาว

สำหรับการปรับใช้เชิงพาณิชย์ การแบ่งพาร์ติชัน A/B OTA สามารถให้กลไกการอัพเดตเฟิร์มแวร์ที่ปลอดภัยยิ่งขึ้น พาร์ติชันระบบที่ไม่ได้ใช้งานสามารถรับอิมเมจใหม่ได้ในขณะที่เวอร์ชันปัจจุบันยังคงมีอยู่สำหรับการย้อนกลับ

ซึ่งเหมาะสมกว่าสำหรับการปรับใช้ B2B ที่มีการจัดการมากกว่าการแฟลชเฟิร์มแวร์ที่มุ่งเน้นผู้บริโภคซ้ำๆ เป็นอย่างมาก

Linux/Android BSP และการเพิ่มประสิทธิภาพเคอร์เนล

ระบบปฏิบัติการเป็นเพียงส่วนหนึ่งของแพลตฟอร์มบอร์ดพัฒนา BSP จะกำหนดว่าฮาร์ดแวร์จะกลายเป็นผลิตภัณฑ์ที่ใช้งานได้อย่างมีประสิทธิผลเพียงใด

แพลตฟอร์ม dual-OS ระดับมืออาชีพควรให้การเข้าถึง:

Bootloader → เคอร์เนล → แผนผังอุปกรณ์ → ไดรเวอร์ → HAL/BSP → มิดเดิลแวร์ → เลเยอร์แอปพลิเคชัน

Android และ Linux อาจใช้ฮาร์ดแวร์พื้นฐานเดียวกันในขณะที่ต้องใช้ไดรเวอร์และการกำหนดค่าระบบที่แตกต่างกัน

สาขาวิศวกรรมที่สำคัญ ได้แก่ :

• การกำหนดค่า U-Boot
• เวอร์ชันและแพตช์เคอร์เนล Linux
• การรวมเคอร์เนล Android
• การกำหนดค่าแผนผังอุปกรณ์
• ไดรเวอร์ GPU/VPU
• ไดรเวอร์ HDMI
• ไดรเวอร์อีเธอร์เน็ตและ Wi-Fi
• สแต็คบลูทูธ
• โฮสต์ USB/การกำหนดค่าอุปกรณ์
• ไดรเวอร์ MIPI CSI/DSI
• ไดรเวอร์ตัวแปลงสัญญาณเสียง
• การกำหนดค่าการจัดการพลังงาน
• ระงับ/ดำเนินพฤติกรรมต่อ
• การกำหนดค่า Watchdog
• การจัดการความร้อน

สำหรับโครงการ OEM การบูรณาการ SDK/API ก็มีความสำคัญไม่แพ้กัน บอร์ดพัฒนาที่ทำงานเฉพาะกับ SDK อ้างอิงคงที่อาจกลายเป็นคอขวดในการพัฒนาเมื่อลูกค้าต้องการแอปพลิเคชันที่เป็นกรรมสิทธิ์ การจัดการระยะไกล อุปกรณ์ต่อพ่วงที่ปรับแต่งเอง หรือเวิร์กโฟลว์สื่อเฉพาะทาง

การออกแบบ PCBA: การย้ายจากบอร์ดพัฒนาไปสู่ฮาร์ดแวร์การผลิต

บอร์ดพัฒนาควรถือเป็นแพลตฟอร์มอ้างอิงทางวิศวกรรม ไม่จำเป็นต้องเป็น PCBA การผลิตขั้นสุดท้าย

เมื่อข้อกำหนดของแอปพลิเคชันได้รับการตรวจสอบแล้ว ฮาร์ดแวร์จะสามารถปรับให้เหมาะสมตามการใช้งานจริงได้

การปรับเปลี่ยน PCBA โดยทั่วไป ได้แก่:

• การเปลี่ยนแปลงการกำหนดค่า RAM และ eMMC
• การเลือกอีเทอร์เน็ต PHY
• การเปลี่ยนโมดูล Wi-Fi/BT
• การกำหนดค่าพอร์ต USB
• การเปลี่ยนแปลงอินเทอร์เฟซ HDMI
• การขยาย GPIO
• การรวม RS232/RS485
• การรวม CAN บัสเมื่อจำเป็น
• ม.2 หรือขยายอุตสาหกรรม
• การรวมอินเทอร์เฟซ MIPI CSI/DSI
• การออกแบบแหล่งจ่ายไฟใหม่
• ตำแหน่งตัวเชื่อมต่อแบบกำหนดเอง
• การเพิ่มประสิทธิภาพมิติ PCB
• การปรับปรุงอีเอ็มไอ/อีเอ็มซี

นี่คือจุดที่ผู้ผลิต OEM/ODM ที่มีประสบการณ์มีข้อได้เปรียบที่สำคัญเหนือโรงงานที่เพียงแค่บรรจุบอร์ดอ้างอิงที่มีอยู่ใหม่

บริษัท เซินเจิ้น Tomato Technology Co., Ltd. สามารถรองรับการเปลี่ยนจากฮาร์ดแวร์สำหรับการพัฒนาไปเป็นฮาร์ดแวร์การผลิตที่ปรับแต่งเองได้ ผ่านการดัดแปลงฮาร์ดแวร์ PCBA, การรวม SDK/API, เฟิร์มแวร์ UI/UX แบบกำหนดเอง และวิศวกรรมความร้อน

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

วิศวกรรมความร้อนเป็นข้อกำหนดด้านประสิทธิภาพ

SoC ประสิทธิภาพสูงสร้างปัญหาการออกแบบการระบายความร้อนซึ่งไม่สามารถแก้ไขได้ด้วยซอฟต์แวร์เพียงอย่างเดียว

การถอดรหัส 4K/8K อย่างต่อเนื่อง การอนุมาน AI ปริมาณงานเครือข่าย และพื้นที่จัดเก็บข้อมูลความเร็วสูงสามารถสร้างภาระความร้อนที่ยั่งยืน ซึ่งแตกต่างอย่างมากจากการทดสอบเกณฑ์มาตรฐานระยะสั้น

คณะกรรมการพัฒนาการผลิตจึงควรได้รับการประเมินภายใต้ปริมาณงานที่ยั่งยืน

พารามิเตอร์ที่เกี่ยวข้องได้แก่:

• อุณหภูมิทางแยก SoC
• ฮีทซิงค์ต้านทานความร้อน
• การนำแผ่นความร้อน
• การไหลเวียนของอากาศในสิ่งที่แนบมา
• อุณหภูมิในการทำงานโดยรอบ
• เกณฑ์การควบคุมปริมาณ CPU/GPU
• การควบคุมพัดลม
• การใช้พลังงาน
• ความเสถียรในการเล่นวิดีโอในระยะยาว

สำหรับป้ายดิจิทัลทางอุตสาหกรรมหรือการใช้งาน IPTV ที่ทำงาน 12–24 ชั่วโมงต่อวัน การควบคุมปริมาณความร้อนอาจกลายเป็นปัญหาด้านความน่าเชื่อถือของระบบ แทนที่จะเป็นปัญหาด้านประสิทธิภาพทั่วไป

โซลูชันการระบายความร้อนแบบกำหนดเองอาจเกี่ยวข้องกับฮีทซิงค์แบบพาสซีฟขนาดใหญ่ขึ้น วัสดุเชื่อมต่อในการระบายความร้อนที่ได้รับการปรับปรุง การระบายอากาศในตู้ หรือการระบายความร้อนแบบแอคทีฟ วิธีแก้ปัญหาที่ถูกต้องขึ้นอยู่กับ PCBA สุดท้าย กล่องหุ้ม และสภาพแวดล้อมการทำงาน

จากต้นแบบสู่ผลิตภัณฑ์เชิงพาณิชย์

แพลตฟอร์ม Development Board ที่แข็งแกร่งควรลดเส้นทางทางวิศวกรรมระหว่างการพิสูจน์แนวคิดและการผลิตจำนวนมาก

กระบวนการพัฒนาเชิงปฏิบัติคือ:

1. กำหนดข้อกำหนดการสมัคร

กำหนดความละเอียดของวิดีโอ ข้อกำหนดของตัวแปลงสัญญาณ RAM พื้นที่เก็บข้อมูล ระบบเครือข่าย อินเทอร์เฟซการแสดงผล อุปกรณ์ต่อพ่วง ระบบปฏิบัติการ และอุณหภูมิในการทำงานที่คาดหวัง

2. เลือกแพลตฟอร์ม SoC

เปรียบเทียบประสิทธิภาพของ CPU/GPU/VPU/NPU, ความสมบูรณ์ของ BSP, การสนับสนุนตัวแปลงสัญญาณ, วงจรการใช้งาน และทรัพยากร SDK ที่พร้อมใช้งาน

3. ตรวจสอบ Android และ Linux

ทดสอบความเสถียรในการบูต ไดรเวอร์ การเร่งความเร็วด้วยฮาร์ดแวร์ อุปกรณ์ต่อพ่วง เครือข่าย การจัดการพลังงาน และเวิร์กโหลดระยะยาว

4. พัฒนาแอพพลิเคชั่นและเฟิร์มแวร์

ผสานรวมส่วนประกอบ SDK/API, มิดเดิลแวร์, ตัวเรียกใช้งานที่กำหนดเอง, UI/UX, การจัดการอุปกรณ์ และกลไกการอัปเดต OTA

5. เพิ่มประสิทธิภาพ PCBA

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

6. ตรวจสอบประสิทธิภาพการระบายความร้อนและความน่าเชื่อถือ

เรียกใช้ปริมาณงานที่ยั่งยืน แทนที่จะอาศัยเพียงการวัดประสิทธิภาพระยะสั้นเท่านั้น

7. ย้ายไปผลิตนำร่อง

หยุดการแก้ไขฮาร์ดแวร์ พื้นฐานเฟิร์มแวร์ และขั้นตอนการทดสอบการผลิตก่อนการผลิตจำนวนมาก

ขั้นตอนการทำงานนี้ช่วยลดความเสี่ยงในการค้นหาข้อจำกัดของฮาร์ดแวร์หลังจากที่การพัฒนาซอฟต์แวร์ได้ใช้ทรัพยากรทางวิศวกรรมที่สำคัญไปแล้ว

สิ่งที่ผู้ซื้อ B2B ควรขอจากซัพพลายเออร์บอร์ดพัฒนา

ทีมจัดซื้อจัดจ้างและผู้วางระบบควรขอมากกว่าเอกสารข้อมูลผลิตภัณฑ์

ซัพพลายเออร์ควรสามารถชี้แจง:

• รองรับระบบปฏิบัติการ Android เวอร์ชันใด?
• มี Linux distribution หรือ kernel เวอร์ชันใดบ้าง?
• มีซอร์สโค้ด BSP หรือไม่
• รองรับการแก้ไขเคอร์เนลหรือไม่
• มีไดรเวอร์ GPU/VPU/NPU รวมอยู่ด้วยหรือไม่
• ตัวแปลงสัญญาณใดที่เร่งความเร็วด้วยฮาร์ดแวร์
• รองรับสถาปัตยกรรม OTA ใดบ้าง
• PCBA สามารถปรับเปลี่ยนได้หรือไม่?
• การกำหนดค่า RAM และ eMMC สามารถเปลี่ยนแปลงได้หรือไม่?
• สามารถเพิ่มอินเทอร์เฟซแบบกำหนดเองได้หรือไม่
• สามารถปรับแต่ง UI และ Launcher ได้หรือไม่
• การรวม SDK/API สามารถทำได้หรือไม่
• แนะนำให้ใช้โซลูชั่นระบายความร้อนแบบใด?
• วงจรชีวิตผลิตภัณฑ์ที่คาดหวังคืออะไร?
• แพลตฟอร์มเดียวกันสามารถเปลี่ยนไปใช้การผลิต OEM/ODM ในปริมาณมากได้หรือไม่

คำถามเหล่านี้แยกแพลตฟอร์มการพัฒนาของแท้ออกจากบอร์ด Android TV Box ทั่วไปที่จำหน่ายเป็นโซลูชันทางวิศวกรรม

บทสรุป

กล่องทีวีระบบปฏิบัติการคู่ Linux และ Android คณะกรรมการพัฒนา ควรเลือกเป็นรากฐานของแพลตฟอร์มฮาร์ดแวร์-ซอฟต์แวร์ที่สมบูรณ์ ไม่ใช่ PCB แบบสแตนด์อโลน

แพลตฟอร์มที่แข็งแกร่งที่สุดผสมผสาน SoC ที่มีความสามารถ, การเร่งความเร็ววิดีโอด้วยฮาร์ดแวร์, หน่วยความจำและพื้นที่เก็บข้อมูลที่เพียงพอ, การรองรับ Linux/Android BSP ที่ครบถ้วน, I/O ที่ยืดหยุ่น, สถาปัตยกรรม OTA ที่เชื่อถือได้, คุณลักษณะด้านความปลอดภัย, พื้นที่ด้านบนระบายความร้อน และเส้นทางที่ชัดเจนไปสู่การผลิต PCBA ที่ปรับแต่งเอง

สำหรับผู้จัดการฝ่ายจัดซื้อ B2B ผู้ดำเนินการ IPTV ผู้รวมป้ายดิจิทัล และผู้พัฒนาระบบฝังตัว ปัจจัยชี้ขาดจึงไม่ใช่แค่ราคาบอร์ดที่ต่ำที่สุดเท่านั้น ซัพพลายเออร์จะสามารถรองรับห่วงโซ่ทางวิศวกรรมทั้งหมดได้หรือไม่ ตั้งแต่การเลือก SoC และ คณะกรรมการพัฒนา การตรวจสอบความถูกต้องของการแก้ไข PCBA, การเพิ่มประสิทธิภาพเคอร์เนล, การรวม SDK/API, การปรับแต่งเฟิร์มแวร์, วิศวกรรมความร้อน และการผลิตจำนวนมากของ OEM/ODM

นั่นคือโมเดลที่จำเป็นเมื่อต้นแบบจะต้องกลายเป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีความเสถียร แทนที่จะเป็นกล่องการออกแบบอ้างอิงอื่น