Нахожусь ли я на пределе времени передачи UART?

serial uart speed stm32

В настоящее время я использую STM32F103C8 (с ядром arduino) для считывания 4 датчиков с частотой 1 кГц, а затем отправляю эти данные через UART (со скоростью 115200 бод) на другое устройство. Каждый датчик возвращает значение с плавающей запятой, я также включаю значение без знака long, представляющее миллисекунды с момента загрузки. В сумме получается 20-байтовый пакет, который я пытаюсь отправить со скоростью 1 кГц. Отбор проб датчиком осуществляется с помощью прерывания по таймеру, так как крайне важно, чтобы время между выборками было постоянным.

Сама передача данных (если я отправляю их медленно) занимает ок. 70 микросекунд. При ускорении до 1 кГц требуется ок. 2500. Я предполагаю, что это происходит потому, что я заполняю какой-то последовательный буфер.

Речь идет об ограничении способа связи? Если для отправки данных требуется более 1000 микросекунд, то, предположительно, прерывание сработает до отправки данных, и его придется запускать снова?

, 👍2

Обсуждение

Вы могли бы попробовать более высокую скорость передачи данных. Хотя это зависит от того, насколько высокую скорость передачи данных может обрабатывать другое устройство, @chrisl


2 ответа

3

При скорости передачи 115200 бод вы можете отправлять 11520 символов в секунду. При 20 байтах на пакет вы можете отправлять 576 пакетов в секунду. Это 1736 мкс на пакет.

Это предполагает нулевое ожидание между байтами. Этого не произойдет.

Ваше измерение в 70 мкс будет просто временем, затраченным на помещение данных в буфер передачи, и не имеет никакого отношения к тому, сколько времени занимает сама передача.

Объедините все это вместе, и значение в 2500 мкс на пакет не будет необоснованным.

Чтобы передавать быстрее, вам просто нужно будет работать с более высокой скоростью передачи в бодах. Если в настоящее время вы получаете 2500 мкс на пакет, а пакет занимает 1736 мкс (для простоты назовем его 1750), то для выполнения фактической работы по отправке данных из буфера требуется около 750 мкс на пакет. Я предполагаю, что это фиксированное значение, хотя, не зная, как работает UART STM32F1, это может быть и не так.

Если вы хотите <1000 мкс, то это оставляет вам около 250 мкс времени, чтобы поместить пакет внутрь. Это означает эквивалент 4000 пакетов в секунду, или 80 000 байт в секунду, или скорость передачи данных 800 000 бод.

1 Мбод - это более чем возможно, и это хорошая стандартная скорость передачи данных в бодах, с которой может справиться большинство устройств. Таким образом, повышение скорости передачи данных до 1 000 000 бод должно позволить передаче данных происходить достаточно быстро.

,

Интересно! Я действительно не знал, что такие высокие скорости передачи данных возможны! У меня был некоторый успех с частотой 921600, а не 1000 000, так что, по-видимому, что-то связанное с кратностью частот кристаллов, @nuggetbram

Чем ближе вы находитесь к целочисленному коэффициенту вашей тактовой частоты, тем точнее будет передача данных в бодах. Но если оба конца соединения используют одни и те же часы, разница в ошибках между двумя концами будет равна 0, поэтому это бессмысленно., @Majenko

Конечно, при более высоких скоростях передачи данных вы в большей степени зависите от точности часов, так как любое небольшое отклонение в часах приведет к большему проценту разницы в скорости передачи данных в бодах., @Majenko

0

Я протестировал множество скоростей передачи данных в бодах на Arduino Unos, включая дешевые китайские модели, и решил использовать значение по умолчанию 115200 для моей системы DaqPort (https://www.daqarta.com/dw_rraa.htm). Я обнаружил проблемы, такие как зависание системы примерно через секунду при скорости передачи 150000 бод, и не хотел, чтобы мои пользователи сталкивались с проблемами, которые было бы трудно устранить.

Поэтому мне интересно, можете ли вы уменьшить количество байтов, которые вам нужно отправить. Вам действительно нужно отправлять float? Я думаю, что 4 байта для данных и 4 для времени дадут достаточное разрешение практически для чего угодно, и я не могу (во всяком случае, навскидку) представить себе тип датчика с разрешением более 32 бит. Кроме того, 32 бита мсек - это почти 50 дней; если вам нужно больше, чем это, должно быть довольно легко развернуть время постфактум.

Просто мысль...

,

Честно говоря, я совершенно забыл о shorts как типе данных, мои датчики в любом случае имеют только 12 бит, так что это очень поможет. Я должен быть в состоянии просто сохранить необработанные показания датчика как короткие и позже обработать все с плавающей запятой. Я использую микросекунды, а не миллисекунды для определения времени, поэтому длина без знака составляет всего 70 минут - моя максимальная продолжительность выборки составляет 20 минут, что слишком долго для unsigned int ., @nuggetbram

Смотрите также: