บทเรียน 3.7 — ออกแบบ HMI: การ์ด ลำดับสายตา สี และงบ widget

ดูของจริงก่อน — แดชบอร์ดเต็มรูปแบบที่บอร์ดทำได้

ผู้สอนเปิดเมนู Sensor Dashboard ของเฟิร์มแวร์บนบอร์ดหน้าห้อง แล้วปล่อยให้มันวิ่ง

หน้าจอเดียว การ์ดหลายใบ เซนเซอร์หลายตัวอัปเดตพร้อมกัน ไม่มีเมนูให้เข้า มองแล้วรู้สถานะทั้งระบบภายในสองวินาที — นั่นคือสิ่งที่โรงงานเรียกว่า HMI (Human-Machine Interface) หน้าจอที่คนยืนดูแล้วตัดสินใจได้ · วันนี้เราจะสร้างของแบบนี้เอง ด้วยงบ 32 widgets ที่ตั้งเอง (เพดานเฟิร์มแวร์ 64) และไฟล์ Python ไฟล์เดียว

ภาพจำลองข้างบนคือผังของ lvgl_dashboards/12_dash_full_eva.py (ตัวอย่าง MicroPython ที่มากับเฟิร์มแวร์ หัวไฟล์นับไว้ 23 widgets — ไม่ใช่ไฟล์ในหลักสูตรนี้) ไม่ใช่หน้า Sensor Dashboard ของเฟิร์มแวร์ — หน้าเฟิร์มแวร์บน Eva Kit มีการ์ด BMI270 · Controls (btn0/btn1/slider) · กราฟการเคลื่อนไหว · เข็มทิศ · จอยสติ๊ก และ ไม่มีการ์ดลูกบิด · บน TESAIoT Dev Kit หน้าเดียวกันมีการ์ดเพิ่มที่ Eva ไม่มี คือ DPS368 (ความดัน) SHT40 (อุณหภูมิ/ความชื้น) และเรดาร์ เพราะเฟิร์มแวร์ประกอบการ์ดตามชิปที่บอร์ดมี (page_dashboard.c ครอบด้วยธง BSP_HAS_*) ดูของจริงจากบอร์ดของทีม

ทำไม · คืออะไร · ทำยังไง — แผนที่ของชุดบทเรียนนี้

ปลายทางที่จับต้องได้ — แดชบอร์ดสี่การ์ดในจอเดียว IMU · เข็มทิศ · CapSense · ลูกบิด ที่รันต่อเนื่องสิบนาทีโดยไม่ค้างและไม่ crash

บทเรียน 3.4–3.6 เราทำกราฟหนึ่งใบให้ลื่น · ชุดบทเรียนนี้ต้องทำให้ของทั้งจอลื่นพร้อมกัน ภายใต้งบที่นับได้

เป้าหมายของชุดบทเรียนนี้

1. ออกแบบผัง HMI บนกระดาษได้ก่อนเขียนโค้ด — วางการ์ด คำนวณพิกัด และ นับ widget ให้ครบก่อนพิมพ์
2. อธิบายหลักการ HMI ที่ใช้ในแผงควบคุมจริงได้: การจัดกลุ่ม ลำดับสายตา และความหมายของสี
3. ประกอบ ui.Panel สี่ใบเข้ากับ Chart, Compass, Bar, Arc, Seg7 ให้เป็นหน้าจอเดียวที่อ่านรู้เรื่อง
4. ทดสอบความทนทานด้วยการรันต่อเนื่อง 10 นาที และแยกให้ออกว่า "ค้าง" กับ "ช้า" ต่างกันอย่างไร

ปลายทางของวันนี้: จอบอร์ดขึ้นแดชบอร์ดสี่การ์ดของทีมเรา รันยาวสิบนาทีโดยไม่มีอะไรสะดุด

ชุดบทเรียนนี้คือ capstone ครึ่งทาง — ไม่มีของใหม่มาก แต่ต้องเอาของเก่าทั้งหมดมาอยู่ร่วมจอเดียวกันให้ได้

