Доброго времени! Всех с НГ!

Занимаюсь созданием приборов с микроконтроллерным управлением. Ничего эдакого, как говорит ЛИ "автоматизация курятников". Из последнего у меня получилось 32К на Си. Освоил и пользуюсь методами из теории конечных автоматов. Сообщения, таймеры много канальные программные.
Однако новые требования заказчиков, косяки в архитектуре ПО и некоторые другие факторы вынуждали меня что то править, что то и вовсе переписывать. Это вылилось в трудно модифицируемую систему с костылями и тп хренью.
С нового года я работаю над еще более сложным прибором и понимаю, что так как было делать нельзя. Смотрю в сторону объектно ориентированных принципов построения ПО, а также подумываю над идеями из теории ОС.
Как вы решали свои задачи, что можете посоветовать посмотреть-почитать? Спасибо!

Посмотрите как делают моргание на светодиодах.
Вот тут например - https://geektimes.ru/post/284248/

Там на одном микроконтроллере программа занимает 160К и на втором 130K
Зато сделано за день.

Вся фишка во фреймворке. Вы просто еще не собрали свой фреймворк. Туда должны входить RTOS (лучше несколько), несколько файловых систем, движки отладочных мониторов, коммуникационные стеки и проч.
И тогда ваши программы со старта уже будут весить под 100К и вы забудете слово "сложные"

Ужасссс!
Не в тему - Александр, меня удивляет ваше увлечение или осмысленное использование Freescale - овских (NXP) контроллеров серии Kinetis - мало кто их использует в наших краях, я то же к ним не равнодушен (работал до этого с MC68332) и хочу заложить в свою конструкцию. Много ли ерратовских косяков и других проблем возникает на пути их юзанья? Это касаемо серий K66 K20 K02?

Рецепт из серии - если у Вас болит зуб - прищемите палец дверью... Удивляет, что Вы еще почему-то до сих пор с микроконтроллерами возитесь и разными RTOS. Пора уже все задачи решать с помощью IBMPC и Линукса .

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

нет, готовые RTOS меня не интересуют. Я работаю с 8ми битниками и задачи у меня в целом достаточно простые: обработать клавиатуру, аналоговые входы. поддержка цифровых интерфейсов и тп. Трудности возникли именно на этапе соединения всего этого зоопарка в единое целое. Быстродействия, памяти мне всегда хватает. Сейчас я подошел к пределу своих возможностей в так сказать в функциональных ресурсах своего подхода к написанию ПО.
Ну например: в устройстве есть некий цифровой выход, который должен уметь быть включенным на x секунд в диапазоне от 0 до 120. При этом выход может быть сконфигурирован как инверсным так и без инверсии. Также выход должен уметь работать циклами включен на y сек, выключен на z секунд. Естественно работа этого выхода связана с другими узлами и логикой системы Так например работа выхода может быть прервана на w секунд, а после продолжена.
Согласен ничего такого в этом выходе нет, но что если приходит заказчик и говорит: хочу чтоб этот выход включался только если темное время суток, а если светлое время суток то хочу чтоб включался другой выход с другими x,y,z,w
Я это реализую, но выглядит это стремно: глобальные переменные, флаги, общие в целом куски ПО. Кароче не то.

Сильно сомневаюсь, что задача типа условного ногодрыга решается дешевле с помощью покупного PLC или даже недо-PLC типа Siemens LOGO
Бывает сильно по-разному. Иногда - да. Экономия времени. Удобство разработки "на всем готовом".
Иногда нет. Особенно что изготовители PLC постоянно стимулируют "докупать" железо, драйвера, лицензии, модули, интерфейсы и прочея и всякая за дорого.
Хотя если учесть, что самый дорогой ресурс - время, то согласен.

1. C
2. там где надо - использовать модули ASM в составе проекта на С
3. Для больших проектов сильно упрощает наличие RTOS.
Посмотрите scmRTOS.
4. Использование ООП (C++) - позволяет на порядок увеличить "читабельность", простоту и упоряченность своего кода.
Естественно - если пишется в "трезвом рассудке и здравом уме"
5. Как тут советовали. Свои наработки "перепакуйте" в модули и/или библиотеки.
Если есть смысл - перепишите с использованием объектов на C++.
6. Для ведения разработки сильно упрощает жизнь системы версирования проектов.
Я пользую SVN. (база данных разработки, с возможностью, например, отката на "позпрошлый понедельник")

