Элементная база основана на том, что есть на складе, поэтому 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-мя схемами, действительно работает. Это реально упрощает схему, избавляет от необходимости использования МК.

Сообщение отредактировал _VoRoN_ - Jul 27 2006, 21:10

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

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

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

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