บทเรียน 1.3 — เปิดกล่อง: สองคอร์ งาน AIoT และป้ายของทีม

ครึ่งหลัง — เปิดกล่องให้เห็นทั้งใบ

เก้าไฟล์ที่ผ่านมาใช้ lcd time ui สามตัว ซึ่งเป็นแค่สามในสิบเอ็ดโมดูลที่บอร์ดนี้มี

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

เปิดทีละไฟล์ รันตาม แล้วตอบคำถามเดียวต่อไฟล์ (ถ้าเรียนเป็นห้อง ผู้สอนเปิดบนจอหน้าห้องให้ทุกทีมรันตามพร้อมกัน) — "ของนี้เอาไปทำอะไรได้ในงานของคุณ" คำตอบที่ได้คือวัตถุดิบของโปรเจกต์จบในบทเรียน 5.1–5.3

ไฟล์ 12_every_sense_at_once.py กับ 15_one_number_many_faces.py คือสองไฟล์ที่ต้องได้เล่นแน่ ๆ ถ้าเวลาไม่พอ — ตัวแรกแสดงว่าบอร์ดรับรู้โลกได้กี่ทาง ตัวหลังแสดงว่าเลขหนึ่งตัวเล่าเรื่องได้กี่แบบ

ข้อมูลไหลไปทางไหน — ตั้งแต่คีย์บอร์ดถึงจอ

เข้าใจเส้นทางนี้แล้ว การดีบักจะเลิกเป็นการเดา — และเข้าใจด้วยว่าทำไม ui.poll() ถึงจำเป็น มันคือจังหวะที่เราเปิดกล่องจดหมายให้อีกฝั่งหยิบของไป

เข้าใจฮาร์ดแวร์ · ทำไมบอร์ดนี้ต้องมีสมองสองก้อน

ในชิปตัวเดียวกันมีซีพียูสองตัวที่ทำงานคนละแบบ

ใครอ่านเซนเซอร์ตัวไหน ต่างกันระหว่างสองบอร์ด: บน Eva Kit CM55 เป็นเจ้าของบัสเซนเซอร์ทั้งหมด (IMU แผ่นสัมผัส ลูกบิด) Python จึงต้องขอค่าผ่าน IPC และ sensors.init() ถูกปฏิเสธ · บน Dev Kit CM33 อ่าน IMU/เข็มทิศเองได้ (sensors.init() ทำงาน) ส่วนแผ่นสัมผัสกับลูกบิดยังอ่านผ่าน CM55 เหมือนกัน — sensors.snapshot() ซ่อนความต่างนี้ให้ คืน dict รูปเดียวกันทั้งสองบอร์ด

โค้ด Python ของเราอยู่ฝั่ง CM33 เสมอ อยากให้อะไรขึ้นจอ ต้อง ฝากข้อความข้ามไปให้ CM55 วาด

AIoT คืออะไร — ตัดสินใจใกล้จุดเกิดเหตุ

IoT = อุปกรณ์มีเซนเซอร์ + ต่อเน็ต ส่งข้อมูลขึ้นระบบกลาง
AIoT = ย้าย การตัดสินใจ ลงมาไว้ที่ตัวอุปกรณ์เอง ไม่ต้องรอถามคลาวด์ทุกครั้ง

ตัวอย่างที่จับต้องได้: เครื่องจักรตัวหนึ่งสั่นผิดปกติ

• แบบ IoT: ส่งค่าความสั่นทุกวินาทีขึ้นคลาวด์ ให้คลาวด์ตัดสิน — เปลืองเน็ต ช้า และถ้าเน็ตหลุดคือตาบอด
• แบบ AIoT: บอร์ดตัดสินเองที่หน้างานภายในเสี้ยววินาที ส่งขึ้นคลาวด์เฉพาะตอน "ผิดปกติ" — ประหยัด เร็ว และเน็ตหลุดก็ยังทำงาน

ใช้จริงที่ไหน — สามอุตสาหกรรมที่ของแบบนี้ทำงานอยู่จริง

