Будем считать что процедура записи в U0THR мгновеная, а скорость передачи сверхнизкая, т.е. байты улетать не успевают

16? Или если ещё и LST_TEMP=1 (но это вряд ли) то и 17?

PS Гады. Ну реализовали они 550 UART но могли бы расширить флагами для статуса FIFO, а то и прерыванием по окончанию передачи из сдвигового регистра.
PPS FIFO понятно включен.

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

17 - пожалуй перебор.
Такой ситуации практически не бывает на относительно невысоких скоростях передачи.
Время передачи одного/двух бит (стоповый бит) или 7..11 бит (целого слова) часто довольно большое.
Например для B9600 м.б. ~100..1100мкс.
Да и на макс. скорости для 8N1 у проца есть 10*16 тактов, что вполне соизмеримо с временем записи 16 байтиков в U0THR с учётом хорошей оптимизации, задержек на ISR и тормознутой переферии.

А смутил меня попавшийся в двух примерах такой (псевдо)код в ISR:


Т.е. они там по одному (в лучшем случае два) байту за прерывание отправляли, при активированном FIFO.

Ну почему же один? U0LSR читается на каждом проходе цикла, пока FIFO не заполнится ULSR_THRE равен 1 и цикл будет выполняться. Т.е. 16-17 легко.

Вот видимо те авторы так-же думали.

THRE - Transmitter Holding Register Empty
0: U0THR contains valid data.
1: U0THR is empty.
THRE is set immediately upon detection of an empty UART0 THR and is cleared on a U0THR write.

Так ведь то что в него записано тут же падает в FIFO и пока FIFO не полон THR пуст.
The U0THR is the top byte of the UART0 Tx FIFO. The top byte is the newest character in the Tx FIFO and can be written via
the bus interface. The LSB represents the first bit to transmit.

Сообщение отредактировал Сергей Борщ - Oct 11 2006, 14:47

Вы ж сами сказали

Т.е. U0THR это голова FIFO, а не отдельный регистр. И если в FIFO чтото есть то THR не пуст.

ИМХО у Филипса тут дока кривоватая. Все эти THRE (как прерывание и как бит в LSR) THR (как U0THR) и т.д. Вроде всё просто, но понимание приходит со временем.

В общем я уже на практике убедился в своих словах.

Именно, голова а не хвост. И с точностью до наоборот - пока в FIFO есть место THR пуст.

т.е. скорость небольшая (за время записи байта в FIFO он не успевает передаться), вы забили в пустой FIFO 16 байт, вышли из прерывания, получили прерывание THE и снова "не глядя" запихнули в FIFO 16 байт, а на второй стороне шнурка UART вывалилось 32 байта?
"Не верю!" (с)Станиславский.

По поводу головы я видимо погорячился. Байт который пишут в U0THR конечно же попадает в хвост FIFO.



Верить или нет - это проблемы Станиславского!
Поглядите на код zltigo
Попробуйте без всяких прерываний выполнить такой код:



Думаю результат будет 2.
Ну а в прерывании 1.


2 zltigo

А tbuf.tail также растёт до бесконечности ( ну или там 2^(8*sizeof(tbuf.tail)) ) ?
Типа задумка такая - чтобы голова и хвост отражали реальное кол-во (по модулю 2^(8*sizeof(tbuf.tail))) прошедших через FIFO данных?

PS. А я что то всегда их циклю!

Сравнение и занесение всегда производится по маскированным значениям, а сами указатели
растут "до бесконечности".

И что еще, что много более полезно - отражали факт переполнения буфера и работали быстрее, нежели в случае:

Недостаток всего один - размер степень двойки.

Наверное вытаскивание и занесение?



В каком смысле "факт переполнения буфера"?
Код засовывания примерно тако?


Ну и не вижу великой разницы по быстродействию (при размере буфера = 2^x), хотя возможно есть. Будем иметь ввиду!

В самом прямом.

Разумеется нет :-)

И все!
Прочувствовали разницу и про переполнение стало яснее?

Не почуствовал.
Не вижу никакого контроля факта переполнения буфера.

Давайте на примере.
Допустим буфер 16 байт, TBUF_SIZE_MSK=0x0F

Запихиваем больше 16-ти байт, например 17 байт такие 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
Легко, контроля то нет. 17-ый лёг на место первого.

Читающий процесс (как в прерываннии вверху треда) также легко их достаёт, но достаёт он такую последовательнось:
16,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

И чё тут клёвого?

Странно, Вы написали 'кучу' строчек в стиле
"А я что то всегда их циклю.." а тут одна :-)

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

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