A0 — สร้างอะไรได้บ้าง และแต่ละส่วนอยู่ที่ใด

เป้าหมายของหัวข้อนี้

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

SDK ชุดนี้ประกอบด้วยอะไร

สิ่งที่อยู่ในแพ็กเกจมี 4 อย่าง

• ไลบรารีโมดูลที่คอมไพล์มาแล้ว อยู่ใต้ lib/<module>/ แต่ละตัวมี archive (ไฟล์ไลบรารีแบบสแตติก .a) ของตน พร้อม include/, api.txt (บัญชี symbol ที่ export ออกมา), consumer_must_provide.txt, overridable.txt และ PROVENANCE.txt ทั้งชุดลงลายเซ็นไว้ ตรวจได้ด้วย lib/verify.sh เทียบกับ lib/manifest.txt
• เทมเพลตแอปพลิเคชันที่ build ได้จริง โปรเจกต์ ModusToolbox 3 ตัว (proj_cm33_s, proj_cm33_ns, proj_cm55) ที่ลิงก์ archive เหล่านั้นเข้าไปและบูตขึ้นมาเป็นเฟิร์มแวร์ที่ใช้งานได้ พร้อมไดรเวอร์เซนเซอร์ ไปป์ไลน์ MQTT และหน้า UI ในรูป ซอร์ส
• Tutorial จัดกลุ่มตามฟีเจอร์ อยู่คู่กับฟีเจอร์ของตนในแถบด้านข้าง
• คู่มืออ้างอิง API อยู่ท้ายสุดของทุกส่วน หนึ่งหน้าต่อหนึ่งตระกูลของฟังก์ชัน โดยแต่ละหน้ามีตัวอย่างโค้ดกำกับ

ความสามารถแต่ละอย่างเป็นของโมดูลใด

archive ที่ส่งมอบมามี 6 ตัว (lib/manifest.txt) — 3 ตัวลิงก์เข้ากับ CM55 และ 3 ตัวลิงก์เข้ากับ CM33_NS ทั้ง 2 คอร์ไม่เข้ากันในระดับ ABI การลิงก์ผิดคอร์จึงล้มเหลวตอนลิงก์ ไม่ใช่ตอนรัน

โมดูล	Archive	คอร์	symbol ที่ export	ทำอะไร	เริ่มอ่านที่
Edge AI	libbento_edge_ai.a	CM55	39	เอนจินอนุมานบนอุปกรณ์: ทะเบียนโมเดล, ตัวจัดเส้นทางป้อนข้อมูลจากเซนเซอร์ที่ทำให้โมเดลหลายตัวทำงานพร้อมกันได้ และตัวโหลดโมเดลจาก manifest ตอนรัน	Edge AI
IPC Core	libbento_ipc.a	CM55	58	บริการภายในข้ามคอร์: sensor hub, LCD, UI และการกระจายงาน	หน้า UI และ IPC
CM55 Core	libbento_cm55.a	CM55	30	การเปิดใช้งานจอแสดงผล, ระนาบควบคุมการเชื่อมโมเดล และขั้นตอนการ provision HSM ตามที่ใช้งานจริง	หน้า UI และ IPC
TESAIoT HSM	libbento_hsm.a	CM33_NS	18	การลงทะเบียน OPTIGA Trust M: คู่กุญแจของอุปกรณ์, CSR และเส้นทาง Protected Update ที่แยกออกมา	ความปลอดภัย / HSM
BLE NUS	libbento_secure.a	CM33_NS	87	agent ของ BLE NUS ที่รับส่งโปรโตคอล Bento Buddy	BLE / Bento Buddy
MicroPython Secure	libbento_mpy.a	CM33_NS	46	โปรโตคอลสาย TACP และการจัดการข้อมูลรับรอง WiFi ตามที่ชั้น MicroPython ใช้ (เฉพาะ mtb-mpy)	ชุดเอกสาร mtb-mpy

Note

