บิตสถานะผู้ส่งใน CAN FD ช่วยตั้งสมมติฐานอย่างไร

บันทึก CAN FD อาจมีธง ESI กำกับมากับเฟรมที่เครื่องมือรับได้ครบ ธงนี้ช่วยให้เห็นข้อมูลด้านสถานะความผิดพลาดของผู้ส่ง แต่ไม่ใช่คำตัดสินว่าข้อมูลในเฟรมนั้นเสีย และไม่ใช่ตัวนับความผิดพลาด บทความนี้อธิบายวิธีใช้ ESI เป็นเบาะแสตามเวลา พร้อมขอบเขตที่ต้องระวังเมื่อข้อมูลผ่านเกตเวย์หรือเครื่องมือมีวิธีเก็บธงเฉพาะ

ESI บอกสถานะ ไม่ใช่ผล CRC

ในการทำงานปกติของตัวควบคุม CAN FD บิต ESI สะท้อนสถานะ error-active หรือ error-passive ของผู้ส่ง โดยระดับ dominant สัมพันธ์กับ error-active และ recessive กับ error-passive ส่วนการตรวจว่าเฟรมรับถูกต้องเป็นกลไกอีกชุดหนึ่ง ดังนั้นเฟรมที่มี ESI แสดง error-passive ยังสามารถเป็นเฟรมที่รับถูกต้องได้ ไม่ควรทิ้ง payload เพียงเพราะธงนี้โดยไม่มีข้อตกลงแอปพลิเคชันรองรับ

ESI ไม่บอกค่า TEC หรือ REC เป็นจำนวน และไม่บอกว่าข้อผิดพลาดก่อนหน้าเกิดจากอะไร จึงใช้แทนการอ่านตัวนับหรือการเก็บ error frame ไม่ได้ อีกทั้ง error-passive ไม่เท่ากับ bus-off การที่ยังมีเฟรมจากผู้ส่งในบันทึกและมี ESI จึงต้องตีความตามสถานะที่รายงาน ไม่ใช้คำว่ากล่องออกจากบัสโดยอัตโนมัติ

1. 1
   ตรวจเฟรม FD

   ยืนยันว่าฟิลด์ที่อ่านคือ ESI ของเฟรม ไม่ใช่ธงผิดพลาดชนิดอื่นในโปรแกรม

2. 2
   อ่านสถานะปกติ

   dominant สัมพันธ์กับ error-active ส่วน recessive กับ error-passive โดยยังรับเฟรมถูกต้องได้

3. 3
   ตรวจเกตเวย์

   ฮาร์ดแวร์บางแบบส่ง ESI เป็น recessive ได้แม้โมดูลยัง error-active จึงต้องรู้บริบท

ธงสถานะไม่ใช่ผลตรวจ CRC และมีข้อยกเว้นในโหมดเกตเวย์บางแบบ

ตัวอย่างสมมติของสถานะที่เปลี่ยนในบันทึก

สมมติชุดฝึกมีเฟรมจาก ก ที่วินาที 1 แสดง error-active วินาที 2 และ 3 แสดง error-passive และวินาที 4 กลับมา error-active เฟรมทั้งหมดในตัวอย่างผ่านการรับของเครื่องมือ เราจึงเห็นการเปลี่ยนสถานะที่สัมพันธ์กับผู้ส่งในช่วงนั้น แต่ไม่ทราบจำนวนเหตุผิดพลาดระหว่างวินาที และไม่รู้ค่าตัวนับสูงสุดจาก ESI เพียงบิตเดียว

ถ้ารายงานว่า ก เสียสองครั้งเพราะมีสองเฟรมแสดง error-passive จะนับผิดความหมาย สองเฟรมอาจอยู่ในช่วงสถานะเดียวกันที่ต่อเนื่อง และยังมีเฟรมอื่นระหว่างนั้นที่ไม่ได้ยกมาในตัวอย่าง สิ่งที่ควรตรวจคือข้อมูลก่อนการเปลี่ยนครั้งแรกและเงื่อนไขที่ทำให้กลับมา ไม่แปลงจำนวนเฟรมที่ธงตั้งเป็นจำนวนครั้งของความเสียหาย

