Экономия RAM. Опции

[Jenya7]

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

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

[aaarrr]

1. если я объявил глобальную переменную uint8_t под нее все равно выделиться регистр?

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

2. если я засунул стринг или какую нибудь переменную во флэш - при обращении к нему он копируется в RAM или я обращаюсь в область text?

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

[Jenya7]

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


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

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

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

[AlexandrY]

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

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

[Jenya7]

Перенести структуры в юнионы.

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

Использовать драйвера интерфейсов не одновременно, а с разделением во времени.

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

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

[aaarrr]

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

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

Код

struct
{
     uint8_t    v1;
     uint32_t   v2;
}

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

Код

struct
{
     uint8_t    v1;
     uint8_t    v2;
     uint16_t   v3;
}

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

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

[zltigo]

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

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

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

CODE

struct
{
     uint8_t    v1;
     uint32_t   v2;
}

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

CODE

struct
{
     uint8_t    v1;
     uint8_t    v2;
     uint16_t   v3;
}

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

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

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

А если нет?

Стеки ужать.

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

Обнулить память для HEAP.

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

Перенести структуры в юнионы.

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

Заменить printf и sprintf на свои версии.

Да.

Укоротить циклические буфера.

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

Заменить в операционке вытеснющие задачи на кооперативные.

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

Использовать драйвера интерфейсов не одновременно, а с разделением во времени.

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

[aaarrr]

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

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

[zltigo]

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

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

[aaarrr]

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

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

[adnega]

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

[Jenya7]

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

[aaarrr]

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

[zltigo]

но смысла в таком выравнивании не просматривается, так что сомневаюсь.

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

[Jenya7]

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

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

[zltigo]

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

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

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

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

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

хранить переменные во флеше - медленный доступ.

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

паковать структуры - тоже удар по быстродействию.

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

[aaarrr]

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

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

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

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

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

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

просто не хочу пользоваться динамическим выделением памяти.

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

[zltigo]

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

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

[aaarrr]

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

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

Во втором "хорошем" примере Ваш конкретный компилятор просто смог соптимизировать.

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

[adnega]

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

Код

struct
{
     uint8_t    v1;
     uint32_t   v2;
}

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

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

[aaarrr]

Я думаю 0.

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

[zltigo]

Это другого рода трудности, возникающие как раз при доступе к "естественной" 32-битной переменной,

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

[adnega]

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

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

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

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

[zombi]

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

[Jenya7]

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

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


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

[zltigo]

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

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

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

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

Чем люди занимаются вместо алгоритма

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

[Jenya7]

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



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



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

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

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

[zombi]

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

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

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

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

[adnega]

представьте адресную книжку - появился новый друг - открыл новую запись.

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

[HardEgor]

ну что значит - как не выделяй. можно создать переменную uint8_t а можно uint32_t.

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

[Jenya7]

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

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

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

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

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


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



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

[jcxz]

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

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

[zltigo]

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

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

я создаю массив структур с запасом не потому что я дурак (хотя это тоже) а потому что я не знаю сколько элементов понадобиться пользователю.

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

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

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

[jcxz]

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

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

[zombi]

Поскольку РАБОТАЮ в одном ассеблере виртуозно, в паре - хорошо, и в десятке терпимо.

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

В отличие от Вас, который и в одном высокоуровневом языке ни уха ни рыла .

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

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

[Jenya7]

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

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

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

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

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

[zltigo]

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

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

структура это пользовательская задача. malloc тут не подходит - пользователь начнет создвать/затирать элементы - хана куче.

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

[ar__systems]

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

[Jenya7]

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

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

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

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

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

Сообщение отредактировал Jenya7 - Mar 9 2016, 07:50

[amaora]

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

[Jenya7]

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

[zltigo]

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

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

Это уже может означать, что блоки будут разных размеров.

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

[Jenya7]

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

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

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

[zltigo]

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

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

[zombi]

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

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

[adnega]

Ну так рассказали бы дикарям

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

[zltigo]

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

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

А не морочили людям голову!

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

[adnega]

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

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

[HardEgor]

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

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

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

[zltigo]

Лет 10 назад...

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

[adnega]

Но упаковался и еще осталость чуток.

