Имам следния проблем. Едно устройство което досега си бачкаше на RS232 под бозата. Сега се опитвам да го прехвърля на USB.

Проблема е че трансфера е много времево критичен. Скоростта е малка - 9600 бода, на 100 мс се прехвърлят по 11 байта в двете посоки (команда - потвърждение). Но е времево критичен, защото устройството иска потвърждение на всяка команда. А командите са твърдо фиксирани на 100мс. И ако в рамките на 100мс след неговия фрейм, устройството не получи насрещен фрейм, почва да бичи грешка в комуникацията.

Проблем с бозата нямам. Под RS232 компютъра отговаря в рамките на няколко милисекунди. С един куча марка USB-RS232 пак си работи добре.

Но като пробвах да го прехвърля на FTDI почнаха проблемите. Имам чувството че тоя тиквеник изчаква буферите му да се напълнят, а това явно трае повече от 100мс. И устройството ръга данни в FTDI -я , ама компютъра ги получава накуп, за съжаление .... твърде късно.

Засега го мъча под VCP драйвера. Пробвах да бъзикам настройките на големина на буферите, някакви таймаути, ама ефект никакъв. Някой сблъсквал ли се е с подобен проблем? Да се мъча ли с D2XX драйверите?

Явно след като кучата марка конвертор го може... някак си може. Имам чувството че понеже работи в Bulk mode, FTDI то чака да му се напълни минималния размер от 64 байта и така ми дава по 6 фрейма на веднъж.

като отвориш ControlPanel-System-Device manager-a за FTDI има един параметър Lattency правиш го 1 мс и това гарантира че през 1 ms ще си flush-ва буферите
иначе е така FT чака да се напълни буфера 4K или да размърдаш модемните линии и тогава пак прави flush

Ами не става. Дадох му 1мс..... подобри се малко, ама не много.....Като си дебъгвам PC апликацията и гледам че ReadFile ми връща повече от 11 байта. Което значи че някъде пак са се буферирали.....

Да не ти е хардуерен проблема ? Аз наскоро си правих един програматор с FTDI. Постоянно се глезеше и даваше грешки. Понеже развойната платка с FTDI я бях взел от опити на едни познати, се хванах за главата. Не знаех какво да правя. Оказа се че не са дали 31 крак(тест) на маса. Ама и в даташита го дават това с много малки букви в таблицата. Нещо такова да не е с някой друг крак ? Иначе FTDI си работи много бетонно.

Тц. Няма как да е хардуерен. Данните които получавам са верни, просто ми ги бави.

Проблема се оказа софтуерен бъг при мен. Сега имам друг проблем.

Когато инсталирам VCP драйвера в XP за първи път след като закача чипа, устройството си работи ок. Ако обаче го дисконектна и конектна отново - почва да ми връща яко грешки почти на всеки байт. Грешките са CE_FRAME и CE_RXPARITY. Най идиотското е че преди това съм сетнал че не ползвам parity. И това състояние е устойчиво - отварям, затварям порта, рестартирам апликацията, конектвам-дисконектвам, стари-нови драйвери... все тая. Оправя се само ако изтрия устройсвото от Device Menager и го опозная наново. И така до следващото откачане-закачане.

Някой да е имал подобни главоболия? Въобще някой работи ли с тоя чип с VCP драйвера. Аз досега съм го ползвал с D2XX и там нямах проблем (конкретната апликация още ме мързи да я преправям), но ми се искаше за това приложение да е под VCP та да е по лесно за юзера.

Всъщност проблема едва ли е в драйвера. Виждал съм купища хардуер и софтуер с този чип под VCP. Така че явно топката е в мойто наказателно. Ама това че като преинсталирам драйвера, работи до първото откачане ме озадачава. Поне да не работеше въобще.

Edit:
Хванах го и тоя проблем. Оказа се тъпо.... По принцип dcb.fParity = FALSE би трябвало да изключва проверката за четност. И на нормален com порт както и на кучата марка USB-RS232 наистина го прави (или поне работи видимо нормално). Обаче в dcb структурата освен този флаг има и BYTE Parity поле което трябва да сложа на NOPARITY за да работи стабилно VCP драйвера.

Според MSDN:

fParity
If this member is TRUE, parity checking is performed and errors are reported.

И аз съм решил че тоя флаг стига. Ама явно авторите на VCP драйвера са решили да гледат другото поле BYTE Parity, а не тоя флаг.