โรงงาน — Predictive Maintenance
มอเตอร์ปั๊มน้ำมีเซนเซอร์ความสั่นติดอยู่ ระบบบนตัวมันรู้ว่า "เสียงสั่นปกติ" หน้าตาแบบไหน พอลูกปืนเริ่มสึก รูปแบบการสั่นเปลี่ยนก่อนพัง 2-3 สัปดาห์ ระบบแจ้งซ่อมล่วงหน้า แทนที่จะรอสายพานหยุดกลางกะ

อาคาร — Smart Building
เซนเซอร์ในห้องประชุมนับคนจากความเคลื่อนไหวและเสียง แล้วสั่งแอร์ให้แรงตามจำนวนคนจริง ไม่ใช่ตั้งไว้ 22 องศาทั้งวัน ค่าไฟลดได้ 20-30% โดยไม่มีใครต้องกดสวิตช์

สุขภาพ — Fall Detection
อุปกรณ์ติดตัวผู้สูงอายุ แยกให้ออกระหว่าง "นั่งลงเร็ว" กับ "ล้ม" — สองอย่างนี้กราฟความเร่งคล้ายกันมาก ค่าเดียวที่จุดเดียวแยกไม่ออก ต้องดูรูปร่างของสัญญาณทั้งช่วง

ทั้งสามเคสนี้ ตัวเซนเซอร์กับตัวตัดสินใจอยู่ที่เดียวกัน — นั่นแหละ AIoT

บอร์ดของเรา: มีอะไรอยู่บ้าง — Eva Kit กับ Dev Kit ต่างกันตรงไหน

จำตารางนี้ไว้ — คอลัมน์ขวาคือแผนที่ของทั้งหลักสูตร เราจะไล่หยิบของในตารางนี้มาสั่งงานเองทีละตัว · ตัวเลขที่ต่างกันระหว่างสองบอร์ด (จำนวน LED, จำนวนลูกบิด) ให้ถามบอร์ดด้วยโค้ดเสมอ ไม่ต้องจำ

ก่อนเริ่มบทเรียน — ผู้สอนตรวจให้ครบ

สี่อย่างนี้เป็นงานของผู้สอน ไม่ใช่ของผู้เรียน ตรวจให้ครบก่อนเริ่ม แล้วบทเรียนจะเดินได้ตลอดชุดบทเรียนโดยไม่สะดุด · ข้อที่สามตรวจเหมือนกันทั้งสองบอร์ด: แตะแผ่นสัมผัสแล้วแถว Touch บนหน้า Home ต้องเปลี่ยน — ถ้าไม่เปลี่ยน สาเหตุที่ต้องสงสัยก่อนคือชิป CapSense ยังไม่ถูก flash ซึ่งเกิดได้กับทั้งสองบอร์ด เพราะแผ่นสัมผัสของทั้งคู่ต่อกับชิป PSoC 4000T แยกต่างหาก ที่ต้องโปรแกรมคนละรอบกับตัวบอร์ดหลัก · ข้อที่สี่มีเฉพาะ Eva Kit เพราะ Dev Kit ไม่มีการ์ด Audio Player

ข้อที่พลาดบ่อยที่สุดคือชิป CapSense — มันเป็นชิปแยกที่ต้องโปรแกรมต่างหากจากตัวบอร์ดหลัก ทั้งสองบอร์ดเหมือนกัน

MVP checkpoint — ผ่านชุดบทเรียนนี้เมื่อ

ทีมสาธิตการใช้ 5 เมนูพร้อมอธิบายว่าเมนูใดใช้เซนเซอร์ใด + รัน lcd.print() ข้อความของทีมขึ้นจอสำเร็จ

แปลเป็นสิ่งที่ตรวจได้จริง:

