คาบ 1 — AIoT รอบตัวเรา

ดูของจริงก่อน — บอร์ดนี้ทำอะไรได้บ้าง

วันนี้ยังไม่ต้องเขียนโปรแกรมอะไรยาว ๆ เราจะ เล่นก่อน และเราจะเริ่มเล่นตั้งแต่สไลด์ถัดไป ไม่ใช่ตอนกลางคาบ

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

คอร์สนี้ใช้บอร์ดสองรุ่น — PSoC Edge Eval Kit (Eva Kit) และ TESAIoT Dev Kit — ภาพร่างข้างบนวาดจาก Eva Kit ส่วน Dev Kit มีของชุดเดียวกันนี้ครบ และเพิ่มเซนเซอร์อุณหภูมิ/ความชื้น ความกดอากาศ เรดาร์ ลูกบิดสี่ตัว และ RGB dot matrix เข้ามา โค้ดที่เขียนในคอร์สนี้รันได้ทั้งสองบอร์ด ที่ต่างกันจะบอกไว้ตรงจุด

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

ของทุกอย่างที่เห็นบนจอวันนี้ อีกสิบเอ็ดคาบข้างหน้าเราจะสร้างมันขึ้นมาเองทีละชิ้น

เป้าหมายของคาบนี้

1. เล่นเมนูหลักบนบอร์ดให้ครบ แล้วบอกได้ว่า เมนูไหนใช้เซนเซอร์ตัวไหน
2. รู้จักสมองสองก้อนของบอร์ด (CM33 กับ CM55) ว่าใครทำหน้าที่อะไร
3. ใช้โมดูล lcd กับ ui ส่งข้อความและตัวเลขของทีมขึ้นจอได้
4. ต่อบอร์ดเข้ากับ BENTO IDE แล้ว รันไฟล์ตัวอย่างของคาบนี้ได้ครบ

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

คาบนี้วัดกันที่ "เล่นเป็น + อธิบายได้" ไม่ใช่ "เขียนโค้ดยาว" — เปิดบอร์ดได้เลยตั้งแต่สไลด์หน้า

รอบที่ 1 — เล่นหน้า Home ให้ทั่ว

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

รอบที่ 2 — สามเมนูที่ต้องเล่นให้ครบ

Controls (Eva Kit เท่านั้น) — แตะวงกลมสีบนจอ แล้วมอง หลอด LED จริงบนบอร์ด ว่าติดตาม
นี่คือครั้งแรกที่น้อง ๆ เห็นว่า "แตะกระจก" ทำให้ "ของจริงเปลี่ยนสถานะ" ได้ (คาบ 3 กับ 4 เราจะสร้างหน้านี้เอง) · Dev Kit ไม่มีการ์ด Controls — ทีมที่ถือ Dev Kit ให้ข้ามไปเมนูถัดไปก่อน แล้วดูไฟจริงติดจากโค้ดตอนรัน examples/s01/11_lights_and_a_button.py^↗ ในครึ่งหลังของคาบแทน

Sensor Dashboard — เขย่าบอร์ดเบา ๆ แล้วดูกราฟทางซ้ายกระเพื่อม เข็มทิศทางขวาหมุนตามการหันบอร์ด
(คาบ 7 กับ 8 เราจะสร้างกราฟและเข็มทิศแบบนี้เอง)

Smart Watch — ปัดนิ้วซ้าย-ขวาเพื่อเปลี่ยนหน้า มีทั้งหน้านาฬิกา สุขภาพ เพลง อากาศ
ตัวนับก้าวคำนวณจากเซนเซอร์ความเร่งตัวเดียวกับที่เราจะใช้ในคาบ 6 · เวลาบนหน้าปัดยังไม่ตรง เพราะบอร์ดตั้งนาฬิกาจากอินเทอร์เน็ตเท่านั้น และยังไม่ได้ต่อ WiFi (คาบหน้าต่อแล้วจะตรงเอง)

เล่นแล้วจดลง worksheet ทันที — ความจำจากการเล่นหายเร็วกว่าที่คิด

รอบที่ 3 — เมนูที่ต้องรู้ว่ามีอยู่

