STM32 และงบเวลา

อ่าน คู่มือ Flash และ RAM ก่อนเพิ่ม buffer หรืองานในเฟิร์มแวร์

ก่อนเริ่มฝึก

วัตถุประสงค์: อ่านตารางเวลา แยก release delay จากเวลาทำงาน และอธิบายงบเวลา พื้นฐาน: อ่าน C/C++ และหน่วยเวลาได้ เวลาฝึกโดยประมาณ: 45 นาที เป็นเวลาที่ผู้จัดทำเสนอ ยังไม่ได้วัดกับผู้เรียนจริง

ตรวจความเข้าใจ: อธิบายหนึ่งแถว log พร้อมหน่วย และระบุว่ายังวัด IRQ latency ไม่ได้ ใช้ผลชุดเดิมประกอบการเรียน การคอมไพล์หรือการจำลองที่ผ่านยังไม่ยืนยันบอร์ดหรือการบินจริง

ดูเส้นทางเรียนทั้งหมด · ทบทวนเซนเซอร์และการสื่อสาร

เลือก STM32 และอ่านโครงสร้างเฟิร์มแวร์

STM32 มีหลายตระกูล เช่น F4, F7 และ H7 ให้ตรวจ core, clock, FPU, RAM/Flash, timer, DMA, บัสเซนเซอร์ และการรองรับของ firmware ตาม รุ่นชิปและบอร์ดจริง FPU ช่วยงาน floating-point ที่รองรับ ส่วน DMA ช่วยถ่ายข้อมูลบางประเภท แต่ทั้งสองยังมีข้อจำกัดการจัดเวลาและหน่วยความจำ เริ่มเครื่องมือจาก STM32CubeIDE และอ่าน datasheet/reference manual ของรุ่นที่เลือก

Timer ใช้กำหนดจังหวะและสร้างสัญญาณ ส่วน interrupt ให้ตอบสนองเหตุการณ์โดยไม่รอวน polling ตลอด ควรทำงานใน interrupt handler ให้สั้น แล้วส่งข้อมูลไปงานที่เหมาะสม การใช้ DMA ไม่ได้ทำให้การเข้าถึงข้อมูลพร้อมกันปลอดภัยเอง ดูตัวอย่างบทบาท timer/interrupt/DMA ใน เอกสาร timer ของ STM32G0 โดยตรวจรายละเอียดใหม่เมื่อใช้ตระกูลอื่น

PX4 แบ่ง sensor, estimator และ controller เป็นโมดูลและส่งข้อมูลผ่าน uORB ส่วน ArduPilot ใช้หลาย thread และ scheduler ตาม HAL/platform การย้ายจาก Arduino จึงต้องเรียนรู้ลำดับงาน การสื่อสารระหว่างงาน และทรัพยากรร่วมด้วย อ่าน PX4 architecture v1.16 และ ArduPilot threading

อ่าน Flash และ RAM ก่อนเพิ่มงานเฟิร์มแวร์

วัตถุประสงค์: อ่านขนาดจาก build แยกจากการใช้หน่วยความจำขณะรัน และทำแผนที่ไม่บวกพื้นที่ซ้ำ พื้นฐาน: อ่าน C/C++ ตัวแปร array และหน่วย byte ได้ เริ่มทำ: อ่านคู่มือและทำโจทย์บน PC หรือกระดาษ ยังไม่ต้องมีบอร์ดหรือ RTOS

ภาพเสมือนจริงสร้างด้วย AI สำหรับบริบทการศึกษา ไม่ใช่ pinout แผนที่หน่วยความจำของชิป หรือผลทดสอบ debugger

Flash, RAM, stack และ heap มีหน้าที่ต่างกัน

คำ	หน้าที่เบื้องต้น	สิ่งที่ต้องตรวจเพิ่ม
Flash	เก็บโปรแกรมและข้อมูลบางส่วนเมื่อปิดไฟ	พื้นที่โปรแกรม bootloader และ partition ตาม target ไม่ใช่ใช้ได้ทั้งหมดเสมอ
RAM	เก็บสถานะและข้อมูลที่ใช้งานขณะรัน	memory region และข้อจำกัดการเข้าถึงของชิป/SDK
Stack	พื้นที่ของการเรียกฟังก์ชันและข้อมูลอัตโนมัติ	ความลึกการเรียก local array และ stack ของ task และ interrupt ตามระบบ
Heap	พื้นที่ที่ allocator จัดสรรและคืนระหว่างรัน	การจองล้มเหลว ขนาดบล็อกต่อเนื่องและการใช้ตามเวลา

