ความถี่ UART มีความสำคัญแค่ไหน?


17

ฉันกำลังจะใช้คริสตัลขนาด 8 MHz เพื่อใช้งานไมโครคอนโทรลเลอร์ของฉันที่ 16 MIPS (คำแนะนำ PLL 4x, 2 รอบ) อย่างไรก็ตาม 8 MHz ไม่ได้แบ่งเป็นความถี่ UART AFAIK ใด ๆ ... ความถี่ที่สำคัญเหล่านี้เป็นอย่างไร ฉันวางแผนที่จะใช้ 115,200 บอด

UART สามารถวิ่งได้ภายใน± 1% หรือไม่? หากวิธีนี้ใช้ไม่ได้ฉันควรใช้ความถี่ใด (ฉันต้องการได้มากถึง 16 MIPS ให้มากที่สุดเพื่อความเร็วในการประมวลผลสูงสุด) หากเป็นเรื่องสำคัญฉันกำลังใช้ PIC24FJ64GA004

คำตอบ:


13

หากคุณอยู่ในระยะ 1% คุณควรจะยอมรับ

สมมติว่า UART ของคุณใช้นาฬิกาสุ่มตัวอย่างขนาด 16x ตัวอย่างเช่นคุณสามารถตั้งค่าเป็น 1,843,200 Hz เป็น 16x สำหรับ oversample 115,200 bps (การสุ่มตัวอย่างแบบนี้ค่อนข้างธรรมดา) สิ่งนี้ทำให้ UART นับ 8 โอเวอร์คล็อกจากขอบตกของบิตเริ่มต้นดังนั้นมันสามารถค้นหาตำแหน่งกึ่งกลางของเซลล์บิตภายใน +/- หนึ่งรอบเวลาของโอเวอร์โอเวอร์หลังจาก ซึ่งจะนับปิด 16 ช่วงเวลาของการทำงานล่วงเวลาเพื่อกำหนดเวลาที่จะสุ่มตัวอย่างข้อมูล

หากคุณคิดว่ามันสามารถกดที่กึ่งกลางของบิตเริ่มต้นจากนั้นเพื่อเก็บตัวอย่างข้อมูลอนุกรมในเซลล์บิตที่ถูกต้องใน 8 บิตบิตความถี่นาฬิกาจะต้องอยู่ระหว่าง (8-0.5) / 8 และ (8 + 0.5 ) / 8 หรือ +/- 6.25% ของอัตราบิตที่ต้องการ การโอเวอร์คล็อกที่สูงขึ้นเข้าใกล้กับสภาพที่เหมาะสมที่สุดของการกดปุ่มตรงกลางของบิตเริ่มต้น แต่ปกติแล้ว 8x หรือ 16x นั้นใกล้พอที่คุณสามารถสันนิษฐานได้ว่า 5% ไม่ตรงกัน

อย่างไรก็ตามคุณไม่สามารถวางใจได้ว่าอีกด้านหนึ่งจะมีความถี่สมบูรณ์แบบ หากคุณเชื่อมต่ออุปกรณ์ที่รวดเร็ว 4% กับอุปกรณ์ที่ช้า 4% คุณจะมีปัญหา ฉันพบกรณีอย่างน้อยหนึ่งกรณีที่พีซีทำงานช้าและอุปกรณ์เร็วเล็กน้อยและทั้งสองสามารถสื่อสารกันได้เล็กน้อยแม้ว่าอุปกรณ์เดียวกันนั้นใช้ได้กับพีซีเครื่องอื่นและพีซีก็ใช้ได้ดี อุปกรณ์ (กำหนดขอบเขตเหล่านี้ประมาณ 112kbps และ 119kbps) ด้วยเหตุนี้จึงเป็นเรื่องดีที่จะพยายามใช้ความถี่เล็กน้อยให้ใกล้เคียงที่สุด ฉันไม่เคยเห็นอะไรเลยภายใน 2% ของผู้มีปัญหา

สิ่งที่ต้องทำตามปกติคือใช้อัตรานาฬิกาหลักที่ให้อัตราการสุ่มตัวอย่างเกินจำนวน UART จำนวนเต็มคูณกับอัตรา baud ตัวอย่างเช่นหากคุณต้องการให้ CPU ทำงานที่ประมาณ 8MHz คุณอาจใช้ออสซิลเลเตอร์ 7.3728MHz ซึ่งสามารถหารด้วย 4 เพื่อรับ 1.8432MHz ซึ่งเกิดขึ้นเป็น 16 คูณ 115200


