Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Железо и гаджеты доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 36
Да, пора бы использовать. Удобный механизм. Спасибо!
Единственное, сравнение с FreeRTOS мне кажется немного некорректныйюм, так как она все таки вытесняющая, там куча примитивов синхронизации. Наверное логичнее было сравнивать с кооперативный многозадачность.
Но в любом случае, а синхронный подход на микроконтроллера очень полезный.
Сравнение с FreeRTOS тут чисто для оценки накладных расходов на хранение контекста задач, в реальных мелких проектах вытеснение часто вообще не нужно, а память под индивидуальные стеки улетает мгновенно
Вот да! Во FreeRTOS же есть корутины, так и надо было запилить кооператив без тасок и сравнить с ним
Можно вместо корутин рассмотреть возможность отделения данных от кода, может получиться гораздо эффективнее и проще: поморгать светодиодами по таймингам
Плюс бонусом - можно менять данные в таблице извне - управлять алгоритмом переключения светодиодов, таймингами не меняя код!
Тут я как раз и хотел уйти от такого кода и поручить всю “грязную” работу по созданию конечного автомата компилятору. Естественно получается менее эффективно по ресурсам чем писать руками, но зато последовательный код легче читать.
ну у меня надо читать последовательные данные - алгоритм записан данными, вроде как. Код как бы не имеет отношения к алгоритму - код читает и интерпретирует данные.
Но это конечно кому как нравится тот так и формулирует. Акценты можно по разному, конечно, расставить. Важно что код который интерпретирует данные, по определению уже управляется этими данными и если такое управление нужно для чего-то оно уже есть.
Так можно дойти и до собственного ассемблера, зашитого в массив констант внутри прошивки))
до ассемблера нельзя! До Питона можно.
До питона не стоит, это интерпретируемый язык и жрет слишком много ресурсов. Не для микроконтроллеров уж точно.
https://www.ethernut.de/en/firmware/nutlua.html
вот он, интернет вещей двадцатилетней+ давности: atmega128, RTL8019 и Lua
Аналогичная питону фигня. Не одним интернетом вещей обуславливается применение микроконтроллеров.
Как тогда пытались применить скриптовые вещи в микроконтроллерах, так и сейчас пихают в них все что не попадя, лишь бы не изучать C и C++. Всё думают что напишем на питоне или Lua и будет также, как на C++, только проще и быстрее. Но так не работает!
дело не в С/С++ а в пользовательских сценариях/скриптах, и для изменения строчки в конфиг файле типа if(some_sensor()) lights_on(); пересобирать всю прошивку довольно глупо.
Ну а то что это немного "просочилось" наружу и позволяет делать несколько больше - вполне нормально, если без фанатизма. Лишних полсотни кБ флэша и десяток-другой кБ памяти под это нынче в любом МК найдётся. Раз уж 20 лет назад в avr влезало.
А кто сказал, что это было хорошо для avr?
Это редкостная скриптовая хрень была, которая ни тогда не пользовалась спросом ни сейчас. А лишних полсотни килобайт и сейчас на микроконтроллере не отыскать.
Если в программирование микроконтроллеров лезут диллетанты с питоном, растом, го и прочими языками, как они считают высокого уровня, то микроконтроллер теряет свой смысл, теряет ту необходимую производительность и становится примитивной игрушкой для моргания светодиодом.
Проходили это уже не один раз.
А никто не говорит про "хорошо", но для конфигурирования поведения "в рантайме" в любом случае появится какой-то парсер и интерпретация/vm+байткод. И изобретение своих корявых велосипедов под это ради экономии десятка кБ - ещё большая хрень.
С разморозкой, за условный 1$ нынче находятся мк с лишней парой сотней КБ RAM, а за 1.5$ ещё и с лишней парой МБ флэша. Можно конечно экономить на спичках какими-нибудь масочными paduk или attiny у которых регистров общего назначения больше чем памяти и которые только для контроллера моргания светодиодом и пригодны, но зачем?
Никто ни купит девайс который будет стоить как крыло от самолета, если конкуренты экономят “на спичках” и ставят микроконтроллер которого хватает впритык
В любом случае если девайс выпускается огромными тиражами, каждый цент BOM выливается в ощутимую экономию и может оказаться что эта экономия перевешивает дополнительные затраты на разработку
Полностю поддерживаю, потому как сам делаю такое. В партии из 100 000 устройств, если я возьму мк за 90 центов, вместо мк за 3 доллара (но они будут выполнять одинаковыые функции) и мне придется проработать программный код на 5 дней дольше, то чистая экономия - 210 000 долларов только на МК. А еще, заливать прошивку из образа куда быстрее чем транслятор, а потом программу на питоне.
И в таком случае я более конкурентен чем другие. Делаю дешевле, за тот-же функционал и быстрее. Ъ
А еще, заливать прошивку из образа куда быстрее чем транслятор, а потом программу на питоне.
А пользователю железки компилятор выдадите для пересборки прошивки, если ему конфиг поправить надо? (вместе с лицензией на какой-нибудь IAR, мы же не разбрасывамся, как конкуренты, лишними килобайтами флэша, а он местами там процентов 20 может наоптимизировать по объёму/скорости, на 100 000 шт. окупится)
Вот для примера как делать не надо - TMCL для вумных контроллеров шаговиков. Для описания пользовательских скриптов (опроса АЦП, концевиков, для всяких автореферерсирований) - изобрели $%^#! недоассемблер, с отдельной IDE для компиляции этой красоты в байт-код. Судя по МК которые там установлены ту же Lua (а-ля nodeMCU) можно было целиком впихнуть вместе с парсером и "компилятором", причём пару раз, а уж если их обрезать и на ПК вынести, оставив внутри только виртуальную машину для исполнения байт-кода так тем более.
И как по вашему это реализовывать надо было? Для повышенной эффективности и конкурентноспособности отдать пользователям в руки GCC и делать систему плагинов и динамических библиотек в МК? Плюс там у них ещё и зоопарк МК в различных контроллерах, старые с ARM7TDMI попадались.
В некоторых сферах пользователи не хотят ничего настраивать. В процессе разработки появляются четкие требования как должна работать железка. Под них и собирается прошивка, затем заливается во всю партию
При этом в пользовательские настройки выносится только то что нельзя записать на этапе производства (к примеру modbus адрес или LoRa AppKey)
Ну а в некоторых других - хотят. Причём не простые настройки параметров, а более сложное поведение с условиями, которое в конфиг вида параметр=значение не вынесешь.
А в чем проблема дать пользователю настроить девайс? Из 100 000 девайсов, перешить его захотят пару человек. Только перешить и дать интерфейс настройки это разные вещи.
Но вы ушли в другую сторону, видимо для того, что бы просто поспорить. Я написал, что заливать прошивку (собранную компилятором) быстрее чем отдельно заливать транслятор а потом заливать код питона. Это говорит о том, что для 100 000 экземпляров при промышленных масштабах заливка транслятора и отдельно программы на питоне займет в несколько рах больше времени, а это деньги. Это первое, второе - если эту железку начнет перешивать любой школьник питоном, то кто будет нести за это ответственность? Придется закрывать код транслятора, а это делать - тот еще гемморой на открытом трансляторе.
Кому, в здравом уме, нужны эти затраты, дыра в продукте в виде питона, ноль производительности и отсутствие надежности?...
Вы как то индивидуально и сильно по своему смотрите на это. Все должны делать так, как вы думаете. А вам объясняют что мир устроен иначе, но вас это не устраивает.
А пользователю железки компилятор выдадите для пересборки прошивки, если ему конфиг поправить надо?
А с какого перепугу пользователь будет перешивать мою железку?
Как часто вы перешиваете программный код стиральной машины, посудомойки, пульта от телевизора и прочих устройств? Таких людей, котоые хотят что-то перешить - человека 3 на миллион. Остальные просто пользуются. А изменение конфига - это просто настройки в виде (web интерфейса, как на вашем домашнем роутере) и микроконтроллер самостоятельно сохранит эти настройки в нужную память.
Что за странный пример...
Вот для примера как делать не надо - TMCL для вумных контроллеров шаговиков. Для описания пользовательских скриптов (опроса АЦП, концевиков, для всяких автореферерсирований) - изобрели $%^#! недоассемблер, с отдельной IDE для компиляции этой красоты в байт-код.
Разве мы говорим о продукте для других разработчиков? При чем тут программный код скрипта, которым другие разработчики могут воспользоваться? Вы куда-то не туда ушли. Или все ищите примеры что бы доказать что питон, lua и прочая скриптовая фигня имеют место применения в микроконтроллерах?
Отвечаю - да, имеют, с массой ограничений.
Если нужно просто передать тупой код от одной или нескольких кнопок через радиоканал в рамках одного микроконтроллера. Зажечь светодиоды, пощелкать реле, покрутить моторчиком. В условиях 1-2 экземпляров в режиме отладки. На столе школьника. Это просто один из примеров, не нужно на него опираться как на базу.
>Отвечаю - да, имеют, с массой ограничений.
Ну так изначально это и был пример такого использования скриптового языка внутри железки в качестве гибкого конфиг файла. К которому вы прицепились что "это всё фигня и так не работает".
Я и не предлагал писать всё на питоне и собственно никто так особо и не делает. Сам контроллер шаговика, который отсчитывает step/dir драйверу с заданной скоростью по команде или общение между avr и rtl8029 и ip стэк внутри не на скриптовом языке написаны, но вот сделать биндинги для этих функций наверх пользователю, чтобы он ими пользовался - вполне нормально и без ущерба для производительности. Но всегда можно сэкономить несколько центов на нескольких десятках кБ флэша и данную фичу не реализовывать, попробуйте, расскажете потом про конкурентноспособность.
Вы занимаетесь разработкой программного кода для микроконтроллеров и разрабатываете устройства на микроконтроллерах?
Со стороны и будучи прикладным программистом, многие рассматривают микроконтроллер как обыкновенный пк, но с меньшими характеристиками и менее производительным. Но задачи микроконтроллера - это в большей мере аппаратная работа, взаимодействие с входами, выходами, периферией и чем быстрее, тем лучше. Мягче выполнение кода, чаще опросы, плавнее работа.
И использование сторонних "высокоуровневых" языков программирования и тем более на базе транслятора (Python) снижает производительность микроконтроллера и особенно это сказывается на аппаратных возможностях. И самое печальное, если вы возьмете микроконтроллер в 10-20 раз производительнее и дороже на 10 долларов, но на Python, его аппаратные возможности будут хуже чем у микроконтроллера за 1 доллар.
А что касается парсеров, это не проблема для С++ и как правило, парсеры стараются не использовать в таких МК и на С++.
И здесь вовсе не проблема в памяти и в чем-то другом.
Аппаратные возможности и отклик - всегда в приоритете для разработчиков электроники.
Микроконтроллеры как правило это не только мигалки и примитивные однозадачные устройства умного дома типа (датчик температуры, влажности и прочее)
И разработчики электроники сильно отличаются от прикладных программистов.
Я бы даже сказал, что вытесняющая FreeRTOS всего на 40% больше тратит время на переключение в сравнении с явной кооперативностью -- это даже скорее неплохо.
Если у вас есть возможность поставить в железку быстрый микроконтроллер с сотнями килобайт ОЗУ и Flash то корутины не имеют особого смысла.
Если цель максимально сэкономить BOM, приходится ставить максимально урезанные микроконтроллеры. RTOS для них уже дороговаты по ресурсам.
Корутины - это способ не писать FSM, только и всего. Они не добавляют реальных возможностей, это просто сахар. Как и С++.
У меня почему-то на сахарном С++ прошивки получаются меньше и/или быстрее, чем на голом С. По коду они короче, понятнее и легче читаются. Какой забористый сахар выходит 🤤.
Ассемблер тоже является сахаром, ибо он ничего не добавляет в плане реальных возможностей к машинному коду. Но почему-то в кодах давно уже не пишут...
Есть примеры реализации вытесняющей многозадачности с вполне сравнимыми требованиями по ресурсам, если не меньше. Переключение вроде даже быстрее, а потребление памяти, те же полсотни байт сохраняемого контекста на задачу.
Основная разница - раздельные стэки у задач и отдельное резервирование памяти под это.
быстрый микроконтроллер с сотнями килобайт ОЗУ
ага, avr и stm8 :)
scmrtos, process switching latency:
900 ns on Cortex-M4 @ 168 MHz
1.8 us on Blackfin @ 200 MHz
2.7 us on Cortex-M3 @ 72 MHz
5 us on ARM7 @ 50 MHz
38-42 us on AVR @ 8 MHz
45-50 us on MSP430 @ 5 MHz
18-20 us on STM8 @ 16 MHz
Главная засада таких кастомных патчей компилятора в том, что ты намертво привязываешься к конкретному форку Clang. Как только проект переходит на новую версию тулчейна или требует сборки под GCC, этот красивый сахар превращается в тыкву. В долгоживущем эмбеддеде рукописные конечные автоматы до сих пор живут именно из-за стабильности сборки на любых компиляторах
Я тоже написал свой велосипед когда свободная ОСРВ перестала влезать в F031.
Я пару лет назад баловался с сопрограммами в Кейле (тамошний компилятор -- ARMCLANG, т.е. обычный clang, несколько подпиленный АРМом). Сами сопрограммы в итоге работали успешно, но вот отлаживать их было возможно только на уровне дизассемблера: штатному отладчику Кейла они напрочь срывали крышу (он терял, в т.ч., способность сопоставлять адреса выполняемого кода с конкретными функциями Си++).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заводим C++ корутины на микроконтроллере