Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Выравнивание полей в структурах IAR STM32?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Rash
Приветствую.
Переношу проект с 8-bit (AVR) на 32-bit (STM32F4xx) и столкнулся с проблемой выровненных данных. Дело в том что обмен по SPI 8 битный. Полученные данные по SPI вычитываются в массив через DMA и накладываются на структуру с не выровненными данными (8бит, 16 бит, битовые поля). В результате не правильный результат. Пока обошёл это дело через pragma pack.

Код
#pragma pack(push, 1)
typedef struct name
{

} name_t
#pragma pack(pop)


Всё работает, но не очень нравиться такая запись, дабы не напороться в дальнейшем на грабли, т.к оформляется всё виде драйвера на устройство и больше туда что б не лезть. Перебирать индексы массива не хочется, теряется наглядность. Есть ли какие ещё варианты записи структуры структуру с не выровненными данными, что бы наложить на массив данных?

Используется IAR6.5, в дальнейшим поддержка проекта будет только в IARе, потому вопрос совместимости с другими компиляторами особо не важен.
Железо будет только Cortex M4 или M3, про ограничения на других АРМах не актуально.

ЗЫ: Заметил ещё неприятную особенность записи pragma pack, как только делаешь сохранения в том файле, где записано pragma pack, то после перепрошивки перестают работать внешние прерывания. Если потом сделать сохранить в другом файле и зашить снова, то всё работает. С чем связано не понятно.
scifi
Цитата(Rash @ Sep 7 2013, 15:32) *
Всё работает, но не очень нравиться такая запись, дабы не напороться в дальнейшем на грабли, т.к оформляется всё виде драйвера на устройство и больше туда что б не лезть. Перебирать индексы массива не хочется, теряется наглядность. Есть ли какие ещё варианты записи структуры структуру с не выровненными данными, что бы наложить на массив данных?

Других вариантов, по большому счёту, нет. Или структура и, как следствие, нестандартная прагма, или честная сериализация.
Если боитесь грабель, то можно вставить в код проверку. Например, вычислить смещение в байтах для последнего поля структуры и проверять его:
Код
assert_static(offsetof(struct my_struct, last_field) == LAST_OFFSET);
jcxz
Цитата(Rash @ Sep 7 2013, 17:32) *
Всё работает, но не очень нравиться такая запись, дабы не напороться в дальнейшем на грабли, т.к оформляется всё виде драйвера на устройство и больше туда что б не лезть. Перебирать индексы массива не хочется, теряется наглядность. Есть ли какие ещё варианты записи структуры структуру с не выровненными данными, что бы наложить на массив данных?

Другой способ я описывал буквально на днях здесь:
http://electronix.ru/forum/index.php?showt...15&start=15
Но это имеет смысл только если код надо переносить между разными компиляторами.
Rash
читал эту тему, но не совсем понял про запись макросов load() и save(), да и у меня Си, а не Си++
jcxz
1.Для ядер поддерживающих невыровненный доступ (Cortex-Mx, x86, ...) эти макросы расширяются в обыкновенную операцию чтения/записи соответствующей разрядности.
2.Для ядер не поддерживающих невыровненный доступ (ARM7/9) эти макросы расширяются в набор байтовых операций чтения/записи с последующим объединением в единый результат OR-ами. То же самое делает компилятор для членов u16/u32 внутри #pragma pack(push, 1)...#pragma pack(pop) неявно.
Rash
т.е. для Кортексов, данные макросы бессмысленны?
jcxz
Макросы - да, классы - нет.
Rash
так в Си нет классов
Rash
Цитата(Rash @ Sep 7 2013, 14:32) *
ЗЫ: Заметил ещё неприятную особенность записи pragma pack, как только делаешь сохранения в том файле, где записано pragma pack, то после перепрошивки перестают работать внешние прерывания. Если потом сделать сохранить в другом файле и зашить снова, то всё работает. С чем связано не понятно.

это моё заблуждение, процессор слишком быстрый, я не выдержал тайминги для упр. сигналов периферии по SPI поэтому не всегда проходила правильная инициализация доп. оборудования, а следсвия внешние прерывания для него.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.