Вот это как раз жутко и не удобно,
- лишний таймер + лишнее прерывание от него
- по условию Вашей задачи, есть длинные прерывания (до 5 символов), то есть пауза после окончания
передачи (TEMT) и до переключения RTS может сильно затянуться что не всегда хорошо,
например если ответ на запрос будет начинаться быстрее чем 5 символов

Похожая тема
http://electronix.ru/forum/lofiversion/index.php/t74127.html

Смеяцо уже можно ? Вы вобсче поняли о чем речь ?

Не надо - лучше прочитайте. Тема большая и про заполнение FIFO там есть.

В той теме я ничего интересного не вижу. Есть только простое забивание всего фифо в прерывании по THRE. У меня щас так и сделано, но могут происходить паузы в потоке символов, хотя и в несколько раз с меньшей вероятностью чем когда совсем без фифо. Но если бы была возможность читать уровень фифо, либо задавать уровень срабатывания THRE, то был бы идеальный 16550 (с буквой B ). Буквально мелочи не хватает для полного счастья.

Конечно я был слишком резок... и FIFO там упоминается, но по теме данного топика там нет ничего...


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

Почитайте описание LPC1114 уарт. Там столько всего есть. Может быть почти всё перечисленное. Даже аппаратное дрыгание RTS/DE.

А у атмеля есть фифо и чтение его указателей?

Почитал. Улучшили. Пока еще не все... Ждемс дальше...
У него есть ДМА на почти всю переферию, причем с двойной буферизацией,
и аппаратный RTS, и прерывание по уходу всего в линию(TEMT в LPC) и настраиваемый таймаут.
Поэтому там таких проблем вообще нет.
ИМХО, это вообще лучшая реализация уартов в МК.
Слабое место атмеловских АРМ это I2C, хотя в новых чипах это вроде подправили.

А что бы дал вам уровень FIFO ?
Ваша проблема как я понял в том, что взведенное прерывание по опустошению FIFO передатчика не обрабатывается с должной скоростью. В результате паузы. Это от того, что кто-то запрещает прерывания надолго. Но это проблема проектирования конкретного софта, и периферийный UART не виноват. Мой совет: используйте вложенные прерывания, или измените код так, чтоб никто не работал в режиме запрета прерываний дольше времени передачи одного символа по UART. Или заассайните FIQ для UARTа.

Из былого, бились несколько дней с такой же проблемой, Rowley CrossWorks + CTL на LPC2387. Оказалось реализованная в CTL байтовая очередь была "слишком безопасной", и на все время копирования данных запрещала IRQ. Теперь пользуем самописную очередь.

Я вас умаляю. Я фанат вложенных прерываний У меня FIQ блокирует остальные прерывания на 5-6 символов уарта. А на FIQе мне нужен нулевой джиттер (он собсно и сделан) и переносить его на IRQ тем более вложенный я не могу. Уровень фифо мне бы помог так, что в периодическом прерывании от таймера (ну скажем в районе 8 символов уарта) я бы его читал и дозабивал фифо до максимума. То есть даже не в прерывании от уарта.

Вобщем-то серьёзной проблемы нет. Всё работает и малые паузы не смертельны. Но лучше было бы без них.