Kinetis обсуждаем здесь - https://electronix.ru/forum/index.php?showt...=0#entry1472241
Я создал специально тему.



Напрасно не интересуетесь RTOS, в той гирлянде на светодиодах применяются автоматы состояний сложнее ваших. Причем автомат состояний на каждый светодиод свой.

Но вижу вы уже на пороге создания велосипеда под названием скриптовый движок.
Только скрипты позволяют пока клиент рассказывает о своей хотелке реализовать ее в это же время.

я сразу же как начал работу с мк делал по рецепту многоуважаемого DiHalt тут AVR. Учебный курс. Операционная система. Введение.
Очень рекомендую. Ну а дальше по желанию любые учебники по написанию embedded кода с семафорами, пайплайнами и прочими прелестями.. Но имхо для 8 битников и DiHalt 'а освоить достаточно будет.

Как поэтично

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

Если проектируемая система единична зачем городить на МК, если есть ПЛК как предлагали выше. Масштабировать, сенсорную панель прикрутить или на верхний уровень АСУТП завести намного легче.

.... и отказаться в результате от услуг разработчика.
Заказчику не должно быть что-то легко переделать самостоятельно в устройстве, иначе у него может возникнуть крамольная мысль "а нафига я столько плачу этому разработчику? эта работа столько не стОит! Я и сам это могу"


Ну если так часто ходят заказчики с такими тривиальными задачами (и у каждого она немного отличается от другого), то у Вас наверное неправильно составлено ТЗ. И вообще - решение задачи архитектурно сделано неверно.
Усложните себе задачу - поставьте её по-нормальному:
1.Реализовать в устройстве поддержку выполнения скриптов (записанных в любом формате, хоть соответствующем некоему стандарту, хоть доморощенном).
2.Реализовать некий необходимый пользовательский функционал со скриптовым доступом (вкл/выкл ноги, послать пакет в порт, задать паузу, установить таймер и т.п.).
3.Привязать выполнение скриптов к событиям от периферии.
4.Дать возможность пользователю редактировать и запускать скрипты на Вашем устройстве.
Всё! С этого места можете спокойно плевать в потолок, попивая пиво и посылая пользователей читать мануал на скрипты.



О, блин! Уже посоветовали....


Дело тут не в RTOS, а в стиле написания. Наличие RTOS тут равнобедренно.


... но как только окажется что чего-то не хватает в функционале этого ПЛК, то уже никак не объедешь. МК - более гибкий подход.

Например чего?

си шарп и микрофреймворк

Например - низкой цены с возможностью поставить на множество мелких объектов с простым функционалом и ограниченным бюджетом.
Или возможности работать долго от батарейки без подзарядки с минимумом потребления.
Или на объекте эксплуатации мало места и никакой готовый ПЛК просто не лезет.
Да мало-ли чего ещё. Практические задачи они такие непредсказуемые.... в теории всё легко.
А захотел клиент чего-нить этакого, чего в готовых кубиках нету и приплыли....

автор работает с 8-битниками

простите меня теоретика, сдающего по нескольку объектов под ключ за сезон.

Занимался как раз задачами автоматизации птичника (более 10 лет). Расскажу с чем мы столкнулись.
Как показала практика все системы должны быть распределёнными (как минимум допускать расширение), либо связаны по сети (диспетчеризация).
Готовые системы не устраивают не зависимо от производителя, должен быть индивидуальный подход.

Минусы использования ПЛК (тип не имеет значение):
1) ОЧЕНЬ дорого, особенно по нынешним ценам;
2) в качестве датчиков температуры использовали DS18B20 (DS18S20). Ни один нормальный ПЛК не поддерживает данный тип датчиков (городить что то по modbus не очень хороший вариант)
3) частично лицензионный софт
4) иногда быстродействие, как ни странно (например, при реализации фазоимпульсной модуляции)
5) модули для контроля входов 220V как правило с трудом выдерживают режим работы 24/7 (приходится опять городить что-то свое).

При разработке основная проблема была с нехваткой портов ввода/вывода, а также памяти (как RAM так Flash), как говорили уже здесь быстродействия вполне хватало (в ОСРВ потребности не было). В итоге даже начинал рассматривать вариант разработки своего ПЛК (хотели переделать ПЛК Delta, они дешевле и используют STM32 (правда среда разработки плохая, нет ST) либо сделать что-то своё аналогичное, платы можно заказать в Китае).

