บทเรียน 3.8 — ประกอบแดชบอร์ด: สี่การ์ดในลูปเดียว

เรื่องที่เราให้ 70% ผู้เรียนเขียน 30%

สิ่งที่เฟิร์มแวร์ทำให้แล้ว (70%)
วาดทุก widget ด้วย LVGL, จัดคิว IPC ข้ามคอร์, อ่านค่าจากเซนเซอร์ทั้งสี่ตัว, แปลงสนามแม่เหล็กเป็นองศา, จัดการ touch

สิ่งที่เป็นงานของเรา (30%)
ตัดสินใจว่า ค่าไหนควรอยู่ด้วยกัน · ค่าไหนต้องเด่น · สีอะไรแปลว่าอะไร · อัปเดตถี่แค่ไหน · และงบที่มีจะแบ่งให้ใคร

ห้าข้อนี้ไม่มีข้อไหนเป็นเรื่องไวยากรณ์ภาษา Python เลย มันคืองานออกแบบล้วน ๆ ซึ่งเป็นงานที่ยังไงเครื่องก็ทำแทนเราไม่ได้

โค้ดวันนี้ยาวขึ้นก็จริง แต่ส่วนที่ยากคือตอนตัดสินใจก่อนพิมพ์ ไม่ใช่ตอนพิมพ์

แกะโค้ดจริง — ท่าที่ 1 เตรียมจอ ชุดสี และเซนเซอร์

import ui
import sensors
import time

ui.screen()          # เปิดหน้าจอ Playground แบบว่าง (ล้าง widget เดิมทุกตัวให้เอง)
time.sleep_ms(200)   # ให้ CM55 ตามทันก่อนเราเริ่มสร้างของใหม่
...
BG_CARD   = 0x171B22   # พื้นการ์ด เทาเข้มอมน้ำเงิน
COL_WHITE = 0xE8EAED   # ตัวเลขพระเอก
COL_GRAY  = 0x9AA3AF   # ข้อความประกอบ / สถานะเงียบ เทาอ่อน
...
COL_STAT  = 0x30A46C   # เขียว "ปกติ"
...
# ไม่มี sensors.init() ทั้งสองบอร์ด (Eva: ได้ OSError / Dev Kit: ไม่จำเป็น)
try:
    sensors.bmi270.motion()      # อ่านทิ้งหนึ่งครั้ง ให้การรอไปเกิดตรงนี้
except OSError:
    print("อ่านเซนเซอร์รอบแรกยังไม่ได้ - ลองใหม่ในลูป")

แกะโค้ดจริง — ท่าที่ 2 การ์ด IMU พร้อมกราฟสามแกน

imu_panel = ui.Panel(x=24, y=100, w=368, h=136,
                     color=BG_CARD, min=COL_IMU, max=12, value=2)
imu_title = ui.Label("ความเร่ง BMI270 (m/s2)", x=40, y=108, color=COL_IMU, value=16)
# Chart เก็บ 50 จุด รับเฉพาะจำนวนเต็ม เราจึงคูณ 10 ก่อนป้อน (-150..150 = -15.0..+15.0)
imu_chart = ui.Chart(x=40, y=136, w=336, h=56, min=-150, max=150, color=COL_IMU)
sy = imu_chart.add_series(COL_STAT)     # แกน Y เขียว
sz = imu_chart.add_series(0x448AFF)     # แกน Z ฟ้า
imu_val = ui.Label("X+0.0 Y+0.0 Z+9.8", x=40, y=200, color=COL_WHITE, value=20)

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

แกะโค้ดจริง — ท่าที่ 3 การ์ดเข็มทิศ

comp_panel = ui.Panel(x=408, y=100, w=360, h=136,
                      color=BG_CARD, min=COL_COMP, max=12, value=2)
comp_title = ui.Label("เข็มทิศ BMM350", x=424, y=108, color=COL_COMP, value=16)
compass = ui.Compass(x=424, y=132, w=96, h=96, color=COL_COMP)
comp_deg = ui.Label("000 deg", x=544, y=140, color=COL_WHITE, value=28)
comp_dir = ui.Label("N", x=544, y=188, color=COL_COMP, value=24)
...
DIRS = ["N", "NE", "E", "SE", "S", "SW", "W", "NW"]
...
            comp_dir.text(DIRS[int((heading + 22.5) / 45.0) % 8])

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

