Доброе время суток.
Начал разбираться с работой RS232 через потоки в WinXP. Байты бегают из компьютера, на компьютер. Никак не могу определить момент, когда отослался последний бит посылки. Какие есть сигнализаторы?

Нету. Единственный вариант, если вы работаете в 485, это слушать сами себя. Других нету.

А смысл?
Есть эвент на последний байт пакета (буфер передачи пуст) и соответствующая функция АПИ
Вот все возможные варианты:
EV_BREAK Состояние разрыва приемной линии
EV_CTS Изменение состояния линии CTS
EV_DSR Изменение состояния линии DSR
EV_ERR Ошибка обрамления, перебега или четности
EV_RING Входящий звонок на модем (сигнал на линии RI порта)
EV_RLSD Изменение состояния линии RLSD (DCD)
EV_RXCHAR Символ принят и помещен в приемный буфер
EV_RXFLAG Принят символ заданый полем EvtChar структуры DCB использованой для настройки режимов работы порта
EV_TXEMPTY Из буфера передачи передан последний символ

Спасибо за наводку, буду разбирать

При использовании EV_TXEMPTY есть одна подлая особенность - то, что буфер пуст, не означает, что последний байт передан.
Поэтому, например, когда мне нужно было переключать направление в полудуплексном RS-485, я добавлял в конец пакета фиктивный байт, по опустошению буфера переключал направление (ногой DTR) и последний байт "улетал в пустоту".
Можно отсчитать паузу от эвента, но это дополнительная морока.

Какую задержку нужно выставить, пару милисекунд?
У меня тоже полудуплексный RS-485. Сделал так (без отслеживвания EV_TXEMPTY ):
поставил задержку после запуска передачи 10 мс, потом переключаю направление ногой RTS. Так не всегда успевает или все передать, или все принять. Добавил еще задержку 20 мс ответа в приборе. Пока помогло, но что будет на другом ПК, или если операционка еще что-то будет делать.
Это заставило поискать альтернаттиву.

Самый мне понравившийся вариант, это просто слушать сам себя. Принимать сообщение, которое уходит в линию. Как только декодировал отправленное сообщение, сразу вырубать передачу.

А если такой возможности нет?
Мне вот почему-то кажется, что должен быть режим, в котором DTR (Data Transmit) сам обозначает время передачи. То есть автоматически. Правда, глубоко в этом вопросе не копал, а наскоком сделать не получилось. Довольствуюсь ранее описанными костылями

Блин, у меня тоже похожая , но немножко другая "беда"...

Пишу сейчас маленькую "прогу" на Visual C++ , типа "оболочки". Программа обмена данными между
компьютером и МК. Получается интересная вещь. Программа работает нормально, обмен идет, но
стоит выключить "таргет" и включить его снова , как то-ли драйвер СОМ порта, то-ли сам СОМ порт впадает в интересный ступор. С компьютера все идет нормально, "таргет" на команды реагирует, только
вот отвечать перестает... т.е. отвечать то он отвечает, но моя программа не видит ничего.
Вывод из "ступора" происходит закрыванием моей программы, включением "терминала" и открыванием
а затем закрыванием СОМ порта.

использую библиотеку SerialGate.dll

там тоже имеются команды Открытия порта, Закрытия порта, Очистки буфера... но не помогает

Возможно библиотека "кривая", возможно я "кривой" но вот такая петрушка...

Может у кого ссылки есть на более продвинутые библиотеки+описание для Visual C++ ?

Это обычная реакция ПиСишного порта на брейк, который формируется при отключении устройства.
Это состояние нужно обрабатывать.

Вот., посмотрите.
Третья ссылка сверху - удобный ПДФ.
А потом решите, нужны ли ещё какие-то дополнительные обёртки к стандартному API

Каким образом ? И если не трудно объясните пожалуйста, что "там" происходит ? Я компьютеры на
аппаратном уровне программировал только под ДОС лет 15 назад...
Возможно и сам-бы разобрался, но у XP Вындоуз заморочки с прямым доступом к портам, отсюда
такие головоломки что приходится пользоваться чужими библиотекам...

пешыте на обшарпанном.
Коллега вот писает кипятком по поводу тамошних готовых классов.
Тем более всё равно в студии...

Это на "Шарпе" что-ли ? Вникать долго, да и смысла нет, я просто "оболочку" пишу, раз в 100 лет.