По поводу требований заказчиков - в итоге мы (заказчики) забрали разработку софта себе, а разработчик оборудования поставлял только железо. Вот так.
Скрипты не нужны, иначе вас заставят отвечать за ошибки в оборудовании (как вы собираетесь доказывать, что виноват скрипт, а не основной софт). Лучше создать железо и базовый софт и продать это всё заказчику, если у них есть кому сопровождать, пускай сами делают всё под себя, можете даже провести обучение. Если нет, поддержка у вас и ни в коем случае не давать дополнительных возможностей в виде скриптов (сломают). Помню как мы по несколько раз в неделю бегали в цех для восстановления параметров блока, пока начальник цеха не наказал их рублём за шаловливые ручки.

Речь в данной теме шла о софте: итог (моё мнение) - всё равно придётся плодить версии под каждого заказчика (заказчик всегда прав), единственно, что можно это попробовать решить за счёт конфигурации блока (недоступной заказчику). Правда я немного не понимаю почему у вас это сводится к изменению ПО, как правило оно тянет за собой и изменение аппаратной части.

Может что нибудь предложить? Какой ПЛК самый лучший?

Тож в Австралии один "курятник" надо автоматизировать.

Последние 2 года в основном ставлю Овен ПЛК110-60 и ПЛК110-30. Самый лучший не подскажу, выбираю под конкретные задачи. По надежности одним из них считаю Simatic S-300. В принципе все хотелки Вам должен написать заказчик в техусловиях на проектирование АСУТП. Может у них Аллен Бредли или Омрон в почете, им виднее.

В своё время рассматривали Schneider Electric Modicon M340 (BMX XBP 1200 + BMXP342020 + ...)

значит время таки пришло ?

В этой теме речь не идет о пром контроллерах, армах или скриптовых движках. Это наверное и важно и интересно, но точно не мне и не сейчас.
Из конструктива в теме отмечу ссылки на ооп и ос. На сколько мне известно, то это огромные темы с массой интересного. Однако напоминаю, что у меня маленькие процы и в принципе простые задачи сложно взаимодействующие друг с другом.
Что из самого ценного взять и трансформировать в мир маленьких камней из ооп и ос? обьекты и задачи? семафоры? есть ли реализации на которые можно смотреть и наследовать?

С++ для микроконтроллеров.

в первую очередь эта статья
http://easyelectronics.ru/rabota-s-portami...erov-na-si.html
и примеры к ней
https://github.com/KonstantinChizhov/Mcucpp/tree/dev

Многие будут отсылать к книге Андрея Александреску "Современное проектирование на С++", но как то пока сложновато.

тоже в основном смотрю в этом направлении, пробую как раз для AVR (8 бит). Задача стоит иметь расход RAM (а потом и Flash) аналогичный применению с использованием Си.

Для себя сделал вывод, что для uC необходимо (желательно) использовать шаблоны классов со статическими членами, тогда вроде всё получается...

Повезло вам с заказчиками... У нас в основном "хочу что-то вот так, включать, чтобы само отключалось потом...", да чтоб картинки красивые, и сенсорные кнопочки с анимашками... Вот и пиши с этого техзадание...

Если ПЛК не может работать в 24\7 - это плохой ПЛК, но чаще всего исполнитель не заботится о защите линий от бросков напряжения и т.п.

Пришло к чему? Поставить винду на 8и битник??

...а после этого обычно оказывается, что "Вы всё неправильно сделали, и вообще я хотел другого. Вы виноваты. Переделывайте всё....".
Сколько занисаюсь разработкой - ТЗ всегда писали сами, заказчик только читал и говорил что ему не нравится. Хотя потом всё равно приходилось переделывать, так как оказывалось что "я хотел не такого, а с перламутровыми пуговицами...."

Как ни странно, но здесь есть доля истины. Только чтоб работать со скриптами, их должна выполнять какая-либо ось, в которой есть уже готовые модули работы с портами в\в интерфейсами, типа того далласа, который указал автор, и еще многое другое. Тогда, да, будет быстрое программирование и не надо винду ставить, сам делал такие ПЛК.

если исполнитель должен заботиться о защите линий по входам 220V, то я скорее выберу свой вариант преобразования из 220V в 24V (с защитой) и возьму обычный модуль дискретного ввода, в противном случае получается необоснованный огород. В принципе мы так и делаем.