Audio Player (Eva Kit เท่านั้น — Dev Kit ไม่มีการ์ดนี้) — เครื่องเล่นเพลงจริงจาก SD card
ถ้าไม่ได้เสียบ SD card หน้านี้จะขึ้น Now Playing: No SD Card และบรรทัด สีแดง SD Card failed: step 2 (InitCard) — นี่ไม่ใช่บอร์ดเสีย ปุ่มเล่นและแถบเสียงยังอยู่ครบ ขาดแค่รายชื่อไฟล์

Wi-Fi Setting — สแกนหาเครือข่าย เลือก แล้วใส่รหัส
คาบนี้ยังไม่ต้องต่อ (คาบ 2 จะต่อด้วยโค้ดของเราเอง) แต่ให้กดเข้าไปดูว่าหน้าตาเป็นยังไง — เมนูนี้มีทั้งสองบอร์ด และอยู่ในเกณฑ์ผ่านของคาบ

BENTO Playground — หน้าที่สำคัญที่สุดสำหรับเรา
ทุกครั้งที่เราส่งโค้ดจากคอมมาที่บอร์ด ผลลัพธ์จะมาโผล่ที่หน้านี้ ถ้าไม่เปิดหน้านี้ค้างไว้ จะงงว่าทำไมส่งโค้ดแล้วไม่เห็นอะไร

TESAIoT Connectivity (Eva Kit เท่านั้น — Dev Kit ไม่มีการ์ดนี้) — แดชบอร์ดสถานะการเชื่อมต่อกับแพลตฟอร์ม IoT
ปลายทางของคาบ 10-11 อยู่ตรงนี้ กดเข้าไปดูไว้ก่อนได้ว่าเราจะไปจบที่ไหน — ทีมที่ถือ Dev Kit จะได้เห็นปลายทางเดียวกันผ่านโค้ดของตัวเองในคาบ 10-11

เมนู Playground คือประตูที่เราจะเดินผ่านทุกคาบตั้งแต่วันนี้เป็นต้นไป

ปลายทางของคาบนี้ — จอที่เราจะได้ตอนปิดคาบ

• เลขตัวเดียว 76 ขับทุกอย่างบนจอพร้อมกัน — Arc, Compass, Seg7, Bar, Slider, Switch, Checkbox, Chart, Spinner
• มุมล่างเขียนว่า ui.list() นับได้ 24 ตัว จาก 64 — บอร์ดนับ widget ของตัวเองได้ · 64 คือเพดานของเฟิร์มแวร์ ส่วนงบที่คอร์สตั้งให้ตัวเองคือ 32 ต่อหน้า (คาบ 4 อธิบายว่าทำไม)
• ปุ่ม "แตะฟังเสียง" มีจริง กดแล้วดัง — บน Eva Kit ดังจากลำโพงบนบอร์ด (Dev Kit: ฟังที่บอร์ดของทีม)

ทั้งหมดนี้เขียนด้วย Python บนบอร์ด ไม่มี LVGL ไม่มี C สักบรรทัด — และวันนี้น้อง ๆ จะได้เขียนเอง

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

สิ่งที่เฟิร์มแวร์ทำให้แล้ว (70%)
อ่านเซนเซอร์ตลอดเวลา, วาดหน้าจอทุกเมนู, จัดการ IPC ระหว่างสองคอร์, ระบบไฟล์บนบอร์ด, รัน MicroPython, จัดการวิทยุ WiFi

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

วันนี้ 30% ของเราเล็กมาก คือแค่ "พิมพ์อะไรลงจอ" แต่กลไกเบื้องหลังเหมือนกันทุกคาบ

เราไม่ได้เรียนเขียนไดรเวอร์ เราเรียน ออกแบบระบบ AIoT โดยยืนบนไดรเวอร์ที่มีอยู่แล้ว

สามโมดูลที่จะลงมือจริงก่อน — แล้วครึ่งหลังจะเปิดที่เหลือทั้งกล่อง

สามตัวนี้คือของที่จะพิมพ์เองครบทุกบรรทัดในครึ่งแรก ส่วนครึ่งหลังของคาบจะเปิดอีกห้าโมดูล — gpio sensors dsp mic machine — และ widget อีกสิบกว่าชนิด ให้เห็นว่ากล่องนี้มีอะไรอยู่จริงบ้าง ก่อนจะไปลงลึกทีละตัวในคาบต่อ ๆ ไป

print() ขึ้นที่คอนโซลฝั่งคอม · lcd.print() ลงลิ้นชักบนบอร์ด · ui.Label ขึ้นบนหน้าจอตรง ๆ — สามที่ คนละที่กัน