เครดิต: โมเดล Edge AI เป็นของ Infineon ไม่ใช่ของ TESAIoT โมเดล motion, audio และ radar ที่เฟิร์มแวร์นี้ส่งมอบ (proj_cm55/modules/ai_models/model_*.c) เป็นผลลัพธ์ที่ export จาก DEEPCRAFT™ Studio และมีลิขสิทธิ์ของ Imagimob AB ซึ่งเป็นบริษัทในเครือ Infineon Technologies ส่วนโมเดล Siren, Cough และ Factory Alarm เป็น DEEPCRAFT™ Ready Model ของผู้สร้างรายเดียวกัน เผยแพร่โดย Infineon อยู่ภายใต้ Imagimob AI Model Evaluation License Agreement และไม่ได้แจกจ่ายต่อในแพ็กเกจนี้ TESAIoT ไม่ได้ฝึกและไม่ได้เป็นเจ้าของโมเดลใดเลย สิ่งที่เป็นของ TESAIoT คือ engine ที่ครอบอยู่ ซอร์สของโมเดลที่ส่งมอบมาระบุเพียง All Rights Reserved โดยไม่มีการให้สิทธิ์ใด ๆ เขียนไว้ในไฟล์ ที่นี่จึงเป็นการให้เครดิต ไม่ใช่การส่งต่อสิทธิ์ การใช้งานที่นี่เป็นไปเพื่อการวิจัยและการอบรม ไม่ใช่การใช้เชิงพาณิชย์ ผู้ที่ต้องการสิทธิ์การใช้งานต้องขอจาก Infineon และ Imagimob โดยตรง ผู้ที่ต้องการฝึกโมเดลของตนเองเริ่มได้ที่ https://www.infineon.com/design-resources/embedded-software/deepcraft-edge-ai-solutions/deepcraft-studio รายละเอียดฉบับเต็มและการอ้างอิงข้อสัญญาอยู่ที่ THIRD_PARTY_NOTICES.md §2.2, §2.4 และ §4.3

สิ่งที่ไม่ได้เป็นไลบรารี และเป็นเรื่องที่ต้องรู้ก่อนไปหา ได้แก่ อุปกรณ์ต่อพ่วง (เซนเซอร์, LED, ปุ่ม, radar, บอร์ดฐาน QWA309) และการเชื่อมต่อ (WiFi, MQTT, mTLS) ทั้ง 2 ส่วนส่งมอบมาในรูป ซอร์สของเทมเพลต ไม่มี libbento_peripherals.a และไม่มีไลบรารีการเชื่อมต่อ อยู่ที่ใดเลย แผนที่ว่า API แต่ละตระกูลอยู่ที่ส่วนใดของเว็บไซต์นี้อยู่ที่ API ของอุปกรณ์ต่อพ่วงอยู่ที่ใด และ API แต่ละตัวอยู่ที่ใด ส่วนที่เก็บข้อมูลกับข้อมูลรับรองอยู่ที่ ที่เก็บข้อมูลและข้อมูลรับรอง

"อยากทำ X" — เปิดบทไหน

