У багатьох зразках коду в Інтернеті люди додають рядок Serial.begin(9600)у блок настройки.

Коли я переглядаю, що Serial.begin()є в офіційній документації, вона говорить, що вона контролює передачу даних за біт в секунду.

Очевидним є питання, чому б не використати 28800, найвищу швидкість передачі? Чому люди поселяються на 9600? Яке тут обмеження?

Чому люди осідають?

Люди осідають, бо це більш ніж досить швидко. Найбільш поширене використання - це просто надрукувати деякі матеріали на терміналі для налагодження. 9600 бод - 960 символів в секунду, або 12 х 80 символьних ліній в секунду. З якою швидкістю ви можете читати? :)

Якщо ваша програма використовує послідовний порт для масової передачі даних, ви вирішите не влаштовувати рішення.

Що таке обмеження ...

Ліміти на серійні високі. Безпосередньо ви можете використовувати 115200 бодів у своїх програмах, і це просто спрацює. Термінал Arduino дозволить отримати максимум 115200, але інші програми, такі як RealTerm, дозволять вам бігти вище.

Серійне обладнання буде працювати на 1 М бод. Якщо ви прочитаєте навколо, ви побачите, що люди використовували до 1 М, безпосередньо керуючи UART. Ви можете скористатися високою швидкістю передачі даних у таких випадках, як передача через мікросхему Bluetooth. Якщо ви використовуєте апаратний послідовний інтерфейс для обміну з мікросхеми на мікросхему лише на невеликій відстані, то 1 М бод є цілком здійсненним. Подумайте про всі пристрої SPI та I2C, які працюють нормально на тактовій частоті 1 МГц.

На більших відстанях у вас виникнуть проблеми зі шумом при використанні сигналів логічного рівня (від 0 до 5 В). Щоб використовувати великі відстані, ви б додали приймач для забезпечення надійної сигналізації, зазвичай RS-232 і рідше RS-485. За допомогою RS-232 ви можете запускати мега-біт на відстані 10 футів.

Реальна межа буде тактовою частотою мікропроцесора. За допомогою апаратного UART процесор повинен завантажувати один байт до UART кожні 10 біт (для N81). Отже, коли ви досягнете 1 М бод, процесором 16 МГц буде складним завданням зберегти UART, що постачається даними. Новий байт буде надсилатися кожні 160 тактових годин, що дуже мало рядків коду. Якщо короткий обсяг даних, ви можете досягти такої швидкості. Повідомлення полягає в тому, що процесор втратить швидкість до того, як UART стане межею.

Зауважте, це все стосується HardwareSerial , серійне програмне забезпечення дуже відрізняється.

На додаток до всіх цікавих відповідей, варто згадати, що встановлення послідовної швидкості на XXX біт / с не означає, що на комп'ютері встановлено XXX біт / с.

Годинники - навіть на основі кварцу - недосконалі і піддаються дрейфу. Крім того, оскільки послідовний тактовий сигнал зазвичай генерується за допомогою попереднього дільника потужності двох лічильників та (цілого) лічильника, все значення не може бути точно отримано з урахуванням базової тактової частоти. За допомогою бітів запуску / зупинки асинхронний послідовний зв'язок може бути толерантним до деякого переміщення годин. Але це має межі.

Наприклад, якщо ваш ATmega328PA працює на частоті 1 МГц, ви можете досягти 9600b / s при 0,2% помилки. Але при 14400b / s похибка становить -3,5% (фактично спілкується зі швидкістю 13900b / s). А при 28800b / s похибка становить + 8,5% (фактично спілкується зі швидкістю 31200b / s). Усі ці цифри представлені з листа даних ATmega48PA-88PA-168PA-328PA, p200 .

Це не проблема, коли два однакових пристрою спілкуються разом (адже насправді вони спілкуються з однаковою швидкістю). Це може бути проблемою під час спілкування між різними пристроями.

Збільшення базової частоти не потребує значного підвищення точності. Наприклад, запуск того ж ATmega328PA, як описано вище, на 2 МГц, насправді не дає кращих результатів, оскільки це, в основному, пов'язано з помилками округлення. Але працює на 1.8432 МГц, дають дуже точні біт / с від 2400b / s до 57,6kHz.

Я думаю, що це традиція використовувати швидкість передачі, яка не є найповільнішою (300), але і не такою, яка може врешті-решт спричинити проблеми в деяких налаштуваннях (28800 або навіть 115200). Послідовний порт ПК (найчастіше це USB-адаптер FTDI232) може справлятися з більш високими тарифами, але обладнання для вашої роботи може зробити це не так. Таким чином, 9600 bps зарекомендував себе як якусь стандартну швидкість передачі для прикладів коду.

Повернувшись до смуг часу, "золотий стандарт" для віддалених клавіатур (за допомогою телефонного модему та телевізорів, якщо ви пам’ятаєте ці) становив 9600 бод, спочатку досягнувши лише за допомогою спеціальної телефонної лінії. Час рухається, повільно; технологія просувається швидко; і пам'ять рухається навіть повільніше, ніж час (здається). Ми можемо регулярно спілкуватися, принаймні на кілька метрів, на пару порядків швидше, ніж 9600 бод. Те, що колись вважалося золотим стандартом, вже не золото, але все ще вважалося еталоном.

tl; dr: Це історія, а не технологія.

Я думаю, що головна причина, по якій люди використовують 9600 більшу частину часу, полягає в тому, що це швидкість передачі даних за замовчуванням в IDE Arduino. Крім того, швидша швидкість передачі даних також може бути ненадійною, якщо послідовний сигнал повинен пройти довгий шлях - хоча я не знаю, чому це було обрано як оптимальну швидкість.

Час реакції людини

Оскільки можливість зупинки послідовного монітора, коли ваш Arduino молотить на порт , потрібна користувачам 100% часу, а максимальна швидкість передачі потрібна менше 100% часу.

9600 бод - це компроміс між "легким вбити утікаючий процес" та "дратівливо повільним".