# เฉลย FIFO และ counter พร้อมเหตุผล

แยกสองแหล่ง:fixture-rows.csvเป็นค่าจากข้อมูลสังเคราะห์เดิม ส่วนtraceเป็นลำดับที่ประกาศใหม่เพื่ออธิบาย ไม่ใช่enqueue traceที่สังเกตจริง ไม่มีผลฮาร์ดแวร์รอบใหม่

## Q1 · ไล่คิวสี่ช่อง

ดูtrace-answers.csv:หลังpush1..4คิว[1,2,3,4];push5/6ถูกปฏิเสธ คิวคงเดิม overflowสะสม2;pop1แล้วคิว[2,3,4];push7รับได้เป็น[2,3,4,7];popที่เหลือได้2,3,4,7 ไม่มีการเขียนทับของเก่า ตัวอย่างนี้ใช้capacityครบ4ช่อง ไม่ใช่ringแบบเว้นช่องว่างหนึ่งช่อง

## Q2 · นโยบายสัมพันธ์กับงาน

drop-newestรักษารายการเก่าที่รับไว้แต่ค่าล่าสุดอาจถูกปฏิเสธ เหมาะกับงานที่ให้ความสำคัญกับประวัติภายใต้ขอบเขตและต้องรายงานloss ส่วนhandoffเก็บtickล่าสุดอาจรวมหลายcallbackเป็นค่าล่าสุดโดยไม่มีประวัติทั้งหมด งานcontrollerต้องพิจารณาความสด ไม่สรุปว่าFIFOหรือคิวใหญ่ดีกว่าเสมอ ต้องประกาศนโยบายการสูญหาย/อายุให้ตรงวัตถุประสงค์

## Q3 · snapshot ณ enqueue

event1–4ถูกสร้างขณะoverflowยัง0 แม้ส่งหลังpush5/6ถูกปฏิเสธ payloadก็ยัง0 event7ถูกสร้างเมื่อoverflow2จึงมีsnapshot2 mainส่งค่าในevent ไม่ใช่counterล่าสุด Counterสุดท้ายที่เห็นจึงไม่ยืนยันการปฏิเสธที่เกิดหลังenqueueของeventสุดท้าย

## Q4 · ช่องว่างคนละสาเหตุ

| กรณี | tickเดิม→ใหม่ | delta_tick | delta_overflow | delta_dropped | สมการ |
|---|---|---|---|---|---|
|overflow|4→7|3|2|0|3=2+0+1|
|dropped|1→3|2|0|1|2=0+1+1|

overflow:callback5/6เข้าคิวไม่ได้ตามเรื่องสอน ส่วนdropped:task2ทำแล้วแต่แถวSerialไม่ถูกส่ง Counterคนละตำแหน่ง ไม่ใช้overflowแทนSeriallossหรือใช้droppedแทนqueue-full สมการตรวจความสอดคล้องของแถวที่สังเกตภายใต้นิยามนี้ ไม่รับรองcaptureครบทุกช่วง

## Q5 · tickวนกลับ

delta=(new−old) mod2^32;4294967295→0ได้1 และ0→1ได้1 ทั้งสองไม่มีช่องว่างตามcounter0ที่รายงาน ใช้ช่วงเดินหน้า1..2^31−1;delta0ซ้ำ/ตั้งแต่2^31กำกวม ปฏิเสธcounterย้อนหลังและแยกไฟล์หลังreset/counterwrap tick0ต่อจากUINT32_MAXไม่ใช่หลักฐานreboot ขณะเดียวกันtraceสั้นก็ยังพิสูจน์ว่าไม่มีrebootจริงไม่ได้

## Q6 · อายุข้อมูล

40000us=40ms คือช่วงจากcallback timestampถึงmainเริ่มLEDหลังpop ไม่ใช่เวลาจากhardwaretimer eventถึงเข้าISRและไม่ใช่deadline Workloadอื่น/CSV/Serialทำให้popถัดไปช้าได้ คิว4ช่องหรือขอ100Hzจึงไม่รับรองageไม่เกิน40ms กรณีนี้เป็นตัวอย่างแต่ง ไม่ใช่ค่าสูงสุดที่วัดบนSTM32

## Q7 · งบงานที่นิยามไว้

overflow data_row4,tick4:work2500us=2.5ms มากกว่างบสอน2000us=2ms เกิน500us=0.5ms มี1แถว over-budget งานwork_usครอบคลุมLED task แต่ไม่รวมpop/จัดCSV/Serial จึงไม่ใช่เวลารวมทั้งloopหรือCPU utilization แถวอื่นในfixtureต่ำกว่างบไม่พิสูจน์ว่าระบบจริงทันทุกdeadline

## Q8 · จำกัดข้อสรุป

normalมี3แถว,counteroverflow/droppedท้ายที่เห็น0 บอกว่าไม่มีlossที่counterรายงานในข้อมูลชุดนี้ แต่ไม่พิสูจน์captureครบตั้งแต่boot/หลังแถวสุดท้าย overflowเป็นsnapshotและอาจไม่แสดงrejectionหลังeventสุดท้าย Host testsไม่จำลองMCU concurrency;volatileไม่ใช่ตัวให้mutual exclusion ตัวอย่างเดิมให้mainเก็บ/คืนPRIMASKรอบpop และcallbacktickตรวจtimer updatesที่ถูกรวมขณะmaskIRQไม่ได้ ต้องใช้protocol/session/captureและจุดวัดจริงก่อนอ้างผลฮาร์ดแวร์

## เกณฑ์ตรวจตนเองที่เสนอ

คำตอบ1+เหตุผล/หน่วย/ข้อจำกัด1ต่อข้อรวม16 Q1ครบ12ขั้น;Q2นโยบายกับงาน;Q3snapshot;Q4สองสมการ;Q5deltaสองช่วง/ขอบreset;Q6หน่วย/ที่มาage;Q7แถว/ส่วนงาน;Q8ขอบเขตcounter/concurrency คะแนนไม่ผ่านการประเมินกับผู้เรียนจริง ใช้เพื่อเลือกอ่านซ้ำ