Stack และ heap มักเป็นการใช้พื้นที่ RAM ไม่ใช่หน่วยความจำเพิ่มอีกสองก้อน อย่าบวกความจุ RAM + stack + heap เป็นความจุรวม อ่านพื้นฐาน Flash/SRAM จาก Arduino memory overview และตรวจรายละเอียด target จริงต่อ

ตัวเลขคอมไพล์ยังไม่ใช่ RAM ว่างขณะรัน

ในโครงสร้าง linker ทั่วไป .text เกี่ยวกับโค้ด, .data เก็บข้อมูล static ที่มีค่าเริ่มต้น และ .bss เป็นข้อมูล static ที่เริ่มด้วยศูนย์ แต่ตำแหน่งโหลด/ตำแหน่งขณะรันต้องอ่าน linker script/map ของ target เช่น .data อาจมีค่าเริ่มต้นใน Flash แล้วคัดลอกมา RAM เมื่อเริ่มระบบ ข้อมูลเดียวจึงมีบทบาทในงบ Flash และ RAM ต่างกัน ไม่รวมสองงบเป็นเลขเดียว

ชื่อและผลรวมในรายงาน size ขึ้นกับ format ที่เลือก อ่าน GNU size คู่กับรายงาน compiler เดิมในบทนี้ อย่านำขนาดไฟล์ ELF บนดิสก์ไปแทนขนาด Flash หรือสรุปว่า RAM ทั้งหมดลบ static RAM เท่ากับ heap ว่างจริง ขนาดที่จอง stack/ระบบและ memory region ยังมีผล

ถ้าจะประมาณ buffer จากจำนวนสมาชิก ต้องใช้ชนิดข้อมูลและ layout จริง sizeof อาจรวม padding/alignment ของ struct และขนาด pointer ขึ้นกับ target อย่าคิดว่า string มีเท่าจำนวนอักษรที่มองเห็นเสมอ ต้องเผื่อ terminator หรือ metadata ตามชนิดที่ใช้

โจทย์จัดงบแบบไม่บวกซ้ำ

ประกาศสมมติฐาน: RAM ใช้จัดงบได้ 16 KiB โดย 1 KiB = 1,024 bytes จอง static 4 KiB, stack รวม 3 KiB และ buffers เพิ่ม 2 KiB ทั้งสามรายการเป็นพื้นที่แยกกัน ไม่รวมกันอยู่ก่อน ไม่มี overhead อื่นในโจทย์นี้

รายการในโจทย์	ขนาด
ความจุที่ประกาศ	16,384 bytes
static + stack + buffers แยกกัน	9,216 bytes
พื้นที่ยังไม่จัดสรรในแผน	7,168 bytes หรือ 7 KiB

ผล 7 KiB เป็น ส่วนที่เหลือในแผนตามสมมติฐาน ไม่ใช่ผลวัด heap หรือขนาด allocation ที่รับรอง หาก buffers 2 KiB อยู่ใน static 4 KiB แล้ว ต้องนับครั้งเดียว: จอง 7 KiB และเหลือ 9 KiB แทน สำหรับ RTOS บางระบบ stack ของ task จองจาก heap จึงต้องระบุการซ้อนทับก่อนรวมตัวเลข

อีกโจทย์หนึ่ง: มี heap ว่างสองบล็อก 4 KiB กับ 3 KiB คั่นด้วยพื้นที่ที่ยังใช้อยู่ รวมว่าง 7 KiB แต่ก้อนใหญ่สุดเพียง 4 KiB ขอพื้นที่ต่อเนื่อง 6 KiB จึงไม่พอ ภายใต้สมมติฐานว่า allocator ต้องใช้ก้อนเดียว ไม่มีการย้ายหรือเพิ่มพื้นที่ และไม่นับ overhead/alignment ตัวอย่างนี้อธิบาย fragmentation ไม่ใช่ dump ของชิปจริง