ปลายทางของชุดบทเรียนนี้ — สี่การ์ดในจอเดียว

• การ์ดสี่ใบ: ความเร่ง BMI270 (กราฟ) · เข็มทิศ BMM350 · แถบสัมผัส CapSense กับปุ่มทองแดงสองปุ่ม · ลูกบิด Potentiometer พร้อมเกณฑ์เป็นเปอร์เซ็นต์และไฟ "เกิน"
• แต่ละใบคือ Panel หนึ่งใบที่ให้สีขอบต่างกัน ใช้แยกกลุ่มข้อมูลด้วยสายตาก่อนอ่านตัวหนังสือ
• แถบหัวบอกชื่อทีม ตัวนับรอบกับ loop ไฟ "ค่าค้าง" และปุ่มสั่งงาน "เดินหน้า" / "หยุดภาพ" (ดูผังพิกัดข้างหน้า)

งบ widget มีจำกัด การจัดวางจึงเป็นการตัดสินใจ ไม่ใช่การตกแต่ง

ทบทวน — สามชิ้นส่วนที่เราสร้างไว้แล้ว

ของใหม่วันนี้มีสองอย่าง: ui.Panel เป็นกรอบการ์ด · ui.Compass กินค่าจาก bmm350.heading()

ที่เหลือคืองานออกแบบ — จัดของที่มีอยู่แล้วให้อยู่ร่วมจอเดียวกันโดยไม่ทับกัน ไม่เกินงบ และยังอ่านออก

เนื้อหาใหม่น้อย แต่ความยากขึ้นชัด เพราะครั้งนี้ทุกชิ้นต้องทำงานพร้อมกัน

ทบทวน (ต่อ) — ของสองอย่างที่ต้องเห็นตอนมันเคลื่อน: สนามแม่เหล็ก และนิ้วบนกระจก

HMI คืออะไร และทำไมต้องจัดของเป็นการ์ด

แผงควบคุมในโรงงานไม่ได้ออกแบบให้ "สวย" มันออกแบบให้ คนที่เหนื่อยและรีบ อ่านถูกในครั้งแรก

หลักข้อแรกคือการจัดกลุ่ม: ค่าที่มาจากแหล่งเดียวกันหรือใช้ตัดสินใจเรื่องเดียวกัน ต้องอยู่ในกรอบเดียวกัน

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

การ์ดหนึ่งใบตอบคำถามหนึ่งคำถาม: "การเคลื่อนไหวเป็นยังไง" · "หันหน้าไปทางไหน" · "มีใครแตะอยู่ไหม" · "ลูกบิดตั้งไว้เท่าไร"

ถ้าตอบไม่ได้ว่าการ์ดใบนี้ตอบคำถามอะไร แสดงว่ายังไม่ควรมีการ์ดใบนี้

ลำดับสายตา — อะไรต้องอ่านออกจากอีกฝั่งห้อง

ขนาดฟอนต์คือการประกาศว่า "ของชิ้นนี้สำคัญกว่าชิ้นนั้น" — ประกาศให้ตรงกับความจริง

สีมีความหมาย ไม่ใช่ของตกแต่ง

จานสีของเฉลย — สีสถานะสามสี กับสีประจำเซนเซอร์สี่สี

สีที่เหลือ (ม่วง · เขียวน้ำทะเล · ม่วงกล้วยไม้ · ฟ้า — จานสีเส้นข้อมูลของหลักสูตร) ใช้เพื่อ แยกแหล่งข้อมูล ไม่ใช่บอกสถานะ — พื้นการ์ดกับตัวหนังสือยืมจาก ui_theme.py ในชุดตัวอย่างที่มากับเฟิร์มแวร์ หน้าจอของเราจะดูเป็นระบบเดียวกับเมนูอื่น · บรรทัดจริงจาก s08_dashboard.py:

