так в чем проблема то?

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


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

Возможно товарищи по каким-то причинам (религиозным?) очень хотят писать в FIFO именно из ISR. Непреодолимое желание сиё понять трудно...
Но, коли так уж хочется, после разрешения empty-tx IRQ можно программно возбудить прерывание при помощи NVIC.

Аминь

Чем плохо писать в FIFO из ISR? Это позволяет (не в случае с LPC конечно) в коде записать в буфер данные и разрешить прерывание. Всё остальное делается в прерывании.

Пинать NVIC не пробовал. При случае попробую. Хотя это чревато лишними вызовами прерываний.

про первичное наполнение FIFO из ISR это можно охарактеризовать как странность восприятия мира
но "докладка" в процессе передачи - вполне обыденное действие.

К примеру на RTOS: задача utx_task принимает от других задач task0, taskN то что нужно передать.
тогда есть два варианта разруливания:
#1
utx_task заполняет FIFO и размещает в глобальной переменной ptr и len чего еще не успело передать и ожидает события завершения ВСЕЙ передачи
в прерывании после опустошения FIFO передачи проверяется len и если != 0 то в ISR досылаем в FIFO иначе выставляем признак события чтобы разбудить utx_task задачу для повторения всех циклов

#2
utx_task заполняет FIFO и ожидает события завершения передачи FIFO
в прерывании после опустошения FIFO выставляем признак события чтобы разбудить utx_task задачу для повторения заполнения FIFO и так по кругу

вроде одинаковый результат, но сдается мне что во втором случае будет чаще дергатся шедуллер



тут только отдельная задача, которая:
1. для синхронной отправки ( блокирующая задача ) - выставляет семафор/событие для блокировки текущей задачи
2. для ассинхронной отправки ( неблокирующая задача ) отправка буфера из кучи - сохраняет в своей очереди ptr и len что передать, и по завершению FREE
3. для ассинхронной отправки ( неблокирующая задача ) отправка из стека - свой MALLOC и MEMCPY и предыдущий вариант 2
4. для ассинхронной отправки ( неблокирующая задача ) отправка из const и CODEMEM/FLASH - вариант 2 без FREE

Отправка выглядела примерно так: уарт не занят, разрешаем прерывание tx_empty, пихаем в фифо первый(или заполняем всё fifo) байт посылки, остальное в очередь которую проверит isr. Если уарт занят, то пихаем всё в очередь.
В моём случае заморочка была в том что прерывание tx_empty бывало, что не срабатывало.
Перебрал кучу вариантов, всё равно случались пропуски. Стабильно заработало когда завёл dma на передачу.

По поводу докладывания FIFO 16-тью элементами. Цитата из UM10360 (LPC17xx user manual)

Так что можно докладывать не заходя в прерывание. Точнее, не дожидаясь полного освобождения Tx FIFO.

Жаль, во многих других процах нет этого регистра.

Сообщение отредактировал GetSmart - Sep 30 2013, 20:43

Что-то вы криво делали - у меня стабильно работает всегда.
Например - после разрешения tx_empty и перед пиханием в буфер, вы не забывали запрещать прерывания?
К тому же - по вашему алгоритму придётся запрет прерывания продлить до конца пихания в очередь всех данных.
Логичнее делать по-другому:
В задаче пишем всё в очередь (с разрешёнными прерываниями). После писания - проверим разрешено-ли прерывание UART (ну или программного флага, если в ISR не запрещаем IRQ TX_EMPTY при опустошении, а просто игнорим его), если запрещено - запрещаем прерывания CPU, вызываем функцию переписывающую из очереди в TX FIFO (эту же функцию вызываем из ISR при TX_EMPTY).
Внутри этой функции, если в очереди имеется хотя-бы один байт - она разрешает прерывания TX_EMPTY (ставит программный флаг), заполняет FIFO из очереди. Если на входе в функцию очередь пуста, она запрещает TX_EMPTY (сбрасывает программный флаг).
Если всё реализуете аккуратно, в том числе очередь - реерентерабельную для перекрывающихся чтений/записей, то всё будет работать как часы.

UM10360, rev2, 20100819

Modifications:
• UART0/1/2/3: FIFOLVL register removed.

Removed from document or removed from new revision chip?

Читая мануал на LPC122x этот регистр снова присутствует. Разработчики развлекаются или мануальщики...

Люди, идиотский вопрос. Столкнулся тоже с этим ньюансом про прерывание при опустошении FIFO и подумал, если такие хлопоты, то почему бы просто не запретить аппаратные FIFO в регистре UART1 FIFO Control Register. И тогда прерывание по THRE будет происходить при отправке каждого байта. И тогда кольцевые буфферы без всяких нарезаний по 16 байт можно поместить в прерывание по отправке. Это будет работать и чем это плохо?

отсутствием FIFO, например.... тем что нельзя пихнуть 16 байт и делать свои дела пока их выдавливает, а надо постоянно отвлекаться и по байту класть. А если у вас ModBus с условием определения конца по паузе между байтами посылки?

Да, но так ли это заметно, если процессор работает на частоте под 100 MГц. Ему переложить из регистра в регистр что из fifo, что вручную велика ли разница?

Велика, если есть критические секции в которых у вас может быть запрещено прерывание, или есть какое-то более приоритетное прерывание.
Если класть по символу у вас есть время 1 символ, если класть по фифо, то задержка может быть до 16 символов

Это все удобства.
У СТМ вот к примеру нет фифо ни на входе ни на выходе. Иногда это неудобно, иногда ДМА решает все проблемы. Но в целом наличие фифо все же благо, и просто от него отказываться я бы не стал

Если ничего не нужно делать в процессе отправки, то почему бы и нет. Только как правило позже выясняется что что-то делать нужно.