Опять засада, правда почти разобрался

вобщем делаю в IAR определения для АЦП-ешки


Для того чтобы посмотреть, что там у меня получается -сделал прогу в С++ Builder
чтобы можно было настройки АЦП передавать своей DSP плате по посл. порту.
посмотрел в билдере sizeof(ADS131_Params)
опа - 28 байт
думаю, ну ладно, у меня объем буфера приема большой - не страшно
На приемной стороне нули, вместо адекватных значений.
Квырялся полдня - потом все же посмотрел, что IAR трактует енумы как байты
поэтому значения попадают на поле с нулем.
Надо исправить, но не знаю как как!
не хочу менять на u8 - так как названия ADS131_XXX более понятны
ищу опции у IAR "treat enum as int" или чего то подобное
не могу найти в опциях.
Как это правильно сделать?

в IAR enum: на cortex/arm четыре байт, avr - один байт, и инт там 2 байта. У вас какая архитектура ?
увеличить можно через union


p.s. гляньте свой предыдущий топик

enum == int, а вот разрядность int зависит от архитектуры микроконтроллера.

Каим местом вообще enum к тому что Вы хотите родить???

Граждане, храните деньги читайте доки, особенно EWARM_DevelopmentGuide:

А последняя строка - как раз об опции в командной строке делать все emum не меньше чем int.

ЗЫ. А также поддержу предыдущего оратора в том, что все эти ухищрения с размерами перечислений вряд ли помогут ввиду другой "особенности" языка. Дело в том, что представление структур в памяти (layout) тоже Implementation-defined, т.е. разные компиляторы могут по-разному разложить структуру в памяти.
Единственный надёжный способ общаться с внешним по отношению к программе миром - преобразование из внутреннего представления в четко определённый формат для передачи и обратное преобразование на приёме.
Сейчас это называется сериализация/десериализация.

PPS. Посмотрел что Ваши предыдущие темы были про техасские DSP, у них с пречислениями может быть иначе, в любом случае это должно быть описано в документации на компилятор. И засада со структурами тоже никуда не денется.

знаем. гугель протобуф
токак оне не поддерживает char

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

протобуф - это достаточно навороченное решение. Есть и значительно более простые. Проблема в том, что раскладка структур может отличаться в широких пределах - тут и размер enum, и размер int и выравнивание и т.п. Так что рекомендую таки озаботиться сразу не только enum. Если и закладываться на раскладку структуры, то как минимум использовать типы с фиксированным размером (вроде int32_t), добавить директивы упаковки. Enum возможно имеет смысл убрать, заменив на uint8_t. Или обновить компилятор - в с++11 есть class enum, которому можно задать тип хранения.

если в IAR - то C/C++ Compiler -> Extra Options
поставить галку Use...
и добавить --enum_is_int

Зачем вообще это ТАК сделано? В чем смысл наворачивания через enum типов, вместо описания нормальной структуры?

После серии граблей (размеры, выравнивание) для себя решил НИКОГДА не использовать структуры напрямую для приема-передачи.

смысл в том, что если мы в ХХХmode попытаемся засунуть константу ХХХfreq, то получим по рукам от компилятора (по крайней мере в плюсах, насчет голого си - не уверен)

Правда enum до с++11 проблематично использовать там, где нужен фиксированный размер. Но это уже другой вопрос

Ваша версия IAR так не умеет?

enum A : short
{
};

У меня мнение строго противоположное.
Всё решаю при помощи атрибутов.
На всех платформах, что я использовал, всегда предсказуемое и ожидаемое поведение.

Да, если не забыть защититься от возможных ошибок, связанных с порядком байтов.

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