8 MHz สามารถหารด้วย 69 เพื่อรับ 115,942 ซึ่งภายใน± 1% ฉันสงสัยว่า PIC รองรับการแบ่งประเภทนี้สำหรับเครื่องกำเนิดอัตราการส่งข้อมูลหรือไม่ ฉันหวังเช่นนั้น แต่ฉันไม่คิดว่ามันจะ
— โทมัสโอ

PIC มีเครื่องมือสร้างอัตราการรับส่งข้อมูล มันจะทำงานได้ดี แต่สำหรับ baud ที่ต่ำกว่าเช่น 9600 มันจะไม่ทำงานสำหรับ baud ที่สูงเช่น 115,200 มันไม่แน่ชัด
— โทมัสโอ

คุณคิดว่าฉันสามารถใช้คริสตัล 7.3728 MHz ได้หรือไม่? (ฉันจะไม่ใช้ออสซิลเลเตอร์ 7.37 MHz ภายในเพราะฉันต้องการความแม่นยำ) อนุญาตให้ฉันหาร 64 ด้วยความถี่ UART ที่ 115,200 มันเร็วที่สุดที่ฉันสามารถไปได้ด้วยความอดทนสูง
— โทมัสโอ

1
ถ้า UART ของคุณรองรับจะดีกว่าให้โอเวอร์คล็อก (เช่น 16x) เพื่อให้สามารถโอเวอร์บิตบิตเริ่มต้นและค้นหาศูนย์กลางของเซลล์บิตได้ แต่การได้ 16x สำหรับ 115K เป็น 1% อาจเป็นเรื่องที่ท้าทายเว้นแต่ คุณใช้คริสตัล baud-multiple
— JustJeff

4

ไม่จำเป็นต้องระบุ 1% @JustJeff UART ส่วนใหญ่อนุญาตให้มีข้อผิดพลาดครึ่งบิตในบิตสุดท้าย เวลาส่วนใหญ่ของเฟรมประกอบด้วยบิตเริ่มต้น 1 บิต 8 ดาต้าบิตและบิตหยุด 1 ครั้งรวมเป็น 10 บิต ครึ่งหนึ่งของบิต 10 บิตคือ 5% (JustJeff ของ 6.25% ไม่ได้ใช้การเริ่มต้นและหยุดบิตในบัญชี)


1
อย่าพูดผิดฉัน อีกครั้ง "1%" คำสั่งของฉันคือว่ามันอาจเป็นเรื่องยากที่จะบรรลุ "6.25%" สมมติว่าคุณเกิดจุดศูนย์กลางของบิตเริ่มต้นและเป็นความแตกต่างสูงสุดที่อนุญาตในอัตรานาฬิกาตัวรับและตัวส่งสัญญาณภายใต้เงื่อนไขดังกล่าว
— JustJeff

1

JustJeff ลืมเกี่ยวกับบิตเริ่มต้น แต่ Stevenh เพิ่มบิตหยุด สมมติว่าโพรโทคอลทั่วไปของบิตข้อมูล 8 บิตเริ่มต้น 1 บิตและไม่มีแพริตีบิต (จำนวนบิตหยุดไม่สำคัญ) มี 8 1/2 บิตครั้งจากขอบนำของบิตเริ่มต้นจนถึงศูนย์กลางของ บิตสุดท้าย โดยทั่วไปคุณต้องการให้ผู้รับตัวอย่างบิตสุดท้ายนี้ภายในเวลา 1/4 บิต โปรดทราบว่า 1/2 บิตเป็นเกณฑ์ที่รับประกันว่าจะล้มเหลว ทุกสิ่งที่อยู่ใกล้ ๆ นั้นไม่น่าจะเกิดขึ้นได้เพราะมักมีเสียงรบกวนทางไฟฟ้าและกระวนกระวายใจอยู่เสมอ

1/4 หารด้วย 8 1/2 = 2.94%

