Последовательный порт детерминизм

Question

Это кажется простым вопросом, но его трудно найти. Мне нужно интерфейс с устройством через последовательный порт. Если моя программа (или другая программа) не завершает запись команды на устройство, как я могу гарантировать, что следующий запуск программы может успешно отправить команду?

Пример:

1. Программа foo запускается и начинает писать «A_VERY_LONG_COMMAND»
2. Пользователь завершает программу, но программа написала только «A_VERY»
3. Пользователь снова запускает программу, и команда отправляется повторно. За исключением того, что устройство видит «A_VERYA_VERY_LONG_COMMAND», а это не то, что нам нужно.

Есть ли способ сделать это более детерминированным? Программирование последовательного порта кажется очень неуправляемым из-за подобных проблем.

Answer 1

Требуемый метод зависит от устройства.

• Последовательные порты имеют дополнительные линии управляющего сигнала, а также линию последовательных данных; возможно, один из них сбросит вход устройства. Я никогда не программировал последовательный порт, но думаю, что ioctl() справится с этим.
• Может быть один байт, который будет сброшен, например, какой-то управляющий персонаж.
• Может быть сигнал на основе синхронизации, например, Модемы набора команд Hayes используют «pause +++ pause».
• Может просто сброситься после неполного получения команды через фиксированное время.

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

Answer 2

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

Или же он должен предоставлять символ сброса программного обеспечения, который будет сбрасывать буфер команд и все состояния.

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

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

Answer 3

Я бы предположил , что если вы вызовете write("A_VERY_LONG_COMMAND"), а затем пользователь нажмет Ctrl + C, пока байты выходят на линию, слой драйвера должен завершить отправку полного буфера. И если пользователь прерывает работу в середине вызова, уровень драйвера, вероятно, просто проигнорирует все это.

На всякий случай, когда вы открываете новый COM-порт, всегда разумно очищать порт.

У вас есть контроль над концом устройства? Возможно, имеет смысл ввести тайм-аут, чтобы устройство игнорировало незаконченные или иным образом поврежденные пакеты.