Видимо, для эффективной экономии ОЗУ нужно не только знать размеры переменных, но и знать архитектуру своего ПО.
Хотя сейчас напрягаться не принято и проще поставить внешнюю SDRAM и/или выбрать МК с большим количеством набортного ОЗУ.
В приложениях с таким функционалом, что приходится использовать TCP/IP, обсуждение размера переменной (1 или 4 байта)
вызывает у меня определенные подозрения (что что-то не так).

[zombi]

Один их эффективых путей экономии это многократное и повторное использование ресурсов.

Америку открыли
Главное обеспечить невозможность одновременного выполнения процессов использующих эту общую область.

Для этого можно использовать менеджеры памяти

И если такой возможности нет то и никакой мыныджер не поможет.

[adnega]

Америку открыли
Главное обеспечить невозможность одновременного выполнения процессов использующих эту общую область.

Вроде, все не так.
Никакой блокировки процессов нет. Процесс просит память, менеджер может выделить память или отказать в выделении.
С выделенной памятью процесс может делать все что угодно, и другие процессы тут вообще никакой роли не играют.
Отказ в выделении памяти процессу нужно как-то обработать.

И если такой возможности нет то и никакой мыныджер не поможет.

Обсуждается ситуация, когда такая возможность есть.
Может, вам стоит побольше вдумчивее читать и поменьше язвительно писать?

[zombi]

Обсуждается ситуация, когда такая возможность есть.

Это Вы сами так решили или подсказал кто?

Может, вам стоит побольше вдумчивее читать и поменьше язвительно писать?

Может.

[adnega]

Это Вы сами так решили или подсказал кто?

ТС в сообщении 15.

[zltigo]

Обсуждается ситуация, когда такая возможность есть.

Навязываемое Вами "обсуждение", откуда взять память, которой нет, абсолютно бессмысленно. Посему речь идет о памяти, котороая есть и которую надо пытаться использовать в разные моменты времени для разных целей. Если такой возможности нет, что практически НЕВЕРОЯТНО, или лениво думать как такое обеспечить, то и разговоров нет. Только Ваш треп ни о чем.

Видимо, для эффективной экономии ОЗУ нужно не только знать размеры переменных, но и знать архитектуру своего ПО.

Для вытягивания последних байтов надо знать уже все . Но это уже на самом деле большая редкость. Я вот тоже на в работе о которой писал, тоже уже для M8C контроллера последние байты вытягивал, вытянул, плюнул, переделал принципиально, и стало 64 свободных байта. Ну придет серверу отказ на исполнение одной редкой команды, если звезды не так лягут, ну переспросит.

В приложениях с таким функционалом, что приходится использовать TCP/IP, обсуждение размера переменной (1 или 4 байта)
вызывает у меня определенные подозрения (что что-то не так).

Одиночной переменной - несомненно, но бывают и солидные массивы данных, где уже счет идет на тысячи таких переменных за каждым из тысяч процессов.
При этом слово тысячи не должно особо пугать - на одном из проектов еще на i8085 у меня в свое время было 256 процессов. На первом из опробованных ARM LPC2114 - 1280 процессов. В обоих случаях прикол был в том, что процессы находились в разных состояниях и в статических состояниях обходились достаточно небольшим количеством данных. На переходных режимах процессам добавлялся блок памяти для обслуживания "развития" процесса.

[Kabdim]

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

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

[zombi]

Только Ваш треп ни о чем.

Интересно помог ли ТС ваш трёп память освободить?

[zltigo]

Интересно помог ли ТС ваш трёп память освободить?

Поживем-увидим. Но то, что я точно знаю, что Вам уже ничего не поможет .

[zombi]

Но то, что я точно знаю, что Вам уже ничего не поможет .

Я в помощи не нуждаюсь , а уж в помощи такого хвастуна-виртуоза как вы и подавно.

[sigmaN]

Хахаха у zombi бомбануло прям так не слабо по ходу))))))))))
Не знаю, вроде zltigo дельные вещи говорил...

[Jenya7]

Интересно помог ли ТС ваш трёп память освободить?

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

[ViKo]

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

[zombi]

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

Т.е. совет использовать менеджер памяти подтолкнул Вас к решению "взять камень с бОльшим RAM"?
Феерично!
Или это сарказм такой?

[adnega]

