Думаю можно сделать "свой UART" на основе таймера и с FIFO.

Как-то не очень глубоко Вы углубились в понимании буфера. Там нет ничего для программиста!

А для облегчения работы, когда скорость отправки не критична, а программировать лень, обычно создают циклический буфер, в который будет добавляться символ по putchar, a считываться и отправляться в системном тике таймера. Тогда этой ботвой с прерываниями по порту можно не заниматься.
Успехов ;)

Вот была похожая тема, там примеры кода приводились.

Хм. Но с прерываниями по порту как-то естественнее :-)

>>>>>>Хм. Но с прерываниями по порту как-то естественнее :-)

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

Напрямую со сдвиговым регистром - нет, нельзя. Да и не нужно оно. Ведь гораздо сложнее отловить момент когда весь символ попал в сдвиговый регистр, чем прочитать его уже готовый из буферного регистора RXBUF. Но я опять не понял, что за проблемы? Теперь уже с приемом данных? Что за чудеса такие? У всех работает, а у вас кристалл "заколдованный" какой-то Может у вас другие лишние прерывания вызываются? Или частоту тактирования ядра слишком низкую установили? У меня был проект где при тактовой частоте 4915,2кГц пакетный обмен (прием/передача) через UART (который на RS-485 работал) на скорости 115200 по прерываниям плюс системные 10мс тики все успешно работало.


Чтобы циклический буфер не переполнялся, по уму нужно два указателя и счетчик байт к нему присовокупить.
P.S. точнее не для того чтобы буфер не переполнялся, а для того чтобы он нормально функционировал. Для того чтобы не переполнялся буфер должен быть "нужного" размера ;)

Не-а, не согласен !
1) Разве по разнице указателей нельзя сделать вывод о количестве байт в буфере?
2) "Нужного"? Если скорость записи больше скорости отправки, размера не хватит никогда, тем более в микроконтроллерах. Нужно просто не гнать коней, то бишь притормаживать запись в буфер.

Количество байт будет либо равно разнице значений указателей либо плюс размер буфера (при переполнении).

Если буфер действительно циклический, а не по типу стека, то разница между указателями сообщает количество находящихся там данных с точностью до размера самого буфера. Т.е. если буфер полностью заполнен, то указатели будут равны и разница их даст значение ноль, в то время как реальное количество данных будет равно размеру буфера. Разницу между указателями в качестве счетчика данных иногда можно использовать в буфере организованному по типу стека. Но и то при условии, что каждый из указателей изменяет свое значение предсказуемо, а не в процедуре прерывания, например.

Если скорость поступления постоянного потока данных в буфер значительно больше скорости передачи, то да. Но это лишь означает, что вы неправильно спроектировали всю систему обмена данными. В реальности же чаще всего данные поступают порциями, пакетами (что-то оцифровали, посчитали, сформировали строку, опросили состояние датчиков и т.п.) и пропускная способность канала известна тоже заранее. Но на этапе передачи данных возникают какие-то задержки/коллизии, например, нужно включить драйвер RS-485 на передачу и выждать паузу до начала передачи. Или получили данные от нескольких каналов АЦП по SPI на высокой скорости, а передать далее нужно через UART. Вот для таких случаев и применяется буфер, но отнюдь не безразмерный, замечу.

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