สามโมดูลที่จะลงมือจริงก่อน (ต่อ) — กฎข้อเดียวที่ต้องจำวันนี้

import lcd
import time
import ui
...
ui.screen()                    # ล้าง widget เดิมทิ้ง เริ่มจากจอเปล่าที่เรารู้แน่
time.sleep_ms(200)
...
say = ui.Label("กำลังพิมพ์ลงลิ้นชัก Console...", x=24, y=56,
               color=COL_ACCENT, value=24)
...
ui.poll()                      # เคาะหนึ่งครั้ง ป้ายถึงจะโผล่ทันที
...
lcd.clear()
lcd.print("สวัสดี บอร์ด PSoC Edge")

กฎข้อเดียวที่ต้องจำวันนี้: สร้างหรือแก้ ui.* แล้วต้องเคาะ ui.poll() หนึ่งครั้ง ไม่งั้นจอจะนิ่งไปราวสองวินาทีจนกลไกกันเหนียวปลดล็อกเอง หลายทีมสรุปว่า "โค้ดพัง" ทั้งที่แค่ยังไม่ได้เคาะ (กติกาที่เหลือของ ui รอคาบ 4) · บรรทัดพวกนี้ตัดมาจาก examples/s01/01_first_line.py^↗ ตรง ๆ — COL_ACCENT คือสีเน้น 0x4A9EFF ที่หัวไฟล์ประกาศไว้

value= บน ui.Label คือขนาดตัวอักษร ไม่ใช่ตัวเลขที่จะเอาไปแสดง — จุดนี้ทำคนสะดุดทุกรุ่น

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

1. บนจอบอร์ด แตะการ์ด BENTO Playground เปิดค้างไว้ (เฟิร์มแวร์เด้งมาหน้านี้ให้เองตอนสคริปต์เรียก lcd ครั้งแรก แต่เปิดรอไว้จะเห็นผลตั้งแต่วินาทีแรก)
2. บนคอม เปิด BENTO IDE เชื่อมต่อบอร์ด (ดูไฟสถานะว่าเจอบอร์ดแล้ว)
3. เปิดไฟล์ตัวอย่างของคาบนี้จาก examples/s01/ แล้วกด Program to Device
4. หันไปมองจอบอร์ด ไม่ใช่จอคอม
5. แตะปุ่มไอคอนสีเขียวที่มุมขวาล่างของหน้า Playground เพื่อเปิดลิ้นชัก Console — หน้านี้เปิดมาที่โหมด UI เป็นค่าเริ่มต้น ข้อความจาก lcd จะรออยู่จนกว่าจะกดสลับ สังเกตจุดแดงเล็ก ๆ ที่มุมปุ่มเมื่อมีข้อความรอ
6. อยากเริ่มใหม่ ปุ่ม RESTART บนหน้า Playground รันสคริปต์ซ้ำได้เลย

พื้นที่วาดของเราคือ 792 x 398 พิกเซล และมุมขวาล่างราว 100x58 เป็นของปุ่ม Console ที่เฟิร์มแวร์จองไว้ — วาง widget ทับตรงนั้นแล้วจะกดเปิดลิ้นชักไม่ได้

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

ไฟล์ที่ 1 · examples/s01/01_first_line.py^↗ — หนึ่งบรรทัด สามปลายทาง

say = ui.Label("กำลังพิมพ์ลงลิ้นชัก Console...", x=24, y=56,
               color=COL_ACCENT, value=24)
ui.poll()

lcd.clear()
lcd.print("สวัสดี บอร์ด PSoC Edge")
lcd.print("หนึ่งบวกหนึ่งได้", 1 + 1)

print("บรรทัดนี้อยู่บนคอม ไม่ได้อยู่บนจอบอร์ด")

lcd.print() รับหลายค่าคั่นด้วยจุลภาคเหมือน print() ทุกประการ และเติมช่องว่างให้เอง ตัวเลขส่งได้เลยไม่ต้องแปลงก่อน

ท้ายไฟล์มี say.text(...) — แก้ข้อความบนป้ายเดิม ไม่ใช่วางป้ายใหม่ทับ ป้ายหนึ่งใบที่เปลี่ยนค่าได้ อ่านง่ายกว่าป้ายสิบใบที่กองทับกัน

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

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

ไฟล์ที่ 2 · examples/s01/02_markup_tags.py^↗ — สีคือระดับ ไม่ใช่ของตกแต่ง

