เวลาต่อโมดูลเข้าบอร์ดผ่าน UART อาการแรกที่เจอได้คือเปิดดูแล้วมีตัวอักษรแปลกๆ หรือข้อมูลดูถูกบ้างผิดบ้าง เราอาจเริ่มจากเปลี่ยน baud rate เพราะเป็นค่าที่เห็นชัดใน serial monitor แต่ถ้าเปลี่ยนแล้วยังไม่จบ ก็ต้องแยกต่อว่าเสียตั้งแต่ระดับสัญญาณหรือเพียงกำลังอ่านข้อมูลด้วยความหมายผิดแบบ
UART รับส่งข้อมูลเป็นลำดับบิตตาม framing ที่ตกลงกัน ส่วนสิ่งที่ byte เหล่านั้นหมายถึงเป็นอีกชั้นหนึ่ง โมดูลบางตัวส่งข้อความ บางตัวส่งข้อมูล binary และบางตัวต้องรับคำขอก่อนจึงตอบ การมีสายเชื่อมถึงกันจึงยังไม่ยืนยันว่าควรเห็นข้อความอ่านรู้เรื่องทันที
วิธีตรวจที่ช่วยได้คือเริ่มจากเส้นทางไฟฟ้าและ framing แล้วค่อยไปที่ byte กับข้อความของแอปครับ จะได้ไม่ปรับ parser เพื่อชดเชยข้อมูลที่รับผิดตั้งแต่ต้น หรือไปแก้สายทั้งที่ข้อมูลจริงเป็น binary อยู่แล้ว
UART ในไมโครคอนโทรลเลอร์ทำหน้าที่จัดจังหวะกับกรอบข้อมูล แต่การเชื่อมกับ RS-232 หรือ RS-485 ยังต้องมีวงจรรับส่งสัญญาณที่เหมาะกับรูปแบบนั้น การเห็นชื่อ serial เหมือนกันไม่ได้หมายความว่าขาทางไฟฟ้าต่อถึงกันตรงๆ ได้
ก่อนต่อจึงต้องอ่านระดับ logic และหน้าที่ขาของบอร์ดกับโมดูลจริง รวมถึง adapter ที่ใช้ ไม่เดาจากชื่อ TX/RX บนหัวต่อเพียงอย่างเดียว และต้องแยก USB connector ออกจากสัญญาณ UART ที่อยู่หลังวงจรแปลงด้วย
สำหรับการต่อ logic-level UART ให้ตรวจทิศผู้ส่งกับผู้รับและ reference ที่วงจรกำหนด ส่วนระบบที่มี isolation หรือ transceiver ก็ต้องดูเส้นทางของวงจรนั้นเพิ่ม ภาพแนวคิดในบทนี้จึงไม่ใช่ผังลงสายหรือการรับรองระดับแรงดันของอุปกรณ์ที่ยังไม่รู้รุ่น
หากมีปัญหาทางสัญญาณ เช่น reference ไม่ถูกหรือขอบสัญญาณเสีย การปรับ baud อาจทำให้อาการเปลี่ยนแต่ยังไม่อธิบายสาเหตุ ควรตรวจด้วยเครื่องมือที่เหมาะสมเมื่อมีหลักฐานชี้ ไม่สรุปว่าสายใช้ได้สมบูรณ์เพียงเพราะเคยรับ byte ถูกหนึ่งครั้ง
ผู้ส่งกับผู้รับต้องตกลงทั้ง baud rate, จำนวน data bits, parity และ stop bits ตามที่อุปกรณ์กำหนด การตั้ง baud ตรงแต่รูปแบบส่วนอื่นไม่ตรงยังทำให้รับผิดหรือเกิด framing error ได้ จึงควรเก็บเป็นชุด configuration เดียวกันเวลาเทียบผล
ใน ESP-IDF สามารถตั้งค่าพารามิเตอร์ UART กับขาที่ใช้ผ่าน driver ตามรุ่น SDK ได้ แต่ขาที่เลือกยังต้องอยู่ภายใต้ข้อจำกัดของบอร์ด ไม่เห็นว่าเลือกผ่านซอฟต์แวร์ได้แล้วถือว่าทุก GPIO เหมาะกับงานทุกแบบ
Flow control ก็ต้องดูว่าทั้งสองฝั่งใช้อย่างไร หากเปิดเงื่อนไขรอสัญญาณที่อีกฝั่งไม่ได้ต่อหรือไม่ได้ส่ง ข้อมูลอาจไม่ออกตามที่คาด ส่วนการปิดทุกอย่างโดยไม่อ่านคู่มืออาจทำให้รับไม่ทันในงานที่มีข้อมูลต่อเนื่องได้
ถ้าอุปกรณ์เปลี่ยนความเร็วหรือมีข้อความช่วงบูตต่างจากช่วงทำงาน ต้องแยกช่วงเวลาที่กำลังอ่านด้วย ไม่เอาข้อความช่วงหนึ่งมาตัดสิน configuration ของอีกช่วงโดยไม่ดูพฤติกรรมตามเอกสารและ firmware ของอุปกรณ์
หลัง framing ผ่าน ควรดูข้อมูลดิบตามขอบเขตที่เหมาะสม เช่น แสดงเป็น hexadecimal ในชุดทดสอบ เพื่อแยกว่ากำลังรับ byte ใดจริง ถ้าโมดูลส่ง packet binary การนำทุก byte ไป decode เป็นข้อความก็มีโอกาสเห็นสัญลักษณ์ที่อ่านไม่ออกตามปกติของข้อมูลนั้น
แม้เป็นข้อความ ยังมี encoding กับตัวจบบรรทัดที่ต้องตกลง เช่น การใช้ newline หรือตัวควบคุมอื่น ผู้ส่งอาจรอคำสั่งที่ลงท้ายครบก่อนตอบ การเห็นข้อความพิมพ์ใน terminal จึงไม่ได้ยืนยันว่า byte ที่ส่งออกตรงกับ protocol แล้ว
อีกจุดคือการอ่านจาก UART driver คืนข้อมูลเป็นช่วงที่มีอยู่ใน buffer ไม่ได้กำหนดว่าหนึ่งครั้งอ่านจะตรงกับหนึ่งข้อความของแอปเสมอไป ข้อความหนึ่งอาจมาไม่ครบในครั้งเดียว หรือหลายข้อความอาจมารวมกันในการอ่านครั้งเดียวได้
Parser จึงต้องรักษาข้อมูลที่ยังไม่ครบและรู้ขอบเขต packet จากกติกาของแอป เช่น ตัวจบ ความยาว หรือส่วนตรวจที่ protocol กำหนด ไม่ตัดสินว่าการอ่านหนึ่งครั้งได้ข้อมูลเท่าไรก็คือข้อความครบหนึ่งชุดตามนั้น
หาก task ที่อ่านไปทำงานอื่นนาน ข้อมูลอาจสะสมจน buffer ไม่พอตามความถี่ที่ปลายทางส่งมา ควรดูเหตุการณ์และสถานะจาก driver ที่เกี่ยวข้องกับ overflow หรือ error แล้วแยกจากปัญหาที่ผู้ส่งส่งผิดรูปแบบ
การเพิ่ม buffer ช่วยรับข้อมูลได้มากขึ้นในบางเงื่อนไข แต่ยังต้องดูว่าอัตรารับกับอัตราประมวลผลสมดุลกันหรือไม่ หากโปรแกรมตามไม่ทันต่อเนื่อง การเพิ่มขนาดอย่างเดียวก็เพียงยืดเวลาก่อนเต็ม ไม่ได้แก้คอขวดของการประมวลผล
ควรกำหนดขนาดข้อความสูงสุด ระยะรอข้อมูลส่วนที่เหลือ และทางกู้ parser เมื่อ packet ผิดรูปแบบ เพื่อไม่ให้ข้อมูลที่ขาดไปหนึ่งส่วนทำให้ทุกข้อความหลังจากนั้นถูกเลื่อนตำแหน่งตามไปเรื่อยๆ
ถ้ามีทั้ง log debug กับข้อมูล protocol ใช้ UART เดียวกัน ต้องมีข้อตกลงชัด ไม่ปล่อยข้อความ log เข้าไปกลาง packet แล้วให้ผู้รับเดาเอง การแยกช่องทางสำหรับวินิจฉัยเมื่อทำได้ช่วยรักษาข้อมูลจริงให้ตรงตามที่ protocol กำหนด
เริ่มจากคู่มืออุปกรณ์และ configuration ที่แน่นอน แล้วเลือกข้อมูลทดสอบที่รู้ว่าควรเป็น byte อะไร ตรวจทั้งการส่งครั้งเดียว ข้อความที่ถูกแบ่งมาเป็นหลายส่วน และหลายข้อความติดกัน โดยใช้วงจรทดสอบที่ระดับสัญญาณเข้ากันได้จริง
ถ้ามีเครื่องมือจับสัญญาณ ให้ใช้ตรวจ timing กับ framing ตามขอบเขตที่เครื่องมือรองรับ และไม่เอารูป waveform ที่วาดเองไปแทนผลวัด ในกรณีแอปกำหนด checksum หรือ CRC ก็ควรตรวจตามนั้น แต่ไม่ถือว่าการตรวจความผิดพลาดระดับนี้ยืนยันสิทธิ์หรือที่มาของผู้ส่งทั้งหมด
บันทึกรุ่นโมดูล ชุด framing รูปแบบ packet และ error ที่พบพร้อมเวลา จะช่วยให้กลับมาตรวจซ้ำได้ และรู้ว่าการเปลี่ยนครั้งใดแก้อะไรจริง โดยไม่ต้องหมุน baud ไปทีละค่าโดยไม่มีข้อกำหนดให้เทียบ
UART ที่อ่านไม่รู้เรื่องต้องแยกระดับสัญญาณ framing และความหมายของ byte stream ออกจากกัน เมื่อใช้ข้อตกลงจากอุปกรณ์จริงกับ parser ที่รับมือข้อมูลมาไม่ครบหรือมารวมกันได้ เราจะตามอาการได้ตรงชั้น และไม่ใช้ baud rate เพียงค่าเดียวอธิบายปัญหาตลอดเส้นทาง