USBXpress cp2102

alik_tv · 01.08.2014, 14:51

Привет всем

Имеем устройство с мегой, на выходе cp2102 и USB. С виртуальным компортом работает.
Решил пойти "глубже", на USBXpress. Поставил SDK Ver 4.0.2. Почитал описание и примеры в ней.
Написал простейшую программу. Передача запроса в устр-во и получение ответа от уст-ва.

Код:

ret = SI_GetNumDevices(&dwNumDevices);
ret = SI_GetProductString(dwDevice,asDeviceString.c_str(  ),SI_RETURN_DESCRIPTION);
ret = SI_Open(dwDevice,&cyHandle);
ret = SI_SetBaudRate(cyHandle,19200);
ret = SI_SetLineControl(cyHandle,0x0800);
ret = SI_SetFlowControl(cyHandle, SI_STATUS_INPUT, SI_HELD_INACTIVE, SI_HELD_INACTIVE, SI_STATUS_INPUT, SI_STATUS_INPUT, 0);
ret = SI_SetTimeouts(100,INFINITE);   //(DWORD dwReadTimeout,DWORD dwWriteTimeout);

// Запрос
ret = SI_Write(cyHandle,btDataCodogrammaOut,10,&dwBytesWritten);
ret = SI_FlushBuffers(cyHandle,1,0);

// Ответ устр-ва
ret = SI_FlushBuffers(cyHandle,0,1);
ret = SI_Read(cyHandle,btDataCodogrammaIn,9,&dwBytesReturned);

ret = SI_Close(cyHandle);

Результаты работы каждой функции я проверяю.
Запросы передает замечательно, устр-во на запрос отвечает(проверял осциком на TX проца).
Но при выполнении "// Ответ устр-ва" выдается ошибка SI_Read - SI_READ_TIMED_OUT.
Скорость 19200, в датаграмме 10 байт.

Но я не сдался. Я переписал прошивку так, чтобы устр-во каждую секунду передавало мне датаграмму(ту же).
И в этом случае программа читает данные правильно, но только пока не нажать "Запрос", после
первой же передачи функция SI_Read передает SI_READ_TIMED_OUT.

Но я опять не сдался. Я взял программный сниффер "Device Monitoring Studio" и посмотрел что же делает ПО
при попытке чтения. Оказалось, что отправляет посылку Function URB_FUNCTION_CONTROL_TRANSFER
и принимает такую же, но данных там даже близко нет.

В общем грабля. Такое впечатление, что канал работает только в одном направлении.
Что делать?

Олег

KBH-I · 01.08.2014, 15:19

Переходить на линукс.
Винде капец:
http://nauka21vek.ru/archives/58844

RECTO · 01.08.2014, 16:37

Сообщение от KBH-I

Переходить на линукс.
Винде капец

Капец тупым юзерам, которые читают спам и кликают по ссылкам. До сих пор не перестаю удивляться, что еще находятся такие идиоты... Линукс их не спасёт, он тут вообще ни при чём.

Извините, что не по теме...

niXto · 01.08.2014, 19:40

Так напишите по теме? Если знаете в чём причина

ksa_kiev · 04.08.2014, 18:10

Доброго дня!
А зачем Вы чистите буфера каждый раз? Это нужно при открытии хендла и все.
Вам же данные нужны полные. Выгребайте, а там уже ваше дело....
И еще - Вы уверены, что ваш проц что-то успеет выдать до момента чтения?

Посмотрите пример CP210xTestDlg.cpp и an169.pdf.
Что-то мне подсказывает, что DelayMS(60) они не напрасно делали.
При 19200 на 1 байт надо около 0.5 мс.

Применяете OVERLAPPED для обработки чтения и записи.
И обязательно контролируйте результат каждой команды. У Вас в коде этого и близко нет. Или Вы просто костяк дали.
Под Win применять линейный код - не реально.
Кто сказал, что каждая функция блокирующая и будет работать так как Вы этого хотите?

SI_SetTimeouts - по описанию обещает блокировать чтение на 100 ms, т.е. ожидать приема хотя бы чего-то.
А проц успевает отдать данные?
И если таки да, то что-то меня ОЧЕНЬ смущает Ваша постоянная очистка буфера.

По логике:
ret = SI_FlushBuffers(cyHandle,0,1);
ret = SI_Read(cyHandle,btDataCodogrammaIn,9,&dwBytesRetu rned);

Ничего не должно отдать, т.к. если проц успел отдать хотя бы 1 байт (0.5 мс), то ReadTimeout уже истек, а теперь вы очистили буфер приема и сразу читаете чистый буфер (и это время скорее всего менее 0.5 мс), а т.к. ничего нет в буфере - вы и получили ошибку. Просили 9 байт, а вернули вам 0. Тип ошибки - это уже можно додумывать что и как... А что в результатах возврата?
Никогда мне не нравились такие функции чтения.
Ни кто не обещал вам ждать 100 мс. Вам обещали, что 100 мс до прихода чего-то будут ждать.