BG_CARD   = 0x171B22   # พื้นการ์ด เทาเข้มอมน้ำเงิน
COL_WHITE = 0xE8EAED   # ตัวเลขพระเอก
COL_GRAY  = 0x9AA3AF   # ข้อความประกอบ / สถานะเงียบ เทาอ่อน
COL_IMU   = 0x8E7BFF   # BMI270 - เส้นที่ 2 ของจานสีเส้นข้อมูล สีม่วง
COL_COMP  = 0x2FB6A8   # BMM350 - เส้นที่ 3 ของจานสีเส้นข้อมูล สีเขียวน้ำทะเล
COL_TOUCH = 0xC77DFF   # CapSense - เส้นที่ 4 ของจานสีเส้นข้อมูล สีม่วงกล้วยไม้
COL_POT   = 0x4A9EFF   # Potentiometer - เส้นที่ 1 ของจานสีเส้นข้อมูล สีฟ้า
COL_STAT  = 0x30A46C   # เขียว "ปกติ"
COL_WARN  = 0xF5A623   # เหลือง "ค่าเชื่อไม่ได้"
COL_ALERT = 0xE5484D   # แดง "ต้องลงมือ"

ให้คัดค่าสีที่ใช้จริงมาวางไว้ต้นไฟล์ของเราเอง (อย่างที่เห็นข้างบน) แทนการ import — ชื่อในไฟล์ต้นทางไม่ตรงกับของเราทุกตัว เช่นสีเตือนของเราชื่อ COL_ALERT ส่วนต้นทางเรียกว่า COL_AX และอย่าสุ่มเลขสีเองเด็ดขาด

อัตราอัปเดต กับ ความอ่านออก — สองอย่างนี้ตีกัน

สัญชาตญาณบอกว่ายิ่งอัปเดตถี่ยิ่งดี ในงาน HMI มันไม่จริง

ตัวเลขที่เปลี่ยนทุก 20 ms คือตัวเลขที่ มนุษย์อ่านไม่ทัน สายตาเห็นเป็นเลขเบลอ ๆ ที่กระพริบ ส่วนกราฟที่เลื่อนเร็วเกินก็ดูไม่ออกว่าแนวโน้มขึ้นหรือลง

ที่ 200 ms คนอ่านตัวเลขทันพอดี (ห้าครั้งต่อวินาที) กราฟเลื่อนแบบเห็นทิศทาง และ CM55 มีเวลาวาดครบทุกเฟรม

อีกด้านหนึ่ง — ด้านของเครื่อง ลูปที่เร็วเกินจะส่งงานให้ CM55 ถี่กว่าที่มันวาดทัน คิวเต็ม แล้วเฟรมจะหายไปเงียบ ๆ ไม่มี error ให้เห็น หน้าจอแค่ "รู้สึกกระตุก" ซึ่งเป็นอาการที่ดีบักยากที่สุด

จำง่าย ๆ: แดชบอร์ดหนัก 200 ms · หน้าเบา ๆ ที่มีไม่กี่ widget อย่างต่ำ 50 ms

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

อัตราอัปเดต กับ ความอ่านออก (ต่อ) — หน้าตาของปัญหา และราคาของการอ่านออก

เข้าใจฮาร์ดแวร์ · จอกว้าง 792 สูง 398 และเลขพิกัดที่เราต้องคำนวณเอง

ui ไม่มีระบบ layout อัตโนมัติแบบเว็บ (ไม่มี grid ไม่มี flex) ทุก widget ต้องบอกพิกัดเอง เราจึงต้องบวกลบเลขบนกระดาษก่อน

เลขที่ต้องตรวจให้ตรงเสมอ: x + w ต้องไม่เกิน 792 และ y + h ต้องไม่เกิน 398 (การ์ด 2: 408+360 = 768 เหลือขอบขวา 24 px · การ์ดแถวล่าง: 252+136 = 388 เหลือขอบล่าง 10 px)

วางของทับกันแล้วจอไม่ error มันแค่วาดทับ — เลขที่ผิดจะเงียบจนกว่าเราจะมองเห็นด้วยตา

ui.Panel — การ์ดหนึ่งใบ กับพารามิเตอร์ที่ชื่อไม่ตรงความหมาย

