А не наоборот? Из мануала по LPC24xx

То есть четвертый приоритет выше пятого.


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

Сообщение отредактировал Novichok1 - Mar 5 2010, 12:25

Не парьтесь, выравнивание на ARM7 не влияет ни на что. На LPC2xxx даже можно SP по модулю 4 не выравнивать (Хотя не проверял, но по всем признакам это так)



Вероятнее всего функция объявлена не как прерывание, а как просто функция. Там в атрибутах ещё должно указываться тип IRQ или FIQ, но точно не проверял как это влияет на прологи/эпилоги. Просто ставил всегда, когда не ставил свои обёртки. Со своими обёртками использовал атрибут naked.

Сообщение отредактировал GetSmart - Mar 5 2010, 12:38

Наоборот, не важно, уберите цифры и читайте больший-меньший.


Легко. Вы думаете, этот код великие корифеи пишут? Да и на старуху бывает проруха.


Ну, когда наткнетесь на некорректную работу плавучки, вспомните про выравнивание стека

Ох, виновен, виновен. Вот пролог:

и эпилог:

То есть вроде все нормально. Но глюк то есть.

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

Сообщение отредактировал Novichok1 - Mar 5 2010, 12:48

Нихрена не нормально. Это бага GCC. Оно два раза вычетает из LR (адрес возврата в основную прогу) число 4. Кстати, я сразу не заметил, но и в первом прерывании та же самая беда.


Такого не должно быть. Эта вещь реализована аппаратно в контроллере прерываний. Единственная причина по которой проц не может улететь на более высокоприоритетное прерывание - запрещённые глобально прерывания (все). То бишь установленный в "1" флаг I в регистре флагов.

Сообщение отредактировал GetSmart - Mar 5 2010, 12:57

О! А этот вопрос был у меня в начале этой темы, не подскажете, как в GCC создавать свои атрибуты? Очень интересно и думаю будет полезно.

Это не свой атрибут, а стандартный. Используется так:
void AdcIntr_Wrapper() __attribute__((naked));
Но очень желательно в GCC с такой обёрткой делать пустую функцию (пустышку) из которой будет вызываться основная функция обработчика. Иначе можно встать на другие грабли, когда из кода выкинется выделение фрейма в стеке.

И ещё вопрос. В тестируемом коде по адресу 0x18 стоит команда LDR PC,[PC,#-0x120] ?

Странно, я же сбрасываю его в ноль:

/* (4) Change to SYS mode and enable IRQ */
msr cpsr_c, #0x1F


Спасибо, а не в курсе, в GCC все-таки можно создавать свои атрибуты?

Не, не в курсе. Я с GCC недавно пересёкся и не знаю что там к чему. Есть здесь такой чел klen он должен быть в курсах.

Кстати, пустышку-обработчик не стоит обзывать static иначе она оптимизируется и выкинется.

Если глобальные прерывания разрешены, значит что-то другое делаете не так. Может приоритеты неправильно задаёте. Вы тут периодически ошибаетесь, а мне гадать не интересно.

Novichok1, хотел ещё спросить, зачем было делать обработчик функцией класса? Ведь изнутри обработчика всё равно доступа к классу не будет.

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

Я бы всё таки выделил прерывания из класса. ИМХО это логичнее, так как действует по другому механизму вызова/передачи параметров. А уже из прерывания можно вызывать функцию(и) любого статического экземпляра, либо из статического указателя. В частности только для этого можно создать функцию класса, вызываемую из обработчика. Но сам обработчик будет вне класса. Во-первых из-за глюков компилятора и обходных путей этих глюков. Я пару постов назад описывал обходной путь именно для сишных функций (хоть с++ вне класса). На функциях класса этот путь не проверял. Знаю только что обычным функциям класса передаётся "невидимый" параметр с указателем на текущий экземпляр класса. Как работает этот механизм со статическими функциями не знаю, может оказаться что им тоже должен передаваться какой-то параметр, который при вызове обработчика прерывания отсутствует.

Да и само по себе прерывание ни к какому классу не должно относиться. Это функция процессора и процессор (если считать его классом) существует в единственном экземпляре, как и конкретное прерывание. Даже со стороны ООП подхода к проге я не вижу причин делать прерывание функцией класса. Но это моё сугубо личное мнение.

Это верно, но только для нестатических методов, то есть которые привязаны к конкретному экземпляру класса, на статические методы, которые принадлежат типу, а не конкретному экземпляру данного типа, это не распространяется, никаких невидимых параметров, типа параметра "this" туда не передается.


О, а это очень даже полезная идея! Насколько я Вас понял, Вы предлагаете примерно следующее: этот главный обработчик обернуть в нечто подобное делегату из C#. В итоге это даст возможность легко подписываться на это прерывание из разных мест разным классам. Правда неизбежны некоторые накладные расходы на вызовы функций и дополнительные проверки.

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

А минимально, по простому:

Накладных расходов здесь почти нет. Главный накладной расход - компилятор GCC, так как у него не самый оптимальный код.

В принципе, можно даже MyIrq() сократить, только предворительно проверить что за код создаёт компилер во всех режимах оптимизации. Лишь бы фрейм стека не выделялся.

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

Сообщение отредактировал GetSmart - Mar 11 2010, 19:08

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

А код я бы по другому сделал, например что-то типа:


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

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

Сообщение отредактировал Novichok1 - Mar 12 2010, 05:05