Тут є кілька факторів:
- Якої високої швидкості передачі може досягти 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 Мбауд, принаймні, для пакетних передач, якби ви витратили на це трохи часу.