ADM485 время задержки

[krik_nk]

Электрическая схема модуля показана тут http://www.mikroe.com/downloads/get/164 ... l_v202.pdf на 10 странице. Больше никаких элементов кроме соединительных проводов модулей нет.
В интернете тоже находил что люди делают задержки включения, но никто не поясняет почему и откуда они взяли их

[YS]

Вы абсолютно точно делаете что-то не так. Никакие задержки не нужны. Я лично работал с RS-485, в частности, делал сеть устройств на этой шине с использованием ST3485 в качестве драйвера физического уровня, и никаких задержек не применял - только ожидание окончания передачи. Все чудесно работало, как и должно работать.

Как бы это глупо ни звучало, проверьте самые очевидные вещи - что RO подключено к RX, DI - к TX, RE и DE соединены вместе и подключены к пину МК, назначенному для контроля прием/передача, который настроен на выход. В конце концов, проверьте, что на микросхему поступает питание. Высокоимпедансные цифровые входы вкупе с защитными диодами, паразитными емкостями и утечками иногда способны творить чудеса.

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

[akl]

Провел опыты и заметил, что в зависимости от скорости USART'а меняется и время необходимой задержки включения порта. К примеру:
100 baud = 16 ms,
150 baud = 4 ms,
200 baud = 3 ms,
400 baud = 2 ms,
1200 baud = 1 ms,
4800 baud = 0 ms,
9600 baud = 0 ms

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

Замечу, что скорости ниже 225 бод на ATmega32 и частоте тактирования 14,7456МГц из-за ограниченной разрядности UBRR не получаются.

[krik_nk]

akl, я это понимаю, поэтому я стал использовать кварц на 3686400. Тогда значение для UBRR в самый раз подходит. Забыл отписаться сюда.
Ладное буду думать, что там не то. Мне тоже кажется, что никаких задержек быть не должно, потому собственно сюда и написал.

[Alkul]

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

Никаких задержек точно быть не должно. Я реализую передачу пакета следующим образом - заранее формирую пакет в буфере передачи в ОЗУ микроконтроллера, организую переменную счетчика переданных байт и переменную, хранящую длину пакета. Для начала передачи я заношу 1 в счетчик переданных байт и записываю первый байт пакета в UDR. А дальше работает обработчик прерывания по передаче байта (USART TX). Обработчик вызывается после завершения передачи байта, сравнивает содержимое счетчика переданных байт и длину пакета. Если счетчик меньше длины пакета, то, используя счетчик переданных байт, как смещение относительно адреса начала буфера передачи, беру из буфера следующий байт, заношу его в UDR, инкрементирую счетчик переданных байт и выхожу из обработчика. Все. После передачи последнего байта обработчик вызовется еще раз, счетчик переданных байт при сравнении окажется равным длине пакета, на чем, собственно, передача и завершается. Если на переданный пакет требуется ответ, то именно здесь уместно переключить драйвер RS-485 на прием.

[krik_nk]

А кто-нибудь тут проводил тесты на таких маленьких скоростях как 100 бод, 300 бод ... до 4800 ? Потому что когда я тестировал на скоростях более 9600 там принципе задержки и нету получается

[YS]

Я работал на 38400 бод.

когда я тестировал на скоростях более 9600 там принципе задержки и нету получается

Хмммм, есть ощущение, что у вас переполняется какая-то переменная-счетчик (или даже какой-то аппаратный таймер), и от этого все проблемы. Правда, это не более чем предположение на правах тыкания пальцем в небо.