for cls, text in REPORT:
    # แท็กเปิดกับแท็กปิดต้องอยู่ในการเรียกครั้งเดียวกันเสมอ
    lcd.print("<span class=" + cls + ">" + text + "</span>")

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

ฝั่งจอแกะแท็กทีละบรรทัด จบบรรทัดแล้วสถานะเริ่มใหม่หมด ลืมปิด </h2> ผลกระทบจำกัดอยู่ในบรรทัดนั้นบรรทัดเดียว

กับดัก: พิมพ์ชื่อคลาสผิด เช่น class=okay ไม่มี error ให้จับสักตัว บรรทัดนั้นแค่ออกมาเป็นสีปกติ — เจอบรรทัดที่ไม่มีสี ให้สงสัยชื่อคลาสก่อน

ตาคุณ: ใน REPORT มีบรรทัดหนึ่งติดระดับไว้ผิด หาให้เจอแล้วแก้ จากนั้นเพิ่มข่าวของทีมเองอีกหนึ่งบรรทัดพร้อมเลือกระดับให้มัน

เกณฑ์ตัดสินง่าย ๆ: บรรทัดนี้ทำให้คนที่เดินผ่านต้องลุกจากเก้าอี้ไหม ถ้าไม่ ก็ไม่ใช่ error

ไฟล์ที่ 3 · examples/s01/03_byte_limit.py^↗ — เพดาน 127 ไบต์

nbytes = len(text.encode())      # นับไบต์ ไม่ใช่นับตัวอักษร
seg.text(str(nbytes))

if nbytes > LIMIT:
    seg.color(COL_BAD)
else:
    seg.color(COL_OK)

ui.Seg7 รับได้ทั้ง .text() และ .value() — แต่ .value(198) ขึ้น 198 เท่านั้น ถ้าอยากได้ 198.0 หรือ 0198 ต้องส่งเป็นข้อความ

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

การตัดที่ต้องตัด ให้ตัดที่ ตัวอักษร ไม่ใช่ที่ไบต์ — ตัดกลางไบต์ของตัวอักษรหนึ่งตัวแล้วจอจะแสดงเป็นขยะ

ไฟล์ที่ 4 · examples/s01/04_console_drawer.py^↗ — บทสรุปที่ไม่ต้องเปิดลิ้นชัก

CHECKS = [
    ("จอแสดงผล", True),
    ("ปุ่มบนบอร์ด", True),
    ("หลอด LED", True),
    ("การ์ด SD", False),
]
...
for name, ok in CHECKS:
    if ok:
        passed = passed + 1
        ...
        lcd.print(name, "<span class=ok>ผ่าน</span>")
    else:
        ...
        lcd.print(name, "<span class=error>ไม่ผ่าน</span>")
    seg.text(str(passed) + "-" + str(TOTAL))
    bar.value(passed)
    ...
    ui.poll()

ตาคุณ: แก้ CHECKS ให้ผ่านครบทุกข้อ ดูว่าการ์ดข้างบนเปลี่ยนไปยังไง แล้วเพิ่มรายการที่ห้า สังเกตว่าต้องแก้อะไรบ้างนอกจาก CHECKS (ใบ้: y ของแถวสุดท้ายยังอยู่ในจอ 398 พิกเซลหรือเปล่า)

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

ไฟล์ที่ 5 · examples/s01/05_clear_and_refresh.py^↗ — เขียนทับที่เดิม

for left in range(TOTAL, -1, -1):
    seg.text(str(left))          # ท่า widget: ทับค่าเดิม
    arc.value(left)

    lcd.clear()                  # ท่าลิ้นชัก: ล้างแล้ววาดใหม่ทั้งหน้า
    lcd.console("<h2>นับถอยหลัง</h2>")
    lcd.print("เหลืออีก", left, "วินาที")

    ui.poll()
    time.sleep_ms(TICK_MS)

สร้าง widget ไว้นอกลูปเสมอ ถ้าย้ายสามบรรทัดนั้นเข้าไปในลูป จะได้ widget ใหม่ทุกวินาที

ห้ามสร้าง ui.Label ด้วยข้อความว่าง ระบบวาดจะเติมคำว่า Label ให้เอง แล้วคำนั้นค้างบนจอจนกว่าจะมีการเขียนทับครั้งแรก

