
Комментарии 23
Я хоть и не питонист, но считаю проект интересный. Сам давно хотел сделать что то типа ОС для есп. Правда я рассматривал что то более низкоуровневое, вплоть до си (для самих приложений). Но есп сейчас много разных, на разных архитектурах, под каждую нужно будет отдельно компилировать. В любом случае приходим к тому что надо какую то виртуальную машину, которая в любом случае будет съедать производительность. Лучше уж взять популярный язык… Тем более на S3 зачастую есть 8мб psram. На простой esp32 особо не разойдешься… Интересно как там свои датчики подключать. Или на си библиотеку вкомпилировать или работать через функции i2c spi из питона
датчики можно подключать через функции микропитона, но если потребуется протаскивать большой объем данных: шрифты, изображения, звук, использовать DMA и пр. то без навыков написания хардкорного модуля для микропитона будет грустно. что касается 8МБ PSRAM, то опять же зависит от объема данных. если они влазят в кеш, то хорошо. а если ваша программа задумает обрабатывать изображения хранящиеся в PSRAM , то все упрется в скорость SPI шины.
Для этого для есть esphome проект, который интегрирован в home assistent. Там кода как такового вообще нет, все через описание на готовые библиотеки для разных датчиков и устройств управления. А этот микропитон вообще непонятно зачем нужен. Все есть в esp-idf от поставщика esp32 и прекрасно пишется любой код через opus4.6 с подключением любого мобильного телефона для вывода телеметрии.

