Имам следната постановка Cortex M3 и GCC компилатор. В кода имам следната структура:

typedef struct {
u8 GroupID;
u8 Level;
T_AcqusitionChannels AcqusitionChannels;
T_AcqusitionFrequency AcqusitionFrequency;
T_AcqusitionResolution AcqusitionResolution;
u8 Reserved[5];
u8 PackageType;
u16 RecordsPerPackage;
u8 DataAwait;
u16 DataPacketLength;
}T_CollectionPropertiesLevel0;

Трите "T_" типа са с размерност байт, демек структурата трябва да е 16 байта дълга. Ама компилатора я прави 18, защото двата u16 типа ги подравнява на 32 бита. Да ама нали кортекса може да аксесва неподравнени... Не е проблем загубената памет, а че тая структура аз я размятам по един протокол и като ми я шибне подравнена с празни полета вътре, става мазало.

На прима виста пробвах с __atribute__((packed)) на двете u16 променливи. И sizeof(T_CollectionPropertiesLevel0) вече връща 16. Ама още не съм разглеждал кода и дали няма да се оплете нещо друго. Няма ли опция на компилатора да си работи по дефоулт с неподравенени данни?

Или аз пак поредните програмистки глупости творя?

Двете ти 16-битови полета се падат на нечетни адреси (неподравнени) и затова преди тях се вмъква по един байт за подравняване, оттам вместо 16 стават 18 байта.

Ако не ти е фиксирана структурата, размени RecordsPerPackage и DataAwait и си готов.

Е нали затова съм го сложил тоя Куртекс, за да мога да аксесвам както ми кефне. Не мога да променя структурата, спуска ми се отгоре. Мога да правя транслаторни гимнастики естествено, ама въпроса е що?

Между другото за проба, размених ги така, че да са на четни адреси -курец, пак ги удължи до 32 бита. За да стане номера, трябва така да ги разбъркам, че да си дойдат точно на границата на цяла дума. Което ми се струва тъпо, компилатора се държи все едно програмирам за ARM7, а не на куртекс, което ме навежда на мисълта, че нещо опции съм оплел. Ама аз си мислех, че да му кажа че е куртекс би трябвало да е достатъчно.

[quote="Цецо" Няма ли опция на компилатора да си работи по дефоулт с неподравенени данни? [/quote]

честно казано не помня дали има опция... Бих могъл да праверя (както и сам можеш), но въпросът е че независимо дали има или няма, масовата практика е да не се ползват дефаулт неща.
Стнадартното (за всички компилатори) е ти да им дадеш свободата да решават кое как да разполагат. Освен ако искаш нещо ти *конкретно* да е по специален начин. И обикновено тия неща се правят с макроси, дето дефинираш според компилатора (IAR/GCC....). Та това е практиката и те съветвам да се придържаш към нея.
Трябват ти два макроса - за пакетиране и за подравняване. Двете неща са различни! Демек трябва да сложиш да подравнява на 1 байт и да пакетира и тогава няма да имаш грижи.

Като ти е твърдо спусната и неподравнена, тогава я обявяваш цялата:

Двете ти 16-битови полета са неподравнени, та ако архитектурата ти (М3) не позволява неподравнен достъп, нямаш много избор и ги четеш пишеш на байтове с макроси/функции. Не познавам Cortex M.

Подравняванията понякога зависят и от ABI модела, ама това 16-битово да се подравнява на 32 звучи звучи невероятно.

Според бърза справка в нета, M3 позволява неподравнен достъп, само че трябва да забраниш да ти генерира exception, което е може би default след RESET. Така че:
1) слагаш на структурата "__attribute__((packed))"
2) пробваш неподравнен достъп до едно от 16-битовите полета
3) ако гърми с exception търсиш и конфигурираш регистъра да го разрешиш

Давай сега като за глупаци.

__attribute__ ((packed)); при мен свърши нещата, т.е. явно "пакетирането" ги намести на нечетните адреси, т.е. завря u16 променливи на нечетни адреси. От там насетне куртекса се оправя добре с тях явно.

Какво е по - различното на "подравняването" на един байт и как се обяснява на GCC - то да го прави (в случай че прави нещо различно де)?

@Владо, не генерира ексепшън, явно по дефоулт е сетнато да не го прави или някъде из стартъп кода някой се е погржил за мен. Ама нали затова ползвам куртекс, за да не мисля за глупости като подравняване.

Аз като си измислям структури, винаги гледам полетата да се падат на такива адреси, че както и да ги подравнява компилатора, все еднакво да е. В краен случай ползвам прагми, ама съвсем в краен. Иначе имам системки, в които има x86 ( PC, по подразбиране подравнява на 8 байта ), MSP430 ( по подразбиране на 2 байта и НЕ МОЖЕ да работи с неподравнени ) и Cortex ( 4 байта, дъвчи ги всякакви ). Между тях се размятат едни структури. Ако за всеки отделен случай се чудя как да ги напасна, все някъде ще гръмне. Случвало ми се е да слягам "reserved" в структурата само заради data alignment.
Така че моят съвет е да редактираш структурите.

Бате, знаем се, ако можех да ги редактирам, мислиш ли, че щях да се двоумя?

Ами различно е... Пакетирането се прави от компилатора и той решава колко голяма ще да е структурата ти - дали 16 или 18 байта.
Обаче на кой адрес ще са аджеба тия 16/18 байта не се решава от компилатора

Това става при линкването, което може да е статично (линкера) или динамично (твоето приложение зарежда динамично код). При теб очевидно е статично линкване, предполагам имаш линкер скрипт, който описва какви секции имаш и как да се подравняват нещата в тия секции. Ти си го писал тоя скрипт, ама си забравил

Та тъй като "подравняването" и "пакетирането" се правят на различни места се налага да имаш и две различни опции...

Писал съм го грънци. Ако го бях писал, нямаше да задавам тъпи въпроси. "Взаимствал" съм го.

Това ли имаш предвид:


Въпросните структури са статични(глобални).

не е това...
Това ти подравнява само етикетите. И аз съм забравил явно Не знам що ми е останало в паметта, че на секциите може да се задава размер за подравняване...


А трябва ли ти всъщност? Ако си с глобални структури то ще си ги разположи на подравнени адреси, теб ти е важно пакетирането само...

Да де. С "attribute packet" нещата се наместиха. Въпроса беше да си изясня нещата.

Не съм много акъл да давам, ама да знаеш че на тия куртекси има периферии които не могат да работят коректно с адреси, които не са алигнати на 32. DMA примерно...

чак сега ми остана време да го погледна...

Може да се задава подравняване на output секциите:

Но винаги се гледаt и ограниченията от input секциите и се взема най-рестриктивното, т.е. горния пример ще подравни на 16 байта, освен ако няма още по-тежко изискване в сорса.

Това няма връзка с проблемите на Цецо обаче... на него му трябва само пакетиране на структурата.