• [ ] เล่นครบ 5 เมนู: Home, Sensor Dashboard, Smart Watch, Wi-Fi Setting, BENTO Playground (ห้าเมนูนี้มีทั้งบน Eva Kit และ Dev Kit — Controls มีเฉพาะ Eva Kit จึงไม่อยู่ในเกณฑ์)
• [ ] ตารางสำรวจเมนูในบันทึกการเรียน กรอกครบ 5 แถวแรก (แถว Controls กรอกเฉพาะทีมที่ถือ Eva Kit)
• [ ] ชี้ได้ว่าเมนูไหนใช้เซนเซอร์ตัวไหน (อธิบายปากเปล่าได้)
• [ ] จอบอร์ดขึ้นหัวเรื่อง <h2> ของชุดบทเรียนนี้
• [ ] จอบอร์ดขึ้นชื่อทีมและชื่อสมาชิกครบทุกคน ไล่ทีละคน
• [ ] จอบอร์ดขึ้นบรรทัดสีเขียวปิดท้าย
• [ ] 09_your_level_rule.py ผ่านครบหกแถว (เขียวหมด)
• [ ] ถ่ายรูปหน้าจอบอร์ดแนบในบันทึกการเรียน

ไม่มีข้อไหนต้องใช้โค้ดเกินสามสิบบรรทัด — ชุดบทเรียนนี้วัดความเข้าใจ ไม่ใช่ปริมาณ

กับดักที่เจอบ่อย

เกือบทุกข้อในตารางนี้ ไม่ใช่ความผิดของโค้ด แต่เป็นความไม่รู้ลำดับขั้นตอน

ลงมือทำ — เติมช่องว่างในไฟล์ฝึก

เปิด s01_hello_lcd.py มีช่องว่างให้เติม 7 จุด (ท่าที่ 4 แยกเป็นสองบรรทัดเพราะเรื่อง 127 ไบต์)

# เติม: lcd.clear()
pass

# เติม: lcd.console("<h2>AIoT in Action - ชุด 1</h2>")
pass

for i in range(len(MEMBERS)):
    # เติม: lcd.print("สมาชิกคนที่", i + 1, ":", MEMBERS[i])
    pass
    # เติม: time.sleep_ms(800)
    pass

ทำสามขั้น: หนึ่ง แก้ข้อมูลทีมสามบรรทัดบนสุด สอง เติมทีละจุดแล้วส่งขึ้นบอร์ดทุกครั้ง สาม ครบแล้วลองเพิ่มบรรทัดของตัวเอง

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

เฉลย s01_hello_lcd.py — ส่วนที่หนึ่ง

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

# s01_hello_lcd.py - ข้อความแรกของทีม ขึ้นจอบอร์ด
import lcd
import time
import ui

TEAM_NAME = "BentoBuilders"
MEMBERS = ["สมชาย", "สมหญิง", "สมศรี"]
MOTTO = "เล่นของจริงก่อน แล้วค่อยแกะ"

import lcd ต้องมาก่อนใช้งานเสมอ ส่วน import time เอาไว้ใช้ sleep_ms() ในท่าที่ 3 และ import ui เอาไว้วางป้ายลงหน้าจอในท่าที่ 5

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

การวางค่าที่ต้องแก้บ่อยไว้บนสุด เป็นมารยาทที่ดีต่อคนอ่านคนถัดไป (ซึ่งมักคือตัวเราเองในอีกสองสัปดาห์)

เฉลย — ส่วนที่สอง: หัวเรื่องและคำทักทาย

lcd.clear()
lcd.console("<h2>AIoT in Action - ชุด 1</h2>")
lcd.console("<span class=muted>ทดสอบจอครั้งแรกของทีม " + TEAM_NAME + "</span>")

lcd.print("สวัสดีจากทีม", TEAM_NAME)
lcd.print("คำขวัญของเรา:", MOTTO)
print("ส่งข้อความทักทายขึ้นจอบอร์ดแล้ว ดูที่จอ ไม่ใช่ที่หน้าคอม")

สังเกตความต่างสองแบบของการประกอบข้อความ: บรรทัด <span class=muted> ใช้ + เพราะต้องแทรกชื่อทีม ไว้กลางแท็ก ส่วน lcd.print("สวัสดีจากทีม", TEAM_NAME) ใช้จุลภาคเพราะไม่มีแท็กมาเกี่ยว

ถ้าใช้จุลภาคกับแท็ก จะได้ <span class=muted> ทีม </span> ที่มีช่องว่างเกินติดขอบแท็ก