Т.е. совет использовать менеджер памяти подтолкнул Вас к решению "взять камень с бОльшим RAM"?

Почитайте сообщение №51.

[zombi]

Почитайте сообщение №51.

Не имею возражений к Вашему сообщению №51

И мне кажется что ТС сам же и ответил на свой вопрос написав:

...закончился RAM. а я еще даже не начал писать.

Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно.
О каких менеджерах вообще может идти речь?

[adnega]

Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно.
О каких менеджерах вообще может идти речь?

Мы с zltigo привели реальные примеры, когда пересмотр архитектуры позволил "найти" нужное количество памяти.
Если ТС не способен ухитриться (или задача не позволяет), то для него путь - тупо увеличить объем ОЗУ.
Отрицать на вашем месте вообще подход с использованием менеджеров памяти - не профессионально.

[Jenya7]

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

тут нужно решать концептуально. есть 10 задач. либо загрузить их в RAM и проходить итерацией , либо брать по одной - загрузил-освободил - тогда можно и с malloc/free. но во втором случае возникает вопрос - где держать задачи.

хорошо. я написал код для PLC. В Ladder Diagram или мнемоник. где хранится пограмма которую PLC исполняет?

идея.положу во флеш..если останется место. он что то тоже стремительно убывает.

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

[zombi]

Отрицать на вашем месте вообще подход с использованием менеджеров памяти - не профессионально.

Обвинять кого либо в том чего он не говорил - не порядочно.

[adnega]

Обвинять кого либо в том чего он не говорил - не порядочно.

Значит менеджеры памяти в некоторых задачах нужны.
Пригодность задачи для использования динамического выделения памяти определяет разработчик.
Если задача непригодна (пусть даже по причине отсутствия опыта у исполнителя) - наращиваем ОЗУ.
Все - конфликт исчерпан. Я прошу меня простить, если с кем-то поступил не порядочно.

[zombi]

...

[adnega]

Тема исчерпана - неплохо бы закрыть и последнее почистить.

[zombi]

Тема исчерпана - неплохо бы закрыть и последнее почистить.

Ну значит так и есть
Удалил, мне не сложно.
А насчёт "закрыть" это лучше к ТС писать

Значит менеджеры памяти в некоторых задачах нужны.

Может СИшникам и нужны, мне точно не нужны.
Для меня это просто часть алгоритма и как его обозвать не имеет значения.

[ViKo]

Создать глобальное объединение (union) из массивов всех нужных типов, максимально необходимого размера, и пользоваться им по мере необходимости вместо кучи. Годится?
Хочу понять, как куча может помочь сэкономить память? Если требуется хранить глобальные переменные, но никуда не денешься, придется выделить для них память сразу и навсегда. Если локальные, так они где создаются - в стеке или в куче? Кто (что) решает?

P.S. Или приведением указателя к нужному типу пользоваться массивом целых и в хвост и гриву.

[jcxz]

Создать глобальное объединение (union) из массивов всех нужных типов, максимально необходимого размера, и пользоваться им по мере необходимости вместо кучи. Годится?
Хочу понять, как куча может помочь сэкономить память?

Никак. Может привести только к бОльшему расходу памяти.
Куча полезна только если нужно запускать различные задачи, заранее не известные (когда и какую), с заранее неизвестными требованиями к памяти. Но и то - нужна обработка случая нехватки памяти. Да и дефрагментация периодическая или после завершения каждой задачи. Это случай Linux-а и подобных ему систем.

Обычно для ембеддед достаточно:
union MemShare {
struct MemMode1 {
int member1, member2;
...
} memMode1;
struct MemMode2 {
int member1, member2;
...
} memMode2;
...
} memShare;
где Mode1, Mode2, ... - состояния работы устройства с неперекрывающимися структурами данных; которые в свою очередь могут быть union и делиться дальше.

[zltigo]

Никак. Может привести только к бОльшему расходу памяти.
Куча полезна только если нужно запускать различные задачи, заранее не известные (когда и какую), с заранее неизвестными требованиями к памяти.

Разумеется нет. Куча, это просто ОДИН ИЗ СТАНДАРТИЗИРОВАННЫХ механизмов расшаривания памяти. Само расшаривание памяти может использоваться для чего угодно, а отнюдь не только для "запуска задач с неизвестными требованиями".

[jcxz]