Вот нашел готовую библиотеку:

public:

enum IN_LINES_NAME {CTS, DSR, RING, RLSD};
enum OUT_LINES_NAME {DTR, RTS};

SerialGate();
~SerialGate();

bool Open(int port, int baud); // открытие порта
int Send(char* buff, int szBuff); // отправить
int Recv(char* buff, int szBuff); // получить
void SetLine(OUT_LINES_NAME ln, bool state); // установить линии
bool GetLine(IN_LINES_NAME ln); // получить состояние линий
void GetPortsInfo(PortInfo* pi); // проверка портов и их состояние
void Close(); // закрыть порт
void Clean(); // очистить буфер

Может я что не так делаю ?

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

За API функции конечно спасибо, но я в них "зароюсь", квалификация не та

У некоторых чипов UART (например, PCI-UART фирмы Exar) есть специальный режим работы, который называется "Auto RS485 Mode". Режим включается взведением бита в соотв. регистре, или через IOCTL драйвера. Суть режима в том, что он с помощью ножки RTS автоматически включает передатчик RS-485, с момента появления в передающем буфере данных до момента отправки последнего байта.
В стандартном 16550А такой возможности, насколько мне известно, нет.
P.S. Кстати, DTR - это не Data Transmitt ... это Data Terminal Ready, сигнализирует противоположной стороне готовность как раз принимать данные.

Да, в стандартном 16550А такой возможности нет,
но в 16550А совместимых(а это практически 100% современных ПЦ) есть возможность отсылать
не весь пакет, а пакет без последнего байта, при приходе TXEMPTY этого пакета
шлем последний байт, тогда следующий TXEMPTY придет только на стоповом бите последнего байта,
и нужно подождать только 1 бит перед переключением направления(на большинстве чипсетов можно
вобще не ждать т.к. стоп бит == неактивное состояние)
Единственно, это гарантированно работает только на уровне драйвера ядра(только что сделал так на линух),
в юзерспейсе, при сильной нагрузке, последний(отдельный) байт может "отрываться" от остального пакета.

По-моему, проблема слегка надумана. Если речь идет о передаче по RS485, то на выходе COM-порта (физического или виртуального) неизбежно стоит преобразователь RS232-RS485 либо USB-RS485. Все проблемы с преобразованием дуплекса в полудуплекс и обратно он должен брать на себя. В том числе и переключение драйвера RS485 c передачи на прием и обратно. Нормальные преобразователи успешно выполняют эту функцию самостоятельно, в автоматическом режиме. Перекладывать эту задачу (управление направлением передачи) на прикладную программу в ПК, на мой взгляд не совсем правильно. Точнее - совсем не правильно.

Какие нормальные ? для RS232-RS485 ?
ADM2483 например нормальный преобразователь ?

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

Это не идеальный вариант, а, как раз, обычный, нормальный и стандартный. Преобразователь - с одной стороны которого стандартный RS232, а с другой - стандартный RS485. И еще, желательно, гальваническая развязка между ними. Стандартный RS232 не предполагает специального сигнала для указания направления передачи, т.к. он полнодуплексный...

А каким способом Вы разделяете передачу, прием в полудутлексном режиме?

Вот здесь почитайте: http://www.ellab.ru/spravochnik/el203-1.pdf

Хорош способ, только мне не подходит, в преобразователь микроконтроллер ставить не разрешают.

Поищите по форуму темы о преобразователях RS232-RS485. Где-то предлагались и чисто аппаратные решения.

Простейшее решение - одновибратор с запуском от TxD. Правда, задержку придётся ставить максимальную, исходя из минимально возможной скорости.
Если снаружи попадётся какое-нибудь резвое устройство (или программа), то можно и граблями получить

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

С USB и чипом от ftdi у нас получилcя такой девайс: ссылка

с USB не так интересно, патамушто все понятно, у нас и USB <-> 3xRS485 есть

А вот про момент переключения интересно,
у @Ark по ссылке не очень понятно, поток пропускается через микропроц или нет ?
То есть там только руление переключением или и "буферизация" ?

Это вы разработчик этого девайса? Можно чуток покритиковать и его и документацию? Критика конструктивная. Может во благо будет и вы чего-то подправите.
Во-первых, на клеммнике нет 3-го провода для выравнивания потенциалов с другими точками подключения. Это чревато тем, что на большом расстоянии амплитуда синфазной помехи может превысить допустимые для драйвера RS485 пределы. Это в лучшем случае приведет к его неработоспособности. В худшем - при возникновении искровых или дуговых разрядов вблизи линии передачи (микросекундные помехи) пробьется изоляция DC/DC в конвертере.
Во-вторых, в документации указано

