И теперь это возможно
FLProg + ИИ — от идеи до собственного блока
До недавнего времени создание собственного блока FLProg обычно означало достаточно глубокое погружение во внутреннее устройство программы, библиотеки, генерацию C++ и формат пользовательских UBI-блоков.
Но сегодня появляется другой подход.
Пользователю уже не обязательно начинать с написания большого количества кода.
Достаточно понимать, какое устройство мы хотим получить и как оно должно работать.
А дальше начинается совместная инженерная работа человека, FLProg и ИИ.
Реальный пример: создаём блок измерения температуры NTC
Задача была совершенно практической.
Есть обычный NTC-термистор.
Нужно получить для FLProg нормальный законченный блок измерения температуры:
• NTC 10 кОм или 100 кОм;
• подключение термистора к GND или VCC;
• работа как от обычного ADC микроконтроллера, так и от внешнего АЦП;
• настройка параметров термистора;
• периодический опрос без блокировки программы;
• отключаемый вход EN;
• результат как FLOAT и как целое значение;
• оформление и поведение в привычном стиле FLProg.
При этом хотелось не писать всё с нуля.
Шаг 1. Берём уже существующие решения FLProg
В качестве примера был выбран уже работающий блок ADS1115 и соответствующие библиотеки в стиле FLProg. ----------------------------------------------------------------------------------------------------------
То есть мы не просим ИИ:
«Напиши мне какой-нибудь код для NTC».
Мы говорим совсем иначе:
«Вот как в FLProg принято строить библиотеки и блоки. Вот рабочий пример ADS1115. Новый блок должен быть построен по тем же принципам».
Это принципиально важная разница.
ИИ получает не только техническое задание, но и образец архитектуры проекта.
Шаг 2. Описываем задачу обычным инженерным языком
Первоначальные требования могут быть совсем простыми.
Например:
«Нужен блок измерения температуры NTC 10 кОм. Делитель питается от 3.3 В. Хочу получить температуру в градусах».
После первой реализации появляются уточнения.
Нужен выбор 10 кОм / 100 кОм.
Нужно задавать Beta.
Нужна опорная температура T0.
Нужно учитывать номинал постоянного резистора.
Нужно поддерживать две схемы включения NTC — к GND и к VCC.
Нужна возможность передавать в библиотеку не только значение ADC, но и уже измеренное напряжение, например от ADS1115.
Нужен вход EN.
Нужна регулируемая периодичность измерений.
И так, итерация за итерацией, первоначальная идея превращается в законченный компонент.
Именно здесь ИИ оказывается особенно полезен.
Не обязательно заранее составлять идеальное техническое задание на десятки пунктов.
Можно построить первую версию, посмотреть на неё глазами пользователя FLProg и сказать:
«Вот этого не хватает».
После чего изменить архитектуру и повторить цикл.
Шаг 3. Не просто код — библиотека в стиле FLProg
В результате появилась отдельная библиотека:
RT_HW_FLProg_pin_NTC.hpp
При её создании задача состояла не только в вычислении температуры по формуле NTC.
Важно было сохранить принципы, уже используемые внутри FLProg и RT_HW:
• неблокирующая работа;
• периодический вызов из основного цикла;
• настройка через параметры блока;
• отделение библиотеки от визуального UBI-блока;
• возможность дальнейшего расширения;
• единый стиль с другими библиотеками FLProg.
Это уже не случайный фрагмент Arduino-кода из Интернета.
Это компонент экосистемы FLProg.
Шаг 4. Создаём пользовательский UBI-блок
Следующий этап — превратить библиотеку в настоящий визуальный блок FLProg.
У блока появляются:
• вход измеряемого значения;
• EN;
• параметры NTC;
• выбор схемы подключения;
• период опроса;
• выход температуры FLOAT;
• выход температуры в целочисленном формате.
После импорта блока пользователь уже не видит всю внутреннюю работу.
Для него это обычный элемент FLProg.
Перетащил на схему.
Задал параметры.
Соединил входы и выходы.
Работаем.
А дальше начинается самое интересное
Сегодня мы сделали NTC.
Но тот же подход можно применять практически к любому новому устройству или алгоритму.
Есть новый датчик?
Новый I2C-чип?
Расширитель входов/выходов?
Контроллер двигателя?
Дисплей?
Необычный промышленный интерфейс?
Берём документацию устройства.
Находим наиболее близкий по архитектуре существующий блок FLProg.
Описываем, что хотим получить.
И начинаем проектирование.
ИИ помогает:
• разобраться с документацией микросхемы;
• подобрать существующие решения FLProg в качестве основы;
• написать библиотеку;
• привести её к стилю проекта;
• создать UBI-блок;
• искать ошибки компиляции;
• изменять интерфейс блока по результатам тестирования;
• готовить документацию и примеры.
Но решение о том, каким должен быть конечный блок, остаётся за человеком.
И это, пожалуй, главное.
FLProg + ИИ превращает пользователя из потребителя готовых блоков в участника их проектирования.
Не обязательно быть профессиональным разработчиком библиотек.
Если вы хорошо знаете оборудование, с которым работаете, понимаете задачу и можете объяснить, каким должен быть удобный блок FLProg, — этого уже достаточно, чтобы начать.
Нам особенно интересны реальные задачи
Если у вас есть устройство, датчик, контроллер или интерфейс, которого пока нет в FLProg, — предлагайте.
Лучше всего, если у вас есть само устройство и возможность проверить результат на реальном оборудовании.
Именно такой цикл:
идея → первая версия → компиляция → реальное устройство → замечания → новая версия
позволяет получать действительно качественные блоки.
FLProg + ИИ. Теперь создать новый блок может не только разработчик FLProg.
Теперь в этом может участвовать каждый инженер, который знает, что именно ему нужно от своего устройства.
--------------------------------------------------------------------------
Результаты: готовые библиотеки и блок.
.
.