ไดอะแกรมเป็นหมวดงบที่ประกาศ ไม่ใช่ address หรือ layout จริง ขนาดแถบ RAM แสดงสัดส่วนของโจทย์เท่านั้น เปิดไดอะแกรมหน่วยความจำขนาดเต็ม

วางแผนตรวจขณะรันและเริ่มฝึก

1. ทำสำเนา ใบวางแผนหน่วยความจำว่าง ระบุ chip/SDK/build/partition หน่วยและแหล่งข้อมูล ให้ค่าที่ยังไม่ทราบเป็น unknown
2. แยกตาราง build, พื้นที่จองและผลขณะรัน ทำ โจทย์ Flash/RAM บนกระดาษ ก่อนดู เฉลยและขอบเขต โจทย์ไม่เพิ่มคะแนนในแบบประเมินเดิม
3. เมื่อมีอุปกรณ์และ SDK ที่รองรับ จึงวางแผนบันทึก free heap กับ largest free block ภายใต้ memory capability เดียวกัน และช่วงงานที่ตรวจ ดู Espressif heap information อย่าใช้ยอดรวมทุกพื้นที่แทนก้อนที่อุปกรณ์หรือ DMA เข้าถึงได้
4. หากใช้ task ให้ตรวจ stack high-water mark พร้อมหน่วยตาม port/SDK และช่วงการทำงานที่ครอบคลุม เอกสาร ESP-IDF RAM usage ระบุเป็น bytes ใน API ที่อธิบาย อย่าคูณขนาด word โดยไม่ได้ตรวจ ผลช่วงที่สังเกตยังไม่รับรอง worst case ทั้งหมด
5. หากจองไม่สำเร็จหรือเกิดอาการผิดปกติ ตรวจผลคืน ขนาด buffer/lifetime การบวกซ้ำและ Log ก่อนเพิ่มหน่วยความจำ หลีกเลี่ยงการจัดสรรที่เวลาไม่แน่นอนในงานคาบสั้นหรือ ISR ตาม SDK ที่ใช้ ต่อ คิวจาก ISR เพื่อเรียนการจำกัดพื้นที่ และ ที่มาและขอบเขต Log เพื่อเตรียมหลักฐาน

ดาวน์โหลดเพิ่ม: คู่มือเริ่มใช้ชุดหน่วยความจำ · ที่มาและสมมติฐานหน่วยความจำ · รายการแฮชไฟล์หน่วยความจำ

จัดงบเวลาและตรวจความหน่วง

ตัวอย่างสมมติ: งานที่ตั้งใจทำ 100 ครั้งต่อวินาทีมีคาบ 10 ms ถ้าอ่านเซนเซอร์ 2 ms ประมาณค่า 2 ms ควบคุม 1 ms และส่งผล 1 ms จะเหลือ 4 ms สำหรับงานอื่นและเผื่อเวลา ตัวเลขนี้เป็นโจทย์ฝึก ไม่ใช่ benchmark หรืออัตราที่กำหนดให้ flight controller ทุกตัว

วัดทั้งเวลาประมวลผลและอายุข้อมูลที่เข้า controller งานอาจใช้ CPU น้อยแต่รับค่าค้างจาก queue ได้ บันทึกคาบจริง jitter, missed deadline, คิวค้าง และพฤติกรรมเมื่อ logging/วิทยุทำงานหนัก หากแยกหลาย MCU ต้องรวมเวลาส่งข้อมูล การซิงก์เวลา และพฤติกรรมเมื่อหนึ่งบอร์ด reset เข้าในงบด้วย

ชุด STM32: ฝึก timing และอ่าน log

วัตถุประสงค์: ต่อยอดจาก GPIO/serial บน Arduino และ ESP32 มาสู่โค้ดที่คอมไพล์สำหรับ ARM STM32 แล้วอ่านหลักฐานว่า task เริ่มช้า ใช้เวลานาน หรือข้ามรอบใด เหมาะกับผู้ที่อ่าน C/C++ และ timestamp ได้ เริ่มบน PC โดยยังไม่ต้องมีบอร์ด

