בקצב שידור נמוך כגון 9600bps, אני לא חושב שיש צורך בבקרת זרימת חומרה CTS / RTS.אני מאמין שבשיעורי שידור גבוהים יותר יהיה צורך ב- CTS / RTS.מה קצב השידור הזה?האם עדיין ניתן להסתדר ללא CTS / RTS במהירות של 115.2 קילו-סיביות לשנייה?
בקצב שידור נמוך כגון 9600bps, אני לא חושב שיש צורך בבקרת זרימת חומרה CTS / RTS.אני מאמין שבשיעורי שידור גבוהים יותר יהיה צורך ב- CTS / RTS.מה קצב השידור הזה?האם עדיין ניתן להסתדר ללא CTS / RTS במהירות של 115.2 קילו-סיביות לשנייה?
לא קצב הנתונים הוא החשוב;אנו משתמשים ב- CTS / RTS (או XON / XOFF לבקרת זרימת תוכנה) כאשר קיימת אפשרות ל הצפת מקלט, אם כי יש להודות כי סבירות גבוהה יותר בשיעורי נתונים גבוהים יותר.
אםמקלט לא יכול לרוקן את המאגרים שלו מספיק מהר, ואז עליו לאמת את ה- CTS (בתגובה לכך, המשדר יטען RTS אם יש עוד נתונים להעביר).
שים לב שהמשדר עשוי לחוות a חציית חיץ ובמקרה זה היא אמורה לאמת את RTS (מכיוון שאין נתונים חוקיים למשלוח).
אז זה מסתכם במהירות שבה ניתן להזיז את המאגרים - סביר יותר להניחלהיות בעיה בשיעורי נתונים גבוהים יותר אך היא תלויה לחלוטין ביישום;אין מהירות אחת.
אתה זקוק לבקרת זרימה כלשהי (זה חומרה או XON / XOFF) כאשר אתה מעביר נתונים במהירות גדולה מכפי שאתה יכול לעבד אותם.זה פשוט כמו זה.
בקרת זרימה משמשת לקצה אחד כדי לומר לקצה השני "חכה רגע, אני עדיין חושב".בדרך כלל הוא קשור למאגר שהוא כמעט מלא (המכונה "סימן מים גבוהים").
בקרת זרימת חומרה מאפשרת לחלקי הציוד המתקשרים להסתנכרן זה עם זה.זה מאפשר לציוד המקבל לציין שהוא מוכן לקבל את הנתונים הנשלחים.אם נתונים נשלחים כאשר המקלט אינו 'מקשיב', הדבר יגרום לשגיאות נתונים.
קצב הנתונים בו מתרחש יהיה תלוי במספר דברים אחרים, כולל סוג המכשיר והתוכנה הנמצאים באתר.המכשיר.אם אתה מחבר שני מחשבים במחיר 115.2K, סביר להניח שהם יוכלו לפעול בסדר.אם מדובר בשני מיקרו-בקרים עם טעינת תוכנה אחרת, הם עשויים שלא.
אם תציין איזה סוג מכשירים שולחים ומקבלים, תקבל ייעוץ טוב יותר.
הצורך בבקרת זרימה בממשק סדרתי אסינכרוני תלוי לחלוטין בצרכי היישום. לפעמים קצב שידור איטי יותר יכול להוריד את קצב הנתונים האפקטיבי כדי להקל על הצורך בבקרת זרימה, אך זה שוב תלוי ביישום.
ישנן כמה טכניקות שיכולות לאפשר ליישום לתפקד בקצב שידור גבוה יותר ללא צורך להשתמש בלחיצת יד שליטת הזרימה. אחת מהן היא שימוש בטכניקת שליחה וקבלה של UART מונעת הפרעה ולתור את זרימת הנתונים בין קוד הראשי של היישום לשגרת ההפרעה דרך מאגרי FIFO מעגליים.
השימוש במאגרי FIFO צריך להיעשות על סמך אם מעבד היישומים יכול להתמודד עם הפרעות UART בקצב התווים (כלומר baud_rate / bits_per_transmission_unit). אם היא לא יכולה להתמודד עם קצב ההפרעה הזה בתוספת התקורה הקטנה שמטילה הטיפול במאגר FIFO, יהיה צורך להוריד את קצב השידור מספיק כדי לאפשר לקצב ההפרעה לתפקד.
לפעמים למעבד היישום שלך יהיה UART הכולל FIFO מובנה בחומרה. אם אלה משמשים בשילוב עם תכנית חוצץ FIFO עם טיפול בהפסקה, זה יכול להועיל לתכנון שגרת השירות להפסיק לרוקן FIFOs של חומרה או למלא FIFOs של חומרי שידור לחלוטין בזמן ההפסקה אל / מ תוכנה טיפלה במאגרי FIFO שבדרך כלל יהיו גדולים יותר. מוגדר ומקודד כהלכה זה יכול להוריד את קצב ההפרעה נטו שעליו צריך להתמודד מעבד יישומים בכל קצב שידור מסוים.
אני זוכר שפעם השתמשנו במסופי "מטומטמים" והיית מקליד Ctrl + S (XOFF) כדי להשהות את השידור כדי שנוכל לקרוא את המסך לפני שהנתונים גוללים ממנו.ואז נקליד Ctrl + Q (XON) כדי לחדש את הפלט.המסך עשוי להיות מושהה במשך 10 דקות.זה לא היה קשור לקצב השידור.
באופן דומה, מדפסת סדרתית שנותרה ללא נייר עשויה לאפשר בקרת זרימת חומרה כדי להשהות את הפלט בזמן שהנייר הוחלף.שוב זה לא יהיה קשור לקצב השידור.
האם בכל זאת אפשר להסתדר בלי CTS / RTS במהירות של 115.2 קילו-סיביות לשנייה?
אני נוהג לשלוח נתונים מאת ה- ATmega328P * למסך סדרתי ב 115200 baud.זה עובד בסדר.
* Arduino
האם אכפת לך שהנתונים שלך יישמטו בדלי הסיביות?אם כן, השתמש בבקרת זרימה.
האם יש לך זוגיות משנית / ECC / בקרת זרימה כמו שיש ל- TCP?אם כן, אז אתה מכוסה.עם זאת, באמצעות TCP / OSI כמודל, מספר שכבות מבצעות בקרת שגיאות ובקרתן על מנת להבטיח את מסירת הנתונים ולשמור על שגיאות כמה שפחות.נניח שאתה מפעיל TCP / IP, ללא בקרת זרימת חומרה במהירות 115.2 קילו-סיביות, הקצב האפקטיבי שלך עקב בעיות בזרימת החומרה יכול להיות נורא.
ישנם שיקולים רבים.
אין מספר קסם ל"מתי אני צריך בקרת זרימת חומרה", זו שאלה שיש לשאול ולענות עליהבהקשר של מערכת ספציפית.
האם בכל זאת אפשר להסתדר ללא CTS / RTS במהירות של 115.2 קילו-סיביות לשנייה?יציאות קונסולות כמעט בכל לוח לינוקס משובץ.
אם למכשיר היעד יש מאגר של 16 בתים אך לא ניתן להבטיח הפרעה מהירה, אז עדיף תמיד RTS / CTS וכולל גם ביט זוגי מוזר לאמינות.ללא כל הפרטים, קשה לדעת את סף הצפת חיץ היעד, ולכן הוא הופך לניסוי וטעייה.