Есть преобразователь RS232->RS485. Желание отказаться от использования линий RTS и CTS для выбора прием/передача привели к необходимости использовать МК, а именно AT89C4051. Все бы ничего, но вот скорости передачи могут быть из числа: 9600, 38400, 115200.
Проблема состоит в необходимости определения этой скорости, ибо от этого зависит время удержания управляющего сигнала прием/передача.
Собственные размышления приводят к сложным конструкциям с мутным результатом
Может кто сталкивался с подобным или просто есть мысли, буду рад помощи.

Перед началом передачи отправлять маркер (все 1) по которому можно выполнить настройку скорости передачи. Вот такое вот решение навскидку.

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

А почему не использовать преобразователь USB<-->RS-485 и не париться?

К сожалению возможности резервировать байт или посылать маркер нет, т.к. передаваемые данные давно определены и внесение изменений в их состав невозможно (взаимодействуют 2-е железяки). В этом-то и загвоздка...

Кстати, забыл сказать, используется протокол ModBus.



Задача стоит именно модернизировать существующее устройство, а не создавать новое. Т.е. RS-232<->RS-485, с автоматическим определением направления и скорости передачи.

Интересно - схемка с сайта rs485.com позволяет это делать без заглавных символов и на таймере 555.

Вообще-то, логика выбора не совсем ясна. Я без проблем использую AVR. Там в UART имеется специальный флажок завершения передачи, фиксирующий момент выдачи последнего бита из UART, когда сдвиговый регистр передатчика опустошается. После передачи последнего байта в пакете нужно просто подождать установки этого флажка и смело переключать драйвер RS-485 на прием. Этот флажок может формировать запрос на прерывание, чем я, собственно и пользуюсь.

Применение AVR не является возможным. Использование UART, видимо, было бы лучшим вариантом, но увы...

Сталкивались.
В данном случае джампера помогут :-)
Или использовать программно считываемые перемычки регилия не позволяет?
Или скорость меняется в динамике?

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

джампера - это уже не совсем автоматически получается

В одной сетке скорости обычно уже определены и необходимости автоматического определения baud rate нет. Исключение составляет какой-нибудь хитрож@пый мастер, который конвертором протоколов работает. Но поскольку у вас протокол один - modbus и ряд скоростей известен заренее я считаю, что городить конвертор интерфейсов с автоподстройкой baud rate это, извините, пижонство и ухудшение надежности работы сети. А если уж вы хотите сделать нормальный конвертор RS232<->RS485, то нужно чтобы он выполнял как минимум две функции.
1. задержка выдачи битового потока в линию RS485 на определенный интервал времени (для RTU >=3,5 символа) после переключения приемопередатчика RS485 на передачу
2. задержка переключения приемопередатчика RS485 на прием после передачи в линию (учитывая буфер битового потока) последнего символа (для RTU >=3,5 символа)
Из этих двух функций вытекает еще и наличие буфера для битового потока, который нужно контролировать с двух сторон - на входе конвертора (RS-232) и на выходе (RS485).

Задача "автобод" реализована во всех модемах и обсуждалась неоднократно в том числе на данном форуме. Я реализовывал, и по моим подсчётам необходимо примерно 7 мипсов для скорости 115к. Для получения достоверной информации. (т.е. рекомендую поставить 2313 для данной цели) Сам протокол MODBUS явно предназначен для rs485, так как в начале посылки указывает свою длину, что позволяет при перехвате посылки высчитать время для переключения. Существуют также различные схемы для автоматического перехода по таймеру. (Типа если не пришла "1" хх мс, то переключить.)
А вот ещё идея на вскидку. Можно сделать задержку. (Для этого вовсе не требуется вообще распознавать данные. Что пришло, - то ушло) Т.е. принимать все данные и передавать их с задержкой. Если за время задержки данные не пришли, то можно на передающей переключить.
Ещё один момент. Применение сигнала RTS для данной цели, по моему, фактически стандарт. Чем Вас данное решение не устраивает?