ตาคุณ: ตั้ง TICK_MS = 150 แล้วขยาย TOTAL เป็น 20 รันดูแล้วตอบว่าท่าไหนอ่านออก ท่าไหนกลายเป็นจอกระพริบ

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

ไฟล์ที่ 6 · examples/s01/06_safe_print.py^↗ — ย้ายกฎเข้าไปอยู่ในฟังก์ชัน

for ch in text:
    size = len(ch.encode())      # ไทย 3 · อังกฤษ 1

    # เช็ก "ก่อนใส่" ไม่ใช่ "หลังใส่"
    if used + size > SAFE_BYTES:
        flush(chunk)
        chunk = ""
        used = 0

    chunk = chunk + ch
    used = used + size

if chunk != "":                  # ก้อนสุดท้ายต้องส่งด้วย
    flush(chunk)

ไฟล์นี้เผื่อไว้ที่ SAFE_BYTES = 120 ต่ำกว่าเพดานจริง 127 อยู่ 7 ไบต์ เป็นระยะปลอดภัย

ข้อจำกัดที่ต้องรู้: ฟังก์ชันนี้ตัดที่ตัวอักษร ไม่ใช่ตัดที่คำ และมันไม่รู้จักแท็ก — ห้ามส่งข้อความที่มีแท็กเข้ามา เพราะแท็กอาจถูกตัดครึ่งกลางคัน

ตาคุณ: ลด SAFE_BYTES เหลือ 40 แล้วรันใหม่ จำนวนก้อนจะเพิ่มขึ้นแต่ตัวข้อความยังครบ ตอบว่าทำไมการแบ่งถี่ขึ้นถึงไม่ทำให้ตัวอักษรหายสักตัว

บรรทัด if chunk != "": ท้ายฟังก์ชันคือบรรทัดที่คนลืมบ่อยที่สุด ลืมเมื่อไรท้ายประโยคหายทันที

ไฟล์ที่ 7 · examples/s01/07_ticks_and_beat.py^↗ — ลูปที่สั่ง sleep เท่าเดิม ไม่ได้เดินตรงเวลา

work = time.ticks_diff(time.ticks_ms(), t_work)   # งานรอบนี้กินไปกี่ ms
left = TARGET_MS - work                           # เหลือให้หลับเท่าไร
if left > 0:
    time.sleep_ms(left)

sleep_ms() แปลว่า "หลับอย่างน้อยเท่านี้" ไม่ได้แปลว่า "รอบละเท่านี้" งานที่ทำก่อนหลับกินเวลาของมันเอง คาบจริงจึงยาวกว่าที่ขอเสมอ และส่วนเกินนั้น สะสมทุกรอบ

ห้ามลบเวลาสองค่าด้วยเครื่องหมายลบธรรมดา นาฬิกานี้นับขึ้นแล้ววนกลับ ticks_diff() รู้เรื่องการวน ส่วน t2 - t1 ไม่รู้ แล้วจะได้เลขติดลบมหาศาล

ui.Chart รับเฉพาะจำนวนเต็ม ช่วงแกนตั้งกำหนดตอนสร้างแล้วเปลี่ยนทีหลังไม่ได้ และมันเกิดมาพร้อมเส้นที่ 0 อยู่แล้ว add_series() จึงคืนเลข 1 เป็นเส้นแรกที่เราเพิ่ม — เก็บเลขที่มันคืนมาไว้ในตัวแปร อย่าเดาเอง

ตาคุณ: ตั้ง SWITCH_AT = 41 เพื่อปิดท่าที่ 2 ทิ้ง ทำนายก่อนรันว่าเลขช้าสะสมตอนจบจะออกมาราวเท่าไร แล้วรันเทียบ

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

ไฟล์ที่ 8 · examples/s01/08_status_screen.py^↗ — จอบอกตอนนี้ ลิ้นชักบอกที่ผ่านมา

    # --- งานของจอ: ทำทุกรอบ ---
    seg.text(str(value))
    seg.color(color)
    level_lbl.text(name)
    level_lbl.color(color)
    bar.value(value)
    chart.set_next(s_value, value)
    ...
    # --- งานของลิ้นชัก: ทำเฉพาะตอนมีเรื่องให้เล่า ---
    if lv != last_level:
        changes = changes + 1
        last_level = lv
        lcd.print("<span class=" + cls + ">" + str(elapsed) + " ms  " +
                  name + "  ค่า " + str(value) + "</span>")

