|
Проблема LPC2214 UART+T0 IRQ |
|
|
|
Nov 22 2006, 11:44
|
Частый гость
 
Группа: Свой
Сообщений: 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. Вообщем чушь какая-то, отладить не получается стоит тормознуть отладчиком идут ответы на пакет.
Может есть пример рабочего кода для обработки приема по УАРТ?
|
|
|
|
|
 |
Ответов
|
Nov 22 2006, 14:32
|
Местный
  
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034

|
Цитата(dmyl @ Nov 22 2006, 14:11)  Немного переделал - выкинул Т0, оставил только прием по прерыванию. Передача в цикле по опросу заполнения буфера. Такое впечатление что при возникновении прерывания в нем все и зацикливается. А почемуб по честному не читать IRR и в соответствии с причиной прерывания действовать, дабы это прерывание сбрасывалось.
|
|
|
|
|
Nov 22 2006, 18:39
|

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

|
Цитата(Alex03 @ Nov 22 2006, 13:32)  А почемуб по честному не читать IRR и в соответствии с причиной прерывания действовать, дабы это прерывание сбрасывалось. Это не честнее, это просто еще более громоздко. Нормальный подход это ОДНА команда: Код ldr pc,[pc,#-0xFF0] ; 18 Jump directly to the address given by the AIC ; from [0xFFFFF020] Curent 18h +8(conveyer)=20h
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Nov 27 2006, 10:07
|
Местный
  
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034

|
Цитата(zltigo @ Nov 22 2006, 20:39)  Цитата(Alex03 @ Nov 22 2006, 13:32)  А почемуб по честному не читать IRR и в соответствии с причиной прерывания действовать, дабы это прерывание сбрасывалось.
Это не честнее, это просто еще более громоздко. Нормальный подход это ОДНА команда: Код ldr pc,[pc,#-0xFF0] ; 18 Jump directly to the address given by the AIC ; from [0xFFFFF020] Curent 18h +8(conveyer)=20h А всётаки IRR в обработчике прерывания UART читать надо  А если прерывания все кроме приёма отключены, это не значит что не надо обрабатывать другие ситуации типа RX Line status Error, что кстати тоже зачастую лучше далать в прерывании. Ну а про общий обработчик IRQ прерывания, тут уж что кому нравится Стартап CW автоматом генерит Код ldr pc,[pc,#-0xFF0] если определён VECTORED_IRQ_INTERRUPTS (и я этим пользуюсь). Но тут надо помнить что запись в VICVectAddr нужна в каждом обработчике. Но и общий обработчик IRQ в ряде случаев полезен, например в ОС-ах и т.д., проблема у автора треда не в нём была.
|
|
|
|
|
Nov 27 2006, 11:39
|

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

|
Цитата(Alex03 @ Nov 27 2006, 09:07)  А всётаки IRR в обработчике прерывания UART читать надо  Я утверждал обратное про обработчик прерывания UART а не про общий обработчик??? Цитата А если прерывания все кроме приёма отключены, это не значит что не надо обрабатывать другие ситуации типа RX Line status Error, что кстати тоже зачастую лучше далать в прерывании. А вот если 'отключены', то в IIR (полагаю речь идет о нем а не о каком-то IRR) их не будет и быть не может. Цитата Но тут надо помнить что запись в VICVectAddr нужна в каждом обработчике. Жуткий напряг и нагрузка на память программиста :-) Цитата Но и общий обработчик IRQ в ряде случаев полезен, например в ОС-ах и т.д., А вот с этого места, пожалуйста поподробнее. Очень люблю про OSы думать. Заинтриговали. Цитата проблема у автора треда не в нём была.  А я сие и не утверждал - речь была просто о уменьшении количества выставленного на обозрение кода.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Nov 27 2006, 15:26
|
Местный
  
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034

|
Цитата(zltigo @ Nov 27 2006, 13:39)  Цитата Но и общий обработчик IRQ в ряде случаев полезен, например в ОС-ах и т.д.,
А вот с этого места, пожалуйста поподробнее. Очень люблю про OSы думать. Заинтриговали. Если Вам надо выполнять одно и то-же действие перед и/или после любого из прерываний. Например: - Подсчёт статистики, такой как кол-во прерываний, систем_тайм/юзер_тайм и т.д. - Переключение задач по соответствующим условиям, как то с низкоприоритетной прерванной задачи, на более (сильно/реалтайм) приоритетную, которая была выведена из спячки текущим прерыванием. - Разрешение вложенных прерываний, опять же в соответствии с заданной в ОС логикой. Также в ОС-ах бывает вызов нескольких зерегестрированных обработчиков по списку, как пример, в PC архитектуре когда на одном физическом прерывании может несколько девайсов висеть, и когда драйвера, а с ними и обработчики прерываний, являются динамически загружаемыми/выгружаемыми модулями. Ну и как доп. уровень абстракции когда писатель драйвера конкретной железки, не занимается программированием MMU или там контроллера прерываний (как то запись в VICVectAddr  ), а использует допустимые (документированные) для данной ОС механизмы. и т.д. зависит от ОС, от архитектуры и прочего. Чем навороченнее ОС тем больше вариантов. Я ОС-ем пока не писал.
|
|
|
|
|
Nov 27 2006, 19:23
|

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

|
Цитата(Alex03 @ Nov 27 2006, 14:26)  Если Вам надо выполнять одно и то-же действие перед и/или после любого из прерываний. Хорошо, посмотрим, что предлагается: Цитата - Подсчёт статистики, такой как кол-во прерываний, Сильно. Просто общее количество прерываний и за каждое обработанное прерывание брать денюжку :-), хотя опять некоторые сложно обрабатывать а некоторве попроще. Тогда надо считать их отдельно, тогда зачем общий обработчик? Цитата систем_тайм/юзер_тайм и т.д. А это уже конкретные обработчики, ну право-же не считать-же системное время по сумме прерываний от таймера, мышки и клавиатуры. Цитата - Переключение задач по соответствующим условиям, как то с низкоприоритетной прерванной задачи, на более (сильно/реалтайм) приоритетную, которая была выведена из спячки текущим прерыванием. Действия понятны, но с этим разбирается система а не какой-то универсальный пролог/эпилог ко всем прерываниям. Цитата - Разрешение вложенных прерываний, опять же в соответствии с заданной в ОС логикой. Разрешение вложенных прерываний огульно любого в любом. Выделение, например стека, неведомого размера (или наоборот не выделение) под вложенное. Причем до того, когда когда управление получит обработчик конкретного прерывания или таже OS. При этом не запущенный обработчик прерывания той-же OS как-то "задает логику"? Вот когда он получит управление он и будет "задавать логику" и именно он а не прокладка перед ним. Цитата в PC архитектуре когда на одном физическом прерывании может несколько девайсов висеть Это к архитектуре никакого отнощения не имеет, у меня вот прямо сейчас перед носом 16 на одном прерывании висят. И разбирается кто вылез обработчик конкретного прерывания, который знает как разобраться "кто сказал Гав" а не некая абстрактная прокладка для всех прерываний вместе взятых. Цитата и когда драйвера, а с ними и обработчики прерываний, являются динамически загружаемыми/выгружаемыми модулями. Сильно. Т.е. девайса нет (не вставили), драйвера нет(не загрузили) а обработчик прерывания - вот он уже есть и готов работать с неведомым ему железом на неведомом прерывании. Цитата Ну и как доп. уровень абстракции когда писатель драйвера конкретной железки, не занимается программированием MMU или там контроллера прерываний (как то запись в VICVectAddr  ), а использует допустимые (документированные) для данной ОС механизмы. Живые примеры вышеописанного "ненавязчивого сервиса" имеют место быть, только зачем для этого обязательно иметь некую абстрактную прокладку перед или после собственно обработчика прерывания, который будет писать писатель драйвера? Цитата Чем навороченнее ОС тем больше вариантов. Навернуть можно много чего, вопрос зачем? Конкретный пример наворота присутствовал в первом примере с которого топик начался. Наворот виден и кушает такты. Польза от наворота? Не писать в каждом обработчике в VICVectAddr? А если я, простите захочу разрешить в одном (только упаси боже не во всех зараз) обработчике вложенные прерывания? Нафига мне тогда такой сервис?
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
Сообщений в этой теме
dmyl Проблема LPC2214 UART+T0 IRQ Nov 22 2006, 11:44       Alex03 Уважаемый zltigo!
У меня нет желания спорить с... Nov 28 2006, 12:31        zltigo Цитата(Alex03 @ Nov 28 2006, 11:31) У мен... Nov 28 2006, 13:38         Alex03 Цитата(zltigo @ Nov 28 2006, 15:38) По ... Nov 28 2006, 16:40          zltigo Цитата(Alex03 @ Nov 28 2006, 15:40) А пер... Nov 28 2006, 17:11 amw Использую оба указанных прерывания. Никаких пробле... Nov 22 2006, 17:23 Andrew2000 Цитата(dmyl @ Nov 22 2006, 11:44) Прерыва... Nov 23 2006, 02:29 aaarrr Цитата(Andrew2000 @ Nov 23 2006, 02:29) Т... Nov 23 2006, 04:22 zltigo Цитата(aaarrr @ Nov 23 2006, 03:22) К инс... Nov 23 2006, 10:20 aaarrr Цитата(zltigo @ Nov 23 2006, 10:20) Моя с... Nov 23 2006, 12:46 dmyl Проблему поборол, не понятно почему вычитывание да... Nov 23 2006, 16:40  zltigo Цитата(dmyl @ Nov 23 2006, 15:40) Проблем... Nov 23 2006, 18:39   dmyl ЦитатаСтранный подход к делу - НЕ должно оно снима... Nov 24 2006, 10:22    zltigo Цитата(dmyl @ Nov 24 2006, 09:22) Или ест... Nov 24 2006, 15:47     dmyl ЦитатаУж не знаю, как и обьяснить... Вы с железом ... Nov 24 2006, 15:55      zltigo Цитата(dmyl @ Nov 24 2006, 14:55) Если вы... Nov 24 2006, 17:18       dmyl Цитата(zltigo @ Nov 24 2006, 18:18) Для п... Nov 24 2006, 20:26        zltigo Цитата(dmyl @ Nov 24 2006, 19:26) ...там ... Nov 24 2006, 21:33         dmyl Цитата(zltigo @ Nov 24 2006, 22:33) Еще р... Nov 25 2006, 10:23          zltigo Цитата(dmyl @ Nov 25 2006, 09:23) Это пон... Nov 25 2006, 11:58           dmyl Цитата(zltigo @ Nov 25 2006, 12:58) Так в... Nov 25 2006, 14:03            zltigo Цитата(dmyl @ Nov 25 2006, 13:03) Со стар... Nov 25 2006, 15:57             dmyl Цитата(zltigo @ Nov 25 2006, 16:57) Если ... Nov 25 2006, 18:02              zltigo Цитата(dmyl @ Nov 25 2006, 17:02) В каком... Nov 25 2006, 18:54 bombastic Цитата(dmyl @ Nov 22 2006, 11:44) Если то... Nov 24 2006, 14:56 Сергей Борщ Цитата(bombastic @ Nov 24 2006, 13:56) Ци... Nov 24 2006, 16:59 sensor_ua У меня работает чуток рихтанутый вариант обработчи... Nov 28 2006, 17:16
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|