ดาวน์โหลดชุด STM32 timing พร้อมโค้ดและคู่มือ (ZIP) · ผลคอมไพล์อ้างอิง (JSON) · เฉลยข้อมูลจำลอง (JSON) · ใบงาน timing (CSV) · รายการไฟล์และ SHA-256

ใช้ NUCLEO-F446RE (MB1136) เป็น target อ้างอิงของชุดนี้ ไม่เหมารวมกับบอร์ดที่ผู้เรียนมี คอมไพล์ด้วย Arduino CLI 1.5.1, STM32duino 3.0.0 และ xPack ARM GCC 14.2.1-1.1 ผ่าน: โปรแกรม 18,784/524,288 ไบต์, static RAM 1,352/131,072 ไบต์, ไม่พบ warning รวมถึงตรวจซ้ำจาก ZIP ไม่มีการ upload หรือผล LED/serial/timing บนบอร์ดจริง และไม่ได้ port PX4/ArduPilot ลง STM32

โค้ดใช้ cooperative polling ตั้งคาบ 10,000 µs (10 ms) จาก micros() รักษา phase เดิม เมื่อขาดหลายรอบจะทำรอบล่าสุดครั้งเดียวและนับ skipped ใช้เพียง LED บนบอร์ดแล้วเขียน CSV เมื่อ buffer ว่างพอ ไม่ใช้ timer ISR/RTOS และไม่ควบคุมมอเตอร์ คาบและงบ task 2,000 µs เป็นโจทย์สอน ไม่ใช่เกณฑ์ของ flight controller

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

ขั้นตอนบน PC

1. เปิดชุดฝึก: แตก ZIP ลงโฟลเดอร์ใหม่ อ่าน README.md, manifest.json และ compile-result.json คงชื่อโฟลเดอร์ stm32_timing และ sketch ชื่อเดียวกัน
2. ตรวจตรรกะและอ่าน log จำลอง: ใช้ Python 3.11+ standard library รันคำสั่งด้านล่าง แล้วเทียบกับ synthetic-answers.json รัน C++ host tests ด้วย GNU C++11 หากมี compiler เช่นใน Ubuntu/WSL
3. คอมไพล์ target: ใน Arduino IDE 2 เพิ่ม index/วิธีติดตั้งทางการ ติดตั้ง STM32 core 3.0.0 เลือก Nucleo-64 → Nucleo F446RE, generic Serial, USB None, Smallest (-Os) และ Newlib Nano แล้ว Verify เท่านั้น หรือใช้ CLI ด้านล่าง ไม่ต้องติดตั้ง driver/CubeProgrammer เพื่อทำขั้น compile
4. บันทึกและตีความ: กรอกใบงานแยกแหล่งข้อมูลจำลอง/ฮาร์ดแวร์ ตรวจรุ่นเครื่องมือ/options กับ receipt ดู late, work, skipped และ dropped ร่วมกัน หากแก้ task หรือคาบต้องเก็บ protocol ใหม่

python test_analyze.py
python analyze_timing.py synthetic/normal.csv
python analyze_timing.py synthetic/missed.csv
python analyze_timing.py synthetic/wrap.csv
python analyze_timing.py synthetic/dropped.csv
g++ -std=c++11 -Wall -Wextra -Werror test_timing.cpp -o timing-test
./timing-test

arduino-cli core update-index --additional-urls https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
arduino-cli core install STMicroelectronics:stm32@3.0.0 --additional-urls https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
arduino-cli compile --fqbn STMicroelectronics:stm32:Nucleo_64:pnum=NUCLEO_F446RE --warnings all --clean stm32_timing

รอบตรวจนี้เก็บ SDK ใน workspace เท่านั้น Windows พบ include path ที่ขยายยาวจนหา bits/c++config.h ไม่ได้ จึงใช้ junction ชื่อสั้นไป GCC ทางการเดิมและ override compiler.path โดยไม่แก้ SDK หรือ config ระบบ หากพบอาการเดียวกันให้ใช้ที่เก็บ SDK path สั้นใน config ของงาน รายละเอียดอยู่ใน README/receipt ของ ZIP