Да так и есть, к сожалению..

Тоже неплохой вариант, вообще считаю, чем больше низковольтки, тем надежнее.

По моему суть вашей "сложности" недостаточно раскрыта.
Может вам просто нужно провести рефакторинг.
По сути переход на ООП это будет рефакторинг и больше ничего.

Может вы еще 20-и часов не провели со своим кодом.
Правило 20-и часов гласит, что спустя 20-ч изучения в течении 20 дней любой код становится простым.

А насколько сложные программы вам удается писать под Овен и на каком языке?
Там многофайловые проекты можно написать?

Именно так. Есть ГОСТ 34.602-89
Когда речь идет о сколь нибудь сложных системах по другому нельзя, ибо заказчик в 99 случаях из 100 полный ноль в предметной области.

Тоже есть опыт использования продукции Овен, есть работающие проекты на ПЛК63, ПЛК100 + СП270. Отношение конечно плохое. ПЛК у Овен получились не очень. Что не понравилось:
- в ПЛК крепления верхней платы идёт (шло) на пластмассовых винтах, которые быстро ломались (после покупки сразу меняли на металлические). Элемент питания для RTC тоже сразу меняли (почти всегда были старые или не рабочие)
- если программировать через RS232, то постоянно терялась связь со средой разработки. Использовать переходники UBS-COM тоже не получалось (ПЛК критичны к уровням RS232), даже ноутбук со встроенным RS232 глючил, пришлось в цех тащить плату c COM-портами и вставлять в обычный ПК. Где то на форуме Овен говорили, что ПЛК110 лучше держат связь со средой разработки при отладке.
- панель оператора СП270. Конфигуратор (IDE) без предупреждений просто отказалась открывать проект, который создавался несколько дней. Как потом опытным путём выяснил - количество элементов отображения какого то типа (не помню уже какого) превысило 255. После этого проект умирал без предупреждений. Писал про этот глюк на форуме, но мне разработчики панели так ничего и не ответили.
- Теперь ПЛК63: в спецификации указан доступный пользователю объём RAM. Создал массив элементов с учётом данного размера, загружаю в ПЛК, ПЛК виснет. Хорошо есть комбинация из трёх пальцев, позволяющая вернуть ПЛК к жизни. В итоге выяснилось, что доступный объём меньше чем указано.

В общем ПЛК Овен работает, если у вас всё же хватит терпения довести проект до конца. У нас уже несколько лет работает и проблем вроде нет. Только СП270 всё же глючит при отображении (сейчас её вроде уже не выпускают). Среда разработки CodeSys 2.3, язык ST, многофайловые поддерживаются. Стандартное меню в ПЛК63 не использовал, сделал своё.

После мучений с Овен по возможности несложные проекты стали делать на ПЛК Delta (дешёвые ПЛК, которые применяются на производстве), правда среда разработки не поддерживала язык ST (не знаю как сейчас).

Как один из вариантов использования ООП для Вас.
(1) Если есть наработки для малых МК - можете рассмотреть возможность создания своего "компилятора".
Это на базе PC.
(2) В разрезе программирования МК. Если не использовали структуры - начинайте исползовать.
В структуры интегрируйте как данные, так и указатели на функции-обработчики этих данных.
Это можно делать на базе С - без плюсов. Эти структуры с разной инф. набирайте в массив.
Например, задача, которая решается элементарно таким способом - сложное меню.
Без единого switch-case и с одной "управляющей" функцией

"маленьких камней" - это как ?
Контроллер с Flash=32k + RAM=8k я маленьким я не считаю.
В контексте использования, например, scmRTOS это вполне достаточные ресурсы.
Вот когда Flash=1k + RAM=512 - это нечто Туда бы OS я и не думал, хотя есть и такие весчи.
Но это скорее не ОС а "планировщик" выполнения кода.

Спасибо за ответы.

Немного почитал о ОС. Мне точно не нужно. У меня нет ничего такого в системах что подразумевало бы управление переключениями контекста\задач\потоков. В моих системах все устроено так, что контекст переключается автоматически когда основной бесконечный цикл ПО снова и снова проходит все задачи по кругу. Я управляю процессом и четко знаю что и как устроено и как работает. У меня нет ничего стороннего в системе (если не считать LUFA для работы с USB).
Я понимаю, что RTOS это то без чего нельзя представить себе мир контроллеров, но вполне себе пока проживет мир RTOS без меня.