ทำไมต้อง lcd.clear() ก่อนเสมอ — ลิ้นชักอาจมีข้อความจากโปรแกรมที่รันก่อนหน้าค้างอยู่ การเริ่มจากสถานะที่เรารู้แน่นอน เป็นนิสัยของงาน embedded จริง ไม่ใช่แค่ความเรียบร้อย

เลือกวิธีต่อสตริงตามว่า "มีแท็กมาเกี่ยวไหม" ไม่ใช่ตามความเคยชิน

เฉลย — ส่วนที่สาม: ลูปและการปิดท้าย

for i in range(len(MEMBERS)):
    lcd.print("สมาชิกคนที่", i + 1, ":", MEMBERS[i])
    time.sleep_ms(800)

TAIL = "ทีม " + TEAM_NAME + " พร้อมลุยชุดต่อไป"
lcd.print("<span class=ok>ขึ้นจอสำเร็จ</span>")
lcd.print("<span class=ok>" + TAIL + "</span>")

range(len(MEMBERS)) ให้ตัวเลข 0, 1, 2 ตามจำนวนสมาชิกจริง — ถ้าทีมมีสองคน ลูปจะวนสองรอบเอง ไม่ต้องแก้อะไร ข้อมูลเป็นตัวขับการแสดงผล

การหน่วง 800 ms อยู่ ในลูป ไม่ใช่นอกลูป ถ้าย้ายออกไปข้างนอก ชื่อทุกคนจะขึ้นพร้อมกันแล้วค่อยหน่วงครั้งเดียว — ลองย้ายดูแล้วสังเกตความต่าง จะเข้าใจเรื่อง indent ในภาษา Python ทันที

บรรทัดปิดท้ายแยกเป็นสอง lcd.print() ตั้งแต่ต้น เพราะรวมกันแล้วเสี่ยงเกิน 127 ไบต์ถ้าชื่อทีมยาว ประโยคปิดท้ายถูกยกออกมาเก็บไว้ในตัวแปร TAIL เพราะท่าที่ 5 ต้องเอาความยาวของมันไปวัด

ใน Python การเยื้องบรรทัดคือความหมาย ไม่ใช่แค่ความสวยงาม

เฉลย — ส่วนที่สี่: ป้ายทีมบนหน้าจอ ที่ lcd ทำแทนไม่ได้

ui.screen()
time.sleep_ms(200)
COL_TEXT, COL_DIM = 0xE8EAED, 0x9AA3AF
COL_CARD, COL_OK, COL_RUN = 0x171B22, 0x30A46C, 0x4A9EFF
BYTE_LIMIT = 127
ui.Panel(x=16, y=8, w=760, h=372, color=COL_CARD, min=COL_DIM, max=12, value=1)
ui.Label("ป้ายประจำทีม", x=32, y=16, color=COL_DIM, value=20)
ui.Label(TEAM_NAME, x=32, y=40, color=COL_TEXT, value=28)
ui.Label(MOTTO, x=32, y=84, color=COL_DIM, value=20)
tbl = ui.Table(x=32, y=116, w=340, h=252, cols=2)
tbl.col_width(0, 100)
tbl.col_width(1, 230)
tbl.add_row("ลำดับ", "ชื่อสมาชิก")
ui.Label("สถานะการเขียนตาราง", x=400, y=116, color=COL_DIM, value=20)
led_run = ui.Led(x=408, y=144, w=48, h=48, color=COL_RUN, value=1)
ui.Label("กำลังเขียน", x=452, y=148, color=COL_DIM, value=20)
led_done = ui.Led(x=408, y=188, w=48, h=48, color=COL_OK, value=0)
ui.Label("เขียนครบแล้ว", x=452, y=192, color=COL_DIM, value=20)
for i in range(len(MEMBERS)):
    tbl.add_row(str(i + 1), MEMBERS[i])
    ui.poll()
    time.sleep_ms(500)
led_run.value(0)
led_done.value(1)

ลูปนี้เดินรายชื่อ ชุดเดียวกัน กับท่าที่ 3 แต่ปลายทางคนละที่ — ท่าที่ 3 พิมพ์เข้าลิ้นชัก ท่านี้เขียนลงตารางบนจอ ข้อมูลชุดเดียวไปได้สองที่พร้อมกัน และนั่นคือสิ่งที่ชุดบทเรียนนี้อยากให้เห็น · ui.Table จัดคอลัมน์ให้เอง ถ้าเรียง ui.Label เองต้องนับพิกเซลทุกแถว พอชื่อยาวไม่เท่ากันคอลัมน์ที่สองจะเยื้องจนอ่านไม่ออก แถวหนึ่งสูงราว 62 พิกเซล หัวตารางบวกสมาชิกสามคนจึงต้องการ h=252

ไฟสองดวงบอกสถานะแทนการเปลี่ยนสีตัวอักษร เหตุผลอยู่ที่ การทดสอบขาวดำ — ถ่ายรูปจอแล้วแปลงเป็นเกรย์สเกล ไฟที่ติดกับไฟที่หรี่ยังแยกออกด้วยความสว่าง ส่วนตัวหนังสือสีเขียวกับสีเทากลายเป็นสีเดียวกัน · led_run.value(0) ทำให้ไฟ หรี่ ไม่ใช่หาย โดยตั้งใจ ไฟแผงควบคุมที่หายไปตอนดับ ทำให้คนดูแยกไม่ออกว่าดับจริงหรือจอเสีย

เฉลย — ส่วนที่ห้า: มาตรวัดไบต์ ตัวเลขที่มีพิสัยกำกับ

used = len(TAIL.encode())
ui.Label("ความยาวบรรทัดปิดท้าย จากเพดาน 127", x=400, y=240, color=COL_DIM, value=20)
ui.Bar(x=408, y=272, w=332, h=16, color=COL_OK, min=0, max=BYTE_LIMIT, value=used)
ui.Scale(x=408, y=288, w=332, h=44, color=COL_TEXT, min=0, max=BYTE_LIMIT)
ui.Label(str(used) + " ไบต์", x=408, y=336, color=COL_TEXT, value=20)
ui.poll()

เลข 72 ลอย ๆ ไม่บอกอะไรเลย เลข 72 ที่มีไม้บรรทัด 0–127 อยู่ใต้มันบอกทันทีว่าเหลือที่อีกเกินครึ่ง นี่คือกฎเดียวกับที่หน้าจอโรงงานใช้ — ค่าที่วัดได้ต้องมาพร้อมพิสัยหรือเกณฑ์ของมัน

ui.Scale ไม่รับ .value() มันคือไม้บรรทัด ตัวที่ขยับคือ ui.Bar ที่เราวางทับไว้ข้างบน (แบบวงกลมมีเข็มจริงผ่าน prop — บทเรียน 3.1–3.3 สอน) ลองเรียก .value(50) ใส่ Scale ดูก็ได้ แล้วจะเห็นว่าไม่มีอะไรเกิดขึ้น

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

เฉลย · ทำไมเรียงห้าท่าแบบนี้ ไม่ใช่สุ่มเรียง

ท่า 1 ล้างจอ + หัวเรื่อง มาก่อน เพราะต้องพิสูจน์ให้ได้ก่อนว่า "ช่องทางสื่อสารกับจอใช้ได้จริง" ถ้าท่านี้ไม่ขึ้น ท่าที่เหลือไม่มีประโยชน์ที่จะเขียนต่อ

ท่า 2 ข้อความคงที่ มาก่อนลูป เพราะการพิมพ์ค่าตายตัวง่ายกว่า และแยกได้ว่าปัญหาอยู่ที่ lcd หรืออยู่ที่ตรรกะของเรา

ท่า 3 ลูป มาหลังจากพิสูจน์สองข้อบนแล้ว ตอนนี้ถ้าพัง เรารู้แน่ว่าพังที่ลูป ไม่ใช่ที่จอ

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

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

นี่คือวิธีคิดแบบ ไล่จากง่ายไปยาก แล้วให้แต่ละขั้นยืนยันขั้นก่อนหน้า ซึ่งเป็นวิธีดีบักงาน embedded มาตรฐาน

