Други! Выручайте! Зациклился. Пытаюсь реализовать обработку FIQ прерываний как описано http://www.keil.com/support/man/docs/ca/ca_le_fiq.htm. Но при компиляции выдаёт ошибку error: #130: expected a "{". Хотя реально никакой синтаксической ошибки нет! Может кто сталкивался?

У разных компилеров свой синтаксис атрибутов процедур. Вероятно тот пример не для кейла. Вероятнее всего нужно изменить заголовок процедуры под кейл. Читайте хелп на кейл.

Ничего не понимаю! Я ж на сайте кейла хелп смотрел!!!

В двух словах что делаю.
1. Файл Startup.s
- импортирую имя C-шной функции: IMPORT MyFIQ_Handler
- указываю переход на эту функцию:
...
FIQ_Handler B MyFIQ_Handler
...
2. В файле проекта, например, Application.c, реализую эту функцию:
void MyFIQ_Handler(void) __fiq
{
/* Чего-то делается */
}

Где ошибка?

Точно. Я и не заметил что сайт кейла
Просто когда выдаётся ошибка '{' expected - это означает, что встретилось что-то ненужное вроде атрибута __fiq там, где он не нужен. В ИАРе этот атрибут ставится перед заголовком процедуры, если поставить после то ИАР тоже ругается.

Вообще-то это даже и не важно! Ошибка выдаётся даже вот с таким текстом:

void MyFIQ_Handler(void) __fiq
{
}

Если аттрибут __fiq переместить в начало определения функции, то выдаётся другая синтаксическая ошибка. С атрибутом __irq такой ерунды не происходит куда бы его не поставить! Он всегда воспринимается правильно.

Если используется компилятор RealView, то там __fiq нет.

Атрибут __fiq кончился вместе с компилятором CARM. У RVCT есть только __irq.

Поясните, пожайлуйста, а как тогда реализовать FIQ?
Действительно, если всё оставить как есть и только убрать __fiq, то всё начинает компилится, НО! Программа вылетает, кажется, в Undefined Mode! Я предполагал, что именно атрибут __fiq обеспечивает правильное сохранение/восстановление регистров. В частности, PC.

Напишите __irq - будет работать. Если хотите использовать преимущества дополнительного банка регистров, пишите обработчик FIQ на асме.

То есть реализовать FIQ на С в кейле невозможно? Вот это да! Вот тебе и хвалёный на всех семинарах кейл! А чего же в хелпе это не отражено?

А разумное объяснение у них есть?!

У тебя с стартапе так релизовано?

Какой проц используешь?

Почему невозможно-то? Возможно, просто не так эффективно будет.


Потому что Вы читаете хелп не от того компилятора.



А зачем тут что-то объяснять? Они вполне разумно решили, что пользователю лучше самому разобраться с банком FIQ, если оно ему надо. А если не надо, то можно использовать __irq.


Ну и к чему все это?

Осталось только раздражение на кейл! Зачем же комплектовать IDE старым хелпом. Там тоже описан атрибут __fiq. Не буду переходить с IAR на Keil

Глупость да и только. Никаких сложностей __fiq не требовал. Кроме этого раньше была аналогичная глупость с вложенными прерываниями. Браво, Кейл!

Да почему непонятно? Зачем зарываться в асм?


Глупость - использовать модификатор __fiq не вдаваясь в подробности, дескать, компилятор все сделает. Максимум, что он может - это сократить сохранение/восстановление контекста, человек способен придумать более разумное использование банка.

Это законное удобство, на которое расчитывает юзер компилятора. Да, хотя бы не сохранять 4 регистра, уже экономия.
Какой человек? Что придумать?

Вместо __fiq поставь __irq. Проверенно работает. Толко вход в фунцию рекомендую писать на ассемблере.

Удобства и экономии на 3 копейки, при заметном усложнении компилятора (типа, тут используем вместо R0-R3 R8-R11, но если есть вызов вложенных процедур, то используем R8-R11 для сохранения R0-R3, и все это ради одного обработчика).


Ну, если думать некому, то можно просто писать __irq - проигрыш от лишних сохранений затереятся на фоне других "изысков".

Ну а причем тут Keil?
У Keil'овского компилятора как раз __fiq атрибут поддерживается.
Браво адресуйте непосредственно ARM-LTD, т.к. RVCT это их творение.


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

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



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

Да, интересно, что ответили бы разрабы RealView на вопрос об отсутствии обёртки для FIQ...
Лидеры, млин, в, так сказать, компилеростроении

ЗЫ: хорошо жить на свете с кортексом, никаких заморочек с обёртками

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

Возвращаясь к теме - некий магический атрибут __fiq, который якобы сделает все максимально быстро и эффективно, на самом деле ничего не сделает, - не догадается компилер хранить static переменные в регистрах FIQ банка...
Отсутствие __fiq в RVCT дисциплинирует, и еще раз заставит задуматься нужен ли там __FAST__ IRQ. Если нужен - Asm в руки и делаем настоящий FAST. А если не нужен (FIQ используется просто как более приоритетный IRQ) то чем __irq атрибут не устраивает?

Зачем тогда С компилятор нужен. На Asm всю прогу писать "Надёжней", "Качественней", сроки реализации "Немногим" медленнее, отладка совсем чуть-чуть, а главное программа выполняется быстрей (иногда), ... . Я согласен, что разработчики компилятора не боги, но и компилятор стоит не дешёво (хотя для кого как и где).
В данном примере действительно правильней реализовать на АSМ, из-за недостатка среды разработки.
Зачем брать автомобиль, который иногда приходится толкать?

С тем же успехом можно возмущаться, что не предусмотрены атрибуты для режимов abort и не встроен обработчик swi. Сколько у Вас FIQ в программе? Я почему-то думаю, что от 0 до 1.

Один. Программно интерфейс пришлось реализовать. А с __swi все в порядке, использую довольно часто. В обще использую Keil только из-за OS, и некоторых удобств в разработке. Последние время больше симпатизирую IAR.

__swi - это вызов, обработчик-то все равно нужен самописный, более того, на асме (sic!). Не напрягает?

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

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

Я, считаю, что я способен думать и без таких заботливых "подсказок".

Если нужно выжать по максимуму я и сам напишу его обработчик на ASM в startup прямо с адреса 0x1C. Если нужно будет написать развеситый обработчик FIQ (есть у меня и такие на многие килобайты), то __fiq мне в этом, как минимум ну СОВСЕМ ничем не помешает. Ну а если просто какой-то средненький о сотню байт, то я предпочту писать на 'C' ( естественно осознавая, что потери, нежели мне вдруг с бодуна придет мысль о вызове, например, функций из обработчика, будут малосовметимыми со скоростью), нежели на ASM благодаря "заботе" об излечении от каких-то якобы имеющихся у пользователей "иллюзий".