Камень STM32f107VC. получил неприятный сюрприз – закончился RAM. а я еще даже не начал писать.
в связи с этим хотел задать несколько вопросов.
1. если я объявил глобальную переменную uint8_t под нее все равно выделиться регистр?
2. если я засунул стринг или какую нибудь переменную во флэш - при обращении к нему он копируется в RAM или я обращаюсь в область text?
3. может есть какие нибудь трюки позволяющие экономить RAM?

Какой же регистр для глобальной переменной? Если речь о количестве выделенной памяти, то для такой переменной оно составит 1 байт.


Нет, ничего никуда копироваться не будет. Если есть сомнения, проконтролируйте размещение по map-файлу.

я понял. а я тут все глобальные переменные определяю uint32_t - вычитал что операции с ними происходят быстрее.

а если я создал в глобальной структуре переменную uint8_t? без выравниания она займет 4 байта?

Стеки ужать.
Обнулить память для HEAP.
Перенести структуры в юнионы.
Заменить printf и sprintf на свои версии.
Укоротить циклические буфера.
Заменить в операционке вытеснющие задачи на кооперативные.
Использовать драйвера интерфейсов не одновременно, а с разделением во времени.
...

а если мне нужно хранить несколько членов одновременно?


а как это экономит RAM?
так вроде и так они разделены по времени.

Зависит от окружения:

В этом случае v1 займет 4 байта.


А в этом - 1 байт.

Но как-то сомнительно, чтобы память была выбрана одиночными переменными.
Основные потребители выше перечислены: heap, стеки, буферы.

Вообще-то 4 байта на этой платформе. Если не паковать в структуры.



Всегда по 4, если так или иначе не указывать компилятороу индивидуальные правила паковки, но и в этом случае структура без паковки будет кратна 4 байтам.





А если нет?



Обязательно.

Ну так уж и обнулить, а если она нужна? А вот вместо тупого выделения статического куска, отдавать Heap всю оставшуюся нераспределеной память,
это дело святое. Общая тенденция прямо противоположная - ИСПОЛЬЗОВАТЬ Heap.

Ну не тупо и бездумно, конечно.

Да.

Лобовой совет, но в общем да.

Или да, или нет.

Это уже следствие совета структуры в юнионы сложить.

Компилятор считает иначе.

Конкретный компилятор руководствуясь конкретными глобальными стратегиями может считать, как ему приказали. В общем случае выравнивение у жестко 32bit платформ идет по границе разрядности.

Без каких-либо специальных установок. Насчет "общего случая" не скажу, но смысла в таком выравнивании не просматривается, так что сомневаюсь.

А посмотреть листинг и понять куда RAM ушла можно?

и все таки? To byte or not to byte? 1 байт или 4 байта?

1 байт. Что легко можно проверить самостоятельно.

Смысл прост - если для контролера естественной единицей являются 32 бита, то любые другие размертности приходится преобразовывать, что уже неестественно. Поскольку у конкретного 32bit команда могут быть навороченными - типа взять и сдвинуть за одну команду, то это может уже оказаться при размещении в структуре "беслатно" и в игру вступает оптимизация.
Но по любому, если нужен ГАРАНТИРОВАННЫЙ результат, то только указания компилятору правил паковки, ну а для достижения лучшей оптимизации, это да - все элементы структуры стараться располагать в ней опять-же по границам слов. Ваш второй пример этому условию соответствует.

ну у меня там есть проблемное место - я выделяю массив структур конечного размера. он отжирает 10 кило. если даже я потом создал один элемент все поле занято под массив. просто не хочу пользоваться динамическим выделением памяти. к тому же LWIP отжирает 29 кило.
вот рассматриваю варианты экономии. хранить переменные во флеше - медленный доступ. паковать структуры - тоже удар по быстродействию.

Если указать паковать структуру побайтно типа
#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.
Перенести структуры в юнионы. - я не понял как это возможно.
Использовать драйвера интерфейсов не одновременно, а с разделением во времени. - то же непонятно. (мне).
я создаю массив структур с запасом не потому что я дурак (хотя это тоже) а потому что я не знаю сколько элементов понадобиться пользователю.
представьте адресную книжку - появился новый друг - открыл новую запись.

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


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

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

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

у меня не совсем адресная книжка но принцип тот же. я загружаю с внешнего носителя до десяти контактов. работаю с ними. если был рисет - они снова загрузяться с носителя.
я думал считывать контакты с носителя поэлементно и работать с ними - но это время - считывание, парсинг. так я только один раз это сделал на стартапе.

такой вот он мап-файл.

Неудачная загрузка. Вам запрещено загружать такой тип файлов


а что собственно флудить. либо выделяем все глобальные переменные нужного размера либо все uint32_t, давайте решим наконец.

Оптимизировать нужно там, где наибольший расход.
29К для TCP-стека это что-то уж слишком много. Поменяйте TCP-стек на более экономный.
Для TCP-стека работающего поверх Ethernet-уровня, вполне достаточно очереди приёма в 3-5 ethernet-кадров и очереди передачи в 2-3 ethernet-кадров.
Плюс - несколько десятков байт на информацию о состоянии сокетов и прочие переменные. Всё в сумме это будет около 10кБ (или меньше в зависимости от размера MTU для Ethernet и кол-ва кадров).
Вся обработка всех уровней Ethernet-IP-TCP/UDP и т.п. - на колбэках на этих же кадрах без копирований.

И абсолютно не соглашусь насчёт HEAP - стандартная HEAP в embedded - это зло. К тому-же совершенно не нужна.