но нигде нет примечания по ограничению на применение последних двух параметров. Кто-то просто тупо списал параметры, не удосужившись их проверить (а чего же тогда не 3Мегабита?, ведь м/с FTDI позволяет) или хотя бы осмыслить. Вы сами-то понимаете, что в совокупности (одновременно) они не работают? Даже если вы применили очень хорошие драйверы RS485 (10Мбит или выше), то либо скорость Мегабит, либо расстояние километр, но не одновременно! Тем более, что судя по параметрам тока потребления и напряжения изоляции, внутри конвертера стоит дешевый нерегулируемый 1Вт DC/DC 5V-to-5V. И предельный ток потребления устройства также из даташита DC/DC списан, без реальной проверки на готовом преобразователе. Не нужно потребителя в заблуждение вводить.
В-третьих, а зачем в комплект драйверов входит хедер и либы? Предполагается, что пользователь сам будет сможет прикрутить конвертер к своей программе (к OPC-серверу, например)? Тогда где на странице продукта руководство по программированию? Будьте уж последовательны в своих намерениях. Выкладывайте полную документацию.
Я ни в коей мере не хочу "очернить" ваше устройство! Я указал на факты, которые просто сходу бросаются в глаза специалисту. Доведите до сведения людей вашей фирмы, отвечающих за разработку и продажу.

Да. Разработчик - наш сотрудник. Спасибо за хинт. Добавим третий клеммник COM или GND.

Скорость в один мегабит обусловлена максимальной скоростью изолятора. Мы всё прекрасно понимаем.
Это указаны (absolute maximum ratings), как говорится. Но Вы правы, в паспорте следует указать характеристики более подробно.
Драйвера идут от производителя ftdi "as is", и если в комплекте идёт либа - пусть идёт. Хлеба не просит...
А Вы мастер, докапаться и до фонарного столба сможете
А если серьёзно - спасибо за критику. Учту. Ваши предложения разумны.

PS. Для того, чтобы прикрутить конвертер к OPC-серверу и любой другой программе либа не требуется, т.к. разработчику доступно API операционной системы, в которой конвертер виден как ком-порт (это на примере ОС windows). Руководство по программированию берётся из руководства по API конкретной ОС. Ну а кому надо непосредственно работать с чипом как например Real'у с ft2232, то тот достаточно компетентен в этом вопросе и зайдёт на сайт производителя и самостоятельно найдёт себе требуемую документацию. Для 99,9 пользователей это не потребуется никогда в жизни.
PS2. Внутри конвертера стоит оптимальный по характеристикам DC-DC преобразователь. И за почти 5-и летнюю историю продаж было всего несколько гарантийных случаев, связанных в основном с непропаем, а продано уже боле 3 сотен таких приборов.
PS3. Все тесты на МИПы и НИПы данный прибор проходит на сертификационных испытания с успехом.

Должно быть дешевое.
А микроконтроллер это: пару деталюшек; разовая оплата программисту; постоянная оплата процеса программирования чипа.
На этом будут экономить.

Гляньте тут. Там схема с автоматическим переключением на любую скорость до 115200 на коротких линиях.
Вы так и не ответили, фиксированная ли у вас скорость? На фиксированную скорость одновибратор на время одного байта строится вообще на диоде, резисторе и конденсаторе как в схеме по ссылке.

Скорость от 1200 до 19200.
Тут еще такая заморочка: из прибора выходит 124 байта, ПК отлавливает только 120. Может где размер буфера СОМ порта явно указывается?

Кто знает? Существует ли нормы на Baud Rate Error для RS-232? Может есть какие-то упоминания в стандартах или в какой-либо документации? Либо это чито линый выбор....?

А просто подумать? За сколько набежит ошибка в половину (хотя это зависит от приемной стороны - приличные реализации контроллеров три сканирования на бит производят и соответственно треть бита) бита на Вашей конкретной посылке. Это соответственно будет абсолютный максимум.

В мануале на процессоры Atxmega (доступен на сайте Atmel) есть такой параграф:
20.8.3Asynchronous Operational Range
Там есть немного формул и рекомендуемые максимальные ошибки в скорости