Вообще, можно и без микроконтроллера, если допускается достаточно большой таймаут на линии: RC-цепочка с Rout 232-го + триггер Шмитта выходом на DE приемопередатчика 485. Запускается от старт-бита. Сам не пробовал, но видел тех кто видел тех кто пробовал Видимо пост. времени надо выбирать в 1.5 - 2 раза больше длительности передачи байта на самой низкой скорости.
Если все же с МК, то вот http://focus.ti.com/lit/an/slaa215/slaa215.pdf. Рекомендую, может поможет чем-нибудь.

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

Элементная база основана на том, что есть на складе, поэтому AT89C4051 и другого не дано Мне бы по программе советик другой. Джампера-это конечно хорошо, но...

???<<Применение сигнала RTS для данной цели, по моему, фактически стандарт. >>

Спецификация на RS485 допускает и не использовать RTS.В этом случае в схеме адаптера для
согласования скоростей используется одновибратор на 155АГ1,3 или подоб.
Я почитал вы отклоняете все предложения.Уточните , что возможно у вас изменить?

Уже существующий преобразователь RS232<->RS485, а это фактически 2-е микросхемы - драйверы RS232 и RS485 гальванически развязанные между собой и по питанию, необходимо избавить от сигнала RTS, для чего необходимо применить МК AT89C4051. Особых проблем с одной скоростью не возникло - достаточно поймать стартовый бит на входе внешнего прерывания и удерживать сигнал передачи в течении времени, равном длительности одного кадра. Однако автоматическое определение скорости создает определенные проблемы, идеи есть, но они вносят либо избыточность в передаваемые данные в виде дополнительных кадров, либо в схему устройства, что крайне не желательно.

Тема преобразователей RS485 <-> RS232 с автоматическим определением скорости очень стара, вряд ли получится придумать что-то новое.

Может это поможет.
Только чтобы этот преобразователь работал необходимо обязательно подтягивать A и B. При скорости 2мбит этот преобразователь у меня вполне нормально работал подтяжки ставил по 620Ом.

Принцип работы преобразователя прост. Приёмник включён всё время, передатчик включается только если передаётся 0. Т.о. если передаём 1 передатчик выключен и на шине 1, которая формируется подтяжками, если передаём 0, включается передатчик и передаёт на шину 0. Т.о. можно исключить конфилитные ситуации на шине и исключить необходимость использования сигнала rts.
Т.к. приёмник включен всё время, мы можем принимать то что передаём и следить чтобы наши 1 никто 0 не давил! Собственно всё вышеописанное реализованно в CAN интерфейсе.

Забыл добавить 5 ножечная микросхема это просто инвертор. Который при передаче 0 включает DE, а при передаче 1 выключает.

Если в устройствах (slave) реализована настраиваемая пауза перед ответом, то сделайте постоянное время удержания DE и не заморачивайтесь вы с этим автоматическим определением скорости передачи! Т.е. как уже и предлагали - перезапускаемый одновибратор, запускаемый от перепада 1->0 на TxD (RS232) , который генерирует импульс управления передатчиком RS485 длительностью соответствующий 3,5 символам на минимальной скорости передачи 11/9600*3,5>=4мс.
Если же пауза перед ответом в слейвах не реализована (встречались с таким в не некоторых устройствах), то это вообще ИМХО тупик.
P.S. кстати, в конверторах RS485<->RS232<->RS485, которые мы выпускаем, реализована и буферизация битового потока и задержка переключения DE на прием. Обе задержки рассчитаны на одинаковое время: режим 1 - 1.5 символа и режим 2 (RTU) - 4 символа. Но, к сожалению, выбор скорости у конвертора определяется положением SMD-switch.

А почему мой вариант не подходит, мои устройства и с задержкой и без работают и на разных скоростях, с одной и той же схемой! Вы наверное говорите не просто о преобразователях интерфейса rs232 в интерфейс rs485, а о преобразователях протоколов обмена. Требуется вроде преобразовать один интерфейс в другой или я чего-то недопонял...

