Байт начал передаваться, но ещё не передался. Как сбросить процесс передачи так, чтобы можно было быть уверенным, что записанный в UDR байт немедленно после такого сброса начал передаваться ?
Возможные варианты на предполагаемое действие типа "запретить и немедленно разрешить UART":
1. Продолжит передаваться недопереданный байт. Хотя это и было бы странно.
2. Передача прервётся и UART забудет о том, что только что передавал байт (это было бы то, что надо).
Если кто может прокомментировать - плиз.
Заранее благодарю.

Видимо, просто остановом и возобновлением работы ничего не получить, ибо в доке нашёл (всё таки английский не родной, потому читается трудно :), что останов происходит по завершению передачи, если таковая есть в процессе.

Есть ли другие способы ?

Если байт попал в шифтер ничего уже сделать нельзя, автомат запущен, и сдвиг отработает.
Единственное, что можно попробовать, это обнулить UBRR, но это достаточно лихой номер и не факт, что сработает.

Не помню как в AVR, но в некоторых типах uC можно было бы сменить функцию порта с Tx на GPIO, например.

Идея! Причем максимально универсальная. Запомнил :-).

Еще вариант:
- на лету перестроить скорость uart на максимально возможную
- сделать программно задержку на нужное число тактов
- вернуть настройки uart по скорости
- записать новый байт на передачу.

Только, имхо, такие манипуляции с uart выглядят более, чем странно. Как приемник со своей стороны разберет такую кашу? Может огласите вопрос в более общей постановке, что вы хотите сделать?

Ясно. Жаль. Задумка была нацелена на экономное решение приёма пакетов по протоколу MODBUS-RTU. Оно работает в симплексном режиме, и признаком ошибки является расстояние между байтами в пакете более 1.5 символа (ну, скажем 2, для круглости) и признаком конца пакета (и уже не ошибки) время простоя приёмника более 3.5 символов (для круглости 4). Думал, было бы, раз режим симплексный, отсчитывать интервалы самим UART-ом, пусть бы передатчик молотил и временные интервалы отмерял, но вот если кто-то будет отправлять байты на приём с паузами, то такой символьный таймер хрен остановишь, как выяснилось, и непонятно, что он там сможет намерять.
То есть, немного подробнее: когда приходит символ на приёмник, нужно запустить таймер. Некий абстрактный таймер с разрешением примерно 1 символ. Сгодился бы передатчик того-же UART, который бы пулял в космос, и генерил бы прерывания, которые я бы асинхронно считал.
Приём байт тоже асинхронный, так что корячится просто использование таймера, которых что-то мало осталось на чипе.
А касательно перенастройки ножки - сам включеный UART её переопределяет и он на ней самй главный.
В общем, опять AVR-ка показала свою негибкость.

Сделайте таймер интервалов на таймере, это будет проще и прямее, меньше ошибок допустите.
Делать, как хотите Вы имеет смысл, только если таймера заняты под другие задачи.

Записать новый байт на передачу - это надо обдумать, может, и проканает.
менять скорость УАРТ-а нежелательно, потому, что приёмник должен работать на нужной скорости.

Спасибо всем ответившим.

Неа! Это уже не то, ибо просто приведет к вероятной передаче мусора. А перепрограммирование выхода это возможность получить надежное отсутствие стоп бита и как следствие "Framing error"
на приемной строне и возможность отсеять байтик.

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

unfortunally
The disabling of the Transmitter (setting the TXEN to zero) will not become effective until ongoing and pending transmissions are completed, i.e., when the Transmit Shift Register and Transmit Buffer register do not contain data to be transmitted. When disabled, the Transmitter will no longer override the TxD pin.
По простому выражаясь, отключит после отработки передачи.

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

В общем не майтесь фигней. Не отправляйте лишнего, чтобы потом не было необходимости это прерывать.

Совершенно справедливо.
Иными словами, попробуйте угадать:
- какой следующий бит будет воспринят приемником как стартовый для следующего байта;
- возрастет или упадет скорость передачи (или реакции системы).

универсальное решение