Ресурсы для управления памятью во встраиваемом приложении
Как я должен управлять памятью в своем встраиваемом приложении в жестком реальном времени?
Я нашел некоторые статьи с Google, но не мог точно определить действительно полезное практическое руководство.
DO-178b запрещает динамические выделения памяти, но как Вы будете управлять памятью затем? Предварительно выделите все заранее и отправьте указатель на каждую функцию, для которой нужно выделение? Выделить его на стеке? Используйте глобальное статическое средство выделения (но затем это очень похоже на динамическое выделение)?
Ответы могут иметь форму обычного ответа, ссылки на ресурс или ссылки на хорошую встроенную систему с открытым исходным кодом, например.
разъяснение: проблема здесь не, является ли управление памятью availible для встроенной системы. А что такое хороший дизайн для встроенной системы, для максимизации надежности.
Я не понимаю, почему статически предварительное выделение пула буферов, и динамично получение и отбрасывание его, отличаются от динамичного выделения памяти.
7 ответов
Как человек, который имел дело со встроенными системами, хотя пока и не так строго (я читал DO-178B, однако):
- Если вы посмотрите на загрузчик u-boot, многое сделано с помощью глобально размещенной структуры. В зависимости от конкретного приложения, вы можете обойтись без глобальной структуры и стека. Конечно, там есть реентерабельность и связанные с ней проблемы, которые не совсем применимы к загрузчику, но могут быть полезны для вас.
- Преаллокация, преаллокация, преаллокация. Если вы можете во время проектирования связать размер массива/структуры списка/etc, объявите его как глобальный (или статический глобальный - смотри, Ма, инкапсуляция).
- Стек очень полезен, используйте его там, где это необходимо - но будьте осторожны, так как можно легко продолжать выделять из него, пока не останется места в стеке. Некоторый код, который я однажды отлаживал, выделял 1k буферов для управления строками в нескольких функциях... иногда использование буферов попадало в стек другой программы, поскольку размер стека по умолчанию составлял 4k.
- Случай с буферным пулом может зависеть от того, как именно он реализован. Если вы знаете, что вам нужно передавать буферы фиксированного размера, размер которых известен во время компиляции, то работа с буферным пулом, вероятно, будет более простой для демонстрации корректности, чем полный динамический аллокатор. Вам просто нужно убедиться, что буферы не могут быть потеряны, и убедиться, что ваша обработка не приведет к сбою. Кажется, здесь есть несколько хороших советов: http://www.cotsjournalonline.com/articles/view/101217
Правда, я думаю, что ваши ответы можно найти, присоединившись к http://www.do178site.com/
Долгосрочные критически важные системы реального времени не должны динамически выделять и освобождать память из кучи. Если вам нужен и вы не можете его создать, напишите свою собственную схему управления выделенным и фиксированным пулом. Да, по возможности выделяется фиксированное заранее. Все остальное требует возможных проблем.
Отказ от ответственности: я не работал специально с DO-178b, но я написал программное обеспечение для сертифицированных систем.
В сертифицированных системах, разработчиком которых я был, ...
- Динамическое выделение памяти было допустимо ТОЛЬКО на этапе инициализации .
- Динамическое освобождение памяти НИКОГДА не было приемлемым.
Это оставило нам следующие варианты ...
- Использовать статически размещенные структуры.
- Создать пул структур, а затем получить / освободить их из / обратно в пул.
- Для гибкости мы могли динамически выделять размер пулов или количество структур на этапе инициализации. Однако, пройдя эту фазу инициализации, мы застряли на том, что у нас было.
Наша компания обнаружила, что объединение структур с последующим получением / выпуском из / обратно в пул было наиболее полезным. Мы смогли придерживаться модели и сохранить детерминированность с минимальными проблемами.
Надеюсь, что это поможет.
Выделение всего из стека обычно делается во встроенных системах или в других местах, где возможность неудачного выделения неприемлема. Я не знаю, что такое DO-178b, но если проблема в том, что malloc недоступен на вашей платформе, вы также можете реализовать его самостоятельно (реализовав свою собственную кучу), но это все равно может привести к сбою выделения, когда у вас закончится место, конечно.
Вы также можете найти этот вопрос интересным, динамическое распределение часто запрещено в настройках с ограниченным пространством (на самом деле, основная память там все еще полезна).
Обычно, когда функция malloc () недоступна, я просто использую стек. Как сказал Tronic , вся причина отказа от использования malloc () заключается в том, что он может дать сбой. Если вы используете глобальный статический пул, вполне вероятно, что ваша внутренняя реализация malloc () может быть защищена от сбоев.
Это действительно, очень, очень зависит от поставленной задачи и от того, что будет выставлено на доске.
Невозможно быть уверенным на 100%.
Вы можете посмотреть примеры распределителей памяти FreeRTOS. Те, если не ошибаюсь, используют статический пул.
Я работал в среде DO-178B (системы для самолетов). Насколько я понял, основная причина, по которой не разрешается динамическое распределение, заключается в основном в сертификации. Сертификация проводится с помощью тестов (унитарных, покрывающих, интеграционных, ...). С помощью этих тестов вы должны доказать, что поведение вашей программы на 100% предсказуемо, почти до такой степени, что объем памяти вашего процесса одинаков от одного выполнения к другому. Поскольку динамическое распределение выполняется на куче (и может быть неудачным), вы не можете легко доказать это (я представляю, что это должно быть возможно, если вы владеете всеми инструментами, от аппаратного обеспечения до любого написанного куска кода, но ...). У вас нет такой проблемы со статическим распределением. Именно поэтому C++ в то время не использовался в таких средах. (это было около 15 лет назад, возможно, ситуация изменилась...)
Практически, вы должны написать много пулов структур и функций распределения, которые гарантируют, что у вас есть что-то детерминированное. Можно придумать множество решений. Ключевым является то, что вы должны доказать (с помощью ТОННЫ тестов) высокий уровень детерминированного поведения. Легче доказать, что ваша ручная разработка работает детерминированно, чем доказать, что linux + gcc детерминированно выделяет память.
Просто мои 2 цента. Это было давно, все могло измениться, но что касается сертификации типа DO-178B, смысл в том, чтобы доказать, что ваше приложение будет работать одинаково в любое время в любом контексте.