Добрый день. Столкнулся с непонятной реакцией Keil на этапе настройки прерываний. Суть заключается в том, возникла необходимость использования одной из библиотек, написанных на ANSI С, о чем свидетельствует начало заголовочного файла. При выборе Target Options -> C/C++ -> Strict ANSI C в настройках начинает ругаться компилятор фразой "invalid type conversion" на следующее выражение:

install_irq(TIMER0_INT, (void *)TIMER0_Handler, 1 );

Данная функция определена в другом модуле как unsigned long install_irq( unsigned long IntNumber, void *HandlerAddr, unsigned long Priority ) {...},
причем TIMER0_INT определен в заголовке как

#define TIMER0_INT 4

TIMER0_Handler определена как "void TIMER0_Handler (void) __irq"

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


Не могли бы вы подсказать в каком направлении двигаться в этом случае?

Он ругается на ключевое слово "__irq". Такого слова в строгом ANSI C нет.
Мне кажется, Вы неправильно понимаете опцию ANSI C. Она для того, чтобы отлавливать опечатки/ошибки на этапе написания кода (типа правил MISRA C). Если код готовый и рабочий, то собирать его можно и без опции ANSI C.

В моем случае эта опция необходима, т.к. проект на стадии разработки. =) Есть ли возможность объявить эту функцию в указанном выше режиме?

Непонятно ваше стремление. Нет в ANSI C __irq да и наверное еще чего из мира embedded. Вам рабочая программа ведь нужна? Ну так ее и пишите.

Спасибо за ответ. Очень вразумительно.

Объяви __irq void TIMER0_Handler (void)
Keil не как не определится куда её (__irq) лучше пристроить

Не понимаю, как из "проект на стадии разработки" следует "опция необходима". Нет в ней необходимости.

Вот моё понимание того, почему опция Strict ANSI C существует: если возникло желание написать переносимый код (ANSI C без всяких добавок), то включаем эту опцию, чтобы компилятор сообщал о нарушениях. Кстати, имейте в виду, что для полной переносимости кода одного соблюдения ANSI C мало. Большинство реальных программ содержат и непереносимый код (к примеру, __irq). Такой код группируем в отдельные исходники и их компилируем без опции ANSI C. Вот и всё.

Наоборот, включите поддержку стандарта C99 (по этим буквам в помощи найдете, как), и будете пользоваться всеми его улучшениями, по сравнению с ANSI C.

Необходимость как раз и состоит в "отлове" нарушений...



Ну я примерно так и сделал, поместив код в блоки условной компиляции.



Эта опция уже использовалась.

Сообщение отредактировал le-greem - Jun 27 2011, 04:52

Соглашусь, что незачем себя ограничивать ANSI C если нет требования переносимости или линкуемости с другими модулями на ANSI C. Автор, сосредоточьтесь лучше на написании программы