ดังที่ JustJeff กล่าวถึงการใช้งาน UART ส่วนใหญ่จะสุ่มตัวอย่างข้อมูลขาเข้าด้วยนาฬิกาแบบอะซิงโครนัส 16 เท่า นั่นเพิ่มความไม่แน่นอนอีกครั้ง 1/16 บิตเนื่องจากเป็นข้อผิดพลาดที่สามารถนำขอบของบิตเริ่มต้น การหมดเวลาบิต 1/16 จาก 8 1/2 บิตเป็นอีก 0.74% ที่มาจากงบประมาณข้อผิดพลาดที่คำนวณไว้ก่อนหน้านี้ คุณจบลงด้วยการอนุญาตให้นาฬิกาไม่ตรงกัน 2.2% เพื่อให้ผู้รับตัวอย่างบิตสุดท้ายภายใน 1/4 บิตเวลาของศูนย์

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


ฉันไม่เห็นด้วยที่บิตหยุดไม่สำคัญ ในการสื่อสารคำถามนี้ล้มเหลวเนื่องจากบิตหยุดถูกตั้งค่าอย่างไม่ถูกต้องเป็นระดับต่ำ
— stevenvh

บิตหยุดจะต้องอยู่ที่นั่นเพื่อให้การสื่อสารโดยรวมทำงานได้ แต่ไม่ได้เข้าสู่การคำนวณงบประมาณข้อผิดพลาดสำหรับ UART ส่วนใหญ่ UART จะต้องใช้เวลาขั้นต่ำหลังจากบิตข้อมูลสุดท้ายก่อนที่จะนำหน้าขอบบิตถัดไปของบิตเริ่มต้นถัดไป นั่นคือสิ่งที่เวลาหยุดบิตสำหรับ เมื่อไม่พบเวลานี้คุณจะได้รับ "ข้อผิดพลาดในการกำหนดกรอบภาพ" บางทีตัวอย่างนั้นเป็นบิตข้อมูล แต่ฉันรู้กรณีที่มันถูกจัดการแตกต่างกัน โทรศัพท์เก่าต้องใช้ 2 สต็อปบิตเพื่อให้กลไกกลไกมีความพร้อมที่จะคว้าตัวละครตัวต่อไป
— Olin Lathrop

ฉันพูดถึงการเริ่มต้นสามครั้งใช่มั้ย
— JustJeff

@OlinLathrop: ต้องใช้บิตหยุดเพื่อให้แน่ใจว่าเมื่อส่งไบต์ซึ่ง MSB เป็นศูนย์จะมี เป็นขอบลดลงสำหรับบิตเริ่มต้นถัดไป อุปกรณ์ต่าง ๆ จะทำงานแตกต่างกันในกรณีที่สายข้อมูลมีระดับต่ำก่อนที่มันควรจะเป็น แต่ถ้าไม่มีการหยุดบิตลำดับการส่งของศูนย์ไบต์จะไม่มีข้อมูลเวลาที่มีประโยชน์ ข้อกำหนดดังกล่าวสามารถพบได้ด้วยวิธีการอื่นโดยมีค่าใช้จ่ายคงที่ในกรอบน้อยกว่า 25% แต่ฉันไม่ทราบว่ามีใครทำเช่นนั้น
— supercat

1

ประเด็นหนึ่งที่ยังไม่ได้กล่าวถึงคืออุปกรณ์บางอย่างคาดว่าจะส่งข้อมูลเป็นไบต์สำหรับข้อมูลทุกไบต์ที่ได้รับ หากอุปกรณ์ดังกล่าวได้รับการป้อนข้อมูลอย่างต่อเนื่องอัตราการรับส่งข้อมูลจะช้ากว่าอุปกรณ์ส่งสัญญาณถึง 0.1% และไม่มีความสะดวกในการส่งบิตหยุดที่หดเล็กน้อย ไบต์ที่มาหากอุปกรณ์ถูก จำกัด ไว้ที่ 16 ไบต์ของการบัฟเฟอร์มันจะวางข้อมูลเป็นไบต์หลังจากผ่านไปประมาณ 16,000 และจะลดลงประมาณหนึ่งไบต์ต่อพันหลังจากนั้น มันคุ้มค่าที่จะทราบว่าโมเด็มที่เรียกว่า "1200 baud" ใช้งานได้จริงในอัตราที่สูงกว่า 1200 บิต / วินาทีเล็กน้อย (ฉันคิดว่ามันประมาณ 1202) ด้วยเหตุผลนี้อย่างแม่นยำ (ดังนั้นแม้ว่าเครื่องส่งสัญญาณจะเร็วกว่า 0.15% ก็ตาม จะเป็น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.