AVN 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба У MSP нет прерывания по опустошению сдвигового регистра, как у AVR. Каким образом мне поймать момент опустошения сдвигового регистра, чтобы переключить направление передачи? Сделал по таймеру, но в этом случае отправляется лишний байт и как-то не нравится такое решение. Кто может что-то предложить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 21 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба Сделал по таймеру, но в этом случае отправляется лишний байт и как-то не нравится такое решение. Кто может что-то предложить? Не понял: откуда берётся лишний байт? Прерывание есть по опустошению передающего буфера, от него можно отсчитать таймером длину байта и переключать. Вполне нормальное решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVN 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба Решение, похоже, единственное за неимением других способов, а лишний байт появляется из-за того. что трудно синхронизовать интервал таймера с длиной байта. Почему-то проскакивает стартовый бит. Или теряется предыдущий байт. Парился долго, но без этих накладок не удалось сделать. Правда, это несущественно для моей задачи. Наверное, так и оставлю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 21 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба трудно синхронизовать интервал таймера с длиной байта. Непонятно. Даже на скорости 115200 длительность битового интервала около 10мкс, (несколько десятков тактов). Задержку можно взять с запасом. Почему-то проскакивает стартовый бит. Или теряется предыдущий байт. Значит, слишком рано переключаетесь. Или лишнего в буфер кидаете. Если буфер пустой, никакой передачи (и соответственно стартовых битов) быть не должно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shasik 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба Не понял: откуда берётся лишний байт? Прерывание есть по опустошению передающего буфера, от него можно отсчитать таймером длину байта и переключать. Вполне нормальное решение. TXBUF пустой, срабатывает прерывание, что готов к передаче следующего, а сдвигающий регистр еще молотит и UART еще продолжает передавать (TXEMP еще не выставлен). Поэтому если отсчитать интервал в длину байта с момента опустошения TXBUF, то можно потерять "кусочек" байта. Может в этом затык? Если не угадал, то приведите свой код, а то не все умеють гадать по звездам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба Не нужно стремиться включать драйвер как можно быстрее. Если у вас разрабатывается поддержка сетевого устройства, а не "настольный" вариант конвертора, то предвосхищая трудности стыковки в одной сети вашего устройства с устройствами других производителей, следует заложить в реализацию настраиваемые задержки. 1) задержка между переключением драйвера RS485 на передачу и началом передачи 2) задержка после окончания передачи, перед переключением драйвера в режим приема. Еще раз подчеркиваю, что это должны быть настраиваемые пользователем задержки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vesago 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба В UxTCTL вродеж есть TXEPT. По крайней мере я его пользовал. Посмотрите мои дровишки - там есть функция USART0_Shift_Reg_Control() я ее когда нужно полю для переключения. Недостаток моей реализации - отсутсвие задержки >=1млс после опустошения сдвигового регистра - забил тогда. usart0_2008_08_07_140125.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба В UxTCTL вродеж есть TXEPT.TXEPT тоже не подходит. Он устанавливается одновременно с выдвижением из сдвигового регистра на вывод TXD последнего бита. Нужно после установки TXEPT делать паузу как минимум на один битовый интервал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shasik 0 7 августа, 2008 Опубликовано 7 августа, 2008 · Жалоба TXEPT тоже не подходит. Ну, отчего же?.. Я просто предположил, что аффтор путает момент возникновения прерывания передатчика с реальным моментом окончания передачи, отсюда и нестыковки во времени. А TXEPT может помочь в расчете момента, когда можно переключать направление. Прерывание передатчика тоже может помочь, главное не путать их местами. Другое дело в ту ли сторону мы копаем. Пусть аффтор, уточнит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба Ну, отчего же?.. Я просто предположил, что аффтор путает момент возникновения прерывания передатчика с реальным моментом окончания передачи, отсюда и нестыковки во времени. Ясно что не понимает. Причем не столько в таймингах, сколько в организации буферов. Как может "отправляться лишний байт", если буфер выделенный для передачи пуст? Откуда он вообще попал в буфер передатчика это "лишний" байт? UART ведь сам по себе ничего не передает. Может в очередной раз нужен пример организации линейных или циклических буферов? :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба 2) задержка после окончания передачи, перед переключением драйвера в режим приема. Еще раз подчеркиваю, что это должны быть настраиваемые пользователем задержки. А это зачем? ИМХО, что чем быстрее устройство отпустит шину после передачи, тем лучше. Какие могут быть причины задерживать момент отключения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 21 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба А это зачем? ИМХО, что чем быстрее устройство отпустит шину после передачи, тем лучше. Какие могут быть причины задерживать момент отключения? Переходные процессы в линии Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба Переходные процессы в линии Для их подавления служит задержка перед началом передачи. А смысла в задержке по окончании передачи я не вижу никакого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба Для их подавления служит задержка перед началом передачи. А смысла в задержке по окончании передачи я не вижу никакого. Для RTU-ных протоколов связи, в которых конец пакета отслеживается по паузе тишины, смысл в формировании этой паузы удержанием драйвера в режиме передачи имеется. К тому же я написал - настраиваемая задержка. Параметр, имеющий величину - 0, означает отсутствие этой задержки ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 8 августа, 2008 Опубликовано 8 августа, 2008 · Жалоба Для RTU-ных протоколов связи, в которых конец пакета отслеживается по паузе тишины, смысл в формировании этой паузы удержанием драйвера в режиме передачи имеется. Во-первых, эта задержка нужна для протокола, а не для собственно передачи по RS-485. А во-вторых, если эта задержка задаётся протоколом, то зачем её дополнительно настраивать? :) К тому же я написал - настраиваемая задержка. Параметр, имеющий величину - 0, означает отсутствие этой задержки ;) По закону тов. Мерфи, если есть настройка, то обязательно найдётся пользователь, который настроит неправильно:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
