реклама на сайте
подробности

 
 
> Проблема LPC2214 UART+T0 IRQ
dmyl
сообщение Nov 22 2006, 11:44
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 123
Регистрация: 11-01-06
Пользователь №: 13 032



Прерывания два УАРТ и Таймер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.
Вообщем чушь какая-то, отладить не получается стоит тормознуть отладчиком идут ответы на пакет.

Может есть пример рабочего кода для обработки приема по УАРТ?
Go to the top of the page
 
+Quote Post
3 страниц V  < 1 2 3  
Start new topic
Ответов (30 - 33)
zltigo
сообщение Nov 28 2006, 13:38
Сообщение #31


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(Alex03 @ Nov 28 2006, 11:31) *
У меня нет желания спорить с Вами.

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

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

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

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

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

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

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

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

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

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

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

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

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


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Alex03
сообщение Nov 28 2006, 16:40
Сообщение #32


Местный
***

Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034



Цитата(zltigo @ Nov 28 2006, 15:38) *
По "статистике прерываний" - замну для ясности, хотя понятно, что делать абстракную статистику всех
прерываний правильнее в "узком месте", непонятно только зачем "всех". Точнее отсылка была явная
- если система большая и универсальная - пусть и это фиксирует, вдруг кто спросит.


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

Цитата
Цитата

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

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


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

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


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

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


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

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


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

У меня вон волосы дыбом вставали когда я видел что в ADSL-модеме на базе линукса светодиодом по CRON-у моргают типа "cat строка > /dev/led", а потом подумал а почему бы и нет, если им мощи хватает, а время на разработку нифига не дешевое.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Nov 28 2006, 17:11
Сообщение #33


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(Alex03 @ Nov 28 2006, 15:40) *
А перекос видимо потому что драйвера под линукс писал.

Заметно smile.gif.
Цитата
Необходимость и достаточность - наше всё! smile.gif

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

уже идет.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
sensor_ua
сообщение Nov 28 2006, 17:16
Сообщение #34


Профессионал
*****

Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387



У меня работает чуток рихтанутый вариант обработчика 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


--------------------
aka Vit
Go to the top of the page
 
+Quote Post

3 страниц V  < 1 2 3
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 25th July 2025 - 07:42
Рейтинг@Mail.ru


Страница сгенерированна за 0.01388 секунд с 7
ELECTRONIX ©2004-2016