Jump to content
    

RapidJSON и FreeRTOS

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

Нет, бОльшего. Ведь приходится резервировать память, априори не зная реальную потребность.

Это как это? Вот например: есть у вас интерфейс, через который могут приниматься JSON-ы. Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт. Но только при статическом выделении это и будет 100 байт потрачено, а при динамическом == 100 байт + заголовок блока + потери на фрагментацию. Причём последняя составляющая - почти непредсказуема (без циклов "сборки мусора" и MMU).

 

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

Как раз наоборот, меньшего.

Ну раз у вас получаются затраты памяти при статическом резервировании больше, то значит - мастерства явно не хватает.  :unknw:

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

С ПЛК работали? Там такая штука не канает.

Почему? Пруфы в студию!

Сдаётся мне, что вы не поняли о чём речь.... Именно благодаря оверлеям, static allocation и выигрывает у dynamic в сложных задачах.

 

PS: Да и при чём тут ПЛК, если тема про FreeRTOS?

Share this post


Link to post
Share on other sites

54 минуты назад, tonyk_av сказал:

С ПЛК работали? Там такая штука не канает.

Нет, не работал. А можно, и правда, выдержку из (что это - стандарт?) документа, где явно об этом написано?

Вы же сами понимаете, что это утопия? В рядовой программе даже банальный union с буфером внутри уже, получается, "запрещен"? А placement new в C++?

А неявные оптимизации расхода стека при работе с невстраиваемыми функциями? Ведь они неявно тоже один и тот же кусок памяти юзают...

Это я даже не упоминаю оверлеи на уровне взаимодействия с линкером.

Share this post


Link to post
Share on other sites

21 minutes ago, jcxz said:

PS: Да и при чём тут ПЛК, если тема про FreeRTOS?

Речь идёт о распределении памяти. В качестве примера привёл вариант решения вопроса распределения памяти в рантаймк ПЛК.

22 minutes ago, jcxz said:

Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт

Смысла в 100 байт как раз и нет. Нужно резервировать столько, сколько может быть максимальный размер запрашиваемого блока. Для понимания того, о чём я говорю, достаточно вспомнить формат хранения строк в нынешних ПЛК S7 от Сименса или старом Паскале.

Share this post


Link to post
Share on other sites

5 минут назад, tonyk_av сказал:

Смысла в 100 байт как раз и нет. Нужно резервировать столько, сколько может быть максимальный размер запрашиваемого блока.

Вы прочитали, что я писал?

34 минуты назад, jcxz сказал:

Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт.

Каким именно образом динамическое выделение в этом случае позволит уменьшить требования по памяти?

Я вам выше исходные условия задачи описал. Спрашивал - каким именно образом динамическое выделение позволит уменьшить требования по ОЗУ.

 

5 минут назад, tonyk_av сказал:

Для понимания того, о чём я говорю, достаточно вспомнить формат хранения строк в нынешних ПЛК S7 от Сименса или старом Паскале.

"Пойди туда, не знаю куда....."

Share this post


Link to post
Share on other sites

5 minutes ago, Arlleex said:

А можно, и правда, выдержку из (что это - стандарт?) документа, где явно об этом написано?

Это стандарты ГОСТ Р МЭК по функциональной безопасности ПО.

Share this post


Link to post
Share on other sites

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

Это стандарты ГОСТ Р МЭК по функциональной безопасности ПО.

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

Share this post


Link to post
Share on other sites

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

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

Имхо - нас забалтывают...  :unknw:

Share this post


Link to post
Share on other sites

1 minute ago, Arlleex said:

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

Прочитайте стандарты. Лейтмотивом в них идёт мысль, что вся характеристики управляющего устройства должна быть детерминированы.

9 minutes ago, jcxz said:

"Пойди туда, не знаю куда....."

Н. Вирт, "Алгоритмы+структуры данных= программы". Классика. Раздел 5. Посмотрите, как построена таблица имён и работа с ней.

Share this post


Link to post
Share on other sites

Только что, tonyk_av сказал:

Прочитайте стандарты. Лейтмотивом в них идёт мысль, что вся характеристики управляющего устройства должна быть детерминированы.

А оверлеи дают недетерминированное поведение? Разумеется, при должном подходе и без них ПО можно сделать недетерминированным.

Лейтмотивы не мыслю, я привык, что в стандартах есть четкие "можно" и "нельзя". А иногда какие-то выкладки носят лишь рекомендательный характер.

  

Только что, jcxz сказал:

Имхо - нас забалтывают...  :unknw:

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

Share this post


Link to post
Share on other sites

Можно вместо голых указателей использовать чуть более сложные объекты для доступа к выделенной памяти. Так, чтобы куча знала где лежат ссылки на ее объекты. Это позволит делать дефрагментацию без mmu. На C++ наверно кто-то так делает, но это сложно.

Другой вариант. Использовать блоки фиксированного размера, и на них строить все необходимые структуры данных, например списки из блоков. Так можно и на C, но метод несовместим со старым и сторонним кодом который работает с большими кусками памяти.

Edited by amaora

Share this post


Link to post
Share on other sites

11 часов назад, dxp сказал:

Фрагментация кучи на физической памяти — неустранимая проблема.

Сам использую такой метод, например нужно распарсить что-то, обнуляем кучу, затем работаем malloc\free, как завершили работу, снова очищаем кучу для следующего сеанса, фрагментация будет только в локальном сеансе и небольшая. Но конечно, если можно не использовать дин память, лучше так и делать...

Share this post


Link to post
Share on other sites

21 час назад, tonyk_av сказал:

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

Физическая память выделяется страницами, а виртуальная "склеивается" из этих страниц. Если запрос не вмещается в промежуток свободного адресного пространства, то память выделяется в адресах, где достаточно места. А страницы физической памяти используются те же самые. Максимум что может грозить виртуальной памяти — то, что она (её адресное пространство) может закончиться. Но это контролировать гораздо проще.

Share this post


Link to post
Share on other sites

Коллеги, а причём тут вообще ПЛК или иные контроллеры? Автор темы о них ничего не говорил. Может быть его плата управляет какой-нибудь кофе-машиной. Да и ладно, подождём пару секунд, пока выделится/склеится память. Кофе от этого хуже не станет))) Просто пока сам автор топика не обозначил область своей разработки, вполне можно предлагать любое решение: MMU, оверлеи и т.п. При этом нет смысла говорить о том, что предложенное решение не подходит для блока управления левым передним колесом марсохода. Зато для кофе-машины подходит!)))

Share this post


Link to post
Share on other sites

4 minutes ago, dxp said:

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

Да ну! А мужики-то не знают!

Share this post


Link to post
Share on other sites

Я некорректно выразился. Исправил.

Вам известны случаи падения программ, например, на x86 из-за того, что фрагментация "побила" всю память?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...