Не доходит концовка посылки от прибора через FTDI232 Опции

[firstvald]

Хотя что - то подобное в нескольких темах видел - точно такого - нет.

Вижу: при обмене (запрос ответ) через FTDI232RL происходит потеря окончания посылки ответа от прибора. Причем посылки-то небольшие : байт по 16.
Игры с настройками тайм-аутов и величины буфера вообще никак не влияют. Данные от машины в сторону прибора доходят без ошибок. В передаче в сторону машины время от времени не хватает нескорльких байт в конце.

По статистике получается самой плохой скорость 19200, на ней бъется в среднем каждый 50 цикл. На других скоростях сбой примерно раз в 200-300 циклов (и от скорости не зависит). Обмен редкий - цикл в секунду.

Кто какую статистику получал? Какую микруху понадежнее использовать? Насколько подвержено этому 2102/3?

[firstvald]

Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то.

То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать?

[galjoen]

Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то.

1. USB - это последовательный протокол.
2. Жёсткие времянки д.б. возложены на контроллер.
3. Появление USB в компе - наоборот прорыв на новый уровень. USB-шные флешки тому пример. Другое дело, что люди в силу своей костности этого не замечают или не хотят замечать. Или скрывают т.о. своё незнание/неумение.

Я делаю свои девайсы подключающимися в USB как составное устройство HID+MassStorage. Это позволяет челу, который никогда не видел мой девайс и не знал о его существовании сразу начать с ним работать - воткнуть в USB и всё.
При этом появится окошечко с файлами (MassStorage), среди которых будет pdf-ка с описанием, исполняемый файл (exe-шник) для работы с моим девайсом и лог-файл, в который мой девайс складывает данные при работе без компа. Запустив exe-шник можно просмотреть лог, настроить мой девайс (через HID), а при подключении к объекту поуправлять и пополучать данные в реалтайме. Всякие модбасы, CAN и т.п., где нужны времянки, естественно формируются в моём девайсе.
При этом чела не заставили устанавливать никакие драйверы, не задали ему ни одного вопроса, не заставили выходить в инет, вводить коды активации и т.д. и т.п. И вообще у него не возникло никаких вопросов. Точнее возник только один - а почему другие так не делают?

То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать?

FTDI и т.п. переходники, на мой взгляд вообще не имеют права на жизнь. Ни одного преимущества у них нет. Та же FTDI вначале позиционировалась как временное решение. Но нет ничего более постоянного, чем временное...

[jorikdima]

FTDI и т.п. переходники, на мой взгляд вообще не имеют права на жизнь. Ни одного преимущества у них нет. Та же FTDI вначале позиционировалась как временное решение. Но нет ничего более постоянного, чем временное...

Когда на МК нет ЮСБ или же обмен данными через ЮСБ настолько прост (малые объемы данных), что не хочется тратить время на реализацию ЮСБ в МК, а пользоваться UART, почему бы и нет???
Эти переходники довольно активно используютсявразличных приборах.