Есть три реализации для работы с АЦП — для STM32 F1/F3/F4.
Сейчас надо ручками (откуда-то) скопировать соответствующую реализацию, поправить пины, то-сё.
Хочется: первая страница — выбор семейства. Последующие страницы — зависят от выбора на первой, и запрашивают разные параметры.
В итоге — имеем .h и .cpp для включения в проект
Да, можно всё завернуть в библиотеки. Но это время, и не факт, что это когда-нибудь окупится.
Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Если взять другую среду, там будут свои аналоги. Только работают и генерят не совсем уже то и не совсем уже так. Можно использовать только готовое, можно изучать, как это сделано в конкретной среде и допиливать её средствами, но ведь удобнее, чтобы такое средство работало везде и всегда, вне зависимости от среды, и лучше — системы вообще
Здравствуйте, Marty, Вы писали:
M>Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Оффтопик, и давно с stm не работал, но чего HAL не заюзаешь?
SPL разве ещё поддерживается st microelectronics (багфиксы и прочее)?
Здравствуйте, Mamut, Вы писали:
M>Единственное из моих задач, которые подходят под это описание — это генерация блога. Для этого я взял Hugo. Для каких-то других задач у меня набор шелл-скриптов (например, переключение gcp и kubectl контекстов). Для каких-то третьих задач у меня будет что-то еще.
M>Как и где мне поможет какой-то «универсальный визард», учитывая, что универсальных задач мало, не понимаю.
Ну, у тебя вот какой-то набор скриптов есть, ты что-то запускаешь, какие-то параметры небось задаешь, и тп. Для этого вполне можно графическую морду приделать — удобно, когда не слишком часто такие задачи повторяются — имена параметров/значений забываешь, приходится лазить смотреть в сорцы скриптов. Опять же, такие скрипты плохо шарятся в команде — каждому надо будет их изучать. А допустим, вот мы на плюсиках пишем продуктовый код, а я напишу таких скриптов себе на питоне. А в команде питон никто не знают и нахрен он особо никому не сдался. А так — запустил визард, прокликал что надо, забил параметры и всё, готово
Здравствуйте, Михaил, Вы писали:
М>Оффтопик, и давно с stm не работал, но чего HAL не заюзаешь?
Ну, HAL — это кал. Во, даже в рифму вышло. HAL как раз во всю такой визард используется, большой и жырный, STM32 Cube называется. Мне всё это хозяйство не нравится тем, что понять, почему нагенеренное не работает мало реально, нельзя просто взять и перекомпилить код под другой камень — нужно опять в куб лезть и заного генерить рыбу, и тп.
М>SPL разве ещё поддерживается st microelectronics (багфиксы и прочее)?
SPL — да, на неё уже забили, но у нас всё легаси на нем.
Вроде на HAL ST тоже начинает забивать, у них там какая-то новая либа, какая-то LL вроде
Здравствуйте, Ops, Вы писали:
Ops>Примечательно: Ops>Image: brB7gME.png
Ops>А мне как раз хочется просто рисовалку, но с поведением, вроде открытия менюшек, адаптивности и т.п.
Ну так чего не хватает-то? Судя по описанию это именно оно.
Ops>Может фотошоп что-то такое и умеет, но он действительно сложен, а для простых случаев не так удобен, как лист бумаги.
Планшет графический подключи к фотошопу
Здравствуйте, Marty, Вы писали:
M>·>Зачем генерировать файлики-то? С++ вроде довольно мощный ЯП. Там и макросы, и шаблоны. Делаешь либу и реюзаешь... Понимаю ещё UI, там визуально нужно... но ведь это тупо код. M>Ну, код вроде и так написан уже с использованием либы — SPL называется. Только вот незадача — она слегка несовместима между собой для разных семейств MCU. Можно поверх еще оберток написать, или к хренам всё переписать на на регистрах, но это потребует времени, которое не окупится. А так — накидал визардик, он, в зависимости от выбранного семейства выбирает шаблон, и подставляет параметры
Звучит как: "Думать некогда, прыгать надо. Щаз тут я накопипастю!". В принципе иногда окупается, но если ты задумываешься о том, чтобы потратить время на автоматизацию копипасты, то это уже чересчур.
M>Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Это неимверное г-но которое тащут традиционно, т.к. когда-то было в первых версиях MSVS. Эти одноразовые визарды в топку, ибо юзабельны только для создания видеоучебников.
В той же IDEA есть рефакторинги и Intentions, которые не просто создают новые файлы, а действуют на уровне сущностей. Т.е. например, "сгенерить метод toString таким-то стилем для данных полей класса", "создать тест для данного класса", "добавить setUp метод для тестов", "первратить локальную переменную в поле класса". И если у тебя есть потребность делать такое — можно сделать плагинчик, API дан.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M> Регулярно встречается такая проблема (по крайней мере), что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
M>Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
Обычно подобные задачи решаются cmdline скриптами. Визард — это скрипт для специализированной задачи к которому добавили UI. Не совсем понятно зачем тебе UI, так как они обычно нужны только для сложной и/или продолжительной визуализации. Вроде у тебя не этот случай. Для шаблоной генерации файлов во всяких питонах и прочих есть куча удобных библиотек.
Здравствуйте, ·, Вы писали:
·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории.
Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Здравствуйте, novitk, Вы писали:
M>>Для таких случаев обычно в каждой уважающей себя среде разработки есть инструментарий для создания таких мастеров, а каждая уважающая себя библиотека, особенно претендующая на звание фреймворка, поставляет свои мастера-визарды для большинства популярных сред разработки.
N>Обычно подобные задачи решаются cmdline скриптами. Визард — это скрипт для специализированной задачи к которому добавили UI. Не совсем понятно зачем тебе UI, так как они обычно нужны только для сложной и/или продолжительной визуализации. Вроде у тебя не этот случай. Для шаблоной генерации файлов во всяких питонах и прочих есть куча удобных библиотек.
UI удобен тем, что не надо писать доки на скрипты — какие параметры задавать, какие значения допустимы и тп, затем, когда хочешь заюзать такой скрипт — доки надо читать, или даже в сорцы питонячьи лазить смотреть. А UI бы избавил бы от всего этого
Здравствуйте, Marty, Вы писали:
M>UI удобен тем, что не надо писать доки на скрипты — какие параметры задавать, какие значения допустимы и тп, затем, когда хочешь заюзать такой скрипт — доки надо читать, или даже в сорцы питонячьи лазить смотреть. А UI бы избавил бы от всего этого
"--help"? если выдача очень большая использовать подкоманды?
Это же и сделать намного быстрей чем UI, да еще и много удобней чем по кнопкам тыкать? Ты с командной строкой не дружишь что-ли?
Здравствуйте, Marty, Вы писали:
M>Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Зачем? Хоть 100500 параметров — запихнули все в файл "super-pupper-config_STM32_mod1234.json" с комментариями по необходимости
Здравствуйте, Marty, Вы писали:
M>·>Это какие-то корявые античные RPC-решения. Сейчас принято класть в проект описание протокола (protobuf-файлы, например) и делать шаг в системе билда, который будет на лету создавать файлики и скармливать их компилятору. Включаются в проект только исходники, которые могут правиться человеком, а не результат кодогенерации, который и видеть-то не нужно. Если приходится искать баги в сгенерированном коде, то надо что-то поправить в консерватории. M>Ну, вот у нас есть протокол обмена для девайсов, и есть язык, на котором описывается, что и как передается. Он умеет в плюсики несколько вариантом генерить, и в шарп. Так вот, он него параметров за сотню перевалило, и без вдумчивого чтения доки уже не разобраться. Вот тут тоже нужен бы визард
Всё равно непонятно. Т.е. доки плохие, куча непонятных параметров, только ты будешь знать какие кнопки в каком порядке натыкать, иначе магия не сработает... Жоп секьюрити что-ли?
Опиши конфиуграцию кодогенерации на каком-либо языке, json/xml/python/whatever и сделай частью исходников.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, novitk, Вы писали:
N>"--help"? если выдача очень большая использовать подкоманды? N>Это же и сделать намного быстрей чем UI, да еще и много удобней чем по кнопкам тыкать? Ты с командной строкой не дружишь что-ли?
Он MSVC пришиблен.
M>Ну, у тебя вот какой-то набор скриптов есть, ты что-то запускаешь, какие-то параметры небось задаешь, и тп. Для этого вполне можно графическую морду приделать
Никогда не было желания
M>- удобно, когда не слишком часто такие задачи повторяются — имена параметров/значений забываешь, приходится лазить смотреть в сорцы скриптов.
Ctrl + R == поиск по истории. Если надо, записывается в документ.
M>Опять же, такие скрипты плохо шарятся в команде — каждому надо будет их изучать.
У нас для этого есть Confluence. Даже изучать не надо. Скопипастил — и вперед
M>А допустим, вот мы на плюсиках пишем продуктовый код, а я напишу таких скриптов себе на питоне. А в команде питон никто не знают и нахрен он особо никому не сдался. А так — запустил визард, прокликал что надо, забил параметры и всё, готово
Опять же. Что именно прокликал, что за визард? Неизвестно никому. Повторю. Вот твоя задача:
что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
Что за поля? Неизвестно. Что за файлы генерятся? Неизвестно. Кто это все будет описывать и создавать в этом универсальном всемогуторе? Опять же неизвестно. Как это упростит «шаринг скриптов в команде»?
M>Вот посмотрите — в той же MSMS — визарды проектов в количестве пары-тройки десятков. Для тех же плюсиков — class wizard, qt class wizard. Для других языков не смотрел, но, скорее всего, там свои волшебники есть.
Потому что это фиксированный набор с заранее известными параметрами. Там нет никаких «универсальных визардов».
Здравствуйте, Mamut, Вы писали:
M>У нас для этого есть Confluence. Даже изучать не надо. Скопипастил — и вперед
Ну, у нас тоже вики есть. Не всегда помогает
M>
M>что делаешь ты что-то раз, другой, а на третий раз — понимаешь, что это уже рутина, и нужен какой-то визард (мастер), который бы ты вызвал — клик-клик, пару полей забил и — вот тебе сгенеренные файлики.
M>Что за поля? Неизвестно. Что за файлы генерятся? Неизвестно. Кто это все будет описывать и создавать в этом универсальном всемогуторе? Опять же неизвестно. Как это упростит «шаринг скриптов в команде»?
Ну, например, какой-нибудь class wizard свой.
1) На первой странице вводим имя класса
2) На второй странице выбираем, какой именно конкретно визард использовать — несколько радиокнопок или список, к примеру. Или дроп даун комбо. В зависимости от выбора задается имя файла (пары .cpp/.h) шаблона.
В зависимости от выбора последующие страницы могут быть разными. Например:
3) Вводим имя класса, от которого наследуем
4) [ ] check-box — "Добавить бла-бла-бла в protected часть класса "
5) Радиовыбор: "При реализации бла-бла-бла: ( ) — Использовать A ... / ( ) — Использовать B ..."
6) Список со множественным выбором: "Подключить опции: Опция 1/Опция 2/Опция 3/Опция 4..."
7) Финальная страничка: показываем что было выбрано (можно и без неё)
После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями, и он выплёвывает готовые файлики. Или, можно, например, сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
Описываем это всё в каком-нибудь конфиге, например, в каком-то "стандартном XML" (превед Шеридану ) или в джейсоне. Первый многословен, зато всё буль менее самодокументирован, во втором — писать проще, но с валидацией похуже.
Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
Здравствуйте, Marty, Вы писали:
M>Ну, например, какой-нибудь class wizard свой.
Магию в топку. Ты программист или где?
M>1) На первой странице вводим имя класса
Так и пиши в коде: class MyClassName.
M>2) На второй странице выбираем, какой именно конкретно визард использовать — несколько радиокнопок или список, к примеру. Или дроп даун комбо. В зависимости от выбора задается имя файла (пары .cpp/.h) шаблона.
В любом более менее сложном приложении в этом дропдауне будет тысячи элементов.
M>В зависимости от выбора последующие страницы могут быть разными. Например: M>3) Вводим имя класса, от которого наследуем
Добавляем : MyParentClassName.
M>4) [ ] check-box — "Добавить бла-бла-бла в protected часть класса " M>5) Радиовыбор: "При реализации бла-бла-бла: ( ) — Использовать A ... / ( ) — Использовать B ..."
Пишем protected: A blaBla;.
M>6) Список со множественным выбором: "Подключить опции: Опция 1/Опция 2/Опция 3/Опция 4..."
Хз что значит и скорее всего опций будет сотни.
M>7) Финальная страничка: показываем что было выбрано (можно и без неё)
Создаём пулл-реквест и на ревью.
M>После нажатия "Finish" берется пара шаблонов .cpp/.h, в подаем их на вход шаблонизатору вместе с выбранными опциями, и он выплёвывает готовые файлики. Или, можно, например, сконфигурировать так, чтобы какая-то команда запустилась, или еще что-то.
M>Из плюсов — такое описание само будет, как документация — видно, какие есть альтернативы, какие опции при разных альтернативах доступны, и тп. Можно по этому формальному описанию и доку человекочитаемую сгенерить.
Хорошая IDE умеет autocomplete, а с хорошим языком и прдуманным API — умеет контекстно-зависимо, показывая только доступные альтернативы. Да ещё и красненьким подчеркнёт, если что-то не так.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
M>>Ну, например, какой-нибудь class wizard свой. ·>Магию в топку. Ты программист или где?
Ок, я не программист.
Я не пойму, что ты мне доказать-то хочешь?
И при чем тут хорошая IDE, это только пример был для плюсиков, а в реале, допустим, надо сформировать командную строку для вызова какой-нибудь тулзы, или это какой-то шаблон кода на lua или сквиреле каком.
Здравствуйте, Marty, Вы писали:
M>Ну, например, какой-нибудь class wizard свой. M>1) На первой странице вводим имя ...
Да поняли мы что ты хочешь. Тебя спрашивают нафига тратить время на GUI? У MS уже есть VS и им имеет какой-то смысл это туда пихать, но тебе то нафига лишние сущности?
Документации не аргумент, так как гораздо проще ее добавить в "--help" или wiki.
) или в джейсоне. Первый многословен, зато всё буль менее самодокументирован, во втором — писать проще, но с валидацией похуже.