อ่านผลและข้อควรระวังเบื้องต้น

ค่าใน CSV	อ่านอย่างไร
start_us	เวลาเริ่มตรวจ task แบบ uint32 หน่วย µs
late_us	ช้าจากรอบล่าสุด 0–9,999 µs; ค่าเล็กยังอาจมีรอบเก่าที่พลาด
work_us	เวลาจาก start ผ่าน scheduler/LED จนถึงจุดวัด ก่อนจัด CSV/ส่ง serial
skipped	จำนวนคาบเก่าที่ไม่ได้ทำในครั้งนี้
dropped	ตัวนับสะสมแถวที่ส่งไม่ได้ตั้งแต่ boot ไม่ใช่จำนวน packet หายบน PC

ตัวอย่างจำลอง missed.csv: หลังงานเวลา 10,000 µs มาถึงครั้งต่อไปที่ 40,100 µs จึงพลาดรอบ 20,000/30,000 สองรอบ แต่ late จากรอบล่าสุดมีเพียง 100 µs อีกแถวใช้ work 11,000 µs เกินงบ 2,000 และจบเลยรอบถัดไป ตัวตรวจปฏิเสธ timestamp ย้อน/ซ้ำ phase ไม่ตรง missing row ที่ตัวนับอธิบายไม่ได้ และค่าไม่ถูกหน่วย/ขอบเขต ตรวจ unsigned clock rollover และขอบงบเวลาผ่าน host tests

เมื่อ dropped เพิ่ม ผลรวม skipped/เกินงบเป็นเพียงแถวที่เห็น ยังอาจมีเหตุในแถวที่หาย งาน formatting/serial ที่อยู่นอก work ยังทำให้งานถัดไปช้าได้ ไม่มี log drop ที่รายงานไม่ได้พิสูจน์ว่าเริ่มเก็บตั้งแต่ boot แยกไฟล์หลัง reset และอย่าเว้นแถวสังเกตเกิน 2^31 µs (ประมาณ 35.8 นาที) เพื่อแยก wrap จากการย้อนเวลา; อ่านรายละเอียดขอบเขตในคู่มือ

ขั้นบอร์ดจริงเมื่อมีอุปกรณ์: ตรวจรุ่น/PCB ตาม ST UM1724 MB1136 และ variant STM32duino 3.0.0 ก่อนใช้ LD2/PA5 และ USART2 PA2/PA3 ผ่าน ST-LINK virtual COM ตามสะพานบัดกรี default ใช้เฉพาะ USB/LED ไม่ต่อ ESC/มอเตอร์ เมื่อพร้อมจึง upload ตามคู่มือบอร์ด เปิด terminal 115200 baud เริ่ม capture แล้ว reset เพื่อรับ header เก็บ log/SHA และเงื่อนไขในใบงาน เปลี่ยนตัวแปรทีละอย่าง ผล LED กะพริบอย่างเดียวไม่รับรอง timing การวัด ISR/timing บนบอร์ดจริง รวม DMA/RTOS ยังเป็นงานถัดไป; ชุด Timer Interrupt บน PC อยู่ในหัวข้อถัดไป

เรียนต่อและทบทวน

เรียนต่อ Timer Interrupt และการส่ง tick · กลับภาพรวมขั้นสูง

ฝึกอ่าน phase และแยกงบเวลา polling

วัตถุประสงค์: แยกเริ่มช้า รอบที่พลาด งานเกินงบ และแถว Log ที่ส่งไม่ได้ พร้อมคำนวณ phase กับ clock wrap พื้นฐาน: อ่าน C/C++ หน่วยเวลา และ CSV ห้าช่อง เวลาเสนอ: 45–60 นาที ยังไม่ได้วัดกับผู้เรียนจริง อ่านโจทย์ด้วย CSV/JSON ไม่ต้องมีบอร์ดหรือติดตั้งเพิ่ม

คงภาพเสมือนจริงและแผนผังเดิม ใช้ CSV สังเคราะห์สี่กรณีรวม 11 แถวเดิม ลำดับ scheduler เจ็ด calls และขอบตัวเลขสี่กรณีเป็นโจทย์ที่ประกาศ ไม่มีผลรัน analyzer/compile/บอร์ดใหม่

