Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Имеет ли смысл вообще начинать обучать этим санкционным мк, если полно китайских 32разрядных?
Принципы-то одинаковы, а у них наверняка есть лаборатории, методички, преподы и все остальное под stm. Переделывать все не один год уйдёт.
Поддерживаю. Если и писать конфигуратор - то для 3-центовых Padauk. Потому что за 10 центов начинаются 32-битные клоны STM32 от Puya, поэтому смысла сейчас что-то делать на мёртворождённых STM8, и тем более обучать на них, как бы вообще нет.
Блин, какая же жуть эти ПО генерации. Что CubeMX, что это. Ну CubeMX хотя бы на Java сделан, что позволяет запускать его везде, а это .exe. Причём альтернатива же очевидная - простой DSL в духе ld (хотя и yaml'а будет достаточно), конфигурирешь что надо, генеришь. Понятная перегенерация (закинуть в make 2 строчки). Ну и главное, такое ПО можно делать расширяемым с помощью простых шаблонов в духе jinja2, если сообщество подхватит, то со временем всё что хочешь можно будет так конфигурировать, хоть отдельные контроллеры, хоть платы-отладчики.
Спасибо что вернули мне 2007й
Русские комменты, особенно для обучения студентов - это боль:
Некоторые проги из 90х, в т.ч. мои, после кучи редакторов и кодировок имеют совершенно нечитаемые комменты, автоперекодировщики и попытки вручную сменить кодировку не помогают;
IAR или еще кто-то неадекватно реагировал на ы, причем постоянно об этом забывалось;
программирование интернационально и лучше сразу писать на английском, я очень тяжело переучивался при смене работы.
И очень рад, что в институте у дочки сразу с первого курса и первых программ заставляли и учили писать комменты на английском, научилась очень быстро и теперь пишет их легко и быстро.
Я то же не совсем понимаю зачем писать такой конфигуратор? Да по опыту работы с Cuba под STM32 - HAL, который он генерит жутко избыточный, кроме того содержал массу ошибок и требовал потом ручной правки. Мы с ним работали примерно с 2013-2014 года. Как глобально поменяют - вот и сиди ищи.
Я бы автора ещё понял, если бы этот процессор имел массовой и очень широкое применение... Но смысл? Сейчас уже ядро устарело, есть ядро RISC-V и куча китайских дешёвых процессоров
Но если очень хочется заниматься данным конфигуратором автору я бы посоветовал связаться с нашими производителями микроконтроллеров - у вот этих вещей им точно не хватает ... Может научите их хоть чему-нибудь . А то, что бы во внутреннюю память готовое залить такие танцы приходится выплясывать.
Здравствуйте. Считаю, что очень полезная программа, в первую очередь для новичка.- очень наглядно. Сразу же попробовал в ST Visual Develop. Быстро избавился от кучи ошибок, осталась одна, с которой совершенно не знаю что делать - чайник. А ошибка такая: "#error clnk Debug\proba_config.lkf:68 Debug\stm8_interrupt_vector.o: symbol f_NonHandledInterrupt multiply defined (Debug\stm8s_it.o)
The command: "clnk -m Debug\proba_config.map -l"C:\Program Files (x86)\COSMIC\FSE_Compilers\Lib" -o Debug\proba_config.sm8 Debug\proba_config.lkf " has failed, the returned value is: 1
exit code=1."
Здравствуйте! Спасибо за отзыв и работу с программой.
Как я понял из текста ошибки - там двойное определение символа " f_NonHandledInterrupt " в файле " stm8_interrupt_vector.с " определен (дважды) и в файле " stm8s_it.* (расширение с или h)", найдите в обозначенных выше трех файлах этот символ и разберитесь где он не нужен.
Похожий символ я обнаружил в файле " stm8s_it.с" в строке 46 "INTERRUPT_HANDLER(NonHandledInterrupt, 25)", но он там без "f_"
У меня в указанных Вами файлах " f_NonHandledInterrupt " нет. Есть в файлах папки Debug, частности stm8_interrupt_vector.o, но там ничего не понятно.
Однако конфигуратор выполнен под парадигму - упростить студентам жизнь на 10% и не меняет тотально правила игры подхода в проектировании логики. Мое мнение, что отказ от кодирования с привязкой к языковым методам,именно то, что еще в ожидании, когда все что нужно знать кодеру останется "под капотом" в виде логического ядра, а разработчики будут строить модели своих алгоритмов простыми, немногочисленными инструкциями и их визуальным вводом в общую оркестрацию системы, без заморочек с загрузкой и прошивками, отладками таймингов, поиском библиотек, с визуальной симуляцией кода в работе и т.д. и т.п....
Вы правы - упростить жизнь не только студентам, но и тем, кто программирует эти МК давно, кто начинает учиться помочь избежать досадных ошибок по неопытности (периферию настроить а забыть включить ее настройкой AFR бит) и дать консультации в виде комментариев в коде. А тем, кто уже умеет программировать, не отвлекаться на рутинную настройку периферии.
При попытке разрешить работу какого либо канала таймера1 (TIM1_OUTPUTSTATE_ENABLE) выдаётся сообщение, что соответствующий пин занятфункцией GPIO_IN. Выходы настраивал, отключал - один результат. Это ошибка или я чего-то не донастраиваю?
Здравствуйте. Идете правильно. При разрешении работы канала таймера и других устройств необходимо подтвердить два раза, тогда все будет работать как надо. GPIO_IN это по умолчанию, система сообщает, что вывод свободен, вы подтверждаете, что хотите занять, система снова сообщает что заняла вывод Вашей функцией и Вы нажимает ок. Если не правильно и вывод не был GPIO_IN, программа не дает вообще включить выход.
"подтвердить два раза" что? У меня получается так: выбираю TIM1_OUTPUTSTATE_ENABLE, это значение остаётся, но выскакивает окно с сообщением, нажимаю ОК, оно пропадает и значение опять переходит в TIM1_OUTPUTSTATE_DISABLE. Повторные нажатия повторяют эту ситуацию. Один раз проскочило когда при нажатии на ОК окно не закрылось или тут же повторилось - не уловил и тогда при нажатии на ОК значение TIM1_OUTPUTSTATE_ENABLE осталось. Считаю, что тут какая-то недоработка.
Здравствуйте, спасибо что интересуетесь моей программой, чувствую надо видео мне сделать и показать некоторые тонкости, пока не успеваю.
В программе описанная Вами ситуация сделана для защиты от назначения двух функций на один вывод, посмотрите, на сообщение, которое Вы закрываете, там должно быть написано, что-то вроде конфликт и нельзя назначить вывод таймера.
При разрешении работы канала таймера и других устройств необходимо подтвердить два раза, тогда все будет работать как надо. GPIO_IN это по умолчанию, система сообщает, что вывод свободен, вы подтверждаете, что хотите занять, система снова сообщает что заняла вывод Вашей функцией и Вы нажимает ок. Если не правильно и вывод не был GPIO_IN, программа не дает вообще включить выход.
Если уж пишется тулс для обегчения жизни, то зачем разрабу нужны в.с. познания установочных инструкций производителя MCU. Почему бы не автоматизировать такую мелочь, как впрочем и все подобные рутинные вопросы, чтоб не нагружать абстракцию интерфейса юзера дополнительным комом начальных знаний, когда важен результат, а не рытье инструкций от дата шит.
Вопрос - на каком языке построено логическое ядро софтины? Его работа не должна, не имеет права на баги в разработке конечных или промежуточных исходников? Ответ я предвижу. Почему бы не применить в качестве ядра под токую IDE язык "G" который заточен под потоковое программирование и визуализацию ввода любых инструкцийв один клик, а блоки его кода при их применении не позволят ошибаться в процессе написания ядра. Глядишь и лагание будет сведено к нулю и сам по себе процесс создания исходника будет автоматным программированием, людям не придет в голову, что есть системная инструкция, о которой они не знали или забыли, другие баги...
И еще, при таком концепте Вы вынуждены постоянно следить и обновлять библиотеки всех тех МКшек, которые актуальны или будут развиваться и это тянет за собой шлейф дополнительных пересмотров всего ядра.
Здравствуйте. Спасибо за интерес к программе.
Это мой первый опыт такой программы, появилась она как попытка заполнить пробел фирмы ST по мк stm8, обидно, для STM32 сделали шикарный CubeMX с созданием кода и проекта на С, а для STM8 нет такой программы. Писал сначала для себя, для упрощения настройки и программирования, доступа к документации.
Я, как писали в комментариях выше, угадав - олдскул. Поэтому эта программа сделана на C++ Билдер - современный образец от 2020г.
А про какой язык "G" вы пишете, можно ссылку на его сайт?
Пардон, если не в тему, но все же это в параллельной экосистеме.
G не про кодогенерацию буквально, если на С вы выполняете описание инструкций, на которых должны функционировать процедуры алгоритма, то на G алгоритм строится из готовых инструкций - узлов. C и G - разные парадигмы, когда G значительно упрощает работу и одновременно исключает человеческий фактор ошибок переводя фокус в иной разрез программирования на потоке с возможностью параллельного выполнения нескольких последовательностей инструкций (потоков) в рамках одного процесса. Программист мыслит потоками данных, а не строками кода.
G, это когда, cреда разработки скрывает генерацию и оптимизацию кода, снижая количество синтаксических и инфраструктурных ошибок и смещая фокус программирования в сторону архитектуры, параллелизма и логики обработки данных.
А, Вы про ЛабВьюв, да, отличный язык (позволяет быстро делать код и интерфейс), я на нем роботов Studica программирую и ездить заставляю и видеокамеру использовать. Вы правы, для работы с G после классики C пришлось таки "сломать голову". Я больше G для измерений с датчиков и управления использую, там потоки и многозадачность нужны.
Не думал делать конфигуратор на G для STM8 (сам контроллер на С программирую, значит и конфигуратор на С писать надо:) ), подумаю над этим. Спасибо за идею.
В свое время лет 5 назад я так же думал о постройке кодогенератора с конфигураотором под MCU, для полигона взял отладочную шилду STM32 и занялся прототайпингом ее эмулятора, чтоб была комфортная GUI обертка под все хотелки разрабов. Настраиваешь GPIO под свой алгоритм и можешь посредством UART управлять состояниями GPIO из под LabView (типа I/O свисток) с возможностью дальнейшей С - прошивки, если результат нравится. Но в какой-то момент остановился, т.к. идея уперлась в массу ограничений, прежде всего концептуальных. Зачем клонировать слонов, если они все ограничивают Вас своей архитектурой, к слову не фонтан какой подходящей для многопортовых контроллеров, где требуется сложная оркестрация, за рамками возможностей RISC да и есть такие IDE визуального программирования (для баловства творческой молодежи).
В конечном итоге я пересмотрел идею в пользу CPU CISC x86 и там все стало на свои места без ограничений с упором на проекты со сложной автоматизацией.
Очень меня заинтересовала Ваша программа! И в самом деле, у STM Microelectronics нет достойного конфигуратора для микроконтроллеров STM8. Созданная Вами программа, устраняет этот пробел.
Какие отличия содержит программа в режиме Demo и в полнофункциональной версии, кроме отсутствия ассемблера?
Можно программу доработать так, чтобы в меню появилась возможность настройки интерфейса вкладок и выбор шрифта вывода сообщений? Ну это же просто какой-то наляпанный ужас с жирным стилем шрифтов, причем разных шрифтов! Содержимое программы отличное, но дизайн...?!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфигуратор микроконтроллеров STM8S103/105