ARM, RISC-V контроллеры

Отказ от динамической памяти -- сомнительное занятие, подходящее лишь для маленьких программок: в системе физической памяти обычно меньше, чем используется всеми программами в разные моменты времени. Либо придётся изобретать свой самодельный аллокатор, но он будет обладать всеми недостатками стандартного, плюс ещё свои. Кроме того, работа с динамической памятью легче проверяется, быстрей выявляются ошибки. И при тестировании (тот же valgrind) и при работе (может периодически проверяться целостность кучи и границы сегмента при операциях free и malloc). Для статически выделенной памяти нет толковых средств отладки (если есть переползание за пределы массива в другой массив -- это никак не отловить). Об этом нигде не пишется, но я имею такое мнение: например, электронные схемы сложные для понимания. Прежде чем делать макет -- их работа изучается в симуляторе. И зачастую уже на основе симуляции можно сделать много интересных выводов. Почему-то по отношению к программам подход такой, мол запустим сразу на МК (без толковых средств отладки, без диагностики и обнаружения ошибок) и _как_нибудь_ уж отладим. Так вот ПО точно так же можно запускать в своеобразном симуляторе. Нужно лишь через какое-то подобие HAL оторвать программу от железа. И в таком виде можно тестировать и отлаживать логику работы куда быстрей и качественней (на PC). Может посмотреть в сторону NuttX. Но по-моему в варианте с MPU там тоже мутная история. Не знаю какие функции у аппарата для наркоза, но рискну предположить, что: 1) часть функций критически важные и эта часть, возможно, не такая уж и большая, чтоб нужна была даже C-библиотека; 2) наибольшая и наисложнейшая часть функций имеет вспомогательный характер. Возможно, какие-то функции окажутся в промежуточном слое между 1 и 2. Очевидный вопрос. Почему бы указанные слои ПО не разделить каким-либо образом. Начиная с разделения по разным МК (отделить, по крайней мере, наиболее критическую часть). Или разделить в рамках FreeRTOS: допустим есть три слоя, к ним же и три процесса, полностью изолированных. В рамках этих процессов уже работает, возможно, какая-либо другая ОС, там есть отдельная C-библиотека, отдельная куча для malloc и т.п. FreeRTOS превращается как бы в гипервизор для виртуальных машин и не позволяет слоям с большим и глючным ПО порушить более важные слои ПО. Я бы как-то так поступил. Возможно, жизненно важный слой ПО уместится и на пик-контроллере проф. уровня. Тогда самые объёмные и сложные слои, и при этом не критичные для работы прибора, можно вынести на попросту отдельный МК -- можно здорово сэкономить на разработке, или нет? Возможно, потребуется какое-то решение на случай отказа этих, "ненадёжных" слоёв ПО. И я бы вот ещё о чём задумался. Не знаю что говорят стандарты, но: любые программы, несмотря на все тесты и всё прочее будут содержать ошибки. Весьма полезно было бы иметь параллельный набор программ с весьма ограниченным функционалом способный проверять правильность работы основной программы, обнаружить неправильную работу основных программ и, в случае отказа основного набора программ, зафиксировать аварийную ситуацию "отказ ПО" и взять управление на себя с целью минимизации последствий. И так же проверка правильности работы более верхних слоёв более нижними. Т.к верхние слои способны выдавать ошибочные управляющие воздействия в силу ошибок. В википедии можно прочитать про Therac. Глюки возникавшие в GUI попадали свободно на нижние уровни без валидации. Разделения на уровни, видимо, попросту не было -- это главная ошибка, не нужно всё мешать, и GUI, и управляющий алгоритм, в одной программе. Не обрабатывались исключительные ситуации (конкретно деление на 0 до сих пор в большей части МК тупо игнорируется).