sensors.bmm350 มีห้าชื่อ — และหนึ่งในนั้นเรายังตอบเรื่องหน่วยไม่ได้

การ์ดเข็มทิศใช้ heading() ตัวเดียว แต่ชิปเปิดให้เราอีกสี่ชื่อ ทุกตัว ไม่รับอาร์กิวเมนต์เลย และโยน OSError เมื่ออ่านไม่สำเร็จ

สามข้อที่ทำให้เข็มทิศบนการ์ดนิ่งหรือไม่นิ่ง

1. มีแต่ heading() เท่านั้นที่ขยับตัวคาลิเบรต — magnetic() ไม่ได้ป้อนอะไรให้มันเลย โปรแกรมที่เรียกแต่ magnetic() จะรอค่าชดเชยจนวันตายก็ไม่ลู่เข้า
2. heading() คืนค่าเฉลี่ยของสิบครั้งหลังสุด เฉลี่ยแบบวงกลมเพื่อไม่ให้พังตอนข้ามรอยต่อ 0 กับ 360 องศา สิบครั้งแรกหลังบูตจึงเป็นค่าที่ยังเฉลี่ยไม่เต็มถัง — อย่าเพิ่งตัดสินจากค่าแรก
3. cal_status()['valid'] เป็น True ก็ต่อเมื่อครบสองเงื่อนไข คือเก็บครบ 50 ตัวอย่าง และ ค่าที่กวาดได้กระจายพอทั้งสองแกน หมุนบอร์ดไม่ครบรอบ เงื่อนไขที่สองไม่ผ่าน · cal_reset() ไม่ได้เขียนอะไรลงชิป มันล้างตัวแปรฝั่งบอร์ดเท่านั้น ค่าคาลิเบรตจึงหายทุกครั้งที่รีเซ็ต

ชิปตัวนี้ตั้ง ODR ไว้ที่ 25 Hz อ่านถี่กว่านั้นจะได้ค่าเดิมซ้ำ ไม่ใช่ค่าใหม่ — ลูป 200 ms ของเราอยู่ห่างจากเพดานนี้มาก จึงไม่ต้องกังวล

sensors.bmm350 — ข้อบกพร่องที่ยังเปิดอยู่สองข้อ พูดตรง ๆ ดีกว่าให้ทีมไปเจอเอง

หนึ่ง หน่วยของ magnetic() ตอนนี้ตอบไม่ได้ว่าคืออะไร คอมเมนต์ในไดรเวอร์และป้ายในไฟล์ตัวอย่างเขียนว่า uT (ไมโครเทสลา) แต่ภาพที่จับจากบอร์ดวัดขนาดรวมสามแกนได้ราว 1532 ขณะที่สนามแม่เหล็กโลกทั้งใบอยู่ที่ 25 ถึง 65 uT — ตัวเลขกับหน่วยเป็นจริงพร้อมกันไม่ได้ อย่างน้อยหนึ่งอย่างผิด และเรายังไม่ได้ตัดสินว่าอันไหน

สิ่งที่ ไม่ ผิดคือทิศ: heading() วัดบนบอร์ดจริงได้ 215.8 เมื่อ 14 ส.ค. 2026 ซึ่งตรงกับความจริง เพราะการหาทิศใช้ atan2 ซึ่งสนใจแค่ อัตราส่วน ระหว่างสองแกน ตัวคูณที่ผิดเท่ากันทั้งคู่จึงหักล้างกันหมด นี่คือเหตุผลที่ข้อบกพร่องนี้อยู่มาได้นานโดยไม่มีใครสังเกต

กติกาของชุดบทเรียนนี้: ห้ามเขียนตัวเลขจาก magnetic() ลงรายงานพร้อมหน่วย uT ให้เขียนว่า "หน่วยของบอร์ด" และเทียบเป็น ค่าต่างจากเส้นฐานที่ทีมวัดเอง เสมอ — ซึ่งบังเอิญเป็นสิ่งที่ 04_magnet_presence.py กับ 05_door_open_switch.py ทำอยู่แล้วทั้งคู่ ทั้งสองไฟล์จึงยังใช้ได้ตามปกติ เกณฑ์ของมันเป็น "เบี่ยงไปเท่าไรจากตอนเริ่ม" ไม่ใช่ "กี่ไมโครเทสลา"

