Проблема LPC2214 UART+T0 IRQ Опции

[dmyl]

Прерывания два УАРТ и Таймер0, Т0 запускается периодически (отсчет таймаута), пока был один Т0 все работало, с делал прерывание на прием по УАРТу - какие-то глюки
Не получается разобраться в чем проблема, вот код
Инициализания прирываний:

static void DefDummyInterrupt(void)
{}

// IRQ exception handler. Calls the interrupt handlers.
#pragma vector=0x18
__irq __ramfunc void irq_handler(void)
{
void (*interrupt_function)();
unsigned long vector;

vector = VICVectAddr; // Get interrupt vector.
interrupt_function = (void(*)())vector;
// __enable_interrupt(); // Enable interrupts.
(*interrupt_function)(); // Call vectored interrupt function.

VICVectAddr = 0; // Clear interrupt in VIC.
}

//************************************************************
void init_IRQ(void)
{
// Setup interrupt controller.
VICProtection = 0;
// Disable all interrupts
VICIntEnClear = 0xffffffff;
VICDefVectAddr = (unsigned long)&DefDummyInterrupt;

// Setup timer callback function.
VICIntSelect=0x0; // Timer0 & UART select as IRQ.
VICVectAddr0 = (unsigned long)&UART0Interrupt;
VICVectCntl0 = 0x20 | VIC_UART0; // Enable vector interrupt for UART0.
VICVectAddr1 = (unsigned long)&Timer0Interrupt;
VICVectCntl1 = 0x20 | VIC_TIMER0; // Enable vector interrupt for timer 0.
VICIntEnable = 0x50; // Enable timer 0 & UART0 interrupt.
}

УАРТ - слот0
Т0- слот1
Процедура обработки для Т0 и УАРТа

// Timer0 interrupt handler
__ramfunc void Timer0Interrupt(void)
{
T0IR = 0xff; // Clear timer 0 interrupt line.
BF=0;
}

//******************************************************************
// Заполняет буфер приема
__ramfunc void UART0Interrupt()
{
while (U0LSR&0x1)
{
rx_buff[rx_end]=U0RBR;
rx_end=(rx_end+1)%RX_BUFF_LEN;
rx_len++;
}
}


Под житагом запускаю программу, передаю пакет данных. На него должен быть ответ, ответа нет. Останавливаю программу, пакет в буфер принимается верно, лишнего нет почему-то постоянно вылетает на DummyInterrupt, пока не тормознешь отладчиком ответа нет, после остановки отладчиком и снова запуска ответ передается.
Если точка останова на irq_handler то постоянно вылезают DummyInterrupt.
Вообщем чушь какая-то, отладить не получается стоит тормознуть отладчиком идут ответы на пакет.

Может есть пример рабочего кода для обработки приема по УАРТ?

[zltigo]

У меня нет желания спорить с Вами.

Постараюсь тоже не спорить, но смолчать как-то не хочется. Вот такая проблема :-)

По "статистике прерываний" - замну для ясности, хотя понятно, что делать абстракную статистику всех
прерываний правильнее в "узком месте", непонятно только зачем "всех". Точнее отсылка была явная
- если система большая и универсальная - пусть и это фиксирует, вдруг кто спросит.

И где по Вашему этим система разбирается?
1. Исполняется юзер-процесс
2. Происходит прерывание
3. Исполняется Ваш обработчик, который выводит из спячки высокоприоритетный процесс.
4. Возврат из прерывания
5. ??? Опять юзер-процесс ??? Где переключение контекста на высокоприоритетный процесс?

В пункте '3' когда обработчик "выводит из спячки высокоприоритетный процесс" по крайней мере
у меня так :-) - после перепланирования очереди задач планировщик возвращает признак наличия
более приоритетного процесса. При наличии более приоритетного дальнейшее поведение может быть
двояким;
- Ну есть и есть - проигнорировали и тогда в пункте 5 - все по Вашему - вернулись в прерванный процесс. И потом уже при ближайшем таймерном система перекючит.
- Вызвали переключатель контекста и тогда из обработчика возвратились уже в высокоприоритетный процесс.
По любому - статистикой системы занимаются вставки в системных вызовах а не универсальная прокладка перед обработчиками прерываний.

Рядом с упомянутыми массивами nIntCounts[N], pIntFn[N] положите ещё массив с флагами для каждого прерывания, такими как возможность разрешения вложенности, флаг реентерабельности (повторного вхождения) и т.д.

Мысль понятна, реализация универсальна, но громоздка.

и приходится ОС (точнее её универсальному обработчику прерывания) вызывать по очереди все зерегистрированные для данной линии обработчики, а уже конкретный обработчик первым делом проверяет своё железо на факт наличия прерывания,

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

Про обязательность везде и всего я не говорил.

Это радует :-) Будем считать, что я про НЕ обязательность везде не говорил :-)
Однако в Ваших примерах просматривается жесткий перекос в большие системы, а я как-то ожидал, даже при упоминании слова "система" говорить о более приземленных материях.

Во первых я сам в LPC пользую
ldr pc,[pc,#-0xFF0]
При этом я не пользую ОС.

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

Ну и как пример оправданности оверхеда с тем же VICVectAddr:

В в системе эта проблема может решаться разными способами, например окончанием обработчика прерывания "системным вызовом", в вырожденном случае заменяющимся макросом с
"с тем же VICVectAddr". Ну и обертку делать тоже никто не запрещает. Это мне много ближе, нежели включение в систему абстрактно написанного драйвера, вызываемого из абстрактного кода. При таком подходе тот-же помянутый оверхед становится далеко не единственным :-(

[Alex03]

По "статистике прерываний" - замну для ясности, хотя понятно, что делать абстракную статистику всех
прерываний правильнее в "узком месте", непонятно только зачем "всех". Точнее отсылка была явная
- если система большая и универсальная - пусть и это фиксирует, вдруг кто спросит.

При отладке (а то и при выяснении причин странного поведения) порой очень помагает.

И где по Вашему этим система разбирается?
1. Исполняется юзер-процесс
2. Происходит прерывание
3. Исполняется Ваш обработчик, который выводит из спячки высокоприоритетный процесс.
4. Возврат из прерывания
5. ??? Опять юзер-процесс ??? Где переключение контекста на высокоприоритетный процесс?

В пункте '3' когда обработчик "выводит из спячки высокоприоритетный процесс" по крайней мере
у меня так :-) - после перепланирования очереди задач планировщик возвращает признак наличия
более приоритетного процесса. При наличии более приоритетного дальнейшее поведение может быть
двояким;
- Ну есть и есть - проигнорировали и тогда в пункте 5 - все по Вашему - вернулись в прерванный процесс. И потом уже при ближайшем таймерном система перекючит.
- Вызвали переключатель контекста и тогда из обработчика возвратились уже в высокоприоритетный процесс.

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

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

Вот тут не факт.
ИМХО во первых разделение system/user тайм гораздо полезнее не с точки зрения оценки времени исполнения кода user процесса(ов) и кода ядра/драйверов, а с точки зрения оценки времени "работы" процесса(ов) (сам процесс и его системные вызовы, за исключением ожидания событий в них) и времени работы ядра на обслуживание системы (шедулинг, прерывания и т.д.)
Во вторых как вы оцените время потраченное на исполнение некоего юзер-процесса, если во время его исполнения постоянно "молотят" никак к нему не относящиеся прерывания.

Это радует :-) Будем считать, что я про НЕ обязательность везде не говорил :-)
Однако в Ваших примерах просматривается жесткий перекос в большие системы, а я как-то ожидал, даже при упоминании слова "система" говорить о более приземленных материях.

Был вопрос про примеры, я привёл, понятно что в простых ОС всё это не надо.
А перекос видимо потому что драйвера под линукс писал.

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

Так и не надо.
Необходимость и достаточность - наше всё!

У меня вон волосы дыбом вставали когда я видел что в ADSL-модеме на базе линукса светодиодом по CRON-у моргают типа "cat строка > /dev/led", а потом подумал а почему бы и нет, если им мощи хватает, а время на разработку нифига не дешевое.

[zltigo]

А перекос видимо потому что драйвера под линукс писал.

Заметно .

Необходимость и достаточность - наше всё!

В embedded пока так.
Но к такому

... в ADSL-модеме на базе линукса светодиодом по CRON-у моргают типа "cat строка > /dev/led", а потом подумал а почему бы и нет, если им мощи хватает, а время на разработку нифига не дешевое.

уже идет.

[sensor_ua]

У меня работает чуток рихтанутый вариант обработчика UART-а оттуда -> http://www.siwawi.arubi.uni-kl.de/avr_proj...s/#lpc_uart_irq
http://www.siwawi.arubi.uni-kl.de/avr_proj...rq_20051008.zip
Там используется while по биту interrupt-pending IIR