ดาวน์โหลด วิธีฝึก polling timing, ใบงาน timing 8 ข้อ, ข้อมูลเดิมและโจทย์ที่ประกาศ, ตารางคู่แถวว่าง, ตาราง scheduler ว่าง และ แบบรายงานว่าง ทำก่อนอ่าน เฉลยพร้อมเหตุผล, เฉลยคู่แถว และ เฉลย scheduler ตรวจที่มา/SHA-256 จาก manifest

1. คาบ งบ และ phase · P1–P3

คำนวณคาบจาก 100 Hz และงบจากตัวอย่างสมมติ แล้วกรอกคู่แถวทั้งเจ็ดโดยแยก case ก่อนหาผลต่าง แก้ start delta ด้วย late ของทั้งคู่เพื่อหา scheduled slot delta จากนั้นไล่ anchor/due ของ scheduler เจ็ด calls คำแนะนำ: รักษา phase ด้วยจำนวน slots ไม่ตั้ง anchor ตาม now และ non-due ไม่มี sample ใหม่ จึงเว้นช่องผลไว้

2. แยกรอบที่พลาดกับข้อมูลที่ส่งไม่ได้ · P4–P5

อ่าน missed ที่ late เพียง 100 µs แต่พลาดสองรอบ แล้วแยกจำนวนที่เกินงบงานจากจำนวนที่จบหลัง slot ถัดไป เทียบ dropped ที่ counter เพิ่มหนึ่งแต่ skipped ในแถวที่เห็นเป็นศูนย์ คำแนะนำ: work ของ row ที่ไม่อยู่ใน CSV ให้ตอบว่าไม่ทราบพร้อมเหตุผล ไม่แต่งค่ามารวม และยอด dropped ไม่ใช่ packet loss ที่วัดบน PC

3. Clock wrap และขอบเกณฑ์ · P6–P7

คำนวณ uint32 delta ของ 4,294,966,000→8,704 µs แล้วระบุขอบ half-range/การ reset ก่อนอ้างผล จากนั้นทำตัวอย่างขอบสี่กรณีด้วย work > 2,000 และ late + work > 10,000 คำแนะนำ: ค่าเท่าขอบไม่ใช่ strictly greater และงบงานกับจบหลัง slot ถัดไปเป็นคนละเกณฑ์ ตัวอย่างขอบเป็นโจทย์เลข ไม่ใช่ trace บอร์ด

4. เขียนรายงานที่ระบุจุดวัด · P8

เลือกกรณีหนึ่งกรอกแบบรายงาน สิ่งที่เห็น → สิ่งที่ยังไม่ทราบ → หลักฐานเพิ่ม อ้างไฟล์ แถว คู่ และหน่วย พร้อมระบุว่า work ชุด polling รวม scheduler/LED แต่ก่อน formatting/Serial จึงไม่เทียบกับ work ของชุด ISR เป็น benchmark ตรง ๆ ผล compile เดิมยืนยัน build target ส่วน LED/Serial/timing/IRQ บนบอร์ดจริงยังต้องตรวจแยก

ตรวจตนเอง: ชุดนี้เสนอข้อละ 2 (คำตอบ 1 + เหตุผล/หน่วย/ขอบ 1) รวม 16 ใช้เลือกทบทวน แยกจากใบงานเดิมและไม่ใช่ผลผู้เรียนจริง รอบนี้ตรวจที่มา/ไบต์/ตัวเลขและคำอธิบาย ไม่รัน analyzer/host tests หรือเพิ่มผล compile/upload/firmware/บอร์ดใหม่ เมื่ออธิบายได้ให้ต่อ Timer Interrupt และการส่ง tick

เลือกชุดฝึกหรือทบทวนต่อ

กลับสารบัญชุดฝึก MCU 10 ชุด เพื่อเลือกโจทย์ตามเป้าหมายและพื้นฐานที่ควรรู้ หรือ ทำแบบประเมินความเข้าใจ 12 ข้อ เพื่อหาหัวข้อที่ควรทบทวน

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