Попробуйте использовать SI_CheckRxQueue(), как рекомендуют в SI_Read.

и сделать
status = SI_Open(dwDevice, &m_hUSBDevice);
status = SI_FlushBuffers(m_hUSBDevice, TRUE, TRUE);
и после этого забыть про SI_FlushBuffers...

alik_tv · 05.08.2014, 15:26

Сообщение от ksa_kiev

Доброго дня!
А зачем Вы чистите буфера каждый раз? Это нужно при открытии хендла и все.
Вам же данные нужны полные. Выгребайте, а там уже ваше дело....
...
и сделать
status = SI_Open(dwDevice, &m_hUSBDevice);
status = SI_FlushBuffers(m_hUSBDevice, TRUE, TRUE);
и после этого забыть про SI_FlushBuffers...

1. Да, я даю без обработчиков ошибок, чтобы не перегружать текст.
2. FlushBuffers не просто чистит буфер, но еще и принудительно передает данные буфера получателю данных. Насколько я понимаю.
3. Если я не вставлю SI_FlushBuffers после передачи, то успешно пройдет только первая передача, при попытке повтора получу SI_DEVICE_IO_FAILED.
Не знаю почему так.
4. SI_FlushBuffers перед приемом я поставил по аналогии с передачей. Но с ним и без него одна и та же ошибка - SI_READ_TIMED_OUT.
5. Так я делал, все также.
status = SI_Open(dwDevice, &m_hUSBDevice);
status = SI_FlushBuffers(m_hUSBDevice, TRUE, TRUE);

На остальные замечания отвечу позже, нужно время для проверки.

alik_tv · 05.08.2014, 16:03

Сообщение от ksa_kiev

И еще - Вы уверены, что ваш проц что-то успеет выдать до момента чтения?

Посмотрите пример CP210xTestDlg.cpp и an169.pdf.
Что-то мне подсказывает, что DelayMS(60) они не напрасно делали.
При 19200 на 1 байт надо около 0.5 мс.

Применяете OVERLAPPED для обработки чтения и записи.
Кто сказал, что каждая функция блокирующая и будет работать так как Вы этого хотите?

SI_SetTimeouts - по описанию обещает блокировать чтение на 100 ms, т.е. ожидать приема хотя бы чего-то.
А проц успевает отдать данные?
И если таки да, то что-то меня ОЧЕНЬ смущает Ваша постоянная очистка буфера.

По логике:
ret = SI_FlushBuffers(cyHandle,0,1);
ret = SI_Read(cyHandle,btDataCodogrammaIn,9,&dwBytesRetu rned);

Ничего не должно отдать, т.к. если проц успел отдать хотя бы 1 байт (0.5 мс), то ReadTimeout уже истек, а теперь вы очистили буфер приема и сразу читаете чистый буфер (и это время скорее всего менее 0.5 мс), а т.к. ничего нет в буфере - вы и получили ошибку. Просили 9 байт, а вернули вам 0. Тип ошибки - это уже можно додумывать что и как... А что в результатах возврата?
Никогда мне не нравились такие функции чтения.
Ни кто не обещал вам ждать 100 мс. Вам обещали, что 100 мс до прихода чего-то будут ждать.

1. У моего уст-ва максимальная задержка 5мс, на выдачу. 9байт это еще около 5мс. потому 100 мс это с большим запасом. Я ставил и 1с, голый номер.
2. То что функции и чтения и записи блокирующие я проверял.
Ставил SI_SetTimeouts 1с таймаут и проверял. Все замечательно блокируется.
3. Я пытался чтение производить из отдельного потока, но последние версии
SDK не поддерживают многопоточности. По крайней мере такую инфу я нашел на одном из форуме, вроде даже силабовском, точно не помню.
Кстати с какой версией SDK Вы работали?
4. Насколько я понял описание, таймаут до возврата стольких байт сколько задано прочитать в SI_Read.

alik_tv · 05.08.2014, 16:28

Сообщение от ksa_kiev

Попробуйте использовать SI_CheckRxQueue(), как рекомендуют в SI_Read.

написал так (как образец взял TestPanelModule.bas)

Код:

ret = SI_CheckRXQueue(cyHandle,&dwNumBytesInQueue,&dwQueueStatus);

while ((ret == SI_SUCCESS)&&(dwQueueStatus != SI_RX_READY))
     {
    ret = SI_CheckRXQueue(cyHandle,&dwNumBytesInQueue,&dwQueueStatus);
     }

ret = SI_Read(cyHandle,btDataCodogrammaIn,9,&dwBytesReturned);//,NULL);

В цикле замечательно виснет, как и должно быть. 0)

alik_tv · 05.08.2014, 18:42

Попробовал с SDK ver. 3.5.1
Без SI_FlushBuffers после SI_Write, запись работает только раз.
Во второй возвращает SI_SYSTEM_ERROR_CODE.
И похоже вешает драйвер т.к. нужно перетыкать уст-во.

SI_Read: и с SI_FlushBuffers и без - SI_READ_TIMED_OUT

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