สอง cal_reset() กับ cal_status() ยังไม่มีใครรันบนบอร์ดจริงแม้แต่ครั้งเดียว ทั้ง Eva Kit และ Dev Kit ไฟล์ที่ใช้มันคือ 14_hard_iron_calibration.py และมันเขียนคำเตือนข้อนี้ไว้ในหัวไฟล์ของตัวเอง เปิดได้ ลองได้ แต่ถ้าได้ OSError นั่นคือข้อมูลใหม่ที่ยังไม่มีใครมี ให้บอกผู้สอน

ตัวเลขที่ถูกกับหน่วยที่ถูกเป็นคนละเรื่องกัน — ระบบวัดที่บอกไม่ได้ว่าหน่วยของตัวเองคืออะไร ยังไม่ใช่ระบบวัดที่เสร็จ

แกะโค้ดจริง — ท่าที่ 4 การ์ดสัมผัสและการ์ดลูกบิด

cap_led0 = ui.Led(x=40, y=288, w=48, h=48, color=COL_TOUCH, value=0)
ui.Label("ปุ่ม 0", x=96, y=300, color=COL_GRAY, value=16)
cap_led1 = ui.Led(x=160, y=288, w=48, h=48, color=COL_TOUCH, value=0)
ui.Label("ปุ่ม 1", x=216, y=300, color=COL_GRAY, value=16)
cap_pct = ui.Label("0 %", x=272, y=256, color=COL_WHITE, value=20)
cap_bar = ui.Bar(x=40, y=348, w=288, h=16, min=0, max=100, value=0, color=COL_TOUCH)
...
pot_arc = ui.Arc(x=376, y=288, w=88, h=88, min=0, max=100, value=0)
pot_seg7 = ui.Seg7(x=480, y=288, w=112, h=44, color=COL_POT, min=0, max=100)
pot_volt = ui.Label("0.000 V", x=480, y=340, color=COL_WHITE, value=20)

cap_led0.value(1 if cap['btn0'] else 0)
cap_led1.value(1 if cap['btn1'] else 0)
cap_bar.value(int(cap['slider']))

เลือก widget ตาม "ใครเป็นคนเปลี่ยนค่านี้" ไม่ใช่ตามว่าอันไหนดูดีกว่า

แกะโค้ดจริง — ท่าที่ 5 ลูปหลัก และการอ่านเซนเซอร์แบบ sync

    while True:
        t0 = time.ticks_ms()
        ok = True
        if running:
            try:
                ax, ay, az, gx, gy, gz = sensors.bmi270.motion()
            except OSError:
                ok = False              # คงค่าเดิมไว้ ไม่เขียนศูนย์ทับ
            imu_chart.set_next(0, int(ax * 10))
            ...
        if time.ticks_diff(time.ticks_ms(), last_text) >= UI_TEXT_MS:
            last_text = time.ticks_ms()
            ...
            head.text("รอบที่ {} | loop {} ms".format(
                rounds, time.ticks_diff(time.ticks_ms(), t0)))
        rounds += 1
        for ev in ui.poll():
            ...
        time.sleep_ms(200)

ทุกบรรทัดในลูปนี้จะถูกรันประมาณสามพันรอบระหว่างการทดสอบสิบนาที บรรทัดที่แพงจะโผล่ให้เห็นเอง

ข้อมูลไหลไปทางไหน — สี่เซนเซอร์ หนึ่งลูป หนึ่งหน้าจอ

ดูเพิ่ม (1 นาที): Working principle of an accelerometer — Bosch Sensortec — 1:01 — ผู้ผลิต BMI270 บนบอร์ดเราแสดงให้เห็นว่ามวลพิสูจน์ในชิปขยับจริง ซึ่งคือที่มาของเส้นกราฟสามเส้นนี้

เซนเซอร์สี่ตัวไม่ได้วิ่งขนานกัน มันต่อคิวกันอยู่ในลูปเดียวของเรา — นี่คือเหตุผลที่ต้องอ่านให้น้อยครั้งที่สุด

