[mdmitry 0]

вот утилита которой пользуюсь:

http://www.hw-group.com/products/hercules/index_en.html

 

ОС: WinXP

 

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

[DmitryM 0]

исходя из этого выходит ФТДИ просто не выполняет своей заявленной функции? (ну или конкретно все драйвера его корявые...)... хотя незнаю

Проблема может быть в терминале, который некорректно отрабатывает состояние RTS/CTS или вообще их не опрашивает.

Может быть в драйверах, но сильно сомневаюсь. Для FTDI можно настроить достаточно параметров, например, глубину буфера и таймауты по незаполнению буфера, и проч.

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

[BlackOps 0]

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3

CTS/RTS у них впрямь не работает как положено!

 

а именно:

"If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

 

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis."

 

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

 

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

 

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

 

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

 

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

[DmitryM 0]

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3

Не сходится про отправку ;)

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.

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

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

[Golikov 0]

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

 

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

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

 

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

 

 

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

 

UPD

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

 

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

 

[Сергей Борщ 119]

еще такой вопрос, для того чтоб стм32 использовал CTS/RTS мне достаточно ее только включить правильно и все? никакие биты в ручную проверять не нужно? (спрашиваю т.к. вижу из мануала что в ручную тоже можно CTS проверять)

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

и еще,запустил я сейчас ГиперТерминал, закоротил TX-RX, CTS-RTS выбираю файл на посылку небольшой и режим Xmodem как Вы упомянули, и ничего не отсылается..

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

 

а вот и то как ФТДИ это описывает: http://www.ftdichip.com/Support/FAQs.htm#HwGen3

CTS/RTS у них впрямь не работает как положено!

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

 

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

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

[vptr 0]

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

 

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

 

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

1-й вариант лучше.

2-й вариант не гарантирует стабильности или придется делать задержку большой, с запасом.

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

[Dopler 0]

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

[slavka012 0]

замкнул контрольные пины тоже, проверил, с контролем потока тоже самое(иногда пересылаются все 600 001 байт, а в основном конечноже не все)... это нормально?

 

разве когда этот FTDI кабель работает в режиме замкнутом - Эхо, и в режиме контроля потока он не должен ждать пока его буфера освободятся перед тем как самому себе вновь новые данные отсылать?

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

 

 

[Golikov 0]

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

 

FTDI переходник очень далек от аппаратного РС232...

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

 

 

[vptr 0]

Удивительные вещи народ рассказывает про компьютерный RS232. Наши приборы работают на скорости 921600, поток данных 500 кБит. Протокол с заголовками и контрольными суммами, конечно, есть, но он скорее привет из 90-х, чем жизненная необходимость.

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

Изменено 10 июня, 2013 пользователем vptr

[Golikov 0]

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

 

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

 

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

[vptr 0]

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

 

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

 

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

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx

Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.

Изменено 10 июня, 2013 пользователем vptr

[jcxz 184]

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

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

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

Можно. И можно много больше 921кбит.

Полностью согласен с Dopler - какие-то странные проблемы тут обсуждаются.

Работаю постоянно с COM-портами на высоких скоростях (до 921кбит иногда, а на 230кбит - так вообще у меня стандарт) во многих устройствах через разные переходники USB-RS232 и USB-UART(3.3V).

В переходниках есть и FTDI и CP2102 и др.

Проблем с потерями не возникает никогда. Вот сейчас передо мной два устройства работают на 460кбит и всё ок.

Ищите проблему в кривых терминалках (или при работе с Win-API) или в работе с портом на стороне микроконтроллера.

 

максимальная, которая указана сейчас 256000 http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx

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

 

Раньше, по интернету народ искал самописные драйвера для COM порта, которые на некоторых материнках даже работали и позволяли взять скорость выше чем 115200. Сам когда-то такой драйвер использовал, но работает он не на всех материнках.

Это справедливо только для UART-чипов на материнках и PCI-платах расширения. USB-переходники используют свой драйвер и какую он скорость поддерживает зависит только от него.

Есть USB-UART-переходники поддерживающие скорости больше 921кбит (и это вполне работает).

Переходники USB-RS232 (12вольтовые) как правило имеют меньший предел по скорости, чем USB-UART (низковольтные), хотя может это мне такие попадались.

У меня USB-RS232 на FTDI имеет предел в одну сторону 230кбит, в другую - 460кбит. На USB-UART(3.3V) я получаю стабильно 921кбит.

[Golikov 0]

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

 

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