บิตแทรกของ CAN เปลี่ยนความยาวเฟรมอย่างไร

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

เหตุผลที่ไม่ปล่อยให้ระดับเดิมยาวตลอด

ตัวควบคุมแต่ละโหนดมีนาฬิกาของตน จึงอาศัยขอบสัญญาณช่วยปรับจังหวะให้สอดคล้องกัน ในบริเวณที่ใช้กฎแทรกบิตของ Classical CAN เมื่อมีบิตค่าเดียวกันต่อเนื่องห้าบิต ผู้ส่งแทรกบิตตรงข้ามก่อนดำเนินต่อ ผู้รับที่รู้กฎจะแยกบิตแทรกออก การนับทำต่อเนื่องตามส่วนของเฟรมที่อยู่ภายใต้กฎ ไม่ได้เริ่มใหม่ทุกขอบเขตไบต์ที่หน้าจอแสดง

กฎนี้ไม่ได้บังคับทั้งเวลาที่บัสทำงานและพัก ช่วง delimiter และส่วนท้ายมีรูปแบบของตน การเห็นระดับ recessive ยาวขณะบัสว่างจึงไม่ใช่ stuff error โดยอัตโนมัติ ต้องรู้ว่าขณะนั้นอยู่ในส่วนใดของเฟรมก่อนนับ นอกจากนี้ CAN FD มีรายละเอียดการแทรกบิตในส่วน CRC ต่างจาก Classical CAN จึงต้องเลือกตัวถอดรหัสให้ตรงรูปแบบ และไม่ยกกฎอย่างย่อไปอธิบายทุกตำแหน่งของ FD

1. 1
   นับลำดับ

   นับบิตค่าเดียวกันต่อเนื่องในส่วนเฟรมที่ใช้กฎ ไม่เริ่มใหม่ทุกไบต์

2. 2
   แทรกตรงข้าม

   เมื่อครบห้าบิต ผู้ส่งแทรกบิตอีกระดับเพื่อสร้างขอบสำหรับรักษาจังหวะ

3. 3
   ถอดบิตแทรก

   ผู้รับนำบิตที่แทรกออกก่อนส่งข้อมูลต่อให้แอปพลิเคชัน

4. 4
   รักษาขอบเขต

   ช่วงพักและส่วน delimiter มีกฎของตน CAN FD ส่วน CRC ก็มีรายละเอียดต่างออกไป

ใช้กับบริเวณที่อยู่ภายใต้กฎ Classical CAN ไม่ใช่ทุกช่วงของบัส

ตัวอย่างสมมติของชุดบิตที่ยาวขึ้น

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

หากคาบบิตในชุดฝึกเท่ากับ 2 ไมโครวินาที บิตแทรกสองตัวกินเวลาเพิ่ม 4 ไมโครวินาที เปรียบเทียบกับชุดสิบิตที่สลับศูนย์หนึ่งตลอดซึ่งไม่เกิดการครบห้าในส่วนที่แยกพิจารณา จะเห็นว่าจำนวนข้อมูลเท่ากันแต่เวลาต่างกันได้ ในเฟรมจริงต้องนำส่วนหัว CRC และประวัติบิตข้ามขอบเขตมารวมด้วย จึงห้ามใช้จำนวนบิตแทรกจาก payload อย่างเดียวเป็นคำตอบของเฟรมเต็ม

นำไปใช้ประเมินเวลาที่บัสถูกใช้งาน

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

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

1. 1
   ศูนย์ห้าตัวแรก

   เมื่อครบห้าศูนย์ แทรกหนึ่งตามกฎ

2. 2
   ศูนย์ห้าตัวถัดไป

   เกิดเงื่อนไขครบห้าอีกครั้ง จึงต้องมีหนึ่งแทรกอีกตัว

3. 3
   เพิ่มสองบิต

   ข้อมูลเดิมสิบบิตยังเท่าเดิม แต่ส่วนแทรกทำให้ใช้เวลาบนสายเพิ่ม

4. 4
   เพิ่ม 4 ไมโครวินาที

   สองบิตคูณคาบสมมติ 2 ไมโครวินาที ไม่ใช่การคำนวณความยาวเฟรมเต็ม

พิจารณาชุดบิตแยกที่ไม่มีประวัติก่อนหน้า และกฎยังใช้ต่อหลังชุดนี้

Stuff error ไม่ได้แปลว่าผู้ส่งเขียนข้อมูลผิดเสมอ

ผู้รับแจ้ง stuff error เมื่อสิ่งที่อ่านไม่สอดคล้องกับกฎในบริเวณที่ควรใช้กฎ แต่ต้นเหตุอาจเกิดจากระดับสัญญาณที่อ่านผิด จังหวะสุ่มอ่านไม่เหมาะ หรือการตีความรูปแบบเฟรมผิด ตัวอย่างเช่นเครื่องมือที่ตั้งอัตราบิตไม่ตรงอาจจัดขอบผิดตำแหน่งจนเห็นลำดับที่เป็นไปไม่ได้ การเปลี่ยน payload เพื่อหลีกเลี่ยงการแจ้งเตือนจึงไม่ใช่การแก้ต้นเหตุ และอาจเปลี่ยนความหมายข้อมูลแทน

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

ตรวจสอบผลด้วยข้อมูลดิบและข้อมูลที่ถอดแล้ว

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

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