Средства и методы разработки

мну "Хочем написать камент":) Вроде как идея базировалась на попытке оптимизировать выдачу задания для одушевленного кодогенератора:) и равно неодушевленного, ну и, соответственно обеспечить формальный контроль выполнения с возможностью подгонки. Т.е. полная постановка задачи типо зарисовывается, а отсутствующие части раздаются на написание после поиска наличествующего в кучеговнокода базе. Установка на изоляцию от оборудования также присутствовала, но затратная часть, как понял, пока опускалась. Т.е. в кучу собраны постановка глобальной задачи, постановка задачи локальной и привязка к железу, в т.ч., как понимаю, и портирование тоже, ну и всё это натягивается на абстрактную ось, которая тем не менее RTOS, с привязкой к хранилищу... (припоминается фраза, насчёт того, что нынче проще файл скачать из нета, чем искать на компе:)) Так понимаю, что обычно устоявшиеся решения окучиваются программным интерфейсом типо API, равно базовыми классами, и всё это загоняется в либы. Аппаратно зависимые же части писать приходится пока вручную и для их интеграции в имеющиеся проекты (портирование) достаточно простым решением выглядит использование опять же унифицированных программных интерфейсов. Думаю, что если программные интерфейсы спроектированы по определенным правилам и их придерживаются (как самих интерфейсов, так и правил при формировании новых), а разделение на системную часть (драйвера, сервисы и т.д., всякие UART-ы ясное дело тоже идут сюданах) и прикладную сделано, то вместо этого придумываемого крупного семикрылого... может оказаться достаточным использование общей постановки задачи и создание по ней спецификации модулей. Картинку по общей постановке можно нарисовать, а можно не рисовать:)