Никакой не преобразователь протоколов, а именно конвертор RS232<->RS485. Потому что при указанной реализации (перезапускаемый по срезу одновибратор или аналогичная по функционалу схема) задержка отсчитывается от последнего фронта, а этот фронт может быть как последним битом символа (или битом четности) так и стартовым битом. Следовательно неточность интервала удержания DE может достигать 0,9 символа. У нас в практике организации сетей сбора данных встречались устройства (сторонних производителей) которые на любой скорости начинали отвечать через 1мс, хоть застрели их. Сами понимаете, что при задержке переключения передатчика RS485 в 3,5 символа (+ 0,9символа), например на скорости 9600, такие устройства выдавали пакет в линию раньше, чем у мастера (или у конвертора) отключался передатчик. При управлением драйвером RS485 с помощью RTS эти устройства вообще не работали. Видимо их разработчики рассчитывали на дуплексную связь и не предусмотрели возможность подключения к полудуплексному интерфейсу RS485.

P.S. я не утверждал, что ваша схема не рабочая. Такие схемы известны и многие фирмы их делают. Однако это все же "настольный" вариант конвертора, который не будет устойчиво работать на длинных (сотни метров) линиях связи да еще и в каких-нибудь условиях сильных помех. К тому же вопрошающему нужен гальваноразвязанный конвертор.

Замечание: Очень полезно при передаче 1 тоже включать передатчик, но на очень короткий промежуток времени (~50% бита на макс. скорости) для быстрой перезарядки емкости линии. Прилагаемая схема делает это и плюс давит эхо. Работает до 115200 без всяких настроек скорости и процессоров. Растяжки, конечно, обязательны.

у меня гальваноразвязанный и нарисован, с использованием adm2483.
линия была конечно не 100метров и более, а всего 30, но скорость 2мбит, и использую свои девайсы на станках в настоящем цеху.


Так вот я и понять не могу откуда может взяться задержка. В приведённой мною схеме и в более правильной схеме Сергея Борща, каждый из девайсов переключает приёмопередатчик самостоятельно и то в момент передачи, какие могут быть задержки? Я понимаю задержки распространения сигнала в длинной линии есть, но как они повлияют на переключение в указанных выше схемах?

Тип м/с на схеме не указан, а сам я не догадался

Это я не про вашу схему, а про реализацию, которую я описывал выше.

Задержка распространения - почти никак. Но вот нарастающий фронт сигналов (A+, B-) на длинной линии может оказаться довольно пологим. Драйвер RS485 как минимум 30мА дает выходной ток, а ваша растяжка линий порядка 3-4мА.
В общем вкратце суть такова, что все эти ухищрения с задержками нужны для того, чтобы помеха, возникающая (или имеющая ненулевой шанс возникнуть) при подключении (отключении) выходного драйвера RS485 к (от) линии передачи не попала в пакет RTU и не испоганила его. Для этого после подключения выходного драйвера RS485 нужна пауза не менее 3,5 символов (пауза тишины, означающая конец пакета RTU) и на такое же время удержание драйвера RS485 в состоянии вывода после окончания передачи пакета. Если вероятность возникновения помехи от переключения линии низка (например, короткая линия), то на эти задержки можно вполне наплевать и использовать предложенную вами схему.

Ооо! Ребята! Спасибо огромное за помощь! Я так понимаю, что вышеуказанный метод, проиллюстрированный 2-мя схемами, действительно работает. Это реально упрощает схему, избавляет от необходимости использования МК.

Как приятно получить чёткие ответы (и множество) на вопрос который стоит передо мной, но я его не задавал.
А я с RTS воюю. На Delfi проблемы с формированием задержки. У меня правда плюс. Я делаю и то и это. Ну а под своё изделие я уж как-нибудь подстроюсь.

Кстати может у кого грамотный компонент есть для Delfi под COM порт.

Грамотный это как?
Вот посмотрите мой компонент Klientservcomconnect . Грамотный он или нет не мне судить, но может быть пригодится. В комплект входят примеры и хелп. Кстати будет интересно ваше мнение о возможностях компонента.

В качестве драйвера RS485 использую MAX487. На выходе A сигнал нормальный, а вот на B, вместо инверсии A присутствует сигнал повторяющий A, но с гораздо меньшей амплитудой. В чем может быть дело?

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

Схема собрана по образу и подобию вашей. Дело значит обстоит так (в пред. посте я перепутал): на выходе A сигнал очень слабый и представляет собой инверсию входного, сигнал на выходе B повторяет сигнал на A, но с нормальной амплитудой.
Растяжки стоят в соответствии с вашей схемой.

Если вы запамятовали, то напоминаю, что сигнал на выходе драйвера дифференциальный и наблюдать его нужно не относительно GND, а непосредственно между сигналами A и B. Например, на сигнал A щуп осциллографа, а на сигнал B землю щупа осциллографа. При лог.1 на входе драйвера на выходе должно быть A > B, при лог. 0 на входе B > A.

Да нет, я не забыл, просто запутался

Схема нормально работает на 9600 и 38400, однако на на 115200 проявляется потеря данных ~10%.

Все, зарубили идею, а ведь почти получилось Для переключения использовать МК - распоряжение начальства. Теперь все с начала...

Зачем сначала :-) диод-резистор-кондер заменяются на MK :-)

До тех пор пока не разберется с длительностью фрейма - изображает одновибратор. После разборок
- чеко управляет передатчиком.

Конечно есть, еще с 3-ей Дельфи
поиском нашел свежую ссылку:
TurboPower Async Professional
http://sourceforge.net/projects/tpapro/

Класс, а чего ж тогда Вы вопрос задаете именно в этом форуме? Есть ведь и другие..

По сабжу, надежней чем "кондер-резистор-диод" Ваш конвертер с C4051 не станет. Если уж МК так почему именно такой плохой выбор? Ведь и AtTiny11/12/13, PIC12F625 запросто справятся с тривиальной задачей формирования задержки в N ms. А для того чтобы разрешить ваш вопрос достаточно удерживать линию в состоянии передачи не долее чем реакция вашего "отвечающего" девайса (вот это и как раз и будут те самые N ms).

Да, с выбором контроллера вы определенно правы На 9600 работает четко, на 38400 - через раз, а вот на 115200 вообще отказывается. Судя по осцилограмме, просто не успевает переключаться в начале, до начала информационного бита, и съедает его добрую часть. Дальше по пакету все нормально.

Правильнее сказать, не на Delphi проблемы с формированием задержки, а под Windows. Можно формировать так:

var
HighT:Double; //Hi-res. timer period, uS

procedure CalibT;
var F:Int64;
begin
QueryPerformanceFrequency(F);
if F=0 then F:=1;
HighT:=1000000.0/F;
end;

procedure Delay(Tm:Integer); //uS
var F1,F2:Int64;
begin
QueryPerformanceCounter(F1);
F1:=Round(F1+Tm/HighT);
repeat QueryPerformanceCounter(F2) until F2>F1;
end;

Но все эти программные задержки под Win на уровне юзера - фикция. Вставьте царапнутый CD в привод и наслаждайтесь полным зависоном десяток секунд

Что касается RTS, то в Async Professional под не-NT Win он переключается по концу посылки, который определяется прямым чтением регистра UART. Под NT Win используется режим RTS_TOGGLE, реализованный в стандартом драйвере COM-порта. Только работает он тормознуто.

Я недавно экспериментировал с этим - получал вроде бы гарантированную задержку по переключению RTS. Если применик держать все время в работаюшем положении а после передачи фрейма сразу же принимать данные то по окончанию последнего байта можно и деактивизировать RTS.
Во всех посылках байта переключение rts случалось по концу посылки без 50 миллисекундной неопределенности виндоза (посредством esccommfucntion ). Можно и по таймингу делать - но момент начала передачи байта железкой неизвестен .

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

А как узнать момент окончания передачи последнего байта?

Сам правда не пробовал, но в FTDI чипах USB-COM есть специальный аппаратный управляющий сигнал для переключения передатчика... По моему - самое простое решение. И питать 485-ый драйвер есть чем...

Если кто знает, посоветуйте пожалуйста толковый компонент под С++ Builder 6 или Delphi 7 для работы с COM портом

Использовал "TMS Async32". Впечатления положительные.
http://www.tmssoftware.com/

В FTDI есть. Но речь шла о COM-порте, а не о USB. Как там?

Ну начальство можно и убедить или в крайнем случае слегка обмануть Просто если делать на МК необходимо будет и протокол несколько переписать. Перед началом обмена передавать несколько синхронизирующих байт по которым ваш МК определит скорость с которой будет вестись передача.
Или добавить в протокол команды для МК, которые будут передаваться всегда на фиксированной скорости, и в них указывать скорость с которой будет вестись передача.

На сотнях метрах и больших скоростях я схему без контроллера не пробовал, но на 30метрах 1мегабит с растяжками по 690Ом будет работать 100% в условиях помех(у меня сейчас под 100 реле без искрогасящих цепочек и электродвигатель на 3кВт). Я смотрел сигналы до 485 и после линии и 485
задержки конечно есть но всего порядка нескольких процентов. Реализовать эту схему гораздо проще и быстрее.
Неужели ваше начальство не может вам лишние два часа выделить, чтобы вы во всём до конца разобрались?

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

Кстати если сигнал просаживается хоть МК ставьте хоть ещё один PC всё равно будет криво работать!
Проверить работоспособность всей линии в целом можно следующим образом:
сигнал до передающего 485 должен совпадать с сигналом после принимающего rs485.

На этот счет где то в msdn прочел что надо разговаривать напрямую с драйвером. Посмотрел IOCTL коды примера из ДДК и не нашел ничего подходяшего. Наверно плохо искал.
Вроде бы два других варианта есть (первый проверил и как будто ничего):
- в полудуплексе rs484 держать прием все время активным так что любой переданный из pc байт будет принят . После передачи последнего байта
начинать прочитывание rx буффера и по последнему байту переданного сообшения сбрасывать rts.
- второй вариант немного кривоват - измеряется количество байтов в посланном пакете , пакет посылается и сразу же стартует таймер (надо изпользовать мултимедийный - он дает 1-3 миллисекунды разрешения нежели другие). По таймауту - сбрасывать rts. Кривизна этого метода заключается в том что неизвестно точное время начала передачи пакета .

PerformanceCounter даёт еще лучше разрешение - обычно не хуже микросекунды. Но что толку? Пожалуй, единственным приемлемым решением является использование режима RTS_TOGGLE, а в подчиненном устройстве делать задержку перед передачей ответа в PC.

Работать должно на расстоянии до 1024 м., для того чтобы использовать схему без МК, потребуются длительные испытания ее работоспособности.
Да, МК - это конечно не самое простое решение, но все же в данном случает другого ничего не остается, так что придется выкручиваться. Идеи есть, но вот только на выбранном ранее МК реализовать их не получится, что не может не огорчать. Причиной этому, как показала практика, оказалось время реакции на внешние прерывания, которое оказалось больше периода сигнала на скорости 115200, в рез-те чего "съедалось" нало слова. На 9600 все работало устойчиво, а на 38400 - с переменным успехом. Это что касается идеи, когда сигнал на передачу устанавливается с началом фрейма и удерживается на время его прохождения.
Если говорить о варианте использования МК в качестве буффера, т.е. принимая передаваемые данные и "выплевывая" их затем в линию, используя 3-й режим UART, со скоростью, задаваемой таймером, то тут опять же облом, т.к. обеспечить скорость 115200 при частоте кварца 24 МГц при помощи Т1 просто невозможно. Для таких скоростей надо использовать Т2, который в 4051 просто отсутсвует, поэтому пришлось переходить на 8252.