Еще очень интересно попробовать идею с объектами. Сам ООП в моей работе вряд ли поможет. А вот объект с свойствами и методами наверное то что нужно. Если есть что то простое для мелких мк - поделитесь ссылками. Спс!

Берете туже scmRTOS.
ОНО сделано на C++. Смотрите исходник как да что. И разницы, какой контроллер - большой или малый, нет.
Просто для контроллера с очень малыми ресурсами - IMHO - использовать класы, наследование, вирт. функции итд итп - смысла не имеет.
А имеет смысл (то что я сказал выше) разработка своего специализированого компилятора.
Точнее пре-компилятора для компилятора С или ASM. Вот тут можете на PC "разгуляться" c ООП и всеми его возможностями.

компилятора!? о_О

Ну так Вы и так из своих "наработок", думаю, постоянно собираете код проекта.
Или каждый раз пишите все с нуля ? По сути - ЭТО - есть компияция вручную

тогда вариант один - делить задачу между несколькими камнями, в каждом иметь законченный софт, при необходимости новых фич - досыпать ещё камней, не трогая прежние

Protothreads в помощь

Начал почитать.
Это некое подобие "безтиковой" ОС, кажется они называются "кооперативные" ?
Чтоб запустить на MK достаточно откомпилировать, портирование не требуется ?

Простите, как вы решаете вопрос "порчи" памяти? Как вы отслеживаете, что например процесс №1 записал данные, выйдя за границы массива на два элемента? Используете ли вы MPU в Cortex-m3?

Рядышком напишите статические переменные и функции и сверху и снизу поставьте коментарии со скобками - вот вам и объект со свойствами.
Зачем платить писать больше если нет разницы?

C++ был придуман для коллективной разработки.
Если вы не используете оси и вообще стронние исходники и проекты, то плюсы вам точно не помогут.
Только лишним множеством имён загрузитесь, потеряете производительность.

Хотя может подсознательно вы и хотите уйти в простой, отвлечься от целевой задачи.


Cortex-M3 давно уже не использую.
Не понял связи ошибки памяти с фреймворками.

Буратино, я думаю, что ваша проблема в том, что у вас нет четко определенной архитектуры ПО. Под архитектурой я подразумеваю то, что ПО должно быть разделено на программные модули, которые взаимодействуют друг-с-другом через четко заданные интерфейсы. Данный подход позволил бы вам разбить сложную программу на несколько простых, которые гораздо легче разрабатывать и поддерживать, а также портировать на другое железо. Сделаете ли вы это с помощью ОС, скриптов или других методов - это уже ваш выбор.

Что касается архитектуры ПО для системы управления, то у меня сложилась следующая архитектура, которую я реализовал не в одном успешном проекте:
К основным модулям данной архитектуры относятся: I/O менеджер, управляющй процесс, менеджер коммуникаций, логгер.

Задачей I/O менеджера является абстрагирование железа от остального ПО. Т.е он должен преобразовывать сигналы, получаемые от физических интерфейсов во внутренние "виртуальные" сигналы, которые затем будут использоваться управляющим процессом и менеджером коммуникаций. Под сигналами я понимаю состояния входов, измерения, команды на включение чего либо, статусные сигналы и т.д. Т.е смысл I/O менеджера в том, чтобы остальному ПО было наплевать откуда появляется нужный сигнал и куда он уходит. Сегодня это может быть пин А, завтра пин B, а послезавтра пин на слейве в Modbus RTU или SPI - все это должно конфигурироваться на данном уровне и только на нем. Также тут можно делать простые действия над сигналами - инвертировать, масштабировать. Неплохой функцией является возможность "подменить" значение какого либо сигнала на свое во время исполнения программы, чтобы упростить отладку. I/O менеджер должен работать в жестком реальном времени, с теми же циклами, что и управляющий процесс, поэтому важно его оптимизировать, чтобы он не занимал много процессорного времени.

