Обновление: ответ см. в нижней части этого ответа. TL;DR: вы установили скорость передачи данных (и, предположительно, все остальные настройки) после открытия порта.
Я считаю, что это ошибка в реализации QSerialPort для Windows. Я еще не смог сузить причину, но у меня есть следующие симптомы:
Загрузите в Arduino (в моем случае Uno; Leonardo может вести себя совсем по-другому) демо ASCII. Отключите и снова подключите Arduino. Обратите внимание, что индикатор TX не загорается.
Подключитесь к нему с помощью Putty или монитора последовательного порта Arduino. Это сбрасывает Arduino, а затем печатает таблицу ASCII. Индикатор TX горит постоянно, как и ожидалось.
Отключите/переподключите Arduino и на этот раз подключитесь к нему с помощью программы QSerialPort. На этот раз, несмотря на то, что порт открыт нормально, индикатор TX никогда не загорается, а readyRead()
никогда не срабатывает. Также обратите внимание, что Arduino не сбрасывается, потому что по умолчанию QSerialPort не изменяет DTR. Если вы сделаете QSerialPort::setDataTerminalReady(false);
, затем сделаете паузу на 10 мс, а затем установите true
, он будет перезагружать Arduino, как и ожидалось, но он все еще не передает.
Обратите внимание, что если у вас есть программа Arduino, которая непрерывно передает данные (пример ASCII останавливается), если вы откроете порт с помощью putty, чтобы он начал передачу, а затем откроете его с помощью QSerialPort, не отсоединяя кабель, он будет работать. ! Однако, как только вы отключаете/подключаете кабель, он снова перестает работать.
Это заставляет меня подозревать, что замазка устанавливает какой-то параметр последовательного порта, который требуется Arduino, и сбрасывается при повторном подключении кабеля. QSerialPort, очевидно, не изменяет это значение.
Насколько я могу судить, вот настройки, используемые Putty:
dcb.fBinary = TRUE;
dcb.fDtrControl = DTR_CONTROL_ENABLE;
dcb.fDsrSensitivity = FALSE;
dcb.fTXContinueOnXoff = FALSE;
dcb.fOutX = FALSE;
dcb.fInX = FALSE;
dcb.fErrorChar = FALSE;
dcb.fNull = FALSE;
dcb.fRtsControl = RTS_CONTROL_ENABLE;
dcb.fAbortOnError = FALSE;
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = FALSE;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
dcb.BaudRate = ...;
dcb.ByteSize = ...;
И QSerialPort:
dcb.fBinary = TRUE;
dcb.fDtrControl = unchanged!
dcb.fDsrSensitivity = unchanged!
dcb.fTXContinueOnXoff = unchanged!
dcb.fOutX = FALSE;
dcb.fInX = FALSE;
dcb.fErrorChar = FALSE;
dcb.fNull = FALSE;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
dcb.fAbortOnError = FALSE;
dcb.fOutxCtsFlow = FALSE;
dcb.fOutxDsrFlow = unchanged!
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
dcb.BaudRate = ...;
dcb.ByteSize = ...;
Поэтому я думаю, что это должно быть одно из тех неизменных значений, которые заставляют Arduino думать, что он не подключен. Из документации DCB Подозреваю fTxContinueOnXoff
.
Хорошо, я собираюсь написать небольшую программу, чтобы прочитать эти настройки и посмотреть, что изменится.
Обновление 1
Хорошо, я написал свою программу и сделал следующее открытие. Различия после запуска putty и только моей программы Qt:
- BaudRate: ЭТО БЫЛО УСТАНОВЛЕНО НЕ QT!!!!!!! Оказывается, вы можете установить скорость передачи только после открытия порта. В противном случае при первом подключении кабеля остается предыдущее значение, равное 0.
- fDtrControl: установите значение 1 для Putty, оставив значение 0 для Qt.
- fOutX и fInX: Оба также установлены в 1 Putty и оставлены в 0 Qt.
После перемещения всех моих вызовов функций set...()
после открытия все заработало отлично. Мне не пришлось возиться с DtrControl или Out/InX. (Хотя я также установил высокое значение DTR вручную.)
Обновление 2
При настройке всех параметров я подумал, что было бы неплохо установить политику ошибок на «пропустить». НЕ ДЕЛАЙТЕ ЭТОГО! ОСТАВЬТЕ ЭТО В ИГНОРЕ! В противном случае это все испортит и добавит странные задержки ко всем вашим сообщениям.
person
Timmmm
schedule
01.10.2013