esphome я тоже с удовольствием использую и с НА и без него. проект хороший. питонОС - это именно ОС для устройств с дисплеем, где можно быстро установить приложение, и получить нужный функционал. а также обмениваться готовыми приложениями. писать через ИИ конечно интересно, но тема не для каждого. к тому же если на то пошло у таких приложений исходники открытые, в теории, можно прямо с устройства попросить ИИ дописать уже имеющееся приложение. и для использования не надо ничего перекомпилировать. я думаю в будущем это превратится в мобильный телефон + lora и тд. на такой платформе можно легко реализовать много приложений чтобы получить из одной железки например: погодную станцию, мп3-плеер, читалка e-ink, гпс-трекер, лора-мессенджер или через инет, ИИ-помощник и многое другое. esphome не всегда для такого хорошо подходит. телефон для всего такого оыбчно подходит, но зачастую он громоздкий, и подключать доп датчики довольно костыльно выглядит.
еще бы какой то универсальный сокет придумать для быстрого подключения датчиков. хотя бы для прототипирования.
я думаю микропитон это промежуточный шаг, но тем не менее важный. эспрессиф сейчас допливает внедрение wasm, я думаю он получше будет, можно на разных ЯП писать приложения и возможно будет лучше производительность. lvgl подвязки там тоже есть.
и еще один кокурент Tactility OS - уже на плюсах, но там как я понял приложения встроены в прошивку. это все надо вкомпилировать в пошивку.
На простой esp32 особо не разойдешься…
MicroPython работает и на esp8266 это конечно не OS. :)
работает - знаю. даже на простой esp32 памяти мало, без всяких питонов - включить блютуз/вифи и делать https подключения всю память сьедает. а еще надо под backbuffer дисплея. запустится - да, но комфортно работать - вряд ли… lvgl надо и тд. Даже эту “OS” вроде портруют на CYD, с учетом его цены 600 руб за esp c тач дислпеем - интересно, но насколько оно будет юзабельно - большой вопрос. надеюсь скоро CYD сделают на esp c N16R8. разница в цене у них в пределах доллара, зато сразу насколько меньше головной боли
Память не сильно удорожает ESP, а например 4Мб уже достаточно для BT, Wifi и дисплея еще и остается... Программировать в python комфортней.
4 мб flash! еще нужна RAM/PSRAM, обычно её не хватает. и блюту и вифи и Https шифрование очень много сьедает, я уже не говорю про память под бэкбуфер кадра.
Я про RAM, но да... в зависимости от разрешения экрана, кадр может съесть и всю память.
да, там сейчас такие дисплеи подключают, что разрешение уже приближается к мегапикселю (1024*600 например). lvgl зачастую выделяет буфер 1/8 или 1/16 экрана и обновляет экран по частям. но это ценой быстродействия. для каждого такого тайла надо пробегать все дерево активных компонентов страницы и проверять что надо отрисовать сейчас.
ну а так любые интепретаторы RAM память в любом случае потребялют больше чем нативное приложение на си/плюсах. это сенйчас они делают запуск приложений по одному. потом в любом случае захочется иметь еще и фоновые процессы (чтобы отслеживать новые сообщения в мессенджере не заходя в приложение). несколько таких приложений на питоне и 8мб станет маловато, даже если дисплей выключен :)
все таки такая ОС это платформа для опенсорс телефона и ИИ помощника. а для ИИ помощника надо еще со звуком работать в обе стороны (микрофон/динамик) + частенькео нужна нейросеть для распознования имени ассистента…
Ещё такое можно сделать на net nanoFramework. И да, основное преимущество использования тоже будет в быстрой компиляции и универсальности
а еще есть espruino (под javascript). nanoFramework не совсем подойдет. питон и жс не надо компилировать на компьютере. можно пярмо esp надиктовать в микрофон какое приложение тебе надо и он через BB сервис навайбкодит тебе его, сохранит py файл и сразу же запустит. с .net такое не прокатит, там еще надо компилировать в IL сначала на компе. к тому же это завязка н аненависную виндовс. с которой в этом году началась волна “перейти на линукс” которую качают все публичные блоггеры… наверное под линуксом тоже можно собрать, но все равно у всех неприятная ассоциация .net=win.
ну и у питона коммюнити банально больше. а жс (espruino на quickjs) не выстрелил похоже изза того что жрет многовато памяти. на вскидку в esp8266 можно было создать макс около 1000 переменных и памяти нет…
переход на linux уже миллион лет пропагандируют, но это только на серверах сработало.
dotnet в целом уже очень давно не ассоциируется с привязкой к винде. Официальная реализация с 2014года не только под винду, неофициальная (unity, mono) так вообще ещё с нулевых годов.
Конкретно net nanoFramework можно собирать, отлаживать и под линуксом
https://docs.nanoframework.net/content/getting-started-guides/getting-started-vs-code.html
По поводу размера питоновского коммунити - ну и что что в каких-то областях оно больше, в каких то меньше. js же вон не выстрелил на микроконтроллерах, хотя у js в целом коммунити вроде как самое большое, но как вы заметили он жрет побольше.
И тут мы переходим к эффективности:
компиляция в IL нужна чтобы ускорить выполнение (и эту компиляцию можно сделать на внешнем сервисе, раз уж вайбкодит все равно где-то во вре. А если сильно заморочиться, то можно затащить компилятор в IL и на микрокотроллер).
Я сравнивал nanoFramework и microPython на одном и том же микроконтроллере, и microPython просто даже сильнее грел микронтроллер. А выделение тепла это как бы и на производительность, и на время работы от батареи влияет. И это либо потому что IL проще интерпретировать, либо потому что nanoCLR в целом эффективнее
Поймите меня правильно, лично я против .net ничего не имею. Но интересуюсь данной темой и слышал про него совсем немного. Как я понимаю он еще в зачатке, сыроват, ммало апи прокинуто. Такое ощущение что он пока экспериментальный (могу ошибаться). А это очень важно, esp-idf огромный на смамом деле и его АПИ по максимуму надо будет прокинуть в питон. это огромная работа и видимо коммюнити нанофреймворка не особо хочет этим заниматься. проблема JS-ников еще и в их высокоуровневости, а тут надо опускаться очень низко и глубоко…
но и в питон я не верю если честно :) хотя тут может показаться что я евангелист микропитона… лично я больше в wasm верю. espressif сами над ним работают, и там тоже компилируется. вы скорее из .net будете в wasm компилировать…
но на данном этапе это неплохой вариант. это позволит вовлечь много новых энтузиастов в эту тему. если раньше это балы платформа для создания своей погодной метестанции или инет-радио, то теперь для ИИ-помощников-ассистенотов. это будет основное назначение таких устройств.
и в общем становится понятно почему именно питонисты его возглавляют…
Да, в nanoFramework не все прокинуто. И нет автоматической прокидывалки, как я понял, хотя можно было бы сделать.
Хорошо, если wasm будет не как в отсталом вебе, где нельзя полную мощность железа использовать и где к апи все равно можно добраться только через один язык.
И ещё нюанс, что wasm из коробки не сможет позволять делать всё и сразу. Либо изначальная прошивка будет много весить.
Мне это в nanoFramework бесит, что все круто и быстро (любое приложение это именно приложение и у него очень быстрое развертывание, а не перезаливка прошивки целиком).
Пока не надо что-то новые железное использовать. А как только надо что-то, а этого нет в прошивке - то надо искать (или собирать самому прошивку) и перепрошивать. А это уже не быстро, не круто и не весело - но это вполне как философия микроконтроллеров
к WASM для интеграции с системой надо еще прикручивать WASI. тут тоже надо все прокидывать.
прикидывать приходится и библиотеки например вот lvgl прокидывают. https://github.com/espressif/esp-wasmachine/blob/master/components/wasmachine_ext_wasm_native/src/wm_ext_wasm_native_lvgl.c
в микропитоне без этого наверное тоже не обойтись…
и да начинаются проблемы с разными версиями этих библиотек и переход между ними. делать андройд с его версиями sdk на esp пока рановато.
Всем привет!
Я бы не сказал что этот проект нужен для IoT.
Ибо можно сделать свой небольшой планировщик на yield-ах, и вам этого скорее всего хватит.
Если же вы хотите изоляции и вытеснения - делайте свою VM для процессов которая уже обеспечивает это всё.
Ибо, в каком проекте который управляет датчиками и кидает это через Wi-Fi нужно тащить громоздкую систему которая просит дисплей, 8 МБ PSRAM и всё в таком роде? Ответ - ни в каком.
Чисто как эксперимент - да.
Но на практике, скорее всего лучше сделать планировщик задач небольшой.
Wi-Fi прикрутить не так сложно наверно.
загляните на любой маркетплейс, там все завалено платами от waveshare, liligo, m5stack и тд. они делают готовые платы на esp с дисплеями, зачастую довольно большими. есть e-ink и тд. создавая благодатную почву для создания своих носимых устройств: часов, подобие телефона, брелки, рации и тд. и использовать такое сложное устройство только для одной прошивки (проекта) довольно грустно. это как носить телефон с одним приложением. так что идея ОС для есп давно уже витает в воздухе. сам не раз подбивал камни к этой задаче, но планировал более низкоуровнево делать.
если вам надо передать показания на сервер - то вам ОС не нужна. банальный esphome выше крыши.
выше уже писал для каких это проектов: погодную станцию, мп3-плеер, читалка e-ink, гпс-трекер, лора-мессенджер или через инет, ИИ-помощник и многое другое. в первую это будет исопльзоваться как раз для ИИ помощников. разновидности проекта xiaozhi, только более продвинутые, заточенные под специфичные задачи.
платы под xiaozhi стоят от 500р и содержат все необходимое под голосового ИИ помощника: дислпей, микрофон, выход под динамик. и у esp хватает мощностей чтобы это все обрабатывать, самая дешевая платформа под такого самописного помощника.
погодную станцию, мп3-плеер, читалка e-ink, гпс-трекер, лора-мессенджер или через инет, ИИ-помощник и многое другое. в первую это будет исопльзоваться как раз для ИИ помощников.
И для чего здесь ОС?
Вижу смысл только в ГПС и ИИ.
для ОС все таки главное открытость и универсальность, наличие уже имеющегося коммюнити. месяц-два назад один человек тут опубликовал свою VM для esp32 (позволяет запускать один код на любой esp). но она проприетарная, закрытая, с нулевым коммюнити, и в итоге никого тут не заинтересовала.
Это согласен.
Но бывают проекты которые реально крутые, они открытые без проприетарщины, но почему то комьюнити всё равно нету.
риторический вопрос. может оно просто никому не надо? или есть конкуретны которые делают проект бессмысленным? а может просто авторы недостаточно его распиарили? не надо забывать, мы живем в мире где даже бесплатные вещи надо продавать :( в общем каждый конкретный случай надо отдельно разбирать. а общих причин можно десятки придумать.
Выпуск ОС MicroPythonOS 0.9.0 с GUI для микроконтроллеров типа ESP32 на базе инструментария MicroPython