Здесь есть несколько факторов:
- Какую скорость передачи данных может получить микроконтроллер ATmega328P?
- Какую скорость передачи данных может обеспечить интерфейс USB-Serial?
- Какова частота генератора на ATmega328P?
- Какова частота генератора на последовательном USB-интерфейсе (если он есть)?
- Насколько устойчив USB-последовательный интерфейс к несоответствию скорости передачи?
Все эти факторы имеют отношение к определению максимально достижимой скорости передачи. ATmega328P использует аппаратный делитель от своей тактовой частоты для генерации базовой частоты для последовательного интерфейса. Если нет целочисленного отношения от основного тактового генератора к битовому времени желаемой скорости передачи, MCU не сможет точно произвести желаемую скорость. Это может привести к потенциальным проблемам, поскольку некоторые устройства гораздо более чувствительны к несоответствию скорости передачи, чем другие.
Интерфейсы на основе FTDI вполне терпимы к несоответствию скорости передачи данных до нескольких процентов ошибок. Однако я работал со специализированными встроенными модулями GPS, которые не могли справиться даже с ошибкой скорости передачи 0,5%.
Обычные последовательные интерфейсы допускают ошибку скорости передачи ~ 5%. Однако, так как каждый конец может быть выключен, более распространенная спецификация составляет + -2,5%. Таким образом, если один конец работает на 2,5% быстрее, а другой - на 2,5% медленнее, ваша общая ошибка по-прежнему составляет всего 5%.
В любом случае. Uno использует ATmega328P в качестве основного MCU и ATmega16U2 в качестве последовательного USB-интерфейса. Нам также повезло, что в обоих этих микроконтроллерах используются аналогичные аппаратные средства 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 бод.
Обратите внимание, что эта скорость передачи только дает MCU 64 80 тактов на байт, поэтому было бы очень сложно поддерживать последовательный интерфейс занятым. В то время как отдельные байты могут передаваться очень быстро, вероятно, будет много времени, когда интерфейс просто простаивает.
Изменить: фактическое тестирование!
2 Мбит / с реальны:
каждый бит равен 500 нс, что в точности соответствует ожидаемому.
Проблемы с производительностью! Общая длина пакета:
500 Кбод:
1 МБод:
2 Мбод:
Примечание. Заметное превышение вызвано плохой практикой заземления зонда и, вероятно, не соответствует действительности. Я использую вывод заземления, который является частью моего зондового прицела, и индуктивность вывода, вероятно, является причиной большинства перерегулирований.
Как видите, общая длина передачи одинакова для 0,5, 1 и 2 МБод. Это потому, что код, который помещает байты в последовательный буфер, плохо оптимизирован. Таким образом, вы никогда не достигнете ничего лучше, чем эффективные 500 кбод, если вы не напишите свои собственные последовательные библиотеки. Библиотеки Arduino очень плохо оптимизированы, поэтому, вероятно, не составит большого труда получить надлежащие 2 Мбод, по крайней мере для пакетной передачи, если вы потратите на это немного времени.