# เฉลย Timer Interrupt พร้อมเหตุผลและขอบ

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

## I1 · เก็บเหตุสั้นใน callback

onTimerUpdate เก็บ micros() แล้วเพิ่ม observedTicks งาน LED/จัด CSV/Serial อยู่ main โค้ดไม่รอ buffer ใน callback setOverflow(100,HERTZ_FORMAT) เป็น requested frequency คาบ 1/100s = 10ms เป็นค่าคำนวณจากคำขอ ยังไม่ใช่คาบจริงที่วัด ISR ที่ทำงานหนักทำให้ขอบเวลาหรือการรับเหตุเปลี่ยน ต้องวัดแยกก่อนสรุป

## I2 · snapshot เป็นคู่และคืนสถานะเดิม

อ่าน savedMask ก่อน disable IRQ คัดลอก tick กับ timestamp ในช่วงปิด IRQ แล้วคืน savedMask ด้วย __set_PRIMASK การใช้ volatile อย่างเดียวไม่ทำให้การอ่านสองช่องเป็น snapshot คู่ที่สอดคล้อง เปิด IRQ ทุกครั้งจะเปลี่ยนสถานะผู้เรียกที่อาจปิดไว้เดิม นี่คือการอ่านโครงสร้าง source ไม่ใช่ผลทดสอบ concurrency บน MCU และไม่วัดระยะ critical section

## I3 · latest value ทำครั้งเดียว

normal เริ่ม handled0: observed0 Idle/handled0; 1 Ready/handled1/missed0; 1 ซ้ำ Idle/handled1; 4 Ready/handled4/missed2; 3 Invalid/handled4; 5 Ready/handled5/missed0 ตัว Ready ทำงาน main หนึ่งครั้งด้วย tick ล่าสุด ไม่ทำซ้ำทุก tick ที่ค้าง Idle/Invalid ไม่เขียน missed parameter และไม่เปลี่ยน handled ช่อง new_missed ว่างหมายถึงไม่มีผลใหม่ ไม่ใช่ missed0 รอบใหม่ อ่านตารางเฉลยที่แยก sequence wrap

## I4 · service ไม่ใช่ IRQ latency

missed data_row1→2 tick delta3/current missed2/dropped delta0; คู่2→3 delta1/missed0 รวม missed ที่เห็น2 สูงสุด service500us/work2500us งานเกินงบ2000usหนึ่งแถว เกิน500us service จาก timestamp ของ ISR ล่าสุดถึง main เริ่ม LED หลัง snapshot/handoff จึงไม่รู้เวลาจาก hardware deadline ถึง ISR เข้า หลาย update ขณะปิด IRQ อาจรวมเป็น callback เดียว tick/missed นี้นับส่วนที่ถูกเรียก จึงไม่รับรอง hardware updates ทั้งหมด

## I5 · แถวส่งไม่ได้ต่างจาก callback ที่ไม่ได้ทำรายครั้ง

dropped คู่1→2 tick delta2/drop delta1/current missed0 จำนวนที่อธิบายขั้นต่ำ = missed+1+drop delta = 2 ข้อมูลสังเคราะห์กำหนด task ของ tick2 ทำแล้วแต่ส่ง row ไม่ได้ ไม่มี service/work ของ row นั้นใน CSV จึงตอบไม่ทราบ ไม่เติมศูนย์หรือค่าเฉลี่ย missed รวม0เป็นเฉพาะแถวที่เห็น dropped สะสมไม่ใช่ packet loss บน PC และไม่รู้เหตุหลังแถวสุดท้าย กรณีหลาย row หาย ค่า missed ในแถวหายอาจมีเพิ่ม; accounted เป็นขั้นต่ำของคู่ ไม่ใช่การวัด hardware events

## I6 · wrap และ half-range

(1−4294967294) mod 4294967296 = 3 callbacks; latest-value handoff ให้ missed2 ใน sequence wrap เริ่ม handled4294967294 แล้ว observed1 Ready/handled1; observed2147483649 มี delta2147483648=2^31 จึง Invalid/handledยัง1; observed2 Ready/missed0 Analyzer เดิมรับคู่ที่ 0<delta<2^31 และ dropped ไม่ย้อน การลด tick ในตัวอย่าง wrap ไม่ใช่ reset เสมอ แต่ reset/หลาย wrap หรือช่องว่างเกินขอบยังต้องแยก run และเก็บหลักฐาน ไม่ใช้เลขนี้ยืนยัน concurrency

## I7 · จุดวัดกับขอบงบ

โจทย์ work1999/2000/2001us ให้ over-budget false/false/true เพราะใช้ work>2000 ไม่ใช่ ≥ ไม่ใช่ trace เพิ่ม service นับจาก ISR timestamp ถึง start; work นับ LED task จาก start ถึงจุดวัดก่อน CSV/Serial ไม่รวม snapshot/handoff ซึ่งเกิดก่อน start ชุด polling รวม scheduler/LED ใน work จึงไม่เทียบตรงเป็น benchmark และ analyzer interrupt ไม่ได้ให้เกณฑ์ finish-after-next-slot แบบ polling ผล over-budget ไม่ครอบคลุมเวลาทั้ง loop

## I8 · รายงานที่มีขอบสังเกต

ตัวอย่าง missed: อ้าง synthetic/missed.csv data_row1–3 กับคู่1→2 รายงาน missed2/serviceสูงสุด500us/workสูงสุด2500us/เกินงบหนึ่งแถวตามคำตอบเดิม ระบุว่าไม่รู้ IRQ latency, hardware updates ที่ถูกรวม, capture ครบตั้งแต่ boot หรือเวลาจัด/ส่ง Log Receipt compile NUCLEO-F446RE เดิมยืนยัน build target ไม่ใช่ upload หรือผล LED/Serial/timing จริง เสนอ protocol และจุดวัดบนบอร์ดเมื่อมีอุปกรณ์โดยแยกเป็นแผน ไม่ใช่ผลที่เกิดแล้ว

เกณฑ์ฝึกเสนอ 16 คะแนน: ข้อละคำตอบ 1 และเหตุผล/หน่วย/ขอบ 1 ใช้เลือกทบทวน snapshot, counter, half-range และจุดวัด ไม่แทนเกณฑ์เดิมหรือผลผู้เรียนจริง