Блоки QextSerialPort при попытке чтения - PullRequest
Новая
       16

Блоки QextSerialPort при попытке чтения

2 голосов
/ 22 марта 2011

Я использую QextSerialPort в Windows, чтобы мое приложение Qt / C ++ могло выполнять чтение и запись с / на последовательный порт.

Я хочу читать байты с последовательного порта, только когда есть байты для чтения.

Сначала я попытался подключить сигнал QextSerialPort::readyRead() к слоту в моем основном классе, но заметил, что приложение зависает.

Затем я попытался использовать QextSerialPort::read(char *, uint64), который возвращает количество прочитанных байтов, и после этого я предпринял еще одну неудачную попытку объединения QextSerialPort::bytesAvailable() и QextSerialPort::read(char *, uint64), чтобы посмотреть, поможет ли это моему приложению не блокировать.

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

Есть ли способ выполнить неблокирующее чтение с помощью QextSerialPort?

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

UPDATE: Я попытался использовать QextSerialPort::atEnd() для проверки наличия байтов для чтения вместо QextSerialPort::bytesAvailable() или QextSerialPort::size(), и он всегда возвращает false.

1 Ответ

0 голосов
/ 22 марта 2011

Чтения должны быть неблокирующими, если вы не установили режим запроса на опрос 

    inline QueryMode queryMode() const { return _queryMode; }

    /*!
     * Set desired serial communication handling style. You may choose from polling
     * or event driven approach. This function does nothing when port is open; to
     * apply changes port must be reopened.
     *
     * In event driven approach read() and write() functions are acting
     * asynchronously. They return immediately and the operation is performed in
     * the background, so they doesn't freeze the calling thread.
     * To determine when operation is finished, QextSerialPort runs separate thread
     * and monitors serial port events. Whenever the event occurs, adequate signal
     * is emitted.
     *
     * When polling is set, read() and write() are acting synchronously. Signals are
     * not working in this mode and some functions may not be available. The advantage
     * of polling is that it generates less overhead due to lack of signals emissions
     * and it doesn't start separate thread to monitor events.
     *
     * Generally event driven approach is more capable and friendly, although some
     * applications may need as low overhead as possible and then polling comes.
...