การ์ดใบที่ห้าที่ทีมเลือกได้ — โมดูล mic ทั้งแปดชื่อ

ไมโครโฟนบนบอร์ดใช้จาก Python ได้แล้ว โมดูล mic ฝังมากับเฟิร์มแวร์ ทั้ง Eva Kit, TESAIoT Dev Kit และ AI Kit import mic ได้เลย ไม่ต้องคัดลอกไฟล์ไปไว้บนบอร์ด และมีอยู่แปดชื่อพอดี

โมดูล mic (ต่อ) — คิวเสียงยาว 625 ms และมันเสิร์ฟของเก่าก่อน

ไมค์ผลิตเสียงตลอดเวลา ไม่ว่าโปรแกรมเราจะอ่านหรือไม่ ตัวรับปลายทางคือวงแหวนที่จุได้ 624.9 ms พอดี (20,000 ไบต์ ที่ 16 kHz แบบสองไบต์ต่อตัวอย่าง) และมันจ่าย ตัวที่เก่าที่สุดก่อน

$$T_{\text{ring}}=\frac{19{,}999\ \text{ไบต์}}{2\ \text{ไบต์/ตัวอย่าง}\times 16{,}000\ \text{ตัวอย่าง/วินาที}} = 0.625\ \text{วินาที}$$

ผลคือ ลูปที่อ่านช้ากว่าที่ไมค์ผลิต จะตามหลังถาวร และเพดานของการตามหลังคือ 625 ms — สิ่งที่การ์ดแสดงจะเป็นห้องเมื่อครึ่งวินาทีที่แล้ว ไม่ใช่ห้องตอนนี้ ทางแก้มีอยู่แล้วในตัว: fresh=True ซึ่งเป็น ค่าตั้งต้น ของ stats() แปลว่า "ทิ้งของค้างทั้งหมด แล้วเอาเฉพาะหน้าต่างล่าสุด"

read() ใช้ทางที่ ไม่ทิ้ง เสมอ อยากได้รูปคลื่นสด ๆ ต้องอ่านให้ทันเอง หรือเรียก stats() นำหน้าเพื่อเคลียร์คิวก่อน

level() เป็นสเกลอ็อกเทฟ ไม่ใช่เปอร์เซ็นต์ของสเกลเต็ม

$$\text{level} = \frac{\bigl(\log_2(\text{rms})\times 256 - 1024\bigr)\times 100}{2816},\qquad \text{rms} < 16 \Rightarrow 0$$

ไทย: ทุกครั้งที่ rms เพิ่มเป็นสองเท่า ตัวเลข level ขึ้นราว 9 หน่วย ไม่ใช่ขึ้นเป็นเท่าตัว สิบเอ็ดอ็อกเทฟถูกยืดลงบนช่วง 0 ถึง 100 พอดี

ตัวเลขจากบอร์ดนี้ ห้องเงียบ rms 30 ได้ level 7 · พูดปกติ rms ราว 1000 ได้ 54 · ตบมือหรือเปิดโทนใส่ไมค์ rms 19335 ได้ 92 — ถ้าใช้เศษส่วนของสเกลเต็มแบบตรง ๆ ทั้งห้องเงียบและเสียงพูดจะกลายเป็น 0 เท่ากันหมด นั่นคือเหตุผลที่มันเป็นอ็อกเทฟ

โมดูล mic (ต่อ) — ราคาที่ต้องจ่าย และกับดักที่เจอบ่อยที่สุด

mic.level() หนึ่งครั้งกินราว 32 ms วัดบนบอร์ด ในนั้น 16 ms คือตัวเสียงเอง (หน้าต่าง 256 ตัวอย่างที่ 16 kHz ก็คือ 16 ms ของเวลาจริง) ส่วนนั้น ลดไม่ได้ ที่เหลือคือค่าใช้จ่ายของการอ่าน — การ์ดเสียงที่ลูป 200 ms จึงจ่ายค่านี้ไปราวหนึ่งในหก ของงบเวลาทั้งรอบ

