Цитата(=DS= @ Nov 8 2010, 21:35)

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

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

. Из-за этого я была просто вне себя от ярости, ругая IAR на чем свет стоит. Пришлось составлять таблицу соответствия старых и новых названий. При этом оказалось, что в даташите на МК как раз использованы НОВЫЕ названия! Тут-то я и осеклась...
Я не в курсе в отношении MSP430-x, но в отношении моего МК удалось выяснить, что компилятор у IAR зачастую появляется еще загодя, когда МК не только еще не появился в продаже, но и даже тогда, когда на него нет даташита. При этом IAR частенько использует хидеры от AVR Studio, переделывая их под себя. А когда выходят на свет даташиты, то некоторые биты в них оказываются названы по-другому. А то случается и так, что такие переименования происходят при появлении даташита новой ревизии. Такая же история повторилась с AT32UC3C (это архитектура AVR32), когда появились новые регистры, а старые сдвинулись со своих мест вместе с ножками

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