Если указать паковать структуру побайтно типа
#pragma pack( push, 1 )
....
#pragma pack( pop )

, то тогда ГАРАНТИРОВАННО 1 бай. Если НЕ указать, то на усмотрение компилятора.


Тогда не жалуйтесь.

Переменные во Flash не храняться в принципе

Не больший, чем использовать без допиливания по месту всяких LwIP запимающих по 29K.

Мы, кажется, обсуждали вполне конкретную платформу, не испытывающую трудностей при доступе к переменным с малой разрядностью, так что эти утверждения -

- не соответствуют действительности.


С этим никто не спорит, но специально добавлять padding там, где в нем ни малейшей нужды нет, компилятор не станет.


Напрасно не хотите.

Трудности таки ЕСТЬ, иначе и в первом Вашем примере все было-бы однобайтовым. Во втором "хорошем" примере Ваш конкретный компилятор просто смог соптимизировать.

Это другого рода трудности, возникающие как раз при доступе к "естественной" 32-битной переменной,
а не гипотетические трудности, возникающие при доступе к переменной с разрядностью менее естественной,
и отсутствующие для данной платформы.


Так сделает любой вменяемый компилятор.

Неужели?
v1 = 256;
v2 = v1;
Сколько будет в v2?
Я думаю 0.

Я тоже так думаю, и что?

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

Есть версия, что v1 займет 1 байт (sizeof(v1) = 1), но после v1 будет размещено 3 неиспользуемых байта.
sizeof для такой структуры будет равен 8.

Нужно ли обсуждать такой момент в доступе к невыровненным данным, как сборка многобайтового числа побайтово?
Как известно CM3 может обращаться к невыровненным данным за счет штрафных тактов без генерации исключения.
А, например, CM0 не допускает обращения к невыровненным данным с генерацией исключения.
В этом случае собирать 32-битное невыровненное число нужно по байтам. А это лишние такты и память в случае CM3.

Можно ли компилятору принудительно разрешить или запретить сборку побайтово? Видимо, ответ: RTFM на компилятор.

Второй момент (все наоборот). Есть память с 32/16-битным доступом (например, батареечная память в STM32).
Можно ли в ней разместить структуру элементов с меньшим размером, но чтоб доступ был 32/16-битным?
Как это указать компилятору и можно ли сделать в принципе?

Даже прочитать всё это сложно! не говоря уже о том что бы понять!
Пипец какой!!!
Для программиста на ассемблере это всё просто дико!
Чем люди занимаются вместо алгоритма

как говорил Форест Гамп - алгоритм алгоритму рознь.


товарищи а вы как поступаете?
как выделяете глобальные переменные и члены глобальных структур?

Какая разница КАК? Как не выделяй, если они НУЖНЫ, то они нужны. В Вашем случае, если хоть как то попытаться понять написанное, одна из проблем растраты памяти, это ее выделение оптом под всякие структуры, хоть используемые, хоть нет. На такие действия ответ один - НЕ выделяйте. А Вы какого ожидали? Если общие советы, то тут уже тоже перечислены: http://electronix.ru/forum/index.php?showt...t&p=1409464



Играться с паковкой и ручным добавлением padding.



Очевидно, что рукопашной возней с битами и байтами в низкоуровневых языках.

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

Сообщение отредактировал Jenya7 - Mar 8 2016, 16:18

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


Нет, так нельзя.
Представьте себе сто появился миллиардный пользователь и открыл новую запись а размер этой записи несколько гигабайт.
Вы предусматриваете такую возможность?

Адресную книжку нужно хранить в энергонезависимой памяти, иначе сброс МК приведет к ее потере.
Доступ к адресной книжке может быть довольно медленным, т.к. пользователь во много раз менее быстро способен воспринимать информацию.
Т.е. адресную книжку можно и нужно хранить во flash.

Выложите свой map-файл, тогда все всё увидят и объяснят. А то получится безрезультатный флуд еще на 2 страницы.