На яку високу швидкість передачі можна перейти (без помилок)?


40

Стандарт - 9600 бод. Це просто стандарт . Використовуючи Arduino Uno SMD R2, яку найвищу практичну швидкість передачі я можу досягти?

Бонусні бали для зухвалих: як би ви почали створювати механізм перевірки помилок, а потім збільшувати сміхотворну швидкість до високих, щоб отримати високі швидкості передачі?


1
Варто відзначити, що плати Arduino, які використовують USB-послідовні ІМ-диски FTDI, можуть дійсно швидко працювати. Звичайний FT232 може тривати 3 мегабауди (це 3 000 000 бод) без проблем. Застосування ATmega16U2 є обмежуючим фактором.
Вонор Коннор

Мій клон Arduino Nano, який я отримав з eBay, виписаний на 1 099 999. Серйозно. Це було. Як тільки вона досягла 1 100 000, результат був зібраний. laqq`na`fca`fga`fga`bcngaah````iin`ha`a`a`bga`fga`bcqpahhqfq```fh`oopa`bca`fca. Він використовує чіп CH340 для USB-комірок.
ПНДА

Відповіді:


59

Тут є кілька факторів:

  • Якої високої швидкості передачі може досягти MCM ATmega328P?
  • Яку високу швидкість передачі даних може досягти USB-послідовний інтерфейс?
  • Яка частота генератора на ATmega328P?
  • Яка частота генератора в USB-послідовному інтерфейсі (якщо він є)?
  • Наскільки толерантним є USB-послідовний інтерфейс невідповідності швидкості передачі?

Всі ці фактори мають значення для визначення максимально досяжної швидкості передачі. ATmega328P використовує апаратний дільник з його тактової частоти для генерації базової тактової частоти для послідовного інтерфейсу. Якщо коефіцієнт цілих чисел від основного тактового часу до бітового часу бажаної швидкості передачі даних не буде, MCU не зможе точно створити бажану швидкість. Це може призвести до потенційних проблем, оскільки деякі пристрої значно чутливіші до невідповідності швидкості передачі даних, ніж інші.

Інтерфейси на основі FTDI є досить терпимими до невідповідності швидкості передачі даних до помилок до декількох відсотків. Однак я працював із спеціалізованими вбудованими модулями GPS, які не змогли обробити навіть 0,5% похибки швидкості передачі даних.

Загальні послідовні інтерфейси мають толерантність до ~ 5% похибки швидкості передачі даних. Однак, оскільки кожен кінець може бути вимкнений, більш поширена специфікація становить + -2,5%. Таким чином, якщо один кінець швидкий на 2,5%, а інший - 2,5% повільний, ваша загальна помилка все ще становить лише 5%.


Все одно. Uno використовує ATmega328P в якості основного MCU, а ATmega16U2 як USB-послідовний інтерфейс. Нам також пощастило, що обидва ці MCU використовують аналогічні програмні USART, а також 16 МГц.

Оскільки обидва MCU мають однакове програмне забезпечення та тактову частоту, вони мають однакову помилку швидкості передачі даних в одному напрямку, тому ми можемо функціонально ігнорувати проблему помилок передачі даних.

У будь-якому разі, "правильна" відповідь на це запитання передбачала б перекопування джерела для ATmega16U2 та відпрацювання можливих швидкостей передачі даних, але оскільки я лінивий, я вважаю, що просте емпіричне тестування спрацює.

Швидкий погляд на таблицю даних ATmega328P створює таку таблицю:
введіть тут опис зображення

Отже, враховуючи максимальну заявлену швидкість передачі даних в 2 Мбіт / с, я написав програму швидкого тестування:

void setup(){};

void loop()
{

  delay(1000);
  Serial.begin(57600);
  Serial.println("\r\rBaud-rate = 57600");
  delay(1000);
  Serial.begin(76800);
  Serial.println("\r\rBaud-rate = 76800");
  delay(1000);
  Serial.begin(115200);
  Serial.println("\r\rBaud-rate = 115200");
  delay(1000);
  Serial.begin(230400);
  Serial.println("\r\rBaud-rate = 230400");
  delay(1000);
  Serial.begin(250000);
  Serial.println("\r\rBaud-rate = 250000");
  delay(1000);
  Serial.begin(500000);
  Serial.println("\r\rBaud-rate = 500000");
  delay(1000);
  Serial.begin(1000000);
  Serial.println("\r\rBaud-rate = 1000000");
  delay(1000);
  Serial.begin(2000000);
  Serial.println("\r\rBaud-rate = 2000000");
};

Потім перегляньте відповідний послідовний порт із послідовним терміналом:

введіть тут опис зображення

Отож, схоже, апаратне забезпечення може працювати без 2 000 000 бод без проблем.

Зауважте, що ця швидкість передачі даних дає лише 64 80 тактових циклів MCU на байт, тому дуже важко тримати зайнятий послідовний інтерфейс. Хоча окремі байти можуть передаватися дуже швидко, можливо, буде багато часу, коли інтерфейс просто не працює.


Редагувати: фактичне тестування!

2 Мбіт / с реально:
введіть тут опис зображення
кожен біт-час становить 500 нс, що точно відповідає тому, що очікується.

Питання продуктивності! Загальна довжина пакета:
500 Кбауд: введіть тут опис зображення

1 Мбо: введіть тут опис зображення

2 Mbaud: введіть тут опис зображення
Примітка: Помітне перевищення пояснюється поганою практикою заземлення зонду, і, ймовірно, не реально. Я використовую наземний кліп-ведучий, який є частиною мого зондування, і індуктивність свинцю, ймовірно, є причиною більшості прострілів.

Як бачите, загальна довжина передачі однакова для 0,5, 1 і 2 Мбауд. Це тому, що код, який розміщує байти в послідовному буфері, погано оптимізований. Таким чином, ви ніколи не досягнете нічого кращого, ніж ефективний 500 Кбауд, якщо не напишете власні послідовні бібліотеки. Бібліотеки Arduino дуже погано оптимізовані, тому, мабуть, не буде надто складно отримати належний 2 Мбауд, принаймні, для пакетних передач, якби ви витратили на це трохи часу.


4
Приємна ілюстрація обмеження пропускної здатності!
jippie

1
@AnnonomusPerson - Якщо перейти на тактову частоту 20 МГц, ви можете робити 2,5 Мбіт / с.
Вонор Коннор

1
@AnnonomusPerson - Вам потрібно буде обмінятись обома або використовувати USB-послідовний інтерфейс FTDI з генератором 20 МГц ATmega328P. ATmega328P не може робити 2,5 Мбіт / с без 20 МГц кристала / резонатора. Те саме стосується будь-яких інтерфейсів ATmega16U2.
Вонор Коннор

1
Чудова відповідь! Всього одна невелика корекція: при 2 Мб / с кожна байтна передача займає 80 процесорних циклів, а не 64. Це тому, що, за часом, кожен байт коштує 10 біт (1 старт, 8 даних, 1 зупинка).
Едгар Бонет

1
@ linhartr22 - Проводи дійсно вступають у гру лише в тому випадку, якщо вони довгі , як у 12 "+. Я думаю, що це мало ймовірно, що занадто багато людей занадто багато використовують кабелі довжиною 100 футів. Крім того, питання полягав у тому, наскільки високий ардуїно / ATmega швидкість передачі даних може подолати, не наскільки високою може бути довільна збірка кабелю.
Коннор Вольф

7

Вікно Arduino Serial Monitor обмежує вас до 115200, але це не найвища швидкість передачі даних. Ви можете прочитати таблиці даних Atmel і FT232 (або все, що ви використовуєте), щоб дізнатися максимум, але я можу успішно використовувати 230400 (вдвічі швидше, ніж найбільша підтримка Arduino Serial Monitor) без жодних проблем.

Якщо ви хочете побачити результати на своєму комп’ютері, вам знадобиться ще один послідовний монітор, який підтримує інші варіанти швидкості передачі даних. Мені подобаються CoolTerm і Termite .

Зверніть увагу, що це сильно залежить і від вашої тактової частоти.

Ось калькулятор, який допоможе вам підрахувати, що можливо.


Коли ви починаєте все швидше і швидше, обмеження перетворюється на послідовну бібліотеку - реалізація не дуже ефективна.
Кібергіббони

веб-сайт посилання мертвий
Codebeat

3

Це, мабуть, один з небагатьох аспектів, коли дошки el-Cheapo відрізняються від оригінальних дощок. Максимальна швидкість передачі послідовних передач майже обмежена якістю плати та її компонуванням. Після того, як послідовні дані надходять або в AVR, або в мікросхему USB інтерфейсу, вони будуть оброблятися інакше, ніж послідовний протокол UART.

Майте на увазі, що мікроконтролер має деяке основне обладнання для передачі / виведення послідовних даних на / з штифтів вводу-виводу, але абсолютна максимальна швидкість обмежена тактовою частотою 16 МГц (для AVR). Після переміщення байта до послідовного буфера апаратне забезпечення UART перейме на себе і висуне / витягне біти самостійно. AVR в кращому випадку досягає 16M інструкцій в секунду, а переривання, які використовуються для заповнення послідовного буфера, мають деякі накладні витрати (принаймні 8 годинних галочок для обробки переривань + інструкції для збереження поточного стану + кілька інструкцій щодо фактичного заповнення буфера). При заданому бітрейті протокол працюватиме з величезними n бітами в секунду, але вашому контролеру потрібно більше часу для заповнення послідовного буфера, ніж потрібно для фактичного виведення даних, що призводить до меншої середньої пропускної здатності, ніж ви очікували, і UART на холостому ходу протягом відносно тривалого часу.

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

Отже, максимальна пропускна здатність залежить від використовуваної програми (наскільки швидко генеруються / обчислюються дані / готові перейти до / з послідовного буфера), а фактичний "фізичний" бітрейт - лише незначна частина дизайнерського рішення.


1
Я дійсно, дійсно сумніваюся, що на будь-якій із дощок там є проблеми з компонуванням досить серйозні, щоб запобігти нормальному роботі 2 МГц. 2 МГц не дуже висока частота.
Коннор Wolf

@FakeName Принаймні одна дошка на моєму столі тут підвищила BER, коли я натискаю серійну швидкість. Зазвичай я використовую 9600, що більш ніж достатньо для більшості застосунків і є надійним.
jippie

Без жартів! Ага. Цікаво, наскільки поганим має бути макет, щоб це сталося? Я б підозрював, що це не макет настільки, як резонатори / кристали поганої толерантності.
Вонор Коннор

1
Високі показники швидкості передачі даних, особливо якщо вони є U2Xn = 1в USART, мають тенденцію до неприємних розбіжностей.
Вонор Коннор

@FakeName Я динозавр, мені подобається "9600 8N1" з усіх помилкових спадкових причин, про які ви можете подумати; o)
jippie

2

Перевірка помилок насправді дуже проста, і є AVR-вкладка, яка робить це в одному вкладиші.

Читайте далі, util/crc16.hі ви повинні бути готові піти в найкоротші терміни з включеними прикладами.

CRC є досить надійним і швидким для простих застосувань.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.