Hi, All!
Осваиваю scmRTOS под AVR (http://scmrtos.narod.ru). Первые впечатления положительные, но столкнулся с такой проблемой.
Если установлен любой уровень оптимизации, кроме максимального, IDE компилит с ключом --no_inline, и, соответственно на объяления inline и соответствующую прагму кладет. А при такой компиляции scmRTOS не работает (а сколько сил ушло, пока я с этим разобрался! :-), некорректно переключает контекст.
При компиляции с максимальной оптимизацией scmRTOS работает, но в таком режиме совершенно невозможно пользоваться отладчиком - многих переменных не видно, программа прыгает черти куда (у меня JTAG ICE MKII).
Как заставить IARовскую IDE компилировать с включенными инлайнами и без оптимизации? Прагма inline=force не помогает. IAR AVR 4.11A

Совсем без оптимизации очевидно не получится.
Попробуйте установить такой уровень оптимизации, при котором inline ещё работает.
Что касается переменных, то оптимизируются, как правило, только локальные.
Попробуйте также отладку по disassembly с открытым рядом окном исходника. Так можно избежать прыжков "в никуда".
Сам использую эту RTOS, проект весит уже 120 кбайт (не считая загрузчика), оптимизация по скорости максимальная (при меньшей не влезет в память). Отладку делаю так, как сказал. Уже привык.

Мне кажется, это вовсе не столь очевидно :-) На мой взгляд, это IARовская IDE своевольничает



Я уже придумал - ставлю максимальный уровень оптимизации, а все галочки, кроме инлайн, снимаю. Стало полегче :-)

Если Вы используете эту ОС, может сталкивались еще с одной проблемой. Почему-то, когда я компилю из IDE, дефайн __HAS_RAMPZ всегда оказывается определенным, хотя стоит Mega128, этого регистра не имеющая. И, соответсвенно, кол-во регистров не совпадает, и контекст переключается некорректно. Вышел из положения, определив свой аналогичный дефайн и подрихтовав исходник ОС, но это же не кошерно.. Это глюк IAR или я что-то не понимаю?

Вообще-то, у меги128 есть RAMPZ.

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

И точно! :-) Я все перепутал. __HAS_RAMPZ__ в сишных модулях определен правильно, а вот в ассемблерном не определен HAS_RAMPZ, поэтому и контекст некорректно восстанавливается. Места, где он определяется, мне найти не удалось.

Определите __HAS_RAMPZ__ (без #define, только одно определение на строку) здесь:
Project\Options\Assembler\Preprocessor\Defined symbols

[[/quote]
Определите __HAS_RAMPZ__ (без #define, только одно определение на строку) здесь:
Project\Options\Assembler\Preprocessor\Defined symbols
[/quote]

Да где определить я знаю, уже определил. Ммне непонятно, как оно определяется в авторской сборке? Оно же из командной строки, и следов такого дефайна я не нашел.

sz36 вопрос немного не в тему. А у Вас JTAG ICE MK2 не "вываливается" из захвата? Случаются ли у Вас сбои JTAG при отладке? И ещё один. Если после останова отладки (МК перестартовывает) выключить и вкл. питание, то работает всё нормально?
А то у меня проблемы некоторые, а я разобраться не могу.

Что значит "вываливается" не понял. Но так, чтобы он точку следующего останова (Step into, Step over, Run to cursor) потерял - сплошь и рядом. Особено Step over. Это с уровнем оптимизации связано, чем он выше, тем чаще такие штуки происходят. Причем, изредка даже при хождении по дизассемблированному тексту.

Еще один нюанс - оно не больше 2 точек останова нормально может, если их больше тормоза дикие начинаются, что можно ошибочно принять за зависание. Например, если у нас где-то определена точка останова, мы стоим на if, из которого два пути, то всего получается три, и при Step over оно безнадежно задумается.


Так вроде нормально... хотя я точно не помню. Но вот если не выходя из отладчика питание отключить, то выскочит ошибка (что правильно), и потом, с некоторой вероятностью, C-SPY эмулятор теряет, помогает отключить USB и включить заново, и перезапустить C-SPY