ไฟล์นี้ไม่มีคำสั่งใหม่เลยสักตัว ทุกอย่างในนี้เคยผ่านตามาแล้วในไฟล์ 01 ถึง 07 ของใหม่คือ "จะเอามันมาต่อกันยังไง" ซึ่งเป็นคำถามที่ไฟล์เดี่ยว ๆ ไม่เคยตอบ

LEVELS เก็บชื่อ สี และคลาสของ span ไว้ด้วยกันในตารางเดียว จอกับลิ้นชักจึงเล่าเรื่องเดียวกันเสมอ เพราะทั้งคู่อ่านจากตารางนั้น

last_level = -1 แปลว่า "ยังไม่เคยรู้ระดับมาก่อน" รอบแรกจึงนับเป็นการเปลี่ยนเสมอ ถ้าตั้งต้นเป็น 0 ประวัติจะไม่มีบรรทัดแรกบอกว่าเริ่มที่ระดับไหน

ลูปในไฟล์นี้ใช้ท่าที่ 2 ของไฟล์ 07 ตรง ๆ — ของที่เรียนมาแล้วต้องกลับมาใช้ ไม่ใช่เรียนแล้วทิ้ง

ทำไมไฟล์ที่ 8 เป็นไฟล์ที่สำคัญที่สุดในชุด

มีงานวิจัยที่ไปสัมภาษณ์นักพัฒนามืออาชีพ 80 คนว่า ตัวอย่างโค้ดที่หาเจอบนเน็ตทำให้หงุดหงิดตรงไหนที่สุด คำตอบอันดับหนึ่งไม่ใช่ "โค้ดผิด" และไม่ใช่ "อธิบายน้อยไป" แต่คือ ตัวอย่างพวกนั้นไม่ช่วยให้คิดออกว่าจะเอาชิ้นส่วนมาต่อกันยังไง

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

reading_at() ในไฟล์นั้นเป็นค่าอ่านจำลอง คาบ 5 เป็นต้นไปจะถอดฟังก์ชันนี้ทิ้งแล้วเสียบค่าจากเซนเซอร์จริงเข้ามาแทน ที่ยังจำลองไว้ก่อน เพราะคาบนี้เรากำลังเรียนเรื่องการรายงานผล ไม่ใช่การวัด

ตาคุณ: ย้ายบล็อก lcd.print() ออกจาก if ให้มันยิงทุกรอบ แล้วรันใหม่ เปิดลิ้นชักดู แล้วตอบว่าประวัติแบบไหนที่คนเดินมาดูหน้างานใช้งานได้จริงกว่ากัน (ใบ้: ลองหาคำตอบจากลิ้นชักว่า "ค่าขึ้นถึงระดับต้องรีบดูตอนวินาทีที่เท่าไร")

ถ้าจะเลือกอ่านซ้ำนอกเวลาแค่ไฟล์เดียวจากทั้งเก้าไฟล์ ให้เลือกไฟล์นี้

ไฟล์ที่ 9 · examples/s01/09_your_level_rule.py^↗ — รันได้ แต่ยังตอบผิดทุกข้อ

CASES = (
    (12, "ปกติ"),
    (49, "ปกติ"),
    (50, "เริ่มสูง"),
    (79, "เริ่มสูง"),
    (80, "ต้องรีบดู"),
    (92, "ต้องรีบดู"),
)
...
# ----- เติมส่วนนี้เอง (งานของคุณ) -----
def level_name(v):
    ...                    # docstring ในไฟล์บอกโจทย์และใบ้วิธีเรียง if ไว้แล้ว
    return "ปกติ"          # ตอนนี้ตอบ "ปกติ" ทุกค่า จึงผ่านแค่สองข้อแรก
# ----- จบส่วนที่ต้องเติม -----

ไฟล์นี้เป็นคู่ฝึกของไฟล์ 08 ในนั้นกฎตัดระดับเขียนไว้ให้แล้ว ส่วนในนี้ยังว่าง และลอกจาก 08 มาตรง ๆ ไม่ได้ เพราะโจทย์คนละเจ้าใช้เส้นคนละที่

โจทย์มาจากทีมซ่อมบำรุง: ต่ำกว่า 50 คือปกติ · ตั้งแต่ 50 ถึง 79 ให้จับตาไว้ · ตั้งแต่ 80 ขึ้นไปต้องเข้าไปดูทันที นี่คือที่มาของตัวเลข ไม่ใช่เลขที่เราคิดขึ้นเอง

