У Вас скорость 115200. У нас была проблема с терминальной программой (ZOC) при работе на такой скорости при непрерывном потоке данных.При использовании Realterm проблем не было, но нельзя было одновременно выводить данные в лог файл и на терминал. Банально не успевал компьютер. Наблюдалось на win xp и win7. Похоже на проблему с драйвером COM-порта. Проблемы были и напрямую с портом (честный RS-232c), и через переходник на USB.

Проблема может быть в терминале, который некорректно отрабатывает состояние RTS/CTS или вообще их не опрашивает.
Может быть в драйверах, но сильно сомневаюсь. Для FTDI можно настроить достаточно параметров, например, глубину буфера и таймауты по незаполнению буфера, и проч.
Например, в системе используется ping-pong, так вот при значении по умолчанию - буфер 1024, скорость передачи/приема очень малая - буфер полностью не заполняется и прием/передача только по тайм-ауту, уменьшение буфера до минимального значения (64) и тайм-аута до 2мс (1мс для некоторых устройств приводила также к замедлению) значительно повышает скорость обмена (400 байт/с -> 2800 байт/с). Поиграйтесь этими настройками Com-порта (в винде дополнительные параметры). Также там есть и реакция на RTS/CTS, что то про неактивность, счас проверить возможности нет.

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3
CTS/RTS у них впрямь не работает как положено!

а именно:

это думаю все и обЪясняет, правда данная ситуация описывала вариант где ФТДИ отправлял данные прибору, но думаю аналогичное тогда будет верно и в обратном случае.

Побродил по форумам Silabs, увидел аналогичную тему тоже, и аналогичное описание проблемы с CP2102.

Так что, мне кажется тут два пути:

1) усложнить отправку и протоколизировать как вы сказали

2) просто добавить задержку после отправки скажем каждых 256 байт с СТМ32, в конце концов все эти побочные эффекты из-за того что переходник не может принять быстрый поток байт, т.е. просто сделать поток медленным должно сработать.

Не сходится про отправку
If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.
If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.
RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

Вот это надежнее

странно это вообще...

неужели если это переходник подключить к порту компьютера и на порте подергать CTR RTS они не появятся на выходе ФТДИ?
Раньше вроде бы появлялись, мы ими питание организовывали для всяких мелких платок... Или там какая-то комбинированная логика, и данные сигналы появляются и когда на порту они есть и когда ФТДИ хочет?

Проверьте пожалуйста, если дергать сигнал порта (тот терминал что я приводил может делать это отдельно от передачи) они появляются на выходе ФТДИ или нет? И сотвественно дерганья ножки ФТДИ появиться на порте?


Протокол всяко надежнее, кто его знает как оно потом будет? Смените носитель или помехи на усб будут... А протокол он навека

UPD
Понятно, теперь все подругому. По описанию получается что если вы на компьютере выставите бит что данных больше не надо, этот бит не появиться на выходе ФТДИ, до тех пор пока не забьется буфер ФТДИ. То есть теперь его нельзя использовать как управление в передачи без контроля данных.

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

Да, должно быть достаточно включить и правильно настроить. На то оно и аппаратное управление потоком.
Читайте описание протокола xmodem. Принимающая сторона должна сообщить о готовности принимать посылкой символа 'C'. Посылайте не через xmodem, а как текстовый файл (Transfer->Sent text file). Можете одновременно записать принятое в файл (Transfer->Capture text) и сравнить с отправленным.

Все там нормально. Данные не теряются - просто после выставления RTS она может выплюнуть еще несколько байтов. Выплюнуть, но не потерять. Так делают многие УАППы и никому это не мешает - приемная сторона выставляет RTS заранее, когда в ее приемном буфере есть место более чем на один байт.

А разве можно делать как-то иначе?

1-й вариант лучше.
2-й вариант не гарантирует стабильности или придется делать задержку большой, с запасом.
У нас была похожая проблема. Гоняли по RS232 на 115200 каждые 5 мс 54 байта. Пакет был с контрольной суммой и заголовком. Так вот чтение этого пакета на компьютере, без потерь, могло зависеть от всего - число запущенных программ в виндос, скорости компьютера, приоритета потока в котором читается ком порт. На новых компьютерах потерь не было, на старых как повезет. Еще зависит как организовано чтение на компьютере, при использовании C#, на старых машинах возникает больше проблем.

Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость. Я уже и не припомню, когда последний раз данные на компьютере терялись. Достаточно только установить правильный размер приемных буферов и таймауты. Можно ли это настроить в терминалах я не знаю, а через API функцией SetupCom (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363439(v=vs.85).aspx). На C# размер буфера тоже задается. Т.е. надо просто взять нормальный сканер COM-порта, и проблемы буфера Windows пропадут.

переполняется скорее всего буфер не компа, а чипа фтди, во всяком случае в варианте эха без flow-control.

FTDI переходник очень далек от аппаратного РС232...
как минимум усб не фул дуплекс, а также там есть драйвер, который тоже весьма странно работает. Вроде разобрались что контроль потока ФТДИ должен устранит переполнения буфера внутри микрухи. Я грешу на драйвер...

А когда в компьютере стандартный COM порт стал штатно поддерживать скорость 921600? И как же разбирать синхронизировать и гарантировать целостность данных без привета из 90-х

Сообщение отредактировал vptr - Jun 10 2013, 11:55

может у них 2090-ые, параллельная реальность...

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

а я вот вспоминал вспоминал, так и не вспомнил, можно задать что-то больше 115200 когда инитиш порт через вин-апи или нет, эх...

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx
Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.

Сообщение отредактировал vptr - Jun 10 2013, 20:43

Можно. И можно много больше 921кбит.
Полностью согласен с Dopler - какие-то странные проблемы тут обсуждаются.
Работаю постоянно с COM-портами на высоких скоростях (до 921кбит иногда, а на 230кбит - так вообще у меня стандарт) во многих устройствах через разные переходники USB-RS232 и USB-UART(3.3V).
В переходниках есть и FTDI и CP2102 и др.
Проблем с потерями не возникает никогда. Вот сейчас передо мной два устройства работают на 460кбит и всё ок.
Ищите проблему в кривых терминалках (или при работе с Win-API) или в работе с портом на стороне микроконтроллера.

На то что написано в свойствах порта в винде можете вообще не обращать внимание.


Это справедливо только для UART-чипов на материнках и PCI-платах расширения. USB-переходники используют свой драйвер и какую он скорость поддерживает зависит только от него.
Есть USB-UART-переходники поддерживающие скорости больше 921кбит (и это вполне работает).
Переходники USB-RS232 (12вольтовые) как правило имеют меньший предел по скорости, чем USB-UART (низковольтные), хотя может это мне такие попадались.
У меня USB-RS232 на FTDI имеет предел в одну сторону 230кбит, в другую - 460кбит. На USB-UART(3.3V) я получаю стабильно 921кбит.

через драйвер или как виртуальный ком порт?

А у меня вопрос нафига рс232 так гнать? есть же усб и прочие?