Управляющий процесс - это сердце вашей системы. Он исполняет все управляющие алгоритмы, которые нужны в данной задаче - автоматы состояний, алгоритмы управления теплицей, курятником, турбиной и пр. Благодаря I/O менеджеру все выходы и входы управляющего процесса будут внутренними переменными, следовательно вы легко сможете изменять свои алгоритмы без необходимости изменять весь проект. Также это значительно упрощает повторное использование алгоритмов и функций, так как они становятся аппаратно-независимыми. Еще раз, важно - никакой непосредственной связи с железом в управляющем процессе. Управляющий процесс опять же исполняется в реальном времени в связке с I/O менеджером. Возможно иметь несколько управлящих циклов, работющие в многозадачном шедулере - самые быстрые с временем исполнения <1мс - например для различных защит, основные 10-100мс - где исполняются основные алгоритмы, медленные 100мс-1с - выборы режимов работы.

Управлящий процесс и I/O менеджер - это два модуля, работающих в реальном времени. Менеджер коммуникаций - уже нет. Его задачей является предоставление доступа различным нереалтаймовым интерфейсам типа HMI, HTTP , файловой систеы к виртуальным переменным I/O менеджера. Это собственно Scada интерфейс.

Логгер - подсистема, взаимодействующая с I/O менеджером и служащая для постоянной записи изменеий всех или выборочных виртуальных сигналов в лог-файл для следующей диагностики.

Приведенная архитектура возможно слегка сумбурна, так как по определенным соображениям не могу привести картинки - спрашивайте, если что не понятно. Как ее реализовывать - это уже дело каждого. Например ПЛК реализуют почти все из этой архитектуры, но на МК возможно вы на чем-то сэкономите. В простых системах все можно сделать даже без ОС, но в более сложных она понадобится. В самых высокопроизводительных системах, как у нас, вообще используется мультипроцессорная архитектура, а I/O менеджер частично реализован на ПЛИС.
Для разработки и отладки управляющего процесса при использовании данной архитектуры идеально подходит т.н. Модельно-ориентированный подход, реализованный, например, на Matlab/Sumulink. Тогда вы сможете сконцентрироваться на решении задачи, а не ее программировании. А все остальное за вас сделает программа, включая генерацию кода.
I/O менеджер в простейшем случае будет представлять shared memory, где хранятся различные переменные. А к этой памяти уже обращаются и драйверы и управляющий процесс. В сложных системах со многими сигналами это уже будет что-то наподобии быстрой базы данных.
Конечно, 8-и битник для всего этого слегка слабоват, так как такая архитектура имеет серьезный оверхед, но начиная с простого АРМ 32-х битника она уже легко позволяет получать циклы в 10мс на сотне-другой I/O сигналов.

Кооперативная многозадачность и "безтиковость" ОС перпендикулярны друг другу. Как тёплое/холодное и круглое/треугольное.

Точно. Стек протопотоков общий. Переполнение одно на всех. Отработка протопотоков асинхронная. Для 8-битников, на мой субъективный взгляд, очень удобно.

Связи нет никакой, скорее всего я озадачился размерами ваших программ))) Ну, а всё-таки, есть в том же kinetis что-то аппаратное, что позволяет вам как-то предохранять память от несанкционированного доступа? В "больших" камнях это решается MMU с вызываемыми исключениями...


Мне нравится ваш подход. Наверно потому, что и я думаю в этом же направлении Уже давно нахожусь на пути создания минимального базиса (фреймворка), включающего в себя ОС (пока FreeRTOS), стек драйверов (high и low-уровни), отладочная текстовая консоль (использую обточенную CLI из FreeRTOS), адекватный менеджер памяти, позволяющую понять куда она ушла (спасибо уважаемому zltigo!). Логгер пока ещё не присобачивал.

Я с вариантами разберусь, а вы пож. не постите ерунду больше.

syoma, спасибо за текст. Не мое точно. Точнее все то что вы пишите в том или ином виде есть по умолчанию в любом проекте. И абстракция и манагер процессов и логер если нужно. Только все это в примитивной форме в достаточной для решения моих задач. Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

"Что-то аппаратное" есть во всех Cortex-M - MPU. Использую MPU в всех своих проектах на Cortex-M обязательно. А почему собственно его не использовать?
Только предохранить какую-то конкретную переменную с помощью него конечно затруднительно. Зато при отладке MPU очень часто помогает.

Вот это все было бы хорошо оформить в виде статьи!
Пусть она будет небольшая, но тем не менее...
Прямо так и начать: "В конференции шло обсуждение... И мое мнение таково..."
И к нам, в КиТ...
Что скажете?