Это Вы по собственной дурости и незнанию обвиняете всех сишников огульно в неведомых грехах. А чем Вы занимаетесь в ассемблере и чем я занимался годы и частично в порядке сопровождения продолжаю в ассемблере заниматься, я знаю. Поскольку РАБОТАЮ в одном ассеблере виртуозно, в паре - хорошо, и в десятке терпимо. В отличие от Вас, который и в одном высокоуровневом языке ни уха ни рыла .



Я хочу 22 миллиарда. Можно? Если НЕ знаете, то почему решили назвать конкретное максимальное число и забить его в качестве количества стуктур?
Что Вы вообще делаете? Что это за стуктуры в непонятных количествах?




Слова "стандартная" это непонятно о чем, по причне того, что стандарта-то и нет. Ну и уж тем более не зло, если не пугаться и уметь хоть чуть-чуть готовить.

Под "стандартной" я имел в виду имеющую стандартный malloc-интерфейс, позволяющий побайтное выделение кусков разного размера, приводящее к фрагментации и, соответственно, перерасходу памяти. А здесь как раз тема экономии ОЗУ...
Ещё можно оправдать выделение памяти кусками одинаковой величины (без фрагментации).

Мда.. дядя.. Сразу видно что такое понятие как скромность вам не ведомо.
Виртуоз многостаночник


Еще и тЭлЫпат ...

Искренне жаль вас.

до стэка еще руки не дотянулись. я с LWIP никогда не работал. менять вобщем то не на что. подходящей альтернативы ему нет, я имею в виду соотношение функциональность-вес. так что процесс будет трудный и медленный.


я выделил 10 элементов. пока это вполне разумно. скажем так - лайт версия. тот же компайлер в котором я работаю - лайт версия компилит 32 кило а не 22 милиарда.
структура это пользовательская задача. malloc тут не подходит - пользователь начнет создавать/затирать элементы - хана куче.

Чего нет, того нет. Просто читать умею и написаное Вами, даже только в этой теиме, совершенно все о Вашем уровне говорит с предельной ясностью.





C чего бы это, если элементы, например, одинаковые, то любому даже предельно убогому хана не грозит. Использование какого-то malloc так же совершенно не обязательно - менеджер может быть даже узкоспециализированый под уникальные объекты. Тут ведь дело в использовании самого принципа динамического использования памяти.

Ставьте 16МБ SDRAM и не придется париться :-)

идея не плохая но цена высокая. а как скорость доступа?

нет. не пойдет. нет у меня столько ног для него.


а я могу создать новый объект и положить его по адресу который я указал?

В динамическом выделении будет смысл если, освободившееся место будет так же динамически использоваться для чего-то другого. Это уже может означать, что блоки будут разных размеров. И может понадобится определить правила по которым будет ограничиваться использование памяти для разных целей, если не хотите, чтобы одна задача (не поток выполнения, а в боле широком смысле) съела всю память. Очень непросто может получится.

я вот думаю а что если использовать внешнюю память или SD карту.
С SD картой удобно работать но считывание и парсинг займет много времени.

Не понял зачем? То, что Вы сейчас восжелали есть принципиальная глупость. Если есть какой-то адрес, по по которому хочется что-то положить, то это значит, что сам "объект", пусть даже в качестве куска памяти УЖЕ СУЩЕСТВУЕТ, и "создать новый обьект" по этому адресу логичеси невозможно.



Блоки БУДУТ таких размеров, каких пожелаете.

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

Что то дикие у Вас представления о менеджерах памяти и программировании - "по каким адресам" этим менеджер заниматеся - Вам то зачем что то знать?

Ну так рассказали бы дикарям про менеджеры памяти которые способны памяти добавить при условии отсутствия свопирования.
Учитывая что вся физическая память используется и в любой момент времени может понадобиться доступ к ней в реальном времени.
А не морочили людям голову!

А дикари научись различать "виртуальную память" и "кучу"?

Увы, нет , только "научились" слова, смысла которых не понимают, из "интеренету" в изобилии таскать.




Пытаетесь морочить голову именно Вы. Тема называется "Экономия RAM" а не извлечение ее из эфира. Один их эффективых путей экономии это многократное и повторное использование ресурсов. Для этого можно использовать менеджеры памяти, или в чистом виде, или узкспециализированые решения постороенные на том же принципе динамического выделения памяти.

Лет 10 назад я разрабатывал устройство на AVR + asm.
ОЗУ в наличии было мало, и для работы со статическим распределением всем бы не хватило.
Сделал так: выделил большой кусок, в котором хранил таблицу при штатной работе.
А в режиме обновления ПО, когда штатная работа прекращалась и таблицы были не нужны - использовал
этот кусок для буфера связи с внешним миром и обновления ПО.
Все работало, но про параллельное использование памяти нужно было помнить.
На C с динамической памятью все куда прозрачнее, хотя смысл тот же - разделяемый по времени ресурс в виде ОЗУ.

И что дальше?
Либо вы не тот файл пытаетесь выложить, либо просто переименуйте .map файл в .txt и выкладывайте.

Буквально две недели назад занимался рефакторингом софта двух давноооо выпускаемых железок одна на PIC, другая на M8C c целью свести по максимуму все функционально различающиеся варианты исполнения в единые фирмвари, дабы по минимуму отвлекаться на дальнейшее сопровождение. Вот уж я тут памяти поискал и (в основном) порасшаривал по полной программе до расплавления мозга . Но упаковался и еще осталость чуток.