อยากทำ	เปิดที่	หมายเหตุ
ทำให้บอร์ดรันโค้ดของตัวเองเป็นครั้งแรก	A1 — จากไฟล์ zip ถึงโปรแกรมแรก	unpack → build → flash → โปรแกรมแรก
อ่านค่าเซนเซอร์	J1 — บัสของเซนเซอร์และ lock ของมัน แล้ว อุปกรณ์ต่อพ่วงโดยสรุป	bus lock มาก่อนเสมอ
ขับ LED หรืออ่านปุ่ม	อุปกรณ์ต่อพ่วงโดยสรุป (pq_pins)	brightness() เป็นกลไก 2 แบบ มีเพียงสามขาที่หรี่ด้วยฮาร์ดแวร์ได้
รู้ว่าเซนเซอร์บนหน้าจออัปเดตอย่างไร	J3 — task ดันข้อมูลอัตโนมัติกับ sensor hub	auto-push task เขียนลง IPC sensor hub
ใช้ radar	J6 — เรดาร์
รันโมเดล Edge AI	E1 — Select, confirm, start: REQUESTED เทียบกับ ACTIVE	REQUESTED ไม่เท่ากับ ACTIVE
รันหลายโมเดลพร้อมกัน	E2 — Parallel set และการวนถามผลลัพธ์
หยุด/ถอดโมเดล หรือโหลดโมเดลที่ staged ไว้	E3 — Stop, unload และโมเดล staged
หาสาเหตุที่อนุมานแล้วผลไม่เข้าท่า	E4 — การอ่านข้อมูลวินิจฉัยของ Edge AI
ต่อ WiFi	C1 — WiFi: ที่เก็บข้อมูลรับรอง 2 แห่งกับการเชื่อมต่ออัตโนมัติตอนบูต	ที่เก็บข้อมูลรับรองมี 2 แห่ง
สั่ง scan/connect จากหน้าจอ	C2 — WiFi จาก UI ผ่าน IPC
ส่งข้อมูลขึ้นคลาวด์	C3 — TESAIoT cloud: ไฟล์ config → MQTT task → broker
ใช้ตัวตน mTLS ที่ยืนอยู่บนชิปนิรภัย	C4 — mTLS: ตัวตนของ TLS ที่ยึดกับ OPTIGA
คุยกับ OPTIGA Trust M	D1 — วินัยการเข้าถึงชิป: gate, lock, touch-hold	ระเบียบการเข้าถึงมาก่อนการเรียกใด ๆ
ลงทะเบียนอุปกรณ์ / ออก CSR / Protected Update	D2 — การลงทะเบียนและ Protected Update ตั้งแต่ต้นจนจบ
เพิ่มหน้าจอใหม่	F1 — การเพิ่มหน้าจอ: 3 ไฟล์ กับความจริงเรื่อง Makefile	ต้องต่อสายครบทั้งสามที่ หรือไม่ต่อเลย
สั่ง widget จากอีกคอร์หนึ่ง	F2 — การขับ widget จาก MicroPython ผ่าน IPC
เก็บไฟล์หรือค่าตั้งไว้ข้ามการรีบูต	G1 — bento_storage กับที่เก็บข้อมูลรับรองฝั่ง C
เปิด BLE / ต่อกับ Bento Buddy	I1 — การ bring-up BLE และกฎวิทยุเดียว	วิทยุมีชุดเดียว WiFi กับ BLE ใช้พร้อมกันไม่ได้
เข้าใจว่าเฟิร์มแวร์บูตขึ้นมาอย่างไร	B1 — เดินดูลำดับการบูตของ CM33_NS แล้ว B2 — การบูต CM55 จนถึงเฟรมแรก
แปลความบรรทัดบนคอนโซลหรือรหัส LED	ภาคผนวก W — แผนที่สัญญาณ	อยู่ในภาคผนวก
รู้ว่าอะไรเคยทำให้คนอื่นเสียเวลามาแล้ว	ภาคผนวก X — กับดักและ anti-pattern
รู้ว่าตัวเองต้องจัดหา symbol ใดให้ archive	ภาคผนวก Y — symbol ที่ผู้ใช้ไลบรารีต้องจัดหา และ symbol ที่เขียนทับได้	หนึ่งหัวข้อต่อหนึ่งโมดูล

ตัวอย่างโค้ดอยู่ที่ใด

มีสามที่ และตั้งใจให้ต่างกัน

