[4.x.x] QextSerialPort, проблемы с чтением

[vregess]

Есть устройство, работа с которым идет по RS232 (COM-порт).
Раньше работал с ним при помощи своей библиотеки.
Вот реши попробовать подцепить QextSerialPort (версия 1.1).

Такой код:

Код:

  char data[4]={12,13,14,15};
  char a_data[60];
  ABaseModbus bus;
  bus.setPort(new QextSerialPort("COM1"));
  bus.port()->setBaudRate(BAUD9600);
  bus.port()->setDataBits(DATA_8);
  bus.port()->setFlowControl(FLOW_OFF);
  bus.port()->setParity(PAR_NONE);
  bus.port()->setStopBits(STOP_1);
  bus.port()->setTimeout(1,0);
  bus.port()->open(QIODevice::ReadWrite);
  
  if(!bus.port()->isOpen()){
    printf("Error open port.\n");
    qDebug()<<bus.port()->errorString();
  }
  char a_frame[]={0x01, 0x11, 0x0c, 0x55, 0x2c};
  qDebug()<<bus.port()->write(a_frame,5);                  // выводит 5
  qDebug()<<"Data "<<bus.port()->readData(a_data,2); // выводит 0

Запись происходит.
А вот ответ не считывается.

Устройство точно получает и возвращает ответ.
Где я ошибся?

[pastor]

Возможно данные не успели ещё прийти. Как правило это частный случай, когда данные сразу же готовы для считывания. Заюзай цикл с использованием метода bytesAvailable (для определения количества байт готовых для чтения) чтобы вычитать данные из порта.

[vregess]

вот я исходники смотрел.
когда происходит чтение, по идее должны использоваться тайминги, которые определяются методом
setTimeout.

оно должно ждать исходя из таймингов, а потом выдавать результат.
тут вроде цикл и не нужен.
смотрел bytesAvailable, как я понял он ничего приличного не вернет для QextSerialPort.
ну в смысле кол-во байт в буфере порта она не вернет

мож я чет не понимаю..

моя реализация и в QextSerialPort похожа в принципе...

[pastor]

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

А откуда такое заключени?
Всегда этот метод возвращал количество байт готовые для считывания. Никаких проблем небыло (с версии 0.7 пользовался)

This function will return the number of bytes waiting in the receive queue of the serial port.

[pastor]

Скажу из опыта по поводу тайм-аутов: нефакт что они могут спасти. Особо полагаться на них не стоит.

ЗЫ: Текущая реализация QextSerialPort неочень удовлетворяла наши потребности. Мы делали отдельный поток и крутили бесконечный цикл со слипом. В цикле вызывался bytesAvailable. Если данные были, то мы их читали и парсили.
В итоге мы переписали QextSerialPort - сделдали работу с портом асинхронной.

[vregess]

Скажу из опыта по поводу тайм-аутов: нефакт что они могут спасти. Особо полагаться на них не стоит.

ЗЫ: Текущая реализация QextSerialPort неочень удовлетворяла наши потребности. Мы делали отдельный поток и крутили бесконечный цикл со слипом. В цикле вызывался bytesAvailable. Если данные были, то мы их читали и парсили.
В итоге мы переписали QextSerialPort - сделдали работу с портом асинхронной.

посмотрел еще раз bytesAvailable. Да я ошибся. все он возвращает.
Но почему-то в моем случае что-то не то.
Ну цикл со слипом меня не устраивает..
Да тайминги мне важны очень, корректность обмена именно по ним только и определяется+crc.
у меня реализация работы с портом синхронная (тк такая мне нужна на данный момент) и не thread-safe (тк в синхронном обмене, как я понимаю, это и не надо), да написано оно без привязки к qt.

После просмотра кода QextSerialPort, решил пересмотреть API. вот переделываю ща.
Можно будет объединить все это..

[pastor]

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

[vregess]

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

это уже конечно оффтоп...
и все же, почему трудно?

[pastor]

это уже конечно оффтоп...
и все же, почему трудно?

Потому что существует множество факторов в передаче данных (возможная задержка с передающей стороны, задержка на принимающей стороне). И эти задержки не постоянны. Одним из факторм может быть сама ось. За заданный тайм аут может прийти только часть данных или не прийти данный вовсе. Если прога затачиваеться под конкетный девайс, то можно подобрать нужные таймауты. Но это не решение проблемы.

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

[vregess]

а вот если. "Пакет" данных определяется именно временем между байтами? Или если нужна именно синхронная работа? (пример, протокол modbus).

Я не глубоко копал, но читал, что в вин тайминги криво реализованы, в лин вроде по-лучше.
На самом деле я тоже не точные тайминги использую. Тк передача у мя синхронная, то для корректной работы можно выставить хоть миллион часов в таймингах. Результатом будет снижение скорости общения, но зато стабильно. Так что вот. Проблемы подбора таймингов в таком случае не очень сложная задача. Можно взять, допустим, 1 сек. А если уж не успел все забрать/считать, то значит обработка ошибки. Это приемлемо для ряда случаев (у меня как раз такой).

хм. появился интерес реализовать все-таки асинхронную передачу в своей либе... вот только проверить негде будет.

это все интересно немножко, но оффтоп сильно. нас не простят!
мож завяжем? тем более в аське все это можно обсудить)

[pastor]

У меня есть переделаная либа реализующая асинхронную передачу. Правда только для Windows, Qt 3.3.x
Но мне кажеться не проблема портануть код под Qt 4

[vregess]

У меня есть переделаная либа реализующая асинхронную передачу. Правда только для Windows, Qt 3.3.x
Но мне кажеться не проблема портануть код под Qt 4

Ок. Буду знать. Придет время, обращусь. Решил пока не заморачивться (ибо не надо).

Кста, я пошел немного другим путем. Все-таки подобная библиотека работает с железом, и я не хотел привязываться к Qt (мож еще где понадобится), поэтому написал просто на с++. И думаю обертку написать как нить для Qt. Мне кажется это более правильный путь.

[pastor]

Мне кажется это более правильный путь.

Ну незнаю насчет правильного пути... QextSerialPort вполне юзабельная библиотека

[vregess]

QextSerialPort вполне юзабельная библиотека

кто спорит

Ну незнаю насчет правильного пути...

просто не хочу привязывать к Qt. Мало ли что, вдруг придется от нее отказаться

[oleg123]

Используй режим работы устройства QIODevice::Unbuffered.
В противном случае при попытке чтения хотя бы одного байта QIODevice
пытается заполнить свой приёмный буфер (в 4.2.2 аж 16 к), отсюда и глюки.