Может кто сталкивался:

По уарту отправляется посылка по прерываниям UDRE
при завершении посылки прерывания UDRE запрещаются и разрешаются TXC прерывания
При окончании передачи последнего байта запрещаются все прерывания передатчика и
включается приёмник и его прерывания RXC. (во время работы передатчика он был выключен)

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

Кто что думает по этому поводу?

и ещё сканирование компьютером показывает что ответ и запрос не накладываются т.е. правильны все байты запроса и ответа

Сообщение отредактировал Пришелец - Mar 20 2008, 11:54

Решение есть техническое и организационное.
1) Техническое обеспечивается постоянным приемом и флагом состояния.
2) Организационное обеспечивается созданием документа под громким названием "Спецификация протокола обмена с пришлыми мирами " и приведением всех устройств в соответствии со спецификацией.

Спасибо. За ответ.

похоже проблема в небольшой задержки включения приёмника которая получается вследствии задержки обработки прервания конца передачи. Вследствие этого рассинхронизация приёмника
1 - думаю поможет
2 - не пойдёт это мы должны придерживаться спецификаций.

и есть ещё
3 - убрать эту задержку.

А ещё может кто по памяти скажет приёмник начинает принимать байт
по фронту старт бита или по уровню (если при включении приёмника уже идёт старт бит)

Синхронизация приемника начинается по фронту.

When the clock recovery logic detects a high (idle) to low (start) transition on the RxD
line, the start bit detection sequence is initiated.

выдержка из DS на ATmtga128 стр.186 рис. 83

Спасибо огромное

так и думал

Т.е. Вы ходите сказать, что приёмник UART слишком долго включается? Т.е. пока он включается успевают 2 байта проскочить? А кстати, и правда интересно. Через какое время после включения приёмник UART "приходит в полную боеготовность".. Что то в даташифтах по этому поводу вроде ничего нет.. Или я ошибаюс ?


Да.. Только "остался за кадром" вопрос, а через какое время после включения приёмник UART начинает сэмплировать линию на предмет обнаружения фронта СТАРТ-бита? Ведь у автора похоже и проблема как раз в том, что слишком большое время проходит от включения приёмника UART до начала сэмплирования им линии



Хотя нет.. Скорей всего слишком большое время проходит от момента окончания собственно передачи, до момента включения приёмника..


Автор.. Обратите на это внимание.. Скорей всего проблемв в этом

Сообщение отредактировал Дон Амброзио - Mar 20 2008, 14:07

да проблема в задержке между последним стопбитом и включением приёмника я думаю
а uart думаю включается сразу после установки соотв бита

Рекомендую вообще не выключать приёмник. Т.е. принимать все байты в т.ч. и самопереданные. А ещё эти самопринятые байты с самопереданными сравнивать и при равенстве просто отбрасывать. А при неравенстве - ошибка. Это кстати и проблему контроля линии в частности на замыкание решает. Сам всегда так делаю когда с RS485 и т.п. интерфейсами работаю (ну где полудуплекс).

да так и сделал уже

отбрасываю при приёме число переданных байт.

Вот буду ждать машину для испытаний -
но думаю в этом дело и было

Всем кто откликнулся спасибо.

Всё ещё веселее. Установка флага TxC и соответствующее прерывание происходят когда передатчик закончит передачу всех стоповых бит (1 или 2), а приёмник заканчивает приём и выставляет флаг RXC в середине (+один клок) первого стопового бита.
Таким образом в Вашем случае удалённый приёмник выставит у себя RXC на 7/16 бита раньше, чем Ваш передатчик свой TXC. А при двух стоповых битах аж на 23/16 раньше.
При работе через RS485 запросто можно получить конфликт, когда один драйвер ещё передаёт остаток стопового бита, а другой уже выдаёт в линию стартовый бит ответа.

Можно ввести аппаратное управление потоками сигналы RTC и CTC, тогда проблем с рассинхронизацией вообще не должно быть. Правда потребуются дополнительные аппаратно-программные затраты.