• หน้าอ้างอิงของแต่ละฟังก์ชัน มีตัวอย่างประกอบ ตัวอย่างที่ยกมาจากซอร์สที่ส่งมอบจริงจะมีหัวข้อ ที่มา ระบุไฟล์ที่ยกมา ส่วนตัวอย่างที่ไม่มี call site ในของที่ส่งมอบจะมีหัวข้อ ตัวอย่าง (เขียนขึ้นเอง) กำกับไว้ตรง ๆ ผู้อ่านจึงแยกออกเสมอว่ากำลังอ่านโค้ดที่รันอยู่จริง หรือโค้ดที่เขียนขึ้นเพื่ออธิบาย
• Tutorial เดินโค้ดจริงตามลำดับ พร้อมอ้างไฟล์และบรรทัด และปิดท้ายแต่ละขั้นด้วยกล่อง สิ่งที่ควรสังเกต ที่ยกเฉพาะสัญญาณซึ่งตรวจแล้วว่าพิมพ์ออกมาจริง
• อุปกรณ์ต่อพ่วงโดยสรุป เป็นตารางล้วน ทุกการเรียกฝั่ง C และฝั่ง Python พร้อมไฟล์ บรรทัด และ gate BSP_HAS_* ของแต่ละตัว ใช้เมื่อรู้แล้วว่ากำลังหาอะไร

ทีละขั้น

ขั้นที่ 1 — เลือกความสามารถหนึ่งอย่างจากตารางโมดูล

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

สิ่งที่ควรสังเกต

ส่วนนั้นเปิดออกมาที่หัวข้อ Tutorial เป็นลูกตัวแรกเสมอ ไม่ใช่รายการฟังก์ชัน

ขั้นที่ 2 — เปิดหน้าอ้างอิงหนึ่งหน้า แล้วดูว่าตัวอย่างของมันเป็นแบบใด

หาหัวข้อ ที่มา หรือ ตัวอย่าง (เขียนขึ้นเอง) บนหน้านั้น

สิ่งที่ควรสังเกต

ทุกหน้ามีอย่างใดอย่างหนึ่ง หน้าที่มี ที่มา คือโค้ดที่รันอยู่บนบอร์ดจริงในตอนนี้

ขั้นที่ 3 — ไปที่บท A1

บทถัดไป พาไปจากไฟล์ zip ถึงโปรแกรมแรกที่เขียนเอง ซึ่งเป็นจุดที่แผนที่ข้างต้นเริ่มมีประโยชน์จริง

สิ่งที่ควรสังเกต

บทนั้นจบด้วยบอร์ดที่กำลังรันโค้ดของผู้อ่าน ไม่ใช่จบด้วยหน้าต่างคอนโซล

กับดัก

• การหาไลบรารีของอุปกรณ์ต่อพ่วง ไม่มี ไดรเวอร์เซนเซอร์และ binding ส่งมอบมาในรูปซอร์สของเทมเพลต (API ของอุปกรณ์ต่อพ่วงอยู่ที่ใด) การไล่หา libbento_peripherals.a จะไม่พบอะไรเลย
• การตั้งชื่อส่วนประกอบตามชื่อไดเรกทอรีที่มันอยู่ ชื่อไดเรกทอรีไม่ได้บอกว่าโค้ดข้างในทำอะไร ตารางโมดูลข้างต้นระบุตามสิ่งที่ archive แต่ละตัว export ออกมาจริง (lib/<module>/api.txt)
• การคิดว่าโมดูลใดก็ลิงก์เข้ากับคอร์ใดก็ได้ archive 3 ตัวเป็นของ CM55 และอีก 3 ตัวเป็นของ CM33_NS การลิงก์ผิดคอร์ล้มเหลวตอนลิงก์ ซึ่งเป็นผลลัพธ์ที่ดีแล้ว
• การคาดหวังให้ mpy_secure มีอยู่บน mtb-only แพ็กเกจนั้นไม่ได้ลิงก์ libbento_mpy.a ชื่อ lfs_wifi_creds_* ทั้งหกเป็นข้อยกเว้นเดียว โดยส่งมอบมาใหม่ในรูปซอร์สฝั่ง C (ที่เก็บข้อมูลและข้อมูลรับรอง)

ขอบเขตการใช้กับแต่ละ variant

variant ที่ใช้ได้

mtb-mpy และ mtb-only แผนที่ในบทนี้ใช้ได้กับทั้ง 2 แพ็กเกจ ต่างกันเพียงแถว MicroPython Secure ในตารางโมดูล ซึ่งไม่มีอยู่ในชุดเอกสารของ mtb-only