ถ้าเขียนรวดเดียวสี่สิบบรรทัดแล้วรัน พอมันเงียบ ผู้เรียนจะไม่รู้เลยว่าต้องเริ่มหาจากตรงไหน

เชื่อมโยงรากฐาน — วันนี้เราแตะอะไรไปบ้าง

ฝั่งระบบสมองกลฝังตัว
สถาปัตยกรรมหลายคอร์และการแบ่งงานตามความถนัด · การสื่อสารระหว่างคอร์ผ่าน IPC · แนวคิดว่าเฟิร์มแวร์คือชั้นที่ซ่อนความยุ่งยากของฮาร์ดแวร์ไว้ให้เรา

ฝั่ง Python และวิทยาการคอมพิวเตอร์
import โมดูล · ตัวแปร list และ tuple · ลูป for กับ range() · การเขียนฟังก์ชันด้วย def · การเข้ารหัสข้อความเป็นไบต์ · นาฬิกาที่วนกลับกับ ticks_diff()

ฝั่งการออกแบบระบบ
การเริ่มจากสถานะที่รู้แน่ · การรายงานสถานะเมื่อจบงาน · การแยกข้อมูลออกจากตรรกะ · การแบ่งหน้าที่ว่าจอตอบ "ตอนนี้" ลิ้นชักตอบ "ที่ผ่านมา"

สามบรรทัดสุดท้ายคือของที่จะติดตัวไปใช้ได้แม้เปลี่ยนภาษาและเปลี่ยนบอร์ด

งานทำเอง 30% + สรุปบทเรียน

วันนี้เราได้:
เล่นบอร์ดครบทุกเมนูหลักและรู้ว่าแต่ละเมนูกินข้อมูลจากเซนเซอร์ตัวไหน · รู้จักสมองสองก้อนและเส้นทางที่ข้อความเดินทางไปถึงจอ · ใช้ lcd ui และ time ประกอบเป็นจอสถานะหนึ่งใบได้ · เขียนกฎตัดระดับเองแล้วให้บอร์ดตรวจจนผ่าน

การบ้านของทีม: เลือกทำ 1 ข้อจากสี่ข้อในสไลด์ "ต่อยอด" จดลงบันทึกการเรียน

ชุดบทเรียนถัดไป: เราจะพาบอร์ดออกอินเทอร์เน็ต ด้วยโค้ดของเราเอง ไม่ใช่กดผ่านเมนู — wifi.connect() ให้ค่าอะไรกลับมา wifi.ip() คืออะไร แล้วทำไม "ต่อติดแล้ว" กับ "ยังต่ออยู่" ถึงเป็นคนละคำถาม · แล้วเลขที่วันนี้จบอยู่บนจอบอร์ด จะออกไปโผล่บนหน้าเว็บ (สไลด์ถัดไป)

เก็บโค้ดของวันนี้ไว้ให้ดี บทเรียนต่อ ๆ ไปเราจะต่อยอดจากไฟล์เดิมเรื่อย ๆ — โดยเฉพาะโครงของไฟล์ 08

ชุดบทเรียนถัดไป — เลขบนจอนี้จะออกจากบอร์ด

วันนี้ตัวเลขทุกตัวจบที่จอบอร์ด 12_every_sense_at_once.py อ่านลูกบิด แผ่นสัมผัส และ IMU ได้ในคำสั่งเดียว แต่คนที่เห็นมีแค่คนที่ยืนอยู่หน้าบอร์ด

ชุดบทเรียนถัดไปเราเอาเลขชุดเดียวกันนี้ส่งออกไปที่ broker สาธารณะ broker.hivemq.com แล้วเปิดหน้าเว็บ my_first_reader.html บนโน้ตบุ๊กของเราเองอ่านกลับมา ใช้แค่เบราว์เซอร์ ไม่ต้องติดตั้งอะไรเพิ่ม

ของที่ติดมือไปชุดบทเรียนถัดไป: sensors.snapshot() จากไฟล์ 12 คือแหล่งตัวเลข · โครงจอสถานะของไฟล์ 08 คือหน้าตาของบันได WiFi → broker → ส่ง ที่ต้องเห็นบนจอทีละขั้น · ชื่อทีม team01 ถึง team19 ที่ผู้สอนแจก ให้จดลงบันทึกการเรียน

