[rkit 1]

53 minutes ago, -=Женек=- said:

Это насмешка над моим дилетантсвом (коего я не стесняюсь, ибо любитель), или намек на то, что предыдущий совет плох?

Это был прогноз. Да, совет плох. Да, дилетант. Действительно лучший ответ был выше - работать по частям.

[Сергей Борщ 119]

13 минут назад, AlexandrY сказал:

типа Azure RTOS

Модератр: Александр, вы нарушете п 3.6 Правил. Устное предупреждение.

[MrBearManul 0]

1 час назад, Arlleex сказал:

Ибо совет в его чистом виде по malloc()/free() - действительно прямой путь к краху.

Ну почему же? Я хоть и сам не сторонник использования во встраиваемых системах динамической памяти через "стандартные" средства, всё-таки в своё время их использовал. Никакого краха не было. Конено, указатель на nullptr проверять после malloc следует. И вызывать free не забывать тоже нужно. Основная проблема - фрагментация кучи и, возможно, скорость поиска свободного блока. В первом случа можно подумать о более интеллектуальном менеджере кучи, благо в инете их полно.

 

Во втором - тут решать только автору топика. Но всё же я солидарен с вами в том, что информацию нужно считывать частями, и затем частями же передавать.

Изменено 19 декабря, 2020 пользователем MrBearManul

[Arlleex 131]

31 минуту назад, MrBearManul сказал:

Я хоть и сам не сторонник ... всё-таки в своё время их использовал. Никакого краха не было.

Все зависит от задачи и конкретных условий.
Например, выделяя всегда одинаковое N байт при длине пула M, при M%N==0, проблем даже со стандартными malloc()/free() не будет, скорее всего.
Но это лишь теория. На практике же, что там реализовали в стандартных malloc()/free() - одним писателям компиляторов известно.
К тому же, malloc()/free() задумывался все-таки для использования в больших системах, где конкретика функционала определяется загружаемой программой.
Это позволяло менеджеру динамической памяти, сборщику мусора и дефрагментатору стать неотъемлемой частью операционной системы как таковой.

Устройства на МК, как правило, имеют вполне определенный функционал. Соответственно, ПО в них тоже вполне "приземлено", а не абстрагировано.
Поэтому и память зачастую может быть распределена заранее (на этапе линковки приложения). Тот же MISRA запрещает использование malloc()/free().
А уж люди в том комитете сидят вполне себе грамотные. Конечно, не надо всегда рубить с плеча и слепо следовать той же MISRA, просто посыл должен быть понятен.

Плюс к этому, я достаточно много видел топиков и тут и на зарубежных форумах, где на одних malloc()/free() в МК дегтя съели больше, чем его было в бочке.

[MementoMori 4]

Поддерживаю идею о работе по частям. 

Правда у меня свои причины. Я пытаюсь читать SD карту при помощи интерфейса touchgfx. А в случае отображения информации на экране, память в любом случае будет забита - в scrolllist, если будет 5000 файлов, все 5 тысяч и загрузится и займут память. Зачем дублировать эти данные массивом, необходимым только для передачи информации из системной области в интерфейсу. Я полагаю, создатели touchgfx озаботились обработкой scrollist, количество элементов которого заранее неизвестно

Правда, я поступил коряво - не стал транспортировать данные, а тупо подключил Fatfs.h к файлу, описыващему конкретный экран и вызываю функции работы с файловой системой прямо из интерфейса. Чем разрушаю идею создателей о разделении интерфейса и системы. Но работает без глюков. 

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

[MrBearManul 0]

28 минут назад, Arlleex сказал:

На практике же, что там реализовали в стандартных malloc()/free() - одним писателям компиляторов известно.

Обычно их не стоит использовать в мире встраиваемых систем. Хотя бы по причине отсутствия статистики. В своё время уважаемый @zltigo выкладывал свою версию менеджера, которая позволяет вести статистику расхода кучи. Именно его менеджер я и использовал. Правда потом пришёл к мысле, что мне динамическая память не нужна. И пользы от неё никакой.

[Arlleex 131]

1 минуту назад, MrBearManul сказал:

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

То то же

3 минуты назад, MrBearManul сказал:

В своё время уважаемый @zltigo выкладывал свою версию менеджера...

Помню, где-то видел. Но в детали не вдавался, т.к. оно мне было не нужно. Так, мб интереса ради.

[jcxz 184]

7 часов назад, V_G сказал:

3. Выделяете в памяти область под известный  объем (malloc())

Пустой совет. Даже вредный.

Если объёма кучи не хватит - будет крах системы. Максимальный "известный объем" равен максимальному читаемому ТС-ом объёму, а значит размер кучи должен позволять его выделить (чтобы не было краха). Но максимальный "известный объем" ТСу заранее известен (на этапе написания ПО) - зачем тогда куча? Значит можно выделить эту память статически и куча не нужна. Для статического выделения физической памяти МК потребуется меньше.

Другими словами: в тех случаях когда статической памяти не хватит на "известный объем", то памяти кучи не хватит тем более. Просто в первом случае известно это станет на этапе написания ПО (и возможно заставит написателя задуматься); то во 2-м случае будет написан быдлокод, который вроде как запускается, но при попытках его использования, будет иногда приводить к краху системы.

5 часов назад, -=Женек=- сказал:

Спасибо! Наилучший совет.

Подумайте ещё раз. Совет был для вас бесполезный.

4 часа назад, Arlleex сказал:

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

Лучший совет!  

 

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

 

4 часа назад, AlexandrY сказал:

Поэтому чтобы бороться с такими проблемами ставят RTOS типа Azure RTOS и делают выделение памяти с таймаутом. 

Эта усиленно рекламируемая вами ОС увеличивает размер ОЗУ МК??? 

Тогда это - уникальная ОС! Нафик тогда все эти Cortex-M7! Ставим самый дешёвый STM8 с килобайтом ОЗУ, ставим на него суперОС и получаем 1гиг ОЗУ!!!  

[AlexandrY 3]

On 12/19/2020 at 3:07 PM, jcxz said:

Тогда это - уникальная ОС! Нафик тогда все эти Cortex-M7! Ставим самый дешёвый STM8 с килобайтом ОЗУ, ставим на него суперОС и получаем 1гиг ОЗУ!!!  

Просто вы не поняли мысль. 
Если памяти нет сейчас, то можно подождать когда ее освободят другие задачи. 
И Azure RTOS  позволяет сделать это легко. 
Я не думаю, что TC задал вопрос не понимая хватает или нет ему памяти для своего массива. 
Он скорее озабочен как эту память поделить между задачами. 
Вот тут-то оси и приходят на помощь.