по прерыванию от порта PIO считываются последовательные данные, то есть при каждом прерывании считывается один бит:

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

записывает данные в некий буфер.
но помимо этого одновременно может идти передача данных по прерываниюот другого таймера, работающего в режиме генератора:

Передача и прием идут с частотой 100 кГц. Приоритеты всех прерываний 7, то есть по идее они должны выполняться по очереди. Но при этом обработчик таймера паузы должен успеть все сделать до прихода следующего слова.
Передача и прием по отдельности работают нормально, без сбоев. Но при их одновременной работе прием не нарушается, а передача происходит с ошибками и в дальнейшем вовсе останавливается. Поэтому я и решил оптимизировать обработчики прерываний.
Для начала я решил все обработчики поместить в RAM, но тут столкнулся с интересной особенностью, если обработчик приемника void irq_Receive() не помещать в ОЗУ, то прием идет очень медленно, не успевает. Но, если обработчик передатчика void timer0_irq_handler() поместить в ОЗУ, то при одновременной работе приемника и передатчика (замыкание выхода передатчика на вход приемника) данные вообще не передаются, а если не помещать в ОЗУ то немного данных передаются. Как правильно размещать обработчики прерываний в ОЗУ и значительно ли это ускоряет работу?

А где код, который вызывает все эти обработчики? У них общий хэндлер?

Структура программы следующая:

Прием и передача идут одновременно с частотой 100 кГц. То есть за 5 мкс необходимо подготовить данные для передачи и выставить их в порт, а за следующие 5 мкс считать данные, которые к тому времени находятся в порту. А во время паузы (40 мкс) надо успеть записать принятое слово в буфер. Для этого я все обработчики помещаю в ОЗУ с помощью __ramfunc. Но при этом какие то сбои происходят при приеме, но когда я убираю из ОЗУ обработчик передатчика timer0_irq_handler, то данные начинают идти, хотя не все... Почему так происходит и как правильно размещать в ОЗУ обработчики прерываний? Все 3 прерывания имеют одинаковый приоритет 7.

Ну понятно. Значит ни входа/выхода в прерывание не организовано (__arm __irq), ни сброса VIC/AIC на выходе из прерывания. Удивительно, что что-то вообще работает.

так выход же у меня происходит путем считывания статусного регистра dummy = AT91C_BASE_PIOA->PIO_ISR или еще нужно в конце обработчика делать запись AT91C_BASE_AIC->AIC_EOICR = 1 ?
по поводу (__arm __irq), я так делал, но у меня возникала ошибка: Error[Pe167]: argument of type "void (__arm __irq __atpcs *)()" is incompatible with parameter of type "void и компилятор ссылался на функцию конфигурации прерывания: AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, MipsTimer.Id, TIMER_INTERRUPT_LEVEL,AT91C_AIC_SRCTYPE_EXT_NEGATIVE_EDGE, timer0_irq_handler);

Именно это должно быть в конце каждого обработчика.

Не знаю что там за проблема, но без __arm __irq (когда нет одного общего на всех хэндлера) нормально прога работать не будет.

Тип преобразуйте:


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

AT91C_AIC_SRCTYPE_EXT_NEGATIVE_EDGE - почему EXT, на кой хрен, простите, EDGE????

дело в том, что все это уже прописано в моем стартапе:
-вход в прерывание B IRQ_Handler_Entry ; 0x18 IRQ
- и конец прерывания str r14, [r14, #AIC_EOICR]
Прикрепляю Cstartup.


Да, извините, тут я упустил. Сейчас во всех 3-х прерываниях поставил AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL.
Только проблема не решилась. А почему у этого контроллера прерывания от порта срабатывают 2 раза - по фронту и по спаду? Для чего тогда ставить AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL или AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE? Может из-за этого контроллер не успевает обработать все прерывания друг за другом. У всех жи одинаковый приоритет.

Потому что так устроен контроллер PIO - генерирует прерывание по любому фронту.


А для чего вообще работать с внутренними источниками прерываний по фронту?

Значит я правильно пользуюсь прерываниями с моим стартапом? Конфликтов между прерываниями никаких не может возникнуть в случае одновременного вызова, учитывая, что приоритеты однинаковы?

Правильно - понятие относительное Да, пользуетесь правильно: для прерываний не нужны модификаторы __irq и запись EOICR, конфликтов не будет.
Но само по себе использование такого кащенитского стартапа является большой ошибкой.

то есть из-за этого стартапа могут проблемы возникнуть?
а могут проблемы быть из-за того, что прерывания от порта 2 раза возникают при приходе одного бита? это же дополнительное аремя на вызов и обработку прерывания.

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


Вы с оптимизацией разобрались? Пока компилятор генерирует код вроде того, что вчера публиковался, о прерываниях с частотой 100кГц лучше забыть.

я пытался применить локальную оптимизацию для обработчиков прерываний таким образом:

но напротив #pragma optimize=s 9 вылазит ворнинг следующего содержания: Warning[Go003]: Optimization can only be lowered from the default, not raised
Но ведь в настройках я вообще отключил оптимизацию. Почему возникает такое предупреждение?

И зачем?


Верните глобальную оптимизацию на место и перепешите обработчики.

Где локальные переменные?
Зачем с периферией работать через левые указатели (regs, MipsTimerBase)?
Это вот -

- зачем повторять в каждом прерывании?