ui.Panel ใช้ kwargs ชุดเดียวกับ widget อื่น แต่ ความหมายไม่เหมือนใคร จุดนี้พลาดกันทุกปี

imu_panel = ui.Panel(x=24, y=100, w=368, h=136,
                     color=BG_CARD, min=COL_IMU, max=12, value=2)

เทียบกับ ui.Slider ที่ min/max/value เป็นตัวเลขค่าจริง ๆ และ ui.Label ที่ value คือขนาดฟอนต์ — ชื่อ kwarg เดียวกันเปลี่ยนความหมายไปตามชนิด widget

ลำดับการสร้างสำคัญ: สร้าง Panel ก่อน แล้วค่อยสร้าง Label/Chart ทับลงไป ของที่สร้างทีหลังอยู่ชั้นบน ถ้าสลับลำดับ การ์ดจะบังตัวหนังสือจนหาย

เวลาสงสัยว่า kwarg ตัวไหนแปลว่าอะไร ให้เปิดตารางนี้ อย่าเดาจากชื่อ

งบ widget — นับบนกระดาษให้ครบก่อนพิมพ์โค้ดบรรทัดแรก

เฟิร์มแวร์รับได้ 64 widgets ต่อหนึ่งหน้าจอ (UI_MAX_WIDGETS ใน ipc_ui_protocol.h เท่ากันทั้งสองบอร์ด) ตัวที่ 65 จะไม่ขึ้น และมันไม่แจ้งเตือนอะไรเลย · ส่วน 32 คืองบที่ชุดบทเรียนนี้ตั้งให้ตัวเอง เพื่อเหลือที่ไว้ให้บทเรียน 4.1–5.3 ต่อยอดบนหน้าจอใบเดิม

วิธีทำงานที่ถูกคือเขียนตารางนี้ก่อน แล้วรวมเลขให้เห็นก่อนแตะคีย์บอร์ด

เกร็ด: ทำไมเพดานถึงเป็น 64 พอดี

ตัวเลข 64 ไม่ได้มาจากความสวยงามของเลขยกกำลังสอง มันมาจากข้อจำกัดจริงของการคุยข้ามคอร์ — และเท่ากันทั้ง Eva Kit และ Dev Kit เพราะสองบอร์ดใช้ ipc_ui ชุดเดียวกัน

โค้ด Python ของเราอยู่บน CM33 ส่วน widget จริง ๆ ถูกสร้างและวาดโดย LVGL บน CM55 สองฝั่งนี้คุยกันผ่าน IPC ซึ่งมีพื้นที่หน่วยความจำร่วมขนาดคงที่ ทุก widget ที่สร้างจะกิน "ช่อง" ในตารางอ้างอิงฝั่ง CM55 หนึ่งช่อง และตารางนั้นถูกจองขนาดไว้ตายตัวตั้งแต่ตอนคอมไพล์ — จองแบบไม่ต้องขอหน่วยความจำเพิ่มตอนรัน เพราะการขอหน่วยความจำระหว่างวาดจอคือทางลัดสู่การค้าง

นี่คือแบบแผนที่เจอได้ทั่วไปในงาน embedded: จองล่วงหน้าในขนาดที่รู้แน่ ดีกว่ายืดหยุ่นแล้วเสี่ยงพังตอนทำงาน ระบบที่ต้องทำงานยาว ๆ โดยไม่มีคนดูแล เลือกทางแรกเสมอ

เชื่อมกับวันนี้: ตอนทีมนั่งเถียงกันว่าจะตัด Label ตัวไหนออกเพื่อให้พองบ 32 ที่ตั้งไว้ — นั่นคือการทำงานภายใต้ข้อจำกัดของหน่วยความจำจริง แบบเดียวกับที่วิศวกรออกแบบ HMI ในเครื่องจักรทำอยู่ทุกวัน และเป็นเหตุผลที่ MVP ของวันนี้วัดกันที่ "รันสิบนาทีไม่ค้าง" ไม่ใช่ "มีของบนจอเยอะที่สุด"