Пожалуйста, подскажите как правильно и оптимально Запрешать/Разрешать прерывания при работе с программыми буферами устройств. Попробовал несколько вариантов:
1)
cpsr=DisableIRQ();

.... // работа с буфером

RestoreIRQ(cpsr);
2)
VICIntEnClr = 1 << UART0_INT;

.... // работа с буфером

VICIntEnable = 1 << UART0_INT;
3)
cpsr=DisableIRQ();
U0IER &= ~UIER_ETBEI;
RestoreIRQ(cpsr);

.... // работа с буфером

cpsr=DisableIRQ();
U0IER |= UIER_ETBEI;
RestoreIRQ(cpsr);

Второй случай давал сбои и зависание на LPC2138, а вот на LPC2368 работаспособен..

Сообщение отредактировал Smallday - Jun 18 2008, 03:18

запрет источника прерывания приводит к потере запроса прерывания, возникшего во время запрета. При глобальном запрещении прерываний запросы прерываний взводят флаги, и если они не сброшены до глобального разрешения прерываний, то после разрешения срабатывает логика контроллера прерваний и вызываются соответствующие обработчики в установленном этой логикой порядке (логика зависит от типа контроллера прерываний или конкретного решения конкретного микроконтроллера, а общий механизм един для процессорных систем). Так что второй вариант не годится.
ИМХО, в русском техническом языке существуют как минимум такие понятия как источник прерывания, запрос прерывания, контроллер прерывания, обработчик прерывания, а вот само слово прерывание в разных контекстах обозначает разное сочетание этих понятий (к моему сожалению всё чаще русскоязычные словосочетания забываются и с английского переводится без учёта контекста). А глобальное разрешение прерываний грубо относится к "кнопке" управления контроллера прерываний со стороны процессора (ядра), которая в случае запрета на время как бы придерживает выдачу запроса прерывания от контроллера прерывания к ядру (в случае с ARM это, например, IRQ со своим запретом и FIQ со своим запретом).
Что касается буферов, то они бывают разными и есть варианты построения и дисциплины работы, не требующие запрета прерываний.
Что касается вариантов 1 и 3, то существуют разные подходы в части использования и способов входа/выхода в/из критических секций и это отдельный вопрос, по которому на форуме было достаточно много обсуждений.

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

Абсолютно. Толко я чуть ошибся с контекстом. Читать "запрет обработки запроса прерывания", хотя и при запрете источника будет так же не работать.
Вопрос же скорости обработки запросов и их потерь при неуспевании, ИМХО, суть другой вопрос.

мне кажется сути это не меняет. А вы попробуйте запретить прервание по приему от UART и отправьте на него символ, а потом разрешите прерывание и посмотрите что получится

Да ну?! Посмотрите хотя бы картинку Interrupt request logic в описании VIC'а.

Смотрю документ
http://infocenter.arm.com/help/topic/com.a...81e/DDI0181.pdf Figure 2-2 и триггеров не наблюдаю. Читаем до того на стр. 20 примечание
The VIC does not handle interrupt sources with transient behavior. For example, an
interrupt is asserted and then deasserted before software can clear the interrupt source. ... However, when a transient interrupt occurs, the priority logic of
the VIC is not set ...
Может я, конечно чего не понимаю, но в LPC2138, например, для источника прерывания по ExtInt проложен регистр (триггеры) ДО VIC (смотрю UM LPC2138 раздел 5-2 External Interrupt Flag register) и если выходы таких регистров служат запросами прерывания, то, естественно, если триггер не сбросишь, то запросы прерывания на соответствующих входах Interrupt Request Logic VIC будет активны.

Зато у UART'а они имеются, как и у >90% других источников.

Просто ваши слова можно было истолковать так, как будто в ситуации "запретили прерывание->получили запрос->разрешили прерывание" запрос будет в любом случае потерян, что неверно.

А можно примерчик такого?

...вот пример кольцевого буфера не требующего запрета прерываний

struct
{
U8 in;
U8 out;
U8 data [256];
} buf;


void init_buf(void)
{
buf.in = buf.out;
}



void isr_rx(void)
{
U8 c;
...

if ((U8)(buf.in + 1) != buf.out) buf.data [buf.in++] = c;
else return;
}


void main(void)
{
U8 c;

...

if (buf.in != buf.out) c = buf.data[buf.out++];

...

}

Да, такая конструкция работает. По причине атомарности добавления. А вот аналогиная передача - работать не будет.

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

А можно пример кода?

Идея кольцевых буферов и код есть в avr-lib. У меня на его основе сделаны кольцевые буферы USART, но для AVR. Идею можно перенести на любую платформу.

Да где ее только нет. Я и сам могу десяток реализаций разных сделать (и делал). Я к тому веду, что в общем случае, при работе с кольцевыми буферами необходима атомарная RMW-операция с памятью хотя-бы в одном месте. С учетом того, что на RISC-процах нет столь любимого на PDP11 INC и DEC прямо ячейки памяти, получается, что необходимо уметь запрещать/разрешать прерывания (или переключение задач в общем случае). Кстати, в ARM есть комманда SWP для управления семафорами (она как раз RMW), только я не могу пока придумать, как ее использовать для циклических буферов.