[Golikov 0]

это всё конечно красиво, но попробуйте сделать вывод в отладочный порт из разных задач. Останавливать задачу ради вывода отладки нельзя, что влезло в буфер, то влезло. Заводить отдельную задачу для слежения за заполненостью буфера, очень не хочется. Запрещать прерывания перед каждым обращением в uart тоже (тут я конечно несколько лукавлю, т.к. при складывании в буфер прерывания всё равно запрещаются).

 

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

 

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

 

 

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

[jcxz 228]

Возможно товарищи по каким-то причинам (религиозным?) очень хотят писать в FIFO именно из ISR. Непреодолимое желание сиё понять трудно... :twak:

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

[Golikov 0]

Аминь:)

[Terminator 0]

Возможно товарищи по каким-то причинам (религиозным?) очень хотят писать в FIFO именно из ISR. Непреодолимое желание сиё понять трудно... :twak:

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

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

 

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

 

[megajohn 5]

Возможно товарищи по каким-то причинам (религиозным?) очень хотят писать в FIFO именно из ISR. Непреодолимое желание сиё понять трудно... :twak:

Но, коли так уж хочется, после разрешения empty-tx IRQ можно программно возбудить прерывание при помощи 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 и так по кругу

 

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

 

это всё конечно красиво, но попробуйте сделать вывод в отладочный порт из разных задач.

Останавливать задачу ради вывода отладки нельзя, что влезло в буфер, то влезло.

Заводить отдельную задачу для слежения за заполненостью буфера, очень не хочется.

Запрещать прерывания перед каждым обращением в uart тоже (тут я конечно несколько лукавлю, т.к. при складывании в буфер прерывания всё равно запрещаются).

 

тут только отдельная задача, которая:

1. для синхронной отправки ( блокирующая задача ) - выставляет семафор/событие для блокировки текущей задачи

2. для ассинхронной отправки ( неблокирующая задача ) отправка буфера из кучи - сохраняет в своей очереди ptr и len что передать, и по завершению FREE

3. для ассинхронной отправки ( неблокирующая задача ) отправка из стека - свой MALLOC и MEMCPY и предыдущий вариант 2

4. для ассинхронной отправки ( неблокирующая задача ) отправка из const и CODEMEM/FLASH - вариант 2 без FREE

[Terminator 0]

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

В моём случае заморочка была в том что прерывание tx_empty бывало, что не срабатывало.

Перебрал кучу вариантов, всё равно случались пропуски. Стабильно заработало когда завёл dma на передачу.

[GetSmart 0]

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

4.14 UARTn FIFO Level register (U0FIFOLVL - 0x4000 C058, U2FIFOLVL - 0x4009 8058, U3FIFOLVL - 0x4009 C058)

 

UnFIFOLVL register is a read-only register that allows software to read the current FIFO

level status. Both the transmit and receive FIFO levels are present in this register.

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

 

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

Изменено 30 сентября, 2013 пользователем GetSmart

[jcxz 228]

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

В моём случае заморочка была в том что прерывание tx_empty бывало, что не срабатывало.

Что-то вы криво делали - у меня стабильно работает всегда.

Например - после разрешения tx_empty и перед пиханием в буфер, вы не забывали запрещать прерывания? :)

К тому же - по вашему алгоритму придётся запрет прерывания продлить до конца пихания в очередь всех данных.

Логичнее делать по-другому:

В задаче пишем всё в очередь (с разрешёнными прерываниями). После писания - проверим разрешено-ли прерывание UART (ну или программного флага, если в ISR не запрещаем IRQ TX_EMPTY при опустошении, а просто игнорим его), если запрещено - запрещаем прерывания CPU, вызываем функцию переписывающую из очереди в TX FIFO (эту же функцию вызываем из ISR при TX_EMPTY).

Внутри этой функции, если в очереди имеется хотя-бы один байт - она разрешает прерывания TX_EMPTY (ставит программный флаг), заполняет FIFO из очереди. Если на входе в функцию очередь пуста, она запрещает TX_EMPTY (сбрасывает программный флаг).

Если всё реализуете аккуратно, в том числе очередь - реерентерабельную для перекрывающихся чтений/записей, то всё будет работать как часы.

[Grape 0]

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

 

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

 

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

 

UM10360, rev2, 20100819

 

Modifications:

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

 

[GetSmart 0]

UM10360, rev2, 20100819

 

Modifications:

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

Removed from document or removed from new revision chip?

 

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

[yanvasilij 0]

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

[Golikov 0]

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

[yanvasilij 0]

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

 

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

[Golikov 0]

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

Если класть по символу у вас есть время 1 символ, если класть по фифо, то задержка может быть до 16 символов

 

Это все удобства.

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

[Kabdim 0]

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

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