เมื่ออ่านคุณสมบัติของ ESP32 แล้วพบ TWAI เราอาจนึกถึงการนำไปคุยบน CAN bus ซึ่งเป็นทางสื่อสารที่ใช้กันในงานหลายแบบ แต่ระหว่างความสามารถในชิปกับสาย bus จริงยังมีส่วนประกอบและข้อตกลงอีกชั้นที่ต้องจัดให้ครบ
Controller ทำหน้าที่จัด frame กับกลไกของ protocol ส่วน transceiver เชื่อมสัญญาณระหว่างขา logic กับทางไฟฟ้าของ bus การมี controller จึงยังไม่ได้แปลว่านำขา TX/RX ในชิปไปต่อสาย CAN โดยตรงได้
แอดอยากแยกสามส่วนนี้ให้เห็นก่อนครับ ทั้ง controller, physical bus และข้อมูลที่แอปตกลงใช้ร่วมกัน จะได้เลือกตรวจตามส่วนที่รับผิดชอบจริง และไม่เอาการส่ง frame ผ่านมาแทนการยืนยันว่างานปลายทางทำสำเร็จแล้ว
บทนี้อิง ESP32 ตามเอกสาร ESP-IDF 5.4 ซึ่งระบุการรองรับ Classical frame ของ ISO 11898-1 ทั้ง standard กับ extended ID และต้องใช้ transceiver ภายนอก โดย controller ที่กล่าวถึงไม่ได้รองรับ CAN FD frame
ชื่อ ESP32 เป็นกลุ่มผลิตภัณฑ์ที่มีหลายรุ่น ความสามารถของ controller กับ driver จึงต้องตรวจตามชิปจริง ไม่ยกข้อมูลของ ESP32 รุ่นที่อ้างในบทนี้ไปยืนยันว่ารุ่นย่อยทุกตัวเหมือนกัน หรือเห็นบอร์ดมีหัวต่อแล้วเดาว่ารวม transceiver มาแล้วเสมอ
หากระบบปลายทางใช้ CAN FD ต้องตรวจความเข้ากันได้ตั้งแต่ความสามารถของ controller และ bus ไม่คิดว่าตั้ง bit rate ให้เท่ากันก็จะอ่าน format ที่ไม่รองรับได้ การแยกชนิด frame เป็นส่วนของการเลือกฮาร์ดแวร์และไลบรารีก่อนเริ่มต่อ
ส่วนตัวอย่างโค้ดที่เปิดใช้ driver ได้ยังบอกเพียงส่วนซอฟต์แวร์ หากยังไม่ทราบ transceiver กับรูปแบบการต่อภายนอก ก็ยังไม่ถือว่าระบบทางไฟฟ้าครบตามที่ bus ต้องใช้
Transceiver ต้องเหมาะกับระดับ logic ของ controller และเงื่อนไขฝั่ง bus รวมถึงโหมดควบคุมที่วงจรนำออกมาให้ใช้ เช่น enable หรือ standby ตามรุ่น หากเลือกการตั้งผิด ส่วนซอฟต์แวร์อาจส่งคำขอได้แต่ไม่มีสัญญาณออกไปตามที่คาด
ด้าน bus ต้องดู topology, termination, สาย และ reference หรือ isolation ตามระบบจริงด้วย ไม่เพิ่ม termination ทุก node หรือเลือกจากภาพโมดูลตัวอย่างโดยไม่ดูว่าส่วนใดติดมาแล้วและควรอยู่ที่ใดในเส้นทาง
ภาพประกอบในบทนี้แสดงบทบาท TX/RX ฝั่ง logic กับสาย bus เท่านั้น ไม่ใช่ pinout หรือวงจรที่รับรองสำหรับโมดูลใด ก่อนลงสายต้องตรวจเอกสารของบอร์ดกับ transceiver ที่ใช้อยู่ และเริ่มใน bus ทดสอบที่แยกจากอุปกรณ์ใช้งานจริง
เมื่อมีอาการ error ต่อเนื่อง ควรตรวจไฟเลี้ยง โหมด transceiver และเงื่อนไขสัญญาณร่วมกับสถานะของ controller ไม่พยายามแก้โดยส่ง frame ซ้ำถี่ขึ้น เพราะการส่งไม่สำเร็จอาจมีเหตุที่การเพิ่ม traffic ไม่ได้แก้
Node บน bus ต้องมีการตั้ง timing ที่เข้ากันตาม protocol และลักษณะระบบ การตั้ง bit rate ตรงเป็นส่วนหนึ่ง แต่ข้อมูล frame ยังมีรายละเอียดที่แอปต้องตกลง เช่น ใช้ standard หรือ extended ID และ ID ใดแทนข้อความประเภทไหน
ID ใน CAN มีบทบาทกับการระบุและ arbitration ตาม frame ไม่ควรถูกมองเป็น IP address ที่แปลว่าปลายทางหนึ่งเครื่องเสมอไป การออกแบบแอปอาจใช้ ID ตามชนิดข้อมูลหรือรูปแบบอื่น จึงต้องอ่านข้อตกลงของเครือข่ายนั้นจริง
Payload ที่รับได้อาจต้องแปลงด้วยหน่วย scale, signedness และการเรียง byte ที่ระบบกำหนดไว้ การจับ frame ได้พร้อม ID ที่ดูคุ้นจึงยังไม่ได้บอกว่าข้อมูลข้างในแปลงถูก โดยเฉพาะเมื่อไม่มีเอกสารหรือข้อมูลอ้างอิงของผู้ผลิตให้ตรวจ
หากเป็น bus ที่ออกแบบเอง ควรเก็บสัญญาของข้อความเป็นเอกสารร่วมกับ firmware ทั้ง ID ความยาว หน่วย รุ่นของ payload และพฤติกรรมเมื่อไม่รู้จักข้อมูล เพื่อไม่ให้ firmware คนละรุ่นอ่าน byte ชุดเดียวกันด้วยความหมายต่างกัน
การใส่งานเข้าคิวส่งของ driver เป็นอีกเหตุการณ์หนึ่งจากการส่ง frame บน bus สำเร็จ ต้องอ่านความหมายของ API กับ alert ที่ใช้ ไม่รายงานกับแอปว่างานปลายทางเสร็จตั้งแต่คิวรับข้อมูลไปแล้ว
แม้มีผลยืนยันระดับ protocol ก็ยังไม่ได้หมายความว่าแอปปลายทางนำข้อมูลไปใช้หรือเปลี่ยนสถานะอุปกรณ์ตามคำสั่งเสร็จ หากต้องการความแน่นอนระดับนั้น ต้องออกแบบข้อความตอบรับหรือสถานะรายงานกลับตามงาน
ตัวอย่างสมมติอาจมีรหัสคำสั่งกับลำดับของการดำเนินการ แล้วปลายทางรายงานว่าได้รับ กำลังทำ หรือเสร็จพร้อมผลที่ตรวจได้ โดยต้องวางพฤติกรรมเมื่อได้รับคำสั่งเดิมซ้ำด้วย ไม่ให้การ retry ระดับแอปสร้างผลซ้ำที่ไม่ตั้งใจ
การตรวจ error ของ driver จึงควรผูกกับสถานะงานของแอป แต่ไม่รวมกันจนแยกไม่ออก วงจร bus ที่กลับมาส่งได้ไม่ได้ยืนยันว่าคำสั่งก่อนหน้าที่ผลคลุมเครือควรถูกสั่งใหม่ทันทีทุกแบบ
หากแอปอ่านข้อมูลไม่ทัน คิวรับอาจเต็มและมีข้อความตกตามขอบเขตที่ตั้งไว้ จึงควรดู alert หรือสถานะที่เกี่ยวข้องพร้อมการใช้งาน task ไม่เพิ่มขนาดคิวโดยไม่ตรวจอัตรารับกับเวลาประมวลผล
Controller มีสถานะเกี่ยวกับข้อผิดพลาดและการกู้คืนตาม protocol ซึ่งต้องจัดการตาม driver รุ่นที่ใช้ หากเข้าสู่สถานะที่หยุดการสื่อสาร ต้องมีขั้นตามเงื่อนไขกู้คืนกับการจัดการงานค้าง ไม่วนเปิด driver ใหม่โดยไม่บันทึกเหตุให้ตรวจ
ในการทดลอง ใช้ node กับข้อมูลที่รู้ข้อตกลงใน bus แยก ตรวจทั้งส่ง รับ ไม่พบ node ตอบรับ และการขาดการเชื่อมต่อในขอบเขตที่ควบคุมได้ หากใช้โหมดทดสอบที่ไม่ต้องการการตอบรับหรือวนรับตัวเอง ต้องระบุด้วยว่าผลนั้นยังไม่ยืนยัน bus หลาย node แบบปกติ
เก็บรุ่นชิป transceiver, timing, frame format และผล alert ที่เกี่ยวข้องไว้กับผลตรวจ ส่วนตัวเลขอัตราส่ง ระยะสาย หรือความเสถียรต้องมาจากการวัดจริงของชุดนั้น ไม่สรุปจากการที่ตัวอย่างใน SDK ทำงานได้
การใช้ TWAI ต้องมีทั้ง controller ที่รองรับ frame, transceiver กับ bus ที่จัดถูก และข้อตกลงข้อความของแอป เมื่อแยกสถานะคิว การส่ง frame และผลของงานปลายทางออกจากกัน เราจะรู้ว่าหลักฐานแต่ละชั้นยืนยันอะไรได้ แล้วพัฒนาเส้นทางสื่อสารต่อได้โดยไม่ฝากทุกความหมายไว้กับคำว่าส่งสำเร็จเพียงคำเดียว