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

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

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


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



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

Оптимизировать нужно там, где наибольший расход.
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 и не придется париться :-)

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

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


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

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

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

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

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



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

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

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

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

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