Emulator ใน ide.tesaiot.dev มีโมดูล mqtt ที่ต่อ broker สาธารณะตัวจริงผ่าน WebSocket ได้ เลขจาก Emulator จึงขึ้นหน้าเว็บได้เหมือนเลขจากบอร์ด

เชื่อมจุดให้เห็นภาพ — วันนี้อยู่ตรงไหนของเส้นทาง

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

บทเรียนที่เหลือ — ทีละชุด ได้อะไรกลับบ้าง

เส้นเรื่องคือเส้นเดียว — บทเรียน 2.1–3.9 ทำให้บอร์ดรับรู้และแสดงผลได้ครบ · บทเรียน 4.1–4.9 พาออกไปหาโลก · บทเรียน 5.1–5.3 คือวันที่ทีมเอาทุกชิ้นมาประกอบเป็นของตัวเอง

รายละเอียดเต็ม พร้อมภาพหน้าจอของแต่ละบทเรียน อยู่ที่ หน้าหลักสูตร (README.md) — เปิดดูล่วงหน้าได้เลย

ดูเพิ่มเติมนอกเวลา — ของจริงที่อยู่ในบอร์ดเรา

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

อ่านต่อสำหรับคนอยากรู้ลึก

• ชิปบนบอร์ดเราคือใคร — Infineon PSOC™ Edge E84: https://www.infineon.com/products/microcontroller/32-bit-psoc-arm-cortex/32-bit-psoc-edge-arm/psoc-edge-e84
• คู่มือบอร์ด Eva Kit ฉบับเว็บ เปิดง่ายกว่าไฟล์ PDF: https://documentation.infineon.com/psocedge/docs/lne1762692969598

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

ต่อยอด — คิดต่อเอง (เลือกทำ 1 ข้อ)

ข้อ 1 · จอต้อนรับของทีม
ทำหน้าจอต้อนรับที่มีหัวเรื่อง ชื่อทีม คำขวัญ และรายชื่อสมาชิกพร้อม "หน้าที่ในทีม" ของแต่ละคน ใช้ระดับสีให้ตรงความหมาย ไม่ใช่เลือกตามชอบ

ข้อ 2 · นับถอยหลัง
ดัดแปลง 05_clear_and_refresh.py ให้นับถอยหลังจากเวลาที่ทีมตั้งเอง แล้วจบด้วยข้อความสีเขียว ลองปรับ TICK_MS แล้วสังเกตความรู้สึกที่ต่างกัน

ข้อ 3 · สำรวจกับดัก 127 ไบต์
จงใจพิมพ์ข้อความไทยยาวเกิน 42 ตัวอักษรในครั้งเดียว วัดดูว่าตัดที่ตัวอักษรที่เท่าไร แล้วอธิบายว่าทำไมภาษาไทยกับภาษาอังกฤษได้จำนวนตัวอักษรไม่เท่ากัน

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

เขียนคำตอบลงบันทึกการเรียน แล้วเอามาเล่าให้เพื่อนฟังต้นชุดบทเรียนถัดไป

หน้าจอของทุกไฟล์ในชุดบทเรียนนี้ (1/5)

หน้าจอของทุกไฟล์ในชุดบทเรียนนี้ (2/5)

หน้าจอของทุกไฟล์ในชุดบทเรียนนี้ (3/5)

หน้าจอของทุกไฟล์ในชุดบทเรียนนี้ (4/5)

หน้าจอของทุกไฟล์ในชุดบทเรียนนี้ (5/5)

อ้างอิงและเครดิต

เอกสารของผู้ผลิต

• KIT_PSE84_EVAL PSOC™ Edge E84 Evaluation Kit guide — Infineon, 002-39007 Rev. *B (2025-09-10)
  §3.2.2.12 IMU BMI270 (หน้า 86) · §3.2.2.13 Magnetometer BMM350 (หน้า 87) · §3.2.2.14 Potentiometer และ Thermistor (หน้า 88) · §3.2.2.15 User LEDs (หน้า 88) · §3.2.2.16 Reset and user buttons (หน้า 89) · §3.2.2.5 CAPSENSE™ (หน้า 64) · §3.2.2.7 Audio subsystem (หน้า 72–74)
• PSOC™ Edge E84 product page — Infineon: https://www.infineon.com/products/microcontroller/32-bit-psoc-arm-cortex/32-bit-psoc-edge-arm/psoc-edge-e84
• KIT_PSE84_EVAL product page — Infineon: https://www.infineon.com/product-information/kit_pse84_eval
• PSOC™ Edge E8x datasheet — Infineon: https://www.infineon.com/assets/row/public/documents/30/49/infineon-psoc-edge-e8x-consumer-datasheet-datasheet-en.pdf

งานวิจัยที่กำหนดรูปร่างของชุดบทเรียนนี้

• Carroll, J. M. et al. (1987–1990) — งานทดลองแบบมีกลุ่มควบคุมเรื่องคู่มือแบบ minimalist: คู่มือที่ให้ผู้เรียนลงมือทำงานจริงตั้งแต่หน้าแรก ๆ ใช้เวลาเรียนน้อยกว่าและทำงานสำเร็จได้มากกว่าคู่มือที่ให้อ่านทฤษฎีก่อน · นี่คือเหตุผลที่ชุดบทเรียนนี้ให้จับบอร์ดตั้งแต่สไลด์ที่สี่ ไม่ใช่ตอนกลางบทเรียน
• Mayer, R. E. — หลักการ pre-training: การบอก ชื่อและหน้าที่ ของชิ้นส่วนสั้น ๆ ก่อนลงมือ ช่วยการเรียนอย่างมีนัยสำคัญ · สไลด์ "สามโมดูลที่วันนี้ต้องรู้จัก" ยาวแค่หน้าเดียวด้วยเหตุผลนี้
• ผลสำรวจนักพัฒนามืออาชีพ 80 คนเรื่องตัวอย่างโค้ด — ข้อร้องเรียนอันดับหนึ่งคือตัวอย่างไม่ช่วยให้คิดออกว่าจะประกอบชิ้นส่วนเข้าด้วยกันอย่างไร · นี่คือเหตุผลที่ 08_status_screen.py ได้พื้นที่สองสไลด์

หมายเหตุเรื่องภาพ

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

ภาพถ่ายและภาพเคลื่อนไหวที่นำมาประกอบ มาจาก Wikimedia Commons และหน่วยงานรัฐ ภายใต้สัญญาอนุญาต CC0 · CC BY · CC BY-SA หรือสาธารณสมบัติ ระบุผู้สร้างและสัญญาอนุญาตไว้ใต้ภาพทุกภาพ

ภาพหน้าจอในเด็คนี้มาจากสามแหล่ง และคำบรรยายใต้ภาพระบุไว้ทุกใบว่าใบไหนมาจากไหน — ภาพถ่ายจากบอร์ด Eva Kit จริง บันทึกโดยผู้สอน · ภาพจาก BENTO Emulator ที่ 800×480 เท่าจอของทั้งสองบอร์ด · และ ภาพจากตัวจำลอง bento_sim ซึ่งเรนเดอร์ด้วยโค้ด CM55 ชุดเดียวกับที่รันบนบอร์ด แต่ค่าจากเซนเซอร์ WiFi และไมโครโฟนเป็นค่าแทนบนเครื่องโฮสต์ — ภาพจากตัวจำลองแสดงหน้าจอที่ตัวอย่างสร้าง ไม่ใช่ผลการวัดของบอร์ด

ข้อเท็จจริงเกี่ยวกับพฤติกรรมของ lcd ui เมนู และเฟิร์มแวร์ ตรวจสอบจากซอร์สโค้ดของโปรเจกต์ KIT_PSE84_EVAL_EPC2-MicroPython-BentoClaw (Eva Kit) TESAIoT_KIT_PSE84_AI-Micropython-BentoClaw (Dev Kit) และ BENTO-TESAIoT-libraries โดยตรง

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