กับดัก: rms() peak() level() แต่ละตัว อ่านไมค์ใหม่หนึ่งครั้ง เรียก peak() แล้ว rms() ติดกันคือการอ่านสองหน้าต่างคนละช่วงเวลา และจ่ายค่า 32 ms ไปสองรอบ ต้องการทั้งคู่ให้เรียก stats() ครั้งเดียว แล้วแกะออกมาสามค่า

อีกสองข้อ: sens= รับ 1 ถึง 5 (ยิ่งมากยิ่งไวต่อเสียงเบา) ใส่ค่านอกช่วงมัน ตกกลับไปเป็น 3 เงียบ ๆ ไม่มี error ให้เห็น · read(n) ตัดให้สั้นได้อย่างเดียว ขอ 1000 จากบัฟเฟอร์ 256 จะได้ 256 ไม่ใช่ 1000 และมันไม่รอเก็บเพิ่มให้

ลองสามไฟล์ตามลำดับ: 02_mic_sound_level_meter.py (level()) · 03_mic_clap_trigger.py (peak() กับเกณฑ์ที่วัดจากห้องเอง) · 07_mic_window_stats.py (read() stats() lag() และการทดลองสลับ fresh ให้เห็นคิวโตกับตา)

ตัวเลขความดังที่อ่านมาช้ากว่าความจริงครึ่งวินาที ยังเป็นตัวเลขที่ถูก — แต่มันตอบคนละคำถามกับที่คนดูจอกำลังถาม

วิธีรันบนบอร์ด

1. บนจอบอร์ด แตะการ์ด BENTO Playground แล้วค้างหน้านี้ไว้ ห้ามกดกลับระหว่างทดสอบ
2. เปิด s08_dashboard.py ใน BENTO IDE
3. วาดผังบนกระดาษก่อน — กรอกตารางงบ widget ในบันทึกการเรียน ให้ครบก่อนแตะคีย์บอร์ด
4. เติมช่องว่างทั้ง 7 จุด ทีละจุด แล้วกด Program to Device ดูผลทุกครั้ง
5. เมื่อครบทั้งเจ็ดจุดแล้ว แก้ชื่อทีมในบรรทัด TEAM ให้เป็นของทีมเรา
6. รันทิ้งไว้ 10 นาที พร้อมจับเวลาและจดเลขรอบตามบันทึกการเรียน

ถ้าจอค้างระหว่างทาง กด RESTART บนหน้า Playground แล้วเริ่มจับเวลาใหม่ตั้งแต่ศูนย์ — ห้ามนับต่อ

ห้ามเติมครบเจ็ดจุดแล้วค่อยรันทีเดียว ถ้าพังจะไม่รู้เลยว่าพังที่จุดไหนในเจ็ดจุด

วิธีทดสอบ soak run 10 นาที — และแยก "ค้าง" ออกจาก "ช้า"

การรันสิบนาทีไม่ใช่การนั่งรอเฉย ๆ เรากำลังเก็บข้อมูลอยู่ จดเลขรอบทุกสองนาที

ที่ cadence 200 ms ลูปควรเดินราว 5 รอบต่อวินาที = ประมาณ 600 รอบต่อสองนาที ถ้าจดได้ 590–600 ทุกช่วง แปลว่าคงที่ ถ้าช่วงหลังเหลือ 300 แปลว่าเริ่มช้าลงแล้ว

วิธีแยกที่เร็วที่สุด: หมุนลูกบิด แล้วดูสามที่พร้อมกัน — เลข Seg7, เลขรอบ, และ loop ms ถ้าเลขรอบเดินแต่ Seg7 ไม่ขยับ ปัญหาอยู่ฝั่งเซนเซอร์ ถ้าเลขรอบหยุด ปัญหาอยู่ฝั่งลูปหรือจอ

อีกอย่างที่ต้องดูคือ ความร้อนและการเสียบสาย — สาย USB ที่หลวมทำให้บอร์ดรีเซ็ตกลางทาง แล้วเราจะไปโทษโค้ดผิด ๆ

"ค้าง" กับ "ช้า" แก้คนละวิธีกันสิ้นเชิง เสียเวลาห้าวินาทีแยกให้ออกก่อน ประหยัดไปได้ครึ่งชั่วโมง