2016-12-03 9 views
1

У меня есть простой скрипт Python для связи с микроконтроллером (STM32F103C8T6) с использованием последовательного порта. Я использую pySerial для записи нескольких 44-байтовых сообщений за раз.Минимальная задержка для связи через последовательный порт с использованием Python

[...] 
serial = serial.Serial(serial.tools.list_ports.comports()[0].device, 115200) 

packet0 = bytearray(INSERT_RELEVANT_44-BYTES) 
packet1 = bytearray(INSERT_RELEVANT_44-BYTES) 
serial.write(packet0) 

time.sleep(0.1) # Delay between communications 

serial.write(packet1) 
[...] 

Мне пришлось вставить задержку между сообщениями, иначе это не сработало. Мое рассуждение состоит в том, что при скорости передачи в 115200 бит/с сообщения должны принимать 44 * 8/115200 = ~ 0,003 секунды для отправки, поэтому это должен быть минимальный идеальный интервал между отправкой пакетов. Код, однако, не работает ни на что меньшее 0,1.

Почему? Я что-то упускаю? Я полагаю, что есть некоторая задержка из-за операционной системы и USB, но она не должна составлять ~ 0,7 секунды. Как я могу оптимизировать это, чтобы использовать минимально возможную задержку?

+0

* «это не сработает» * - Это сводка, которая не содержит никакой диагностической информации. Ваш * «рассуждение» * слегка выключен; он не учитывает 2 бита кадрирования на символ. Что заставляет вас думать, что передача с минимальной задержкой практична; то есть приемник, способный обрабатывать (принимать и обрабатывать) такую ​​скорость передачи пакетов? Также рассмотрите точность функции сна и накладных расходов на интерпретируемый язык. – sawdust

+0

Это зависит от того, как вы используете последовательный порт в stm32. Можно ли использовать код, который вы пишете в stm32? – saygins

+0

Вы, кажется, ищете причину только на стороне отправки. Есть отправитель, который может потерять символы и приемник (в вашем случае у вас, по-видимому, есть адаптер USB-to-serial, который также может потерять символы). Без дополнительной диагностики на * где * проблема, мы, вероятно, не можем помочь. – tofro

ответ

0

Вместо того, вычисление номинальной задержки на основе линии UART, вы могли бы просто опрашивать драйвер последовательного порта, чтобы определить, пуст ли буфер Tx:

serial.write(packet0) 
while serial.outWaiting() > 0 : 
    pass 
serial.write(packet1) 

Это имеет преимущество учета автоматически для любой задержки, программные служебные и буферные ограничения в любом месте цепочки кода приложения, библиотеки, драйвера, USB-последовательного моста. Однако он не решает каких-либо проблем с реализацией последовательного ввода-вывода STM32, вероятно, вам следует решить коренную проблему, почему данные не могут быть потоковыми, что, скорее всего, приведет к плохой реализации на устройстве устройства STM32.

+0

Последовательный адаптер USB <> по-прежнему занимает 10 бод, чтобы вывести каждый байт, как обычный COM-порт, поэтому вы можете «(« не сказать, что это хороший выбор ») рассчитывать такую ​​минимальную задержку, возможно, добавляя фактор вымывания для накладных расходов , Размер буфера в USB <> последовательном адаптере не влияет на это - совершенно не имеет значения. – barny

+0

@barny: Возможно, моя мысль была неясной. Мы не знаем, в чем проблема, проблема заключается не в проблеме, а в решении.Если адаптер сказал 128 бит буферизации, вы можете отправить оба блока данных без задержки, и все данные будут переданы с точки зрения ПК в гораздо меньшей степени, чем время соединения UART с адаптером на STM32. USB-часть канала будет иметь управление потоком, в то время как раздел UART может не работать. Буферизация, конечно, не имеет значения, если данные передаются потоком, но здесь ошибка возникает только после двух 44-байтовых блоков. – Clifford

+0

Вы все еще говорите о буферизации на USB <> RS232-устройстве, как будто это имеет значение. В частности, при отсутствии контроля потока на месте, что касается кода на Python, COM-порт является обычным, и данные будут передаваться так быстро, как они передаются из «UART» в сторону STM32. Я предполагаю, что серийный и Windows тоже будут буферизировать. Поэтому размер буферов в USB <> RS232-адаптерах совершенно не имеет значения и полное отвлечение вашего «ответа» – barny