Вобщем задача такая
хочу реализовать параллельную шину данных и 8 ног внешнего прерывания по которым будет опрашиваться шина.
данные с шины должны опрашиваться как можно быстрее т.е. прерываться выполнения IRQ и не допускать вложенности.
Для этих целей хочу использовать FIQ. Использовать EBI для общения как с статической памятью не получится, буду использовать ногодрыг, да и устройство на другой стороне имеет относительно низкую скорость шины.
IRQ будут висеть на таймерах и т.д. а FIQ на физических пинах.

Отсюда вопросы насколько хорошо выполненна реализация IRQ в стандартных примерах атмеля?
из архив at91sam9m10-ekes-softpack-1.9.zip
Если там все по кривому, было бы не плохо увидеть ссылку на правильный код.
Получится ли вообще повесить на 8 ног FIQ прерывания?
Не владею асемблером, где можно посмотреть пример кода с FIQ на этот проц?
сохранение стека, возврат и т.д.
И еще стоит ли вообще использовать FIQ или достаточно использовать на эти 8 ног IRQ с одинаковым самым высоким приоритетом?
будут ли выполняющиеся в этот момент IRQ с более низким приоритетом прерываться для выполнения IRQ с более высоким приоритером?
и как я понимаю вложенности тоже не будет т.к. IRQ будут с одинаковым высоким приоритетом?

Сообщение отредактировал Sergey1212 - Apr 26 2013, 08:08

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


FIQ прерывание одно. Поэтому получится, но только если все ноги находятся в пределах одного порта.


Лучше FIQ, чем вложенные прерывания.

Не подскажите пример хорошей реализации IRQ и FIQ?

Получится. По ИЛИ.

Вы сначала не ассемблер, а описание на ядро ARM7/9 почитайте. Нет там никакого сохранения стека. По соотв. прерыванию (IRQ или FIQ) переключается контекст CPU.

Не будут, но по-другой причине. В ядре нет никаких приоритетов. Если произошло IRQ, то CPU переключается в контекст IRQ и автоматом запрещает IRQ.
То же для FIQ (но запрещаются и IRQ и FIQ).
Приоритеты есть только в контроллере прерываний, который можно использовать, а можно - нет.
Поэтому для одного высокочастотного прерывания ядро ARM7/9 удобнее кортексов: если FIQ происходит, то вход в контекст FIQ очень быстрый и нет необходимости ничего сохранять и восстанавливать.

А вообще для быстрой работы с GPIO лучше использовать DMA (если есть возможность в вашем процессоре).
А дёргание в прерывании и программный ногодрыг - это пустая трата тактов процессора.
А ещё лучше - используйте канал SPI. Мегагерц на 60 думаю сможете его завести. И дорог на плате меньше.

ИМХО, хорошая реализация может выглядеть примерно так:
1. Векторизация через LDR PC, [PC,# -&F20] безо всяких оберток.
2. Если нужны вложенные прерывания (тут надо крепко подумать, нужны ли на самом деле), делаем
индивидуальные обертки для всех процедур прерывания, кроме прерывания с высшим приоритетом.
3. Обработчик FIQ пишем на ассемблере сразу по адресу вектора.

Но некоторое знание ассемблера и тщательное изучение AIC понадобятся в любом случае.

а всетаки пример может кто скинет?
с вложенными IRQ, использованием AIC и FIQ

Сообщение отредактировал Sergey1212 - Apr 26 2013, 11:04

Есть вот такой код фика

но работает он только если я в AIC_SMR[source] = AT91C_AIC_PRIOR_HIGHEST | 0;
а если использую другие варианты (0x2 << 5) или (0x1 << 5) или (0x3 << 5) то прерывание остается активным т.к. все время заходит в процедуру fiq и там прочитанный статус равен 0
если тот же обраотчик вешаю на IRQ то все работает отлично прерывания сбрасываются как положено
т.е. дело не в обработчике
вот код fiq


Подскажите в чем проблема?
И как сделать чтобы переходил по вектору на процедуру сохраненную через AIC
комментирую строку ldr r0, =fiq в фик не попадаю
жытага нет поэтому в слепую очень уж непросто разбираться и учиться
подскажите пожалуйста

Сообщение отредактировал Sergey1212 - May 2 2013, 05:48

Прочитайте внимательно раздел "27.8.4.5 Fast Forcing":
1. Прерывания по фронту в этом режиме автоматически не сбрасываются, поэтому и зависает
2. AIC_FVR всегда возвращает значение из AIC_SVR0

Подумайте, нужны ли вам вообще прерывания по фронту - для внутренних источников (к которым относится и GPIO), в 99.9% случаев смысла работать по фронту нет.

И где же восстановление прерванного режима CPU???
У вас после такого возврата, CPU останется в режиме FIQ, стек разрушится, не говоря уже о том что прерывания останутся запрещёнными.

По-моему - Вы обманываете. Такой код работать не будет.

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

Проблема автора в том, что он не хочет ничего читать из документации на CPU, а хочет надёргать каких-то левых чужих кусков не разбираясь как они работают, и чтобы это всё заработало, да ещё и быстро...


Запускать такие тяжёлые функции из ISR, к тому же ещё на стеке SVC (printf до фига ест стека) неизвестно какого размера (скорей всего - небольшого)???
Ну-ну, успехов!

Нет, тут все правильно: subs pc, lr, #4 восстановит режим.


Если это из атмеловских примеров, то у них как раз все наоборот - стек IRQ/FIQ имеет минимальный размер, а SVC/USR достаточно приличные.
Но правильно, конечно, будет убрать это дурацкое переключение и расширить при необходимости стек FIQ.

Я конечно понимаю что вы очень умный и начитанный документаций до того что даже не можете понять что код рабочий.

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

То что смысл весь фика убиваю так это да, но я непонимаю и незнаю как сделать чтобы было правильно.
Если бы все знал и понимал думаю тут бы не оказался.





Дело в том что если я не по фронту делаю то при подаче на ногу сигнала вызов прерывания повторяется пока этот сигнал не будет снят.
для сброса я так понимаю нужно AIC_ICCR использовать?

Судя по коду обработчика, у вас задействовано прерывание GPIO Input Change. Оно переходит в активный уровень по любому фронту на одной из разрешенных линий. То есть выделение фронта сделано еще до AIC, поэтому последний должен работать по уровню и никаких "повторений" наблюдаться не должно.

Вы-то как это поняли? Методом тыка?

Не поверите, но изучал ассемблер ARM7/9 я как раз без JTAG ещё. А вот без понимания ассемблера дальше приложений пользовательского уровня соваться не стоит.
Не надо делать: впустую переключать контекст, использовать AIC если у вас одно прерывание (да и больше - не всегда он нужен), даже половину регистров в FIQ в ARM7/9-ядрах можно не сохранять, а использовать для static переменных...
Всего этого вы не узнаете пока не прочитаете доку на ядро.

Код в первую очередь отлаживается головой.

Да спасибо, это видимо потому что прерывание не сбрасывал, вот только как то странно получалось как только уровень снимал оно сбрасывалось
щас добавил в обработчик AT91C_BASE_AIC->AIC_ICCR = status;
стало при появлении уровня срабатывать и при исчезновении еще раз
а при настройке по фронту все равно не сбрасывается
а если вы говорите что оно еще до AIC где-то настроено это где тогда?
хотелось бы всетаки по фронту сделать
чтобы появился уровень затем снялся и только тогда прерывание появилось

Да, давненько не писал для ARM7/9. На cortex-ах отвык уже... Не заметил этого модификатора, ведь при применении к PC у него особый смысл
Я всегда делал по-другому: