Никто не знает, с какого бодуна ИАРовцы решили поменять структуру заголовочных файлов (io430***.h) в новой версии 5.10.6? Сегодня накатил sp6 и вдруг компилятор перестал понимать, что такое UCMST. Полез в io430x26x.h (текуший мой камень), а там выкинута куча #define, частично заменены на struct + enum, причем сделано все через ж... Тот же USMST в UCB0CTL0 переименовали в UCB0MST. а в UCB1CTL0 оставили как USMST, зачем-то ввели для UCB0CTL0 еще одно определение UCB0CTL0__SPI ... В общем, ляпов там выше крыши. Бегло сравнил размеры файлов в INC с предыдщей версией, изменений довольно много. Кто нибудь еще сталкивался с этим? Это у ИАРа идейное (типа, избавляемся от #define, переходим на enum) или просто ляп? Я бы просто откатился назад, но в этой версии появились удобные штучки типа __persistent, __ro_placement... Так что просто подставил старый .h из sp4, но оно не кошерно как-то...
ЗЫ: Не знаю, куда было правильнее поместить тему - в ИАР или МСП, но все-таки ближе к МСП, по-моему.

Всю жизнь с начала освоения MSP430 пользуюсь хедерами (msp430xxxx.h) от производителя (TI) и горя не знаю. Битовые поля мне без необходимости, т.к. работаю с битовыми масками, а другой насущной необходимости использования хедеров от IAR я не вижу.
Вообще уже давно рекомендуется хранить все используемые хедеры в папке проекта, ввиду навязчивого желания IAR все время что-то модифицировать так, что оно становится несовместимо с предыдущими версиями.

У них только один недостаток - если меняешь камень в проекте, приходится бегать по всем файлам и менять их вручную. С иаровсими хедерами проще - везде пишешь io430.h, а тип камня меняешь в настройках проекта.
Хотя, наверное, стоит написать аналог io430.h для тексасовских хедеров. Только поддерживать его придется самому

Нафига? Я пишу один хедер msp430def.h вида

который включаю во все файлы проекта.

Как то не додумался

А почему бы просто не написать
#include "msp430.h"
У меня работает!

Замена дефайнов на структуры - прогрессивное явление. Дикий атавизм, работая на языке C, с присущей ему системой структур, поддерживающих битовые поля, пользоваться масками, получаемых сдвигом единички влево .

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

А вот изменение имен битов в портах - это действительно очень болезненно. Старые проекты перестают при этом компилироваться, а переименование имен битов, порой весьма трудоемко и запутанно. В свое время IAR переименовала несколько штук битов в области USB-регистров у AT90USB647, причем таких, назначение которых я не слишком хорошо понимала . Из-за этого я была просто вне себя от ярости, ругая IAR на чем свет стоит. Пришлось составлять таблицу соответствия старых и новых названий. При этом оказалось, что в даташите на МК как раз использованы НОВЫЕ названия! Тут-то я и осеклась...

Я не в курсе в отношении MSP430-x, но в отношении моего МК удалось выяснить, что компилятор у IAR зачастую появляется еще загодя, когда МК не только еще не появился в продаже, но и даже тогда, когда на него нет даташита. При этом IAR частенько использует хидеры от AVR Studio, переделывая их под себя. А когда выходят на свет даташиты, то некоторые биты в них оказываются названы по-другому. А то случается и так, что такие переименования происходят при появлении даташита новой ревизии. Такая же история повторилась с AT32UC3C (это архитектура AVR32), когда появились новые регистры, а старые сдвинулись со своих мест вместе с ножками по сравнению с UC3A. А ныне грядет внедрение USB в новые модели ATxmega128A1U и ATxmega128B1, тогда как раньше у Xmega USB не было. Надо полагать, что снова начнется чехарда и именами битов, которых у USB-интефейса видимо-невидимо.

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

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

Особенно когда нужно одной командой записать весь регистр начальным значением или сбросить/установить биты сразу в нескольких битовых полях volatile-переменной. Или когда надо какой-то критический кусок написать на асме - вот тут польза от замены дефайнов на структуры очевидна

Компайлер должен это дело соптимизировать в одну операцию, и volatile по идее не помешает.
+1 к отказу от текстовых подстановок, макросов.

Компилятор не имеет права оптимизировать две операции

в одну

, если SFR - volatile.
Поэтому весь этот "синтаксический сахар" в виде структур - вещь весьма неоднозначная.

Совершенно верно! Именно поэтому кажутся безосновательными претензии к IAR за то, что тот якобы изъял все дефайны, заменив их на структуры. Если бы такое случилось, то была бы потеряна возможность манипулировать в регистре более чем одним битом одновременно. А во многих случаях это требование является необходимым.

То есть вы признаёте, что погорячились и были не правы по поводу "дикого атавизма" и дефайнов?

Думаете, я это сам сочинил? Мне бы такое и в страшном сне не приснилось... Хотите, пришлю конкретный хедер. Все там есть: и изьятые дефайны (причем нвполовину, часть битов в одном и том-же регистре определена, часть нет), и несоответствующие даташиту имена. Причем в предыдущих версиях это как раз был нормальный рабочий файл (как обычно, struct+define, полностью соответсвующий даташиту), а изгадили его недавно.
PS: Уже выпустили и 5.20 и 5.20.2, там все то-же.

Сообщение отредактировал =DS= - Jan 20 2011, 02:04

Как раз очень однозначная - привязка "программистов" к конкретному компилятору. Посему всякие хидеры (про "библиотеки" с "визардами" вообще помолчу при дамах ) от производителей компиляторов (да и производителей контроллеров тоже) в их оригинальном виде, сразу "в топку". А если к этому добавить, что они решают только ЧАСТЬ проблемы работы с битами, то быстро-быстро "в топку" - ибо просто лишняя сущность.
Для тех контроллеров, с которыми собираюсь работать не разово, а долго и счастливо ВСЕГДА создаю свои хидеры. Тем более работа эта ввиду своей постепенности и по любому необходимости изучения документации, совершенно необременительна.

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