CASES เลือกไว้ให้มีค่าที่อยู่ ตรงเส้นพอดี (49, 50, 79, 80) เพราะนั่นคือจุดที่กฎผิดกันบ่อยที่สุด >= กับ > ต่างกันแค่ตัวเดียว

กับดักที่ต้องระวัง: ลำดับของ if สำคัญกว่าที่คิด ถ้าเช็กเงื่อนไข 50 ก่อน 80 ค่า 92 จะตกลงช่องกลางแล้วไม่มีวันไปถึงช่องบนเลย และไม่มี error ให้จับสักตัว

ตาคุณ (หลังผ่านครบหกข้อ): เพิ่มลงใน CASES อีกหนึ่งแถวที่คุณคิดว่ากฎของตัวเองน่าจะตก แล้วรันดูว่าตกจริงไหม ถ้าไม่ตก แปลว่ากฎแข็งกว่าที่คิด

เก้าไฟล์เรียงแบบนี้เพราะอะไร

ต้องทำในคาบ · เปิดตามลำดับนี้

ติดตรงไหน เปิดอันนี้

ทุกไฟล์จบด้วยบล็อก ตาคุณ — อ่านแล้วรันแล้วยังไม่จบ ต้องแก้แล้วรันซ้ำถึงจะจบ

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

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

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

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

ไฟล์ examples/s01/12_every_sense_at_once.py^↗ กับ examples/s01/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 จึงไม่อยู่ในเกณฑ์)
• [ ] ตารางสำรวจเมนูในใบงาน (ข้อ 4.1) กรอกครบ 5 แถวแรก (แถว Controls กรอกเฉพาะทีมที่ถือ Eva Kit)
• [ ] ชี้ได้ว่าเมนูไหนใช้เซนเซอร์ตัวไหน (ตอบปากเปล่ากับผู้สอนได้)
• [ ] จอบอร์ดขึ้นหัวเรื่อง <h2> ของคาบนี้
• [ ] จอบอร์ดขึ้นชื่อทีมและชื่อสมาชิกครบทุกคน ไล่ทีละคน
• [ ] จอบอร์ดขึ้นบรรทัดสีเขียวปิดท้าย
• [ ] examples/s01/09_your_level_rule.py^↗ ผ่านครบหกแถว (เขียวหมด)
• [ ] ถ่ายรูปหน้าจอบอร์ดแนบใน worksheet

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

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

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

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

เปิด practise_codes/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 — คาบ 6 สอน) ลองเรียก .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 ข้อจากสี่ข้อในสไลด์ "ต่อยอด" บันทึกลง worksheet ข้อ 8

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

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

คาบหน้า — เลขบนจอนี้จะออกจากบอร์ด

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

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

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

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

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

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

สิบคาบข้างหน้า — ทีละคาบ ได้อะไรกลับบ้าง

เส้นเรื่องคือเส้นเดียว — คาบ 3 ถึง 8 ทำให้บอร์ดรับรู้และแสดงผลได้ครบ · คาบ 9 ถึง 11 พาออกไปหาโลก · คาบ 12 คือวันที่ทีมเอาทุกชิ้นมาประกอบเป็นของตัวเอง

รายละเอียดเต็ม พร้อมภาพหน้าจอของแต่ละคาบ อยู่ที่ slides/roadmap.html — เปิดดูล่วงหน้าได้เลย

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

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

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

• ชิปบนบอร์ดเราคือใคร — 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 · นับถอยหลัง
ดัดแปลง examples/s01/05_clear_and_refresh.py^↗ ให้นับถอยหลังจากเวลาที่ทีมตั้งเอง แล้วจบด้วยข้อความสีเขียว ลองปรับ TICK_MS แล้วสังเกตความรู้สึกที่ต่างกัน

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

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

เขียนคำตอบลง worksheet ข้อ 8 แล้วเอามาเล่าให้เพื่อนฟังต้นคาบหน้า

หน้าจอของทุกไฟล์ในคาบนี้ (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 คนเรื่องตัวอย่างโค้ด — ข้อร้องเรียนอันดับหนึ่งคือตัวอย่างไม่ช่วยให้คิดออกว่าจะประกอบชิ้นส่วนเข้าด้วยกันอย่างไร · นี่คือเหตุผลที่ examples/s01/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 โดยตรง

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