Всеволод, спасибо за подробный разбор. Вы очень точно описали один из сценариев, к которому мы хотим прийти: схема и документация компонентов -> проверка инженерных ограничений -> выбор архитектуры -> генерация и сборка прошивки. Особенно ценное замечание - необходимость анализировать не только код, но и саму принципиальную схему, распределение периферии, прерываний и ресурсов микроконтроллера. Мы не рассматриваем платформу как замену опытному инженеру. Скорее как инструмент, который снимает повторяющиеся операции и даёт специалисту проверяемую основу для дальнейшей работы. Пытаемся сделать так что бы нам самим для начала было удобно и понятно все этим пользоватся. А такой вопрос - что для вас было бы главным условием доверия к такому инструменту? А так же что бы конерктно вас как профи сподвигло пользоватся им?

Чистый, прозрачный и читабельный код, который экономно расходует системные ресурсы - вот основа доверия. Код, который можно поддерживать, - тогда нет повода не доверять.

Что бы меня сподвигло? Понятный и простой пользовательский интерфейс, хорошо написанная документация и широкая поддержка существующих семейств микроконтроллеров.

Вы очень точно сформулировали критерий, который для нас тоже является принципиальным: результат должен быть не просто работоспособным, а понятным, экономным по ресурсам и пригодным для дальнейшего сопровождения инженером. Мы пока не исходим из того, что ИИ уже способен стабильно писать качественный низкоуровневый C/C++-код для произвольных микроконтроллеров, датчиков и периферии. Поэтому базовые драйверы, библиотеки и программные модули мы разрабатываем и тщательно отлаживаем сами на реальном оборудовании. Роль ИИ видим несколько иначе: подобрать совместимые проверенные модули, сформировать конфигурацию проекта, связать их между собой и реализовать прикладную логику конкретного устройства. Как раз сейчас проверяем, насколько надёжно ИИ справляется с взаимосвязями между модулями, потоками данных, состояниями устройства и требованиями пользователя. Интересно ваше мнение из практики: какая часть embedded-разработки iot чаще всего оказывается самой сложной для формализации и автоматизации? Тоесть вопрос из области - какую "боль" инженеров и программистов вы посоветуете нам закрывать в первую очередь?

Понимаете, если задача четко сформулирована и есть нормальная принципиальная схема, то боли никакой не должно быть. Ну бывает такая дилемма: использовать операционную систему реального времени (RTOS) или нет? Тут важно знать перспективу: этот проект будет развиваться или нет? Если менеджмент скажет, что это одноразовая работа, это один сценарий; если скажут, что проект будет развиваться и расширяться, сценарий совсем другой.

Действиельно, вы правы ключевая сложность часто возникает ещё до начала программирования — на этапе выбора архитектуры с учётом того, как устройство будет развиваться дальше. Если не подумать об этом в самом начале проекта, то это грозит большими проблемами и потенциальными убытками в будущем. Специалисты из крупных компаний также рассказывали мне, что в начале проекта бывает непросто разобраться в предметной области и чётко сформулировать реальные требования. Я и сам как разработчик регулярно с этим сталкиваюсь. Для нашей концепции это важное замечание. Возможно, система не должна сразу переходить к сборке прошивки. Сначала ей необходимо подробно расспросить инженера или заказчика о предметной области, назначении устройства и перспективах проекта: это разовая разработка или развиваемый продукт, будут ли добавляться новые функции и интерфейсы, потребуются ли обновления, диагностика и масштабирование. Нужно отдельно продумать такие критерии и правила, по которым система будет делать из ответов архитектурные выводы. И только после этого предлагать bare metal, RTOS или другой вариант реализации, объясняя причины выбора. Признаюсь, настолько глубоко этот этап мы пока не рассматривали. Спасибо вам за содержательные комментарии - они действительно помогают точнее сформулировать концепцию платформы.

Anytime

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

Вот бы вспомнить. Помню что много таких было. Я и сам такую делать пытался.