นำไปใช้ประกอบเส้นเวลาของผู้ส่ง

1. ตรวจว่ารายการเป็น CAN FD จริงและช่อง ESI ของเครื่องมือมีนิยามตรงกับบิตในเฟรม
2. แยกข้อความตามชนิดเฟรม ช่องเครือข่าย และผู้ส่งเท่าที่มีเอกสารรองรับ ไม่เดาผู้ส่งจากชื่อรหัสเอง
3. ทำเครื่องหมายช่วงที่ธงเปลี่ยนและเก็บบริบทก่อนหน้า รวมสถานะข้อผิดพลาดอื่นที่อ่านได้
4. ตรวจว่าข้อมูลผ่านเกตเวย์หรือมีโหมดฮาร์ดแวร์ที่ปรับการส่ง ESI ได้หรือไม่
5. สรุป ESI เป็นหลักฐานสถานะที่เห็น พร้อมระบุข้อมูลที่ยังต้องใช้ยืนยันต้นเหตุ

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

1. 1
   วินาที 1

   เฟรมสมมติของ ก แสดง error-active

2. 2
   วินาที 2–3

   เฟรมแสดง error-passive ทั้งสองครั้ง อาจเป็นสถานะเดียวต่อเนื่อง

3. 3
   วินาที 4

   กลับมา error-active โดยยังไม่ทราบค่าตัวนับสูงสุดระหว่างนั้น

4. 4
   ย้อนหาบริบท

   ต้องดูข้อมูลก่อนธงเปลี่ยนและสถานะอื่น ไม่แปลงจำนวนเฟรมเป็นจำนวนครั้งที่เสีย

สองเฟรมที่แสดง error-passive ไม่ได้แปลว่าเสียสองครั้ง

ข้อยกเว้นเมื่อมีโหมดเกตเวย์

Microchip ระบุสำหรับตัวควบคุมบางแบบว่าโหมดเกตเวย์สามารถทำให้ ESI ถูกส่งเป็น recessive แม้ตัวโมดูลที่ส่งอยู่ใน error-active ได้ เพื่อรองรับบริบทการส่งต่อ ดังนั้นการอ่าน ESI ฝั่งออกแล้วสรุปว่าฮาร์ดแวร์เกตเวย์เอง error-passive เสมอจึงไม่ครอบคลุม ต้องตรวจความสามารถและการตั้งค่าที่ใช้จริง บทความนี้อธิบายข้อยกเว้นโดยไม่ให้คำสั่งเปลี่ยนรีจิสเตอร์

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

ตรวจสอบผลร่วมกับความครบของข้อมูล

หลังแก้เหตุที่มีหลักฐาน ให้ตรวจว่า ESI กลับสู่สถานะที่คาดและข้อมูลยังมาต่อเนื่อง หากธงหายเพราะโปรแกรมส่งออกไม่เก็บฟิลด์นี้ ผลนั้นไม่ใช่การฟื้นของผู้ส่ง ต้องเปรียบเทียบรูปแบบไฟล์และธงอื่นด้วย ตัวอย่างการตรวจคือเปิดไฟล์ดิบที่มีธงครบแล้วคำนวณช่วงสถานะใหม่ แทนดูเฉพาะคอลัมน์ที่ผู้ใช้เลือกแสดงบนหน้าจอ

การยืนยันว่าไม่มีปัญหาไม่ควรใช้เพียง ESI เป็น error-active ตลอด เพราะตัวนับอาจมีข้อผิดพลาดที่ยังไม่ถึงเกณฑ์เปลี่ยนสถานะ และเหตุสั้นอาจอยู่ระหว่างเฟรมที่เก็บไว้ รายงานควรระบุเวลาสังเกต จำนวนเฟรม และสถานะข้อผิดพลาดที่เครื่องมือรองรับร่วมกัน การอ่านธงเป็นหลักฐานส่วนหนึ่งของเรื่องจะช่วยให้ใช้ข้อมูลนี้ได้มากโดยไม่ขยายเกินความสามารถของมัน