Насколько высока скорость передачи в бодах (без ошибок)?

Стандарт составляет 9600 бод. Это просто стандарт . Используя Arduino Uno SMD R2, какова максимальная практическая скорость передачи в бодах, которую я могу достичь?

Бонусные баллы за смелый: Как вы могли бы создать механизм проверки ошибок, а затем увеличить скорость передачи в бодах, чтобы получить высокие скорости передачи?

34 голоса | спросил Anonymous Penguin 19 FebruaryEurope/MoscowbWed, 19 Feb 2014 07:16:57 +0400000000amWed, 19 Feb 2014 07:16:57 +040014 2014, 07:16:57

4 ответа


53

Здесь есть несколько факторов:

  • Насколько высока скорость передачи данных, которую может достичь MCU 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 МГц часы.

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

В любом случае, «правильный» ответ на этот вопрос потребует выкапывания источника для ATmega16U2 и разработки возможных бод-ставок оттуда, но, поскольку я ленив, я считаю, что простое, эмпирическое тестирование будет работать.

Быстрый взгляд на таблицу ATmega328P дает следующую таблицу:
введите описание изображения здесь

Поэтому, учитывая максимальную скорость передачи 2 Мбит /с, я написал программу быстрого тестирования:

void setup () {};

void loop ()
{

  Задержка (1000);
  Serial.begin (57600);
  Serial.println ("\ r \ rBaud-rate = 57600");
  Задержка (1000);
  Serial.begin (76800);
  Serial.println ("\ r \ rBaud-rate = 76800");
  Задержка (1000);
  Serial.begin (115200);
  Serial.println ("\ r \ rBaud-rate = 115200");
  Задержка (1000);
  Serial.begin (230400);
  Serial.println ("\ r \ rBaud-rate = 230400");
  Задержка (1000);
  Serial.begin (250000);
  Serial.println ("\ r \ rBaud-rate = 250000");
  Задержка (1000);
  Serial.begin (500000);
  Serial.println ("\ r \ rBaud-rate = 500000");
  Задержка (1000);
  Serial.begin (1000000);
  Serial.println ("\ r \ rBaud-rate = 1000000");
  Задержка (1000);
  Serial.begin (2000000);
  Serial.println ("\ r \ rBaud-rate = 2000000");
};

И затем посмотрев соответствующий последовательный порт с последовательным терминалом:

введите описание изображения здесь>> </p>

<p> Итак, похоже, что аппаратное обеспечение может работать на скорости 2 000 000 бод без проблем. </p>

<p> Обратите внимание, что эта скорость в бодах дает только MCU <strike> 64 </strike> 80 тактов на каждый байт, поэтому было бы очень сложно поддерживать последовательный интерфейс. Хотя отдельные байты могут передаваться очень быстро, вероятно, будет много времени, когда интерфейс просто простаивает. </p>

<hr>
<p> Изменить: Фактическое тестирование! </p>

<p> 2 Мбит /с реально: <br> <img src =
каждый бит-время составляет 500 нс, что точно соответствует ожидаемому.

Проблемы с производительностью! Общая длина пакета:
500 Кбод: введите описание изображения здесь>> </p>

<p> 1 Мбод:
<img src =
Примечание: заметное превышение связано с плохой практикой заземления зонда, и вероятно не является реальным. Я использую заземление, которое входит в мой зонд, и свинцовая индуктивность, вероятно, является причиной большинства перерегулирования.

Как вы можете видеть, общая длина передачи одинакова для 0.5, 1 и 2 Mbaud. Это связано с плохой оптимизацией кода, который помещает байты в последовательный буфер. Таким образом, вы никогда не добьетесь чего-нибудь лучшего, чем эффективный эффективный 500 Kbaud, если вы не напишете свои собственные серийные библиотеки. Библиотеки Arduino очень плохо оптимизированы, поэтому, возможно, не было бы слишком для получения надлежащего 2 Mbaud, по крайней мере для пакетных передач, если вы потратили на это немного времени.

ответил Connor Wolf 19 FebruaryEurope/MoscowbWed, 19 Feb 2014 10:24:54 +0400000000amWed, 19 Feb 2014 10:24:54 +040014 2014, 10:24:54
7

Окно Arduino Serial Monitor ограничивает вас до 115200, но это не самая высокая скорость передачи. Вы можете прочитать данные Atmel и FT232 (или все, что вы используете), чтобы узнать максимум, но я могу успешно использовать 230400 (в два раза быстрее, чем самый большой, поддерживаемый Arduino Serial Monitor) без проблем.

Если вы хотите увидеть результаты на своем компьютере, вам понадобится другой последовательный монитор, который поддерживает другие параметры скорости передачи. Мне нравится CoolTerm и Termite .

Заметьте, что это также сильно зависит от вашей тактовой частоты.

Вот калькулятор , чтобы помочь вам рассчитать, что возможно.

ответил sachleen 19 FebruaryEurope/MoscowbWed, 19 Feb 2014 09:27:35 +0400000000amWed, 19 Feb 2014 09:27:35 +040014 2014, 09:27:35
3

Это, вероятно, один из немногих аспектов, когда платы el-Cheapo отличаются от оригинальных плат. Максимальная скорость последовательного переноса в значительной степени ограничена качеством платы и ее компоновкой. После того, как последовательные данные поступают в чип AVR или USB, данные будут обрабатываться иначе, чем последовательный протокол UART.

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

Еще один эффект, который следует помнить, заключается в том, что все накладные расходы, требуемые для вывода данных на UART (или втягивание), не могут быть потрачены в вашей реальной программе, что опять-таки влияет на среднюю практическую пропускную способность. Вы можете использовать только каждый цикл команд один раз, либо для заполнения буфера, либо для вычисления основного цикла.

Таким образом, максимальная пропускная способность зависит от используемого вами приложения (насколько быстро генерируются данные /вычисляются /готовы к переходу в /из последовательного буфера), а фактический «физический» битрейт является лишь малой частью дизайнерского решения.

ответил jippie 19 FebruaryEurope/MoscowbWed, 19 Feb 2014 10:39:32 +0400000000amWed, 19 Feb 2014 10:39:32 +040014 2014, 10:39:32
2

Проверка ошибок на самом деле очень проста, и есть AVR lib, который делает это в одном лайнере.

Читайте на util /crc16.h , и вы должны быть в курсе последних примеров.

CRC является достаточно надежным и быстрым для простых приложений.

ответил 80HD 19 FebruaryEurope/MoscowbWed, 19 Feb 2014 19:31:57 +0400000000pmWed, 19 Feb 2014 19:31:57 +040014 2014, 19:31:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132