ведь прерывания по опустошению сдвигового регистра нет!
Тупо зависать в прерывании на поллинге флага для передачи последнего байта пакета? Я не могу себе это позволить - скорость может быть и 300 бод. Запускать таймер при начале передачи последнего байта - слишком накладно (целый таймер для этого отводить). Как кто поступает?

Делаете FIFO-буфер, из него прерывание при передаче считывает ваш пакет данных. Опрашивать флаг готовности передачи символа при этом не нужно.

ЗЫ
тут VAI выкладывал работу с кольцевым буфером + UART
http://electronix.ru/forum/index.php?showtopic=24037

ЗЗЫ
вот пример для AVR, доходчиво расписана работа с очередью, поэтому можно взять идею
http://atmel.ru/Articles/Atmel12.htm

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

> что бы направление переключить
Направление чего? Переключиться с передачи на прием? А почему бы один раз не выставить URXEx (или URXIEх) и пусть себе работает.

Предположу ,что у человека полудуплекс, например- 485

Зачем весь таймер? Таймер пускай работает как работал, а для определения таймаута достаточно одного compare-регистра CCRx. Не поверю, что в вашей программе какой-нибудь таймер не используется для генерации системных тиков

Конечно, и не один все 5 + 3 канала. Поэтому выделить какой-либо таймер для этой задачи не просто.
Просто не совсем понятно, почему не сделали ткую нужную вещь, как прерывание по завершению передачи? Ведь это просто необходимо в любом полудeплексе.
А еще у меня слейв отвечает через несколько микросекунд (будь он не ладен) после запроса - надо все успеть.
Сейчас пробую передавать на байт больше (последний dumb так сказать), а направление переключать по последнему значащиму байту. Т.е. передатчик контроллера передает dumb байт, но тот уже никуда не попадает, так как передатчик драйвера выключен. Пока вроде прокатывает, но как-то все это через ж.

А вот это уже системный глюк! Времена и задержки при транзакции через RS-485 должны быть регулируемыми/программируемыми под каждую конкретную систему.

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

В конкретном случае ADAM-4117 - время ответа несколько микросекунд.
В других - например излучающий контур и мне по завершении передачи необходимо выключить его питание. Каждая миллисекунда на счету (срок работы от батареи 1 Ач - 10 лет). Да малоли еще ситуаций, когда необходимо определить завершение передачи как можно быстрее и с меньшими накладными. А тут приходится огород городить. В общем все методы определения завершения передачи очень нелогичны: приходится то таймер задействовать, то еще что. Почему не сделали прерывание?

Ну раз вам так важно, то включайте LOOPBACK при передаче последнего символа. По окончании передачи байта получите прерывание от приемника USART. Хотя у вас вроде как эхо и без этого принимается? Тогда какая проблема? Ведите счетчик передачи и приема. Синхронизируйте их до начала передачи. И как по окончании передачи пакета они сравнялись, то значит передача окончена.