Разумеется нет. Куча, это просто ОДИН ИЗ СТАНДАРТИЗИРОВАННЫХ механизмов расшаривания памяти. Само расшаривание памяти может использоваться для чего угодно, а отнюдь не только для "запуска задач с неизвестными требованиями".

Прочитайте внимательнее. И уловите разницу между полезно и может. Никто не спорит, что куча может использоваться для чего угодно, ход код переносимый оттуда выполняйте.

[zltigo]

Прочитайте внимательнее. И уловите разницу между полезно и может. Никто не спорит, что куча может использоваться для чего угодно, ход код переносимый оттуда выполняйте.

Я прекраcно улавливаю разницу между "полезно" и "полезно ТОЛЬКО". Вот про использования Вами "полезна ТОЛЬКО если нужно запускать различные задачи", "Может привести ТОЛЬКО к бОльшему расходу памяти" и отвечал. Так что либо уберите слово ТОЛЬКО из своих постов, либо не пытайтесь сейчас юлить.

[zombi]

ТС вопрошает

закончился RAM. а я еще даже не начал писать.

"вЫртуоз" пишет:

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

Что то дикие у Вас представления о менеджерах памяти и программировании

Просто прохожий -

Ну так рассказали бы дикарям про менеджеры памяти

"вЫртуоз"-

- этим менеджер заниматеся - Вам то зачем что то знать?

и тд и тп

"полезно" и "полезно ТОЛЬКО"."полезна ТОЛЬКО если нужно

Внимание, ВОПРОС!!!
Помог ли "вЫртуоз" освободить память вопрошающему?

И если помог, то представляю как сейчас TC "купается" в огромном количестве свободной памяти которая так и просит его - ну возьми ну используй меня...

[zltigo]

Внимание, ВОПРОС!!!

Будьте внимательнее. Ответ уже был http://electronix.ru/forum/index.php?showt...t&p=1410271
Мне описанный мной подход к делу помогает. По причине того, то я понимаю, что и как делаю. Вам, по причине полной неспособности понять, соответственно - нет.

[sigmaN]

А помогли ли ТС ваши советы?
И где конкретно советы? один сплошной трёп!

Да ладно? Нормально тема раскрыта.
Или вы хотели чтоб тут за ТС прям все исправили и отладили?
Направление для изучения дано, варианты расшарить память между задачам/подсистемами/etc даны.
Техники от полу-кустарных, ручных вариантов с union до более правильных менеджеров памяти в общих чертах описаны....
Дальше человек уже должен маленько по гуглить и найти всё что ему нужно.

Тут как-бы получается умному достаточно, а дурак все равно не поймет.

P.S.
Честно не понимаю чего у нескольких людей на форуме так бомбит пукан от советов zltigo?
Это такой способ отомстить за курс Евро или что?
Потому что это уже явно какая-то не адекватная реакция часто начинается.. Объяснения приходят только в стиле теории заговоров или борьбы с империализмом и ненависти к буржуазии )))

Но убирает он вас всех здорово! Порой тему читаю только чтоб по улыбаться со всего этого ))))

[adnega]

Вы либо курите что-то запрещённое , либо zltigo Ваш работодатедь как и для adnega?

Скоро вы всех СИ-шников припишете к наемникам zltigo...
Есть профи, которые на жизнь электроникой зарабатывают (и при этом любят электронику).
Им виднее, что и как надо делать, а что и как не надо делать - поэтому они готовы давать советы
для решения конкретной задачи в конкретных условиях.
А есть любители, которые считают только свой подход правильным в любых условиях.
Вроде, вопрос топика закрыли несколько страниц назад. Хочется поговорить о бесполезности СИ,
о ненужности абстракций программирования и о "любимом" ASM? - открывайте свою тему.
Да, zltigo довольно прямолинеен, но по информации из его постов можно судить о таком опыте
(в том числе и asm-разработок) и таком объеме созданного полезного, до которого вам еще очень далеко.
Завязываете: а то очень басню о Моське и Слоне напоминает.

[zombi]

Прямолинеен

[ar__systems]

Неужели наконец-то всю память сэкономили?

[Jenya7]

Неужели наконец-то всю память сэкономили?

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

Сообщение отредактировал Jenya7 - Mar 23 2016, 07:35