Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"MicroPythonOS - ОС с графическим интерфейсом для микроконтроллеров"	+/–
Сообщение от opennews (??), 11-Окт-25, 08:55
Опубликован выпуск проекта MicroPythonOS 0.0.11, разрабатывающего операционную систему для микроконтроллеров, таких как ESP32, написанную с использованием инструментария MicroPython. Операционная система оснащена графическим интерфейсом, развиваемым с оглядкой на Android и iOS, и поддерживающим управления через сенсорные экраны. Из областей применения MicroPythonOS упоминаются устройства интернета вещей (IoT), системы управления домашней автоматизацией,  интерактивные панели, роботы и умные носимые устройства с управлением экранными жестами. Проект также может применяться для быстрой разработки прототипов новых устройств.  Код написан на языках Си и Python и распространяется под лицензий MIT... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64038
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–20 +/–
Сообщение от Аноним (1), 11-Окт-25, 08:55
pip поддерживает? встроенный редактор с проверкой синтаксиса есть? глобальный лок на месте? cphyton и pytorch все библиотеки поддерживает? если нет, то зачем?
Ответить | Правка | Наверх | Cообщить модератору

	2. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+14 +/–
	Сообщение от заполнить поле Name (?), 11-Окт-25, 09:00
	>pytorch >на ESP Ахахахаха. Хорошая шутка.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (10), 11-Окт-25, 10:39
	Распознование лиц и детекцию объектов делают же ж на ESP32, там simd есть.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от Аноним (23), 11-Окт-25, 13:57
	В случае микроконтроллеров её делали или на плис или или на специальных модулях.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от Смузихлеб забывший пароль (?), 12-Окт-25, 11:04
	в есп32-кам что-то подобное делали, но частота кадров была не сильно выше нуля не надо забывать, что там памяти мало помимо того, что это мк пусть и мноргоядерный, ещё и любящий поглючить/зависнуть
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	81. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (81), 12-Окт-25, 11:47
	> Распознование лиц и детекцию объектов делают же ж на ESP32, там simd есть. Вы еще на китайском тетрисе его сделайте. Измеряя перфоманс в юнитах FPH (frames per hour). Сидите спокойно перед старым фотоаппаратом, как мумия, иначе картинка смажется^W^W рожа не распознается.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	111. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (111), 13-Окт-25, 12:27
	как же вам наверно тяжело жить в таком странном информационном пузыре https://github.com/jomjol/AI-on-the-edge-device
	Ответить | Правка | Наверх | Cообщить модератору

	3. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+4 +/–
	Сообщение от Stanislavvv (ok), 11-Окт-25, 09:02
	"Потому что можем!" © С учётом ресурсов микроконтроллера — сомневаюсь, что там много чего есть. Вообще, идея писать все приложения для ограниченных ресурсов на интерпретируемом языке сомнительна, по-моему.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	4. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+6 +/–
	Сообщение от Аноним (4), 11-Окт-25, 09:08
	Был же basic на минимуме ресурсов
	Ответить | Правка | Наверх | Cообщить модератору

	82. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (81), 12-Окт-25, 11:52
	> Был же basic на минимуме ресурсов Был. И были нативные программы. И например Microsoft C 80 какой. И проч. Тоже на мизерных ресурсах. Почему-то про басика успешно все забыли. А сишка живет с своих 70х и далее.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от pofigist (?), 11-Окт-25, 09:36
	man forth
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	104. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Stanislavvv (ok), 13-Окт-25, 08:09
	Толку с него в чистом виде... Нет, когда конкретно форт-процессоры используются — ок. А так...
	Ответить | Правка | Наверх | Cообщить модератору

	134. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 17:18
	> man forth ок, покажи свой хеловрот на форте. Вот для ESP32. Можно без сенсорного экрана (который один хрен непонятно как подключать), а просто как у таких esp принято - веб-мордочка где-то. Где-то разумеется динамическое и проявляет свой адрес каким-то (на твое усмотрение) автоматическим способом. Ждем, уже ведро пиваса закупили и два чемодана попкорна.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	15. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от _kp (ok), 11-Окт-25, 12:36
	Городить OS на Питоне, точно глупость, а сам Микропитон, как дополнительный скриптовый язык вполне практичен и его даже хватает. И для экранного интерфейса Микропитон вполне удобен и скорости хватает.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	24. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (23), 11-Окт-25, 13:57
	Хайп ради хайпа и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от Аноним (96), 12-Окт-25, 20:44
	Сначала они городили фронтенд на питоне, для меня это было шок, потом я узнал про бекенд на питоне, шок(х2), а теперь ОС на питоне - здезда в шоке. Мы с этим питоном свернули куда-то не туда.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	117. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от x3who (?), 13-Окт-25, 19:00
	Микропитон для того и сделан, чтобы на нём операционные системы писать - ведь прошивка МК она и есть сама себе ОС.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Смузихлеб забывший пароль (?), 12-Окт-25, 11:11
	> Поддержка запуска как на платах с микроконтроллерами ESP32, > так и на обычных ПК или платах с Linux, таких как Raspberry Pi c Raspbian. > Поддержка установки внешних приложений, распространяемых через > централизованный каталог App Store (например, просмотрщик изображений и > программа для работы с камерой) Вдобавок, вероятно, ещё и с подвиранием. Апп Стор, который яблочный, на перечисленных устройствах едва ли работает тупо потому что работает под ябблОСью. Ну и бонусом - там сложности с выгрузкой приложений, работающих на интерпретируемых ЯП, под которые нет встроенных движков у яблока. Для жс ещё можно применить вебкитовский жс-кор( свой - нельзя ). С питоном могут быть сложности не меньше, чем с си-шарпом Либо типы просто врут, либо - попытались спереть оф. название конкретного магазина приложений( даже у гугла не Апп Стор, а Плей Маркет )
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	105. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Stanislavvv (ok), 13-Окт-25, 08:21
	Думаю, третий вариант — тупо посчитали, что App Store — нечто нарицательное, а не ™ Что, впрочем, дополняет портрет.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Соль земли2 (?), 13-Окт-25, 09:58
	MicroPyTorch минимальные требования: ESP6080Ti Super.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	116. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от x3who (?), 13-Окт-25, 18:58
	Оказывается, оно и в самом деле есть, но требует просто ESP32 :) https://github.com/ljk53/upytorch
	Ответить | Правка | Наверх | Cообщить модератору

12. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
Сообщение от Аноним (12), 11-Окт-25, 12:02
А что, если занять МК полезной работой? Да ну на! Давайте крутить на нём интерпретатор питона для рисования поросячьих мордочек!
Ответить | Правка | Наверх | Cообщить модератору

	17. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+5 +/–
	Сообщение от _kp (ok), 11-Окт-25, 12:44
	С рисованием ситуация такая - есть крутая библиотека lvgl для дисплейных панелей, которая поддерживает и отрисовку кнопочек и жесты, и sdl, и видео, а ней есть интерфейсы на Микропитоне и С, но не С++. Из этих двух, Микропитон поудобне. А в инновационной "ОС" вряд ли наизобрелали велосипедрв, а скорее обмазали RTOS+LVGL питон прокладками, и назвали получившееся ОС. Если не придираться к термину ОС, то в остальном ничего плохого, по сути интергировали имеющеся и упростили работу для любителей Питона.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от ptr (ok), 12-Окт-25, 00:33
	> есть интерфейсы на Микропитоне и С Ещё и Rust https://docs.rs/lvgl > Микропитон поудобне. Но сильно нагружает оперативную память, требует довесок в четверть мегабайта флеша и намного медленней. Eсли на высокопроизводительном ESP32-S3 это еще можно терпеть, то на ESP32-C3 это превращается в большую проблему. Впрочем, именно поэтому MicroPythonOS наиболее популярные ESP32 (Xtensa) и ESP32-C3 не поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (10), 12-Окт-25, 00:47
	> Но сильно нагружает оперативную память, требует довесок в четверть мегабайта флеша и намного медленней. Это ничего, менеджер из своего кармана докинет по 5 баксов на более мощный проц и флеш в партии миллион штук, а пользователь потерпит. Главное, чтобы программистам удобно было и не нужно было учить С!
	Ответить | Правка | Наверх | Cообщить модератору

	60. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 01:00
	> Это ничего, менеджер из своего кармана докинет по 5 баксов на более > мощный проц и флеш в партии миллион штук В сумме $5 миллионов? Сами готовы столько выложить? ))) Если вспомнить, что ESP32-C3 стоит $1, то Вы предлагаете пятикратное удорожание!
	Ответить | Правка | Наверх | Cообщить модератору

	106. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от _kp (ok), 13-Окт-25, 09:26
	> Ещё и Rust https://docs.rs/lvgl Благодарю, гляну. >> Микропитон поудобне. Так, альтернатив не густо. Лично мне может больше JS по душе, вариант LVGL для JS есть, но он так себе, а к ESP32 не применим вовсе. Но, из того что доступно и работает, пока остаётся Микропитон. > сильно нагружает оперативную память Это не проблема пользователя. Копеечный PsRam - и нет проблем. На ESP32 полет мысли в принципе жрет память и без скриптовых языков, и нередко только встроенного ОЗУ недостаточно. Если интерфейс дисплея не статический, с парой экранов, то на объектном или скриптовом языке результат круче и делается быстрее. Более того если говорить именно о LVGL, то на Cи, что то кроме статического интерфейса делать, и вовсе неблагодарное занятие. > на высокопроизводительном ESP32-S3 это еще можно терпеть Так, на скриптовом языке не надо писать не то что критичный код, но и общую часть приложения. А экранный интерфейс получается хорошо, как и работа с настройками.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	109. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 13-Окт-25, 11:01
	>>> Микропитон поудобне. > Так, альтернатив не густо. Лично мне может больше JS по душе Использование интерпретатора для GUI на высоком уровне абстракции понятно, так как там производительность кажется не важной. Но как только этим интерпретатором спускаемся немного ниже, получаем веб-страницы, способные загрузить на 100% более одного современного десктопного ядра и требующие гигабайты оперативной памяти. >> сильно нагружает оперативную память > Копеечный PsRam - и нет проблем. Мало того, что само использование Python приводит к падению производительности на порядок, так предлагаете снизить производительность ещё на порядок? ))) > На ESP32 полет мысли в принципе жрет память и без скриптовых языков, > и нередко только встроенного ОЗУ недостаточно. Так может полёту мысли не хватает навыков реализации этих мыслей? Я когда-то Арканоид сумел впихнуть в ATMega328 с 2К RAM, причем он был вполне играбельным. На нескольких десятках килобайт RAM расцвели игровые приставки и ZX Spectrum. А ESP32 заметно превосходит по возможностям Macintosh, у которого было всего 128К RAM. Так может память жрут кривые руки и недостаток знаний? ))) > Так, на скриптовом языке не надо писать не то что критичный код, > но и общую часть приложения. А экранный интерфейс получается хорошо, как > и работа с настройками. Но в статье не стали ограничиваться экранным интерфейсом, сделав полностью OS. Я именно об этом речь и веду, что такой подход потребовал минимум ESP32-S3, тогда как реализация скриптовым, а лучше даже декларативно-скриптовым, языком, снизила бы требования до ESP8266, не говоря уже о ESP32-C3.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 13-Окт-25, 12:19
	> Я когда-то Арканоид сумел впихнуть в ATMega328 с 2К RAM.. Да, тоже собирал Arduboy, и много что туда, в 2КБ впихивал. Но, то спортивный интерес для опытных, и процесс обучения для начинающих, ибо на простом учиться проще. А в практических изделиях минимализм не нужен, или не сама цель. > А ESP32 заметно превосходит по возможностям Macintosh, у которого было всего 128К > RAM. Написал на ESP32 эмулятор и того Макинтоша, и 8086, и даже 386 (тормозно, но Windows 3.1, а не 3.0 запускает, а там и Delphi1 и TotalCommander, как прикол годно) >кривые руки и недостаток знаний? ))) Видимо не совсем кривые руки. :) > Так может полёту мысли не хватает навыков реализации этих мыслей? Не. Просто аппетиты растут. :) Сейчас на ESP32 и Web и локальные базы данных, и обработка данных, какие то библиотеки принципиально большие, и ни с какой магией не влезающие ни 2 кБ, ни в 222 кБ. > не стали ограничиваться экранным интерфейсом, сделав полностью OS. Ну, да конечно, полностью. Только работающей поверх RTOS, поверх библиотек ESP32, и поверх библиотек LVGL...  Бегло глянув в исходники "системы, полностью написанной на MicroPython", видим что из 0.7 МБ исходников этой "ОС", 0.5 МБ обмазки для встроенных библиотек, а 0.2 МБ "лишнее и не обязательное". Здесь проблема, что среду на Микропитоне назвали "ОС", типа о ужас, там типа все медленно, но на самом деле, это всего лишь безобидная обертка над нормальными библиотеками и ОС, именно что бы делать экранные интерфейсы, кстати при использовании LVGL хорошие интерфейсы.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 13-Окт-25, 15:55
	>> Я когда-то Арканоид сумел впихнуть в ATMega328 с 2К RAM.. > Да, тоже собирал Arduboy, и много что туда, в 2КБ впихивал. Я не собирал, я именно впихнул: https://github.com/vpetryaev/ST7735 > А в практических изделиях минимализм не нужен, или не сама цель. До тех пор, пока, как Вы, не уперлись в недостаток ресурсов. > Написал на ESP32 эмулятор и того Макинтоша, и 8086, и даже 386 > (тормозно, но Windows 3.1, а не 3.0 запускает Дайте ссылки на github посмотреть. Больше всего интересует, какими средствами удалось реализовать виртуальную память без аппаратной поддержки. > Видимо не совсем кривые руки. :) Не знаю. Сначала посмотрю в исходники. >> Так может полёту мысли не хватает навыков реализации этих мыслей? > Сейчас на ESP32 и Web и локальные базы данных, и обработка данных И даже сотен гигабайт на SD-карте не хвататет для БД? ))) > какие то библиотеки принципиально большие А может просто отказаться от любимых JavaScript и Python и тогда и большие библиотеки не потребуются и ресурсов сразу хватит? >> не стали ограничиваться экранным интерфейсом, сделав полностью OS. > Здесь проблема, что среду на Микропитоне назвали "ОС", типа о ужас Ужас в том, что на этом сверху и будут приложения этой OS. И точно так же, как я указывал Выше: >> как только этим интерпретатором спускаемся немного ниже, получаем веб-страницы, >> способные загрузить на 100% более одного современного десктопного ядра >> и требующие гигабайты оперативной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 13-Окт-25, 18:38
	> Дайте ссылки на github посмотреть. Моего нет на гит. Я за основу брал эмулятор: g github b-dmitry1 e86r. И портировал на esp32, что то упростил, что то выкинул, что улучшил. Рендеринг прибит к дисплейной матрице waveshare 640x480 в шинном режиме. Делал как игрушку - действующий макет PC. Windows95 не запускает, именно из за кривости эмуляции памяти, но windows 3.1 запускает. Эмулятор простой, в стиле fake86, исходник больше, но бинарник даёт сильно компактнее, написан вменяемо, просто, но недописан и заброшен. Скорость в режиме 8088 примерно как у fake86, то есть на грани вменяемости, а  в 386 режиме остаётся 55-70%, то есть в DOOM уже слайд шоу, но в Windows в работает хорошо. :) >>сотен гигабайт на SD-карте не хвататет для БД? ))) Нужны не базы в сотни мегабайт, а очень быстрые операции, а это требует ОЗУ. Кстати, на SD базы так себе, а на встроенной SPI флеш, и ресурс на запись конский, и скорости поиска приличнее, ибо эта флешь как ОЗУ отображается. > А может просто отказаться от любимых JavaScript и Python и тогда.. Вы думаете, что например, динамический экранный интерфейс на С будет компактнее? ОЗУ израсходует вероятно меньше, а кодовой памяти как бы сильно больше не скушал. ;) Но разницу в скорости реализаций интерфейса пользователь точно не заметит. Так же, бывает и изменяемая скриптовая часть ПО, а когда это все равно есть, то можно в скрипты многое вынести. > Ужас в том, что на этом сверху и будут приложения этой OS. Соглашусь. С дуру все можно свести к маразму. И если это возможно, то именно так и сделают.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 13-Окт-25, 21:19
	>> Дайте ссылки на github посмотреть. > Моего нет на гит. То есть это тоже сны или фантазии? > портировал на esp32 Уже "портировал", а не "написал на ESP32 эмулятор"? ))) >>>сотен гигабайт на SD-карте не хвататет для БД? ))) > Нужны не базы в сотни мегабайт, а очень быстрые операции, а это > требует ОЗУ. Это требует навыков, продемонстрировать которые ссылкой на свой github Вы не смогли. Более того, для Вас даже парсинг XML большого размера оказался проблематичным. Тогда как, для примера, на виртуарле c 8ГБ RAM и запущенным PostgreSQL с shared buffers в 2ГБ, я недавно без проблем загрузил в БД ФИАС, который в ZIP архиве 49ГБ, а в распакованном виде его XML файлы занимают более 7 терабайт. Просто уметь надо работать с большими данными. > Кстати, на SD базы так себе, а на встроенной SPI флеш, и > ресурс на запись конский, и скорости поиска приличнее, ибо эта флешь > как ОЗУ отображается. Во-первых, ресурс там совсем небольшой (10000-100000) https://github.com/orgs/micropython/discussions/12009 Причем без ремаппинга! На SD-картах он такой же, но благодаря встроенному ремаппингу практический предел достигается намного позже. Во-вторых, поменять SD-карту, при заполнении зоны ремаппинга свыше 50% не сложно. А вот как Вы будете менять флеш в МК? В-третьих, применяя FS или БД адаптированную к SSD, можно существенно продлить срок службы SD-карты, пусть и потребляя в тысячи раз больше места на ней. Для примера, при моделировании работы MQTT в ESP-MESH-LITE из десяти ESP32-C3 с двумя из них, выделенными, как MQTT брокеры, больше тысячи стираний на SD-картах у меня было уже через сутки. Но так как объем БД не превышал мегабайта, то тех 32ГБ, которые были на моих SD-картах (менее ёмкие карты сейчас стоят дороже) хватит лет на двадцать. >> А может просто отказаться от любимых JavaScript и Python и тогда.. > Вы думаете, что например, динамический экранный интерфейс на С будет компактнее? Как минимум, ему не потребуется хранить типы и счетчики использования для каждой переменной-объекта. > ОЗУ израсходует вероятно меньше, а кодовой памяти как бы сильно больше не > скушал. ;) Во-первых, очень сомневаюсь по поводу большей потребности в флеш-памяти. Во-вторых, на практике, флеш как раз намного меньшее ограничение, чем RAM. В том же RP2040 флеша может быть 16МБ, а вот SRAM - только 264К. Да и у ESP32 есть модули с 16МБ флеша. В-третьих, я не предлагал реализовывать верхний уровень абстрации на C/C++. Подход Qt, с декларативным QML тут выглядит вполне разумным компромиссом. > Но разницу в скорости реализаций интерфейса пользователь точно не заметит. Уже в третий раз пишу: >> получаем веб-страницы, способные загрузить на 100% более одного >> современного десктопного ядра и требующие гигабайты оперативной памяти Просто зайдите, например на https://dzen.ru/ с запущенным htop и понаблюдайте совершенно неприличную картину. На ПК 10-15 летней давности, который намного производительней почти любого МК, это чудо будет безбожно тормозить. А ведь встречаются веб-страничики и похлеще. >> Ужас в том, что на этом сверху и будут приложения этой OS. > Соглашусь. С дуру все можно свести к маразму. И если это возможно, > то именно так и сделают. Это уже происходило неоднократно в подобных случаях. Так что вероятность такого развития событий 99%.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 14-Окт-25, 02:19
	>>Уже "портировал", а не "написал Ну, всё с нуля и не пишут. Рендеринг свой, а эмулятор, взял за основу существующий. Но, уж эмулятор то 8088 я по памяти перепишу, много я подобного писал. >>продемонстрировать Это Вы настаиваете. Я не возражаю, но на гитхабе пока нет. Но, я пожалуй таки выложу. С вами общаться интересно, но Вы излишне придираетесь. >>ресурс там совсем небольшой не у всякого ssd столько стираний на ячейку, плюс таки с "ремапом" ;) >>поменять SD-карту.. не сложно. Вы не поверите, но поменять весь мрдуль ESP32 дешевле. Хотя, и это не требовалось. >>в ZIP архиве 49ГБ На копеешной железке столько не требуется. У меня в самом страшном сне 1Мб, суммарно. >>для Вас даже парсинг XML большого размера оказался проблематичным У меня? XML? Я не писал об этом. Вот JSON, в том числе большой бывает. И конечно парсинг скриптами на esp32 не делал никогда. Нет проблем. >>сомневаюсь по поводу большей потребности в флеш-памяти. Обновлять дистанционно ПО собираетесь? Поделите размер места для ПО на флешке примерно на 2.7. :( >>в третий раз пишу: >> получаем веб-страницы, способные загрузить Не видел такого. Делал изделия с web интерфейсом для теплиц, с кучей датчиков, разными видами отображения, с анимациями, просмотром архивов и графиков... Дохлый смартфон этим не подавился.  Кстати, с точки зрения отзывчивости, быстрее работают большие страницы, но при минимуме транзакций для полного отображения. Да, на страницах используются скрипты для дорисовки, но без излишеств, что бы со смартфонов открывалось быстро. >>QML Так на ESP из крутых библиотек только LVGL, к которому даже для С++ обертки нет. ;) Приходится использовать, то что работает прямо сейчас. И так, мы снова вернулись к скриптовым языках, на маломошных железках. Для LVGL микропитон удобнее, если интерфейс сложнее нескольких окон. А основное ПО я на нем не пишу. Более того, скажу, Питон я не люблю. Но если практично, то использую. Или здесь Rust часто ругают, и я его ненавижу тоже, но пробовал. И будь он не сырой на Esp32, и будь более удобная среда разработки, то и его бы использовал. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	120. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 14-Окт-25, 09:43
	>>>Уже "портировал", а не "написал > Ну, всё с нуля и не пишут. То есть "портировал" и "написал" по-Вашему одно и то же? Вы можете доказать, что это синонимы? > Но, уж эмулятор то 8088 При чем тут 8088, если я проявил интерес именно к реализации механизма виртуальной памяти на ESP32, никаким боком виртуальную память не поддерживающим? >>>поменять SD-карту.. не сложно. > Вы не поверите, но поменять весь мрдуль ESP32 дешевле. Перечитайте то, что я писал. ESP32 нужно при этой нагрузке менять в срок от 10 до 100 суток. Ну пусть, в среднем, раз в два месяца. А SD-карту на 32ГБ - раз в 20 лет. Вы хотите сказать, что 160 рублей раз в 20 лет - это дороже, чем 130 рублей каждые два месяца? Вы можете доказать, что ~16 тыс - это дешевле, чем 160 рублей? >>>сомневаюсь по поводу большей потребности в флеш-памяти. > Обновлять дистанционно ПО собираетесь? Поделите размер места для ПО на флешке примерно > на 2.7. :( Во-первых, непонятно, почему при реализации на C/C++/Rust обновление прошивки нужно, а для Pyhton/js - уже нет. Вы можете себе представить МК работающий без прошивки? Во-вторых, дистанционное обновление ПО требует наличие функции перепрошивки в загрузчике и совершенно не требует хранения одновременно старой и новой прошивок. Для примера, ESPHome OTA требует лишних несколько килобайт. В-третьих, при размере флеша в 16МБ и размере кода в 1МБ, в этом флеше можно хранить до 16 версий кода, но в чем смысл деления на 2.7 - остается загадкой. >>>в третий раз пишу: >>> получаем веб-страницы, способные загрузить > Не видел такого. Ну так зайдите по указанной мной ссылке и сразу увидите ))) > Делал изделия с web интерфейсом > Так на ESP из крутых библиотек только LVGL, к которому даже для Вы уж определитесь. В случае веб-интерфейса lvgl совершенно не нужен. А то, что lvgl не умеет читать видеопамять, размещая фреймбуфер с четырьмя слоями в основной памяти - это сильно сужает область его применения на МК. > С++ обертки нет. ;) А авторы lvgl то не знали и написали "A fully portable C (C++ compatible) library with no external dependencies." ))) > И так, мы снова вернулись к скриптовым языках, на маломошных железках. Это как? Религия не позволяет вызывать lvgl из C/C++/Rust? ))) > Для LVGL микропитон удобнее, если интерфейс сложнее нескольких окон. Авторы lvgl куда более сложные виджеты на C пишут. Дайте ссылку на issue, где Вы их просили перейти на более удобный MicroPython. Очень хочется почитать эту ветку ))) > здесь Rust часто ругают У каждого инструмента есть свои недостатки. Если инструмент ругают - значит не умеют им пользоваться. Если критикуют - то речь идет о конкретном сценарии использования. > И будь он не сырой на Esp32 А я просто коммичу исправление багов в esp-idf-hal/-sys/-svc, что делает его поддержку на ESP32 менее сырой. Не пробовали так поступать? > будь более удобная среда разработки Какая среда разработки есть заметно удобней VS Code, но не имеет возможности адаптации к cargo/rust?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 14-Окт-25, 11:17
	Окончим об эмуляторе. Если хотите, с этим в личку, почту. Мне не жалко, но эдесь не уместно. > ESP32 нужно при этой нагрузке менять в > срок от 10 до 100 суток. Это проблема в вашей задаче. У меня расчетный срок службы 20лет, с ремапом ячеек еще больше, и зависит от свободного места. К тому времени устройство морально устареет, и его заменят на новое. Кстати, дешевые sd карты живут 3-5 лет на улице, а не 20, и дохнут чаще зимой. Дешевые sd приемлимы, только если это проверенная серия. >непонятно, почему при реализации на C/C++/Rust обновление прошивки нужно, а > для Pyhton/js - уже нет. Да что же вы там в чай подливаете? Всё обновляется, и при обновлении сохраняется всё  предыдущее ПО и настройки. >> в загрузчике.. А работать кто будет во время обновления? А вдруг что то пойдет не так? У меня не Windows, и синих экранов нет, устройство после обновлений работает после автотеста на новой прошивке или переключаетсяна старую. А загрузчик, есть, но то на выпушенном устройстве он так, на всякий случай. > и совершенно не требует хранения одновременно старой и новой прошивок. Понял. Спасибо, не надо. Мы и настройки то избыточно храним для соседних контроллеров. Зато, при замене, одно устройство тупо заменил, и никаких настроек вручную. Кстати, эта функция реализована на Питоне. >размере кода в 1МБ, У меня сильно больше > смысл деления на 2.7 - остается загадкой. Две копии ПО и настроек + загрузчик. > В случае веб-интерфейса lvgl совершенно не нужен. А мужики то не знали. Ну, мы же оба  грамотные, знаем, и все в этой теме знают,что и зачем. Вам же не дают покоя большие html страницы, написал и про страницы. > "A fully portable C (C++ compatible) Вы отличаете набор для сборки велосипеда от велосипеда? Да, самодельный будет лучше, но готовый, бери и пользуйся. Можно на С++ переварить Си код, но смысл? В случае с lvgl никакого. > куда более сложные виджеты на C пишут Вы отличаете виджет от целостного интерфейса? Или всё едино. >> Дайте ссылку А я должен знать, кто что у кого просил? Я это не знаю. > issue, где Вы их просили перейти на более удобный MicroPython. Очень > хочется почитать эту ветку ))) > А я просто коммичу исправление багов Я раньше тоже коммитил. Потом, когда основной аккаунт забанили, забил > VS Code Вот, эта среда, тоже снижает популярность. Да, хорошо, что она есть, да выручает. Но, это ведь не полноценная IDE.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 14-Окт-25, 13:29
	>> ESP32 нужно при этой нагрузке менять в >> срок от 10 до 100 суток. > Это проблема в вашей задаче. MQTT - совершенно типичная задача для IoT. А 1000 стираний за сутки - это меньше одной транзакции в минуту на один 4К блок. Или меньше одной транзакции в секунду на 64 блока флеша ESP32, суммарным размеров в 256К. Больше уж точно не выделите. > У меня расчетный срок службы 20лет Я даже не представляю себе назначение БД в которой производится транзакция реже, чем раз в три минуты. Можете раскрыть этот секрет? > Кстати, дешевые sd карты живут 3-5 лет на улице, а не 20 Что я делаю не так, если дешёвые SD-карты в видеорегистраторах автомобилей меня, жены и дочки живут уже явно больше 10 лет? Причем не то что тёплого, вообще гаража у меня нет. В уличном роутере с LTE модемом тоже дешёвая карта уже лет 15 точно работает. А почему у Вас живут 3-5 на улице я догадываюсь. Корпус надо делать герметичным и или не вскрывать его во влажную погоду, или забросить туда пакетик силикагеля. Потому что умирает любая электроника от конденсата. >>непонятно, почему при реализации на C/C++/Rust обновление прошивки нужно, а >> для Pyhton/js - уже нет. > Да что же вы там в чай подливаете? Всё обновляется, и при > обновлении сохраняется всё  предыдущее ПО и настройки. Это уже к Вам вопрос, что Вы там курите, если у Вас только для C/C++/Rust спрашиваете > Обновлять дистанционно ПО собираетесь? >>> в загрузчике.. > А работать кто будет во время обновления? А вдруг что то пойдет > не так? У меня не Windows, и синих экранов нет, устройство > после обновлений работает после автотеста на новой прошивке или переключаетсяна старую. Во время обновления работает только загрузчик. Если что-то пойдет не так, то после сброса управление попадет к нему же. Изучите, для примера, как работает OTA в ESPHome. В случае secure boot, OTA загрузчик занимает около 30К, без него - около 16К. Всё остальное место доступно для прошивки. > Мы и настройки то избыточно храним для соседних контроллеров. Зато, при замене, > одно устройство тупо заменил, и никаких настроек вручную. Опять сказки рассказываете. У нового устройства будет другой MAC-адрес, так что регистрировать его всё равно потребуется вручную, так как в противном случае он вечно будет висеть в режиме точки доступа. Или если я буду проезжать рядом на автомобиле, то мой ESP32 в нем сможет автоматически зарегистрироваться в Вашей сети? ))) А вот прошивать вручную в любом случае не требуется, так как HA автоматически перепрошивает ESP32 при необходимости. >> смысл деления на 2.7 - остается загадкой. > Две копии ПО и настроек + загрузчик. Вот поэтому Вам флеша и не хватает ))) >> В случае веб-интерфейса lvgl совершенно не нужен. > А мужики то не знали. Ну вот теперь и Вы об этом узнали ))) > Вам же не дают покоя большие html страницы, написал и про страницы. Веб-страницы - это яркий пример того, к чему приводит использование интерпретатора. Только не MicroPython, а куда более производительного, благодаря V8, js. >> "A fully portable C (C++ compatible) > Можно на С++ переварить Си код, но смысл? > В случае с lvgl никакого. Религия не позволяет вызывать функции с аттрибутом extern "C"? ))) Ну даже для таких радикалов есть выход https://github.com/vpaeder/lvglpp А вот то, что lvgl не умеет обходится без фреймбуфера в основной памяти, ограничиваясь видеопамятью контроллера, приводит просто к катастрофическому перерасходу RAM. Например, для ST7796S требуется фреймбуфер размером в ~450КБ, что больше всей доступной RAM в ESP32-C3. А я без lvgl без проблем делал GUI на ST7796S как раз на ESP32-C3. Используюя в качестве фреймбуфера память видеоконтроллера, как в Арканоид на ATMega328P, ссылку на который я уже давал. Причем, так как тактовая там намного выше, чем в ATMega328P и есть DMA, то кувыркаться с ассемблером уже не понадобилось. Достаточно было HAL. >> куда более сложные виджеты на C пишут > Вы отличаете виджет от целостного интерфейса? Или всё едино. Разница несущественна, так как виджет уже содержит в себе пользовательский интерфейс и определенную логику. А если сравнивать большинство целостных интерфейсов на lvgl с наиболее сложными его виджетами, то последнии окажутся существенно сложнее. >>> Дайте ссылку > А я должен знать, кто что у кого просил? Я это не > знаю. То есть Вы, как ёжик колетесь, плачете, но продолжаете есть кактус (пользоваться виджетами, написанными на C)? ))) >> VS Code > Вот, эта среда, тоже снижает популярность. Я о другом спрашивал: >> Какая среда разработки есть заметно удобней VS Code, но не имеет возможности адаптации к cargo/rust? > Но, это ведь не полноценная IDE. Эта догма из Корана или Нового завета? ))) Если Вам даже удастся найти что-то, чего нет сейчас в VS Code, в чём я сильно сомневаюсь, то из этого совершенно не следует, что это нельзя в нем реализовать через расширение.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 14-Окт-25, 14:33
	> > назначение БД в которой производится транзакция реже, чем раз в три минуты. Сельсхозяйственные датчики. Записываются показания в среднем раз в час. Что то пишется чаще, но не круглосуточно. Страницы флеш не обязательно стирать и переписывать по новой, есть же дозапись. > Во время обновления работает только загрузчик. Если что-то пойдет не так, то > после сброса управление попадет к нему же. Ну, попало управление в загрузкик? Раз уж что то пошло не так. А где старая прошивка? Или вы собираетесь вручную сотни коробочек обновлять? Настраивать? > В случае secure boot, OTA загрузчик занимает около 30К. Отлично. А теперь пусть оно САМО обновится по сети. ;) > Опять сказки рассказываете.. другой MAC-адрес.. Это параметр канала связи, а не устройства, а при работе по uart, МАКа и вовсе нет ;) > его всё равно потребуется вручную.. Вот, именно для минимизации ручных операций вся возня. > сможет автоматически зарегистрироваться в Вашей сети? Если будете следовать протоколу регистрации, то да. И если знаете нюансы от производителя, то тоже есть шансы. Вы ведь знаете, что ESP умеет не только стандартный Wifi. А вообще, систему вероятно сделаем открытой. Всему свое время, удовлетворите любопытство. > яркий пример того, к чему приводит использование интерпретатора. Скорее пример злоупотребления интерпретаторов. Да и #овнокод тупой мощью процессора непобедить. > Ну даже для таких радикалов есть Не пробовал. Начинал делать когда этого точно еще не было. Может быть и перейду постепенно. Кстати, не заброшено ли оно? Но, все рано благодарю. > к катастрофическому перерасходу RAM. Если дисплейная панель "большая", то они практически все безбуферные, в отличии от дисплеев 320х240. А если дисплей небольшой, типа ST7796S, так там и интерфейс требуется попроше, в основном  меню настроек, и состояние, с эстетичностью можно не заморачиввться, и там, действительно,  можно и без lvgl. Но, это если есть другая библиотека виджетов, а не рисования примитивов на экране. У меня есть. Но у кого нет, придется строить велосипед. > Эта догма.. ? Вкусы, привычки, традиции у всех разные. По этому пункту прошу не придираться.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	131. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 14-Окт-25, 15:33
	>> назначение БД в которой производится транзакция реже, чем раз в три минуты. > Сельсхозяйственные датчики. Записываются показания в среднем раз в час. Очень странно. В аналогичной задаче контроля температуры и влажности почвы, транзакции требовались не менее одной транзакции в минуту и это только с одного датчика. > Страницы флеш не обязательно стирать и переписывать > по новой, есть же дозапись. На транзакцию всё равно получается одно стирание. Запись в журнал транзакций, добавление кортежа, обновление индексов и опять запись в журнал транзакций. Причем это всё должны быть разные страницы флеша, так как иначе не сможете восстановить БД после сбоя. Например, при сбое питания в странице флеша может оказаться вообще всё что угодно. А чтобы была возможность восстановить уже зафиксированные транзакции в странице, которую дописываете, в журнал транзакций потребуется писать и их. Вы вообще какой СУБД пользуетесь? Вы хоть понимаете, как транзакции работают и как происходит восстановление БД после сбоя? >> Во время обновления работает только загрузчик. Если что-то пойдет не так, то >> после сброса управление попадет к нему же. > Ну, попало управление в загрузкик? Раз уж что то пошло не так. > А где старая прошивка? А зачем она? Если контрольная сумма флеша не нулевая, то загрузчик опять перейдет в режим AP и будет ждать прошивки от HA. Даже если вдруг, в случае простейшего CRC32, в одном случае из четырех миллиардов, управление будет передано неполной прошивке, то шансы на несрабатывание WatchGog будут ничтожны. Так что всё равно управление попадет в итоге в загрузчик. > Или вы собираетесь вручную сотни коробочек обновлять? Настраивать? Вы читать умеете? Обновление OTA - процесс автоматический! Всё, что делается вручную - это клик мышью напротив обнаруженных при сканировании эфира ESP32 и выбор из дропбокса, чем же его прошивать. У Вас что-ли ESP32 с применением AI и экстрасенсорных способностей сам догадывается, какую функцию ему выполнять? А SSID и PSK он откуда возьмет? >> В случае secure boot, OTA загрузчик занимает около 30К. > Отлично. А теперь пусть оно САМО обновится по сети. ;) Так в ESPHome это так и работает. Переключается в режим AP и ждет, пока его HA не прошьет, обнаружив в эфире при очередном сканировании уже известный ему по MAC-адресу ESP32. >> Опять сказки рассказываете.. другой MAC-адрес.. > Это параметр канала связи, а не устройства, а при работе по uart, > МАКа и вовсе нет ;) При чем тут UART? UART требует физического доступа к MK для прошивки, что уже подразумевает ручное вмешательство и физический доступ к порту МК. А OTA требует лишь наличия устройства в эфире. Прошивка устройства с новым MAC адресом подтверждается вручную. Впоследствии в автоматическом режиме безопасность обеспечивают ключи secure boot. >> сможет автоматически зарегистрироваться в Вашей сети? > Если будете следовать протоколу регистрации, то да Мои соболезнования. Такую дырищу закладывать в свой проект надо еще догадаться ))) >> яркий пример того, к чему приводит использование интерпретатора. > Скорее пример злоупотребления интерпретаторов. К которому Вы так яростно тут призываете ))) >> к катастрофическому перерасходу RAM. > Если дисплейная панель "большая", то они практически все безбуферные, в отличии от > дисплеев 320х240. Опять сказки рассказываете. Например, в SSD1963 есть свой фреймбуфер размером свыше мегабайта, вполне доступный для чтения. А уже больше 864 x 480 смысла вешать на МК нет. Это даже не касаясь того, что в случае lvgl оперативки почти на полтора мегабайта в МК не найдете. >> Эта догма.. ? > Вкусы, привычки, традиции у всех разные. По этому пункту прошу не придираться. Вы ксендз или поп, раз делаете утверждения без доказательств? Вы же не написали, "не нравится". А утверждаете, что VS Code неполноценная IDE. И опять, уже в третий раз не ответили на вопрос: >> Какая среда разработки есть заметно удобней VS Code, но не имеет возможности адаптации к cargo/rust? Мне тоже Вас игнорировать?
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	137. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 14-Окт-25, 17:44
	> температуры и влажности почвы, транзакции требовались не менее одной транзакции в минуту С дуру заказчик может много что натребовать. Причем, ему даже позавчерашний архив с такой подробностью уже не нужен. А оперативные данные с датчиков о ОЗУ есть. > На транзакцию всё равно получается одно стирание. Дозапись в стертую страницу возможна. > какой СУБД пользуетесь? как происходит восстановление БД после сбоя? Своей. Там нет сбоев, или очень маловероятны. Да и понятия сбоев там нет, есть состояния. >> А где старая прошивка? > А зачем она? ... загрузчик опять перейдет в режим AP и будет ЖДАТЬ А работать кто будет? А проверять кто будет, а не завис ли кто то в загрузчике? У нас разное видение системы, делающей заданную работу, и не требующую внимания. Ваш стиль обновления вполне нормальный для штучных устройств, но если они хотя бы десятками, то пусть как нибудь сами. > управление будет передано неполной прошивке, то шансы Не будет. Новая прошивка и проверяется при записи, и слегка тестируется, для чего есть ещё небольшой раздел загрузчика. > процесс автоматический!.. - это клик мышью напротив обнаруженных.. и выбор из дропбокса.. и все с одним ключем/сетрификатом или без них. И потом проверить, а не завис ли кто в загрузчике... Да, это может долбить и ПО, и даже можно мышью не кликать, а автоматически взять обновление из репозитория. У нас подходы разные, Вы предполагаете наличие оператора/админа, а у нас приоритет всему на автомате, поэтому стоковый OTA не подходит. > У Вас что-ли ESP32 с применением AI и экстрасенсорных способностей сам догадывается Не только у нас. Лампочки и принтеры тоже сперва как то узнают параметры сети к которой затем подключаются. :) > Такую дырищу закладывать в свой проект надо еще догадаться ))) Не дырищу, а протокол, с управляемой и прогнозируемой реакцией. А дыриши всплывают в ПО, где защита основана на её незнании, и вере в стоковые библиотеки.   >>> использование интерпретатора. > К которому Вы так яростно тут призываете ))) Не призываю, а говорю, что местами они вполне уместны. И уж тем более не яростно, я ж писал, что даже не люблю Питон. > Опять сказки рассказываете. Например, в SSD1963 есть свой фреймбуфер И в изделии надо экономить не байты, а себестоимость. А SSD1963 дороговатый, точно дороже мешочка PSRAM. > Мне тоже Вас игнорировать? Не стоит. Несмотря, что Вы излишне придираетесь, спорим мы вполне плодотворно и в рамках приличий. Оба задумываемся. И даже коллеги. С уважением.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	83. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+5 +/–
	Сообщение от Аноним (81), 12-Окт-25, 11:55
	> А что, если занять МК полезной работой? Да ну на! Давайте крутить > на нём интерпретатор питона для рисования поросячьих мордочек! Ну так диды на каком-то хламе - на луну летали, еще и патча код прям на орбите, когда факап вышел. А что сделали внучки получив процы в 100500 раз мощнее, дофига памяти и проч? А, нахрен полеты на луну - давайте вот селфи своих ценных рож снимать!
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	87. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Bottle (?), 12-Окт-25, 15:19
	Не забываем про такую гениальную вещь как шитый код, который позволял максимально дохлым контроллерам делать вези в разумные сроки.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (91), 12-Окт-25, 16:15
	> шитый код Это вы про Forth? Но он планету не завоевал. Редко о нём можно ныне можно услышать.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 11:15
	> Ну так диды на каком-то хламе - на луну летали таких дидов бабы разучились рожать. Потому что лететь в консервной банке от которой может в любой момент что-то важное отвалиться - ради оставить свой след на мертвом песке - ну такое себе. И спонсировать это ТЫ из своего кармана - не хочешь, гад. nasa гуляла на налоги, чтоб ты знал. А внуки сделали себе удобненько - хочешь попрограммировать esp32 - на тебе питон, а прдлнг с кросс-компиляцией и переносом бинарника на перфолентах оставим дидам.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

13. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
Сообщение от Аноним (13), 11-Окт-25, 12:10
> Очень быстрая загрузка. Быстрее Windows 3.1?
Ответить | Правка | Наверх | Cообщить модератору

	18. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от _kp (ok), 11-Окт-25, 12:46
	Быстрее
	Ответить | Правка | Наверх | Cообщить модератору

	56. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Хайль_тоталитарный_Либерализм_РФиНАТО (ok), 12-Окт-25, 00:49
	Докажи - запусти на 386
	Ответить | Правка | Наверх | Cообщить модератору

	127. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от _kp (ok), 14-Окт-25, 12:51
	> Докажи - запусти на 386 Ну, посмотрите на Ютубе сколько времени на 386м запускался Windows 3.11, думаю секунд 30-60. А "поделка на Питоне" запускается на ESP32 за секунду-полторы. ;) Скорость отрисовки? В lvgl Форма с примерно 250 простыми элементами обновляема примерно до 50 раз в секунду, более легкие формы еще быстрее. А сколько раз в секунду на Windows3.1 вы сможете перерисовать форму? Не то что на 386м, да хоть на Пентиуме. И конечно без мерцаний. Как замерите, обязательно расскажите. :)
	Ответить | Правка | Наверх | Cообщить модератору

	135. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 17:23
	>  Ну, посмотрите на Ютубе сколько времени на 386м запускался Windows 3.11, думаю секунд > 30-60. чот я не понял, ты его - на ютубе запускал, или таки на 386? Если на втором - у меня для тебя хреновые новости, там не секунды а минуты. Ну не 60, парочка-трочека, максимум пяток. Извените, те st3020 были изрядно небыстрыми.
	Ответить | Правка | Наверх | Cообщить модератору

14. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
Сообщение от Аноним (14), 11-Окт-25, 12:15
Пока ещё очень ограниченная поддержка железа, хоть и используется Micropython. А так было бы очень интересно попробовать эту систему на Raspberry Pico, с учётом того, что писать на Micropython под эту плату очень легко и что самое прикольное, в Micropython полностью поддерживается PIO (реально крутая штука). Если бы ещё была лёгкая отладка PIO, было бы вообще замечательно. P.S. использую в деле и C/C++ (включая Arduino) и Micropython. Каждый из этих инструментов имеет свои плюсы и минусы - главное выбирать разумно.
Ответить | Правка | Наверх | Cообщить модератору

	22. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (23), 11-Окт-25, 13:55
	В этих ммгпоказ так мало логики что писать её на с/спп также просто и быстро как на питоне. Вопрос зачем там питон остаётся открытым.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (14), 11-Окт-25, 17:26
	Поверьте, не всегда там мало логики. На деле там ее бывает вполне много, благо современные микроконтроллеры имеют впечатляющие по цене/возможностям характеристики и позволяют все это обрабатывать быстро. Но чем больше логики, тем обычно сложнее код. И не хочу обидеть коллег, но в embedded разработке, уделяя много времени и сил железу, часто забывают про качество кода. Это хорошо видно во многих библиотеках ко всяким модулям Arduino, которые может быть написаны сверхоптимизированно (что не всегда плохо), но качество кода с т.з. поддержки, расширяемости и программной архитектуры зачастую очень ужасное. Ну и помимо всего прочего, писать быстрее и проще писать читаемый и поддерживаемый качественный код на micropython. Критически важные элементы по производительности уже пишутся на том же C/C++ или с помощью задействования специализированных решений, как например PIO в Pico. Но это сугубо мое личное мнение и мой опыт, который разумеется может кардинально отличаться от вашего.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (51), 11-Окт-25, 20:31
	Ну а зачем поддерживать оптимизированные модули? Обычна стоит задача написать максимально оптимизированную функцию, которая будет выполнять одну конкретную задачу, часто под конкретное железо. В жизненном цикле девайса железо не меняют и ресурсоемкие задачи тоже не меняются, максимум что могут обновить интерфейс, и то врятли. Эмбедовка это про железки-черные-яцики, там функционал пишут один раз и оно работает годами. Вот что нибудь на линуксе это уже про ту самую поддержку и обновления, потому что часто это сложные девайсы, где можно себе позволить какие-то фичи новые придумывать.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 01:25
	> Критически важные элементы по производительности > уже пишутся на том же C/C++ или с помощью задействования специализированных > решений, как например PIO в Pico. PIO в RP2040/RP2050 - это лишь универсальная замена блокам CAN, USB, DVI, USART, SPI и т.п. Вычислительные задачи PIO решать не может. А вот то, что любая структура данных, напрямую обрабатываемая на C/C++/Rust, требует в Python, фактически, сериализации и десериализации из объектов и в них - это уже проблема при ограниченных возможностях МК. В итоге, при решения задачи, для которой хватало CH32V003 на C/C++/Rust, в случае Python можно упереться в нехватку ресурсов даже RP2040 и необходимость применения уже RP2050. Если питание от сети, то это ещё можно пережить, хоть и с утерей конкурентоспособности даже на средней по величине партии. А вот при батарейном питании - это уже катастрофа.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	64. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Еще один Аноним (?), 12-Окт-25, 04:10
	Разумеется не стоит использовать Micropython там где нужна максимальная эффективность. Он для этого и не создавался. В таких случаях нередко и Arduino идет в помойку и достается официальный SDK. Тем не менее, я вполне умудрялся на RP2040 делать долгоживущие от аккумуляторов (до года на LR2032) проекты на Micropython, хотя в нем и нет глубокого сна. Просто проектирование становилось намного более сложным с т.з. железа, с полным обесточиванием компонентов через мосфеты. Большей проблемой были саморазряд аккумуляторов, а также энергоэффективность сторонних модулей. Ну и писалось это с активным применением как PIO (для LCD), так и с активным использованием регистров. Вроде еще Viper активно использовался, но сейчас уже не вспомню. Что касается PIO, то я и не говорил нигде, что он используется для вычислительных задач. Но PIO позволяет разгрузить основной процессор при работе с периферией, хотя при этом разумеется усложняется логика приложения. Это позволяет быстрее выполнить работу и раньше усыпить микроконтроллер и периферию. Большей проблемой зачастую при работе с Micropython является память и сборка мусора. Для необходимости эффективного использования памяти (особенно при возможной фрагментации), однозначно лучше старый добрый C/C++ (включая Arduino).
	Ответить | Правка | Наверх | Cообщить модератору

	71. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 09:57
	> Тем не менее, я вполне умудрялся на RP2040 делать долгоживущие от аккумуляторов > (до года на LR2032) проекты на Micropython, хотя в нем и > нет глубокого сна. LIR2032 со своими долговременными 3мА RP2040 даже не потянет по нагрузочной способности, так как снизить тактовую частоту до нескольких десятков килогерц он не позволяет. Не говоря уже о логике проекта, способном за год уложится в 30-40 mAh. RP2040 минимум потребляет 180мКА, а при загрузке требует около 10мА. Так что Вы что-то совершенно фантастическое написали. > PIO позволяет разгрузить основной процессор при работе с периферией Только в тех случаях, когда соответствующего интерфейсного блока не предусмотрено. Это просто такое решение в RP2040/RP2050, когда два фиксированных переферийных блока заменены на два универсальных и  вместо целой линейки МК с разным набором переферийных блоков можно выпускать только один МК с двумя универсальными блоками PIO. > Большей проблемой зачастую при работе с Micropython является память и сборка мусора. Ещё большей проблемой при этом является управление питанием флеша и RAM. Даже в теории я не представляю на MicroPython выполнение кода из конкретной страницы RAM с выключением питания остальных страниц и флеша. А на тех же STM8L152 выполнение кода из RAM дает трехкратную экономию потребления, по сравнению с флешем.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (-), 12-Окт-25, 14:56
	> LIR2032 со своими долговременными 3мА RP2040 даже не потянет по нагрузочной способности, > так как снизить тактовую частоту до нескольких десятков килогерц он не > позволяет. Для такого STM32L0/L1/G0 какой-нибудь скорее уместен. Он в 3 мА уместится как делать нефиг. Даже на частоте несколько мегагерц. Конечно и основную систему дизайнить придется под стать. > RP2040 минимум потребляет 180мКА, Ну то-есть при емкости типичного CR2032 в 200 mAh оно если ничего кроме спячки не делать проживет - около месяца. А если еще и просыпаться порой - и того меньше. В этом месте даже дубовый STM32F1 дико угорает, с его standby и побудкой RTC или вачдогом при жоре в микроамперы. Но громко хайповать это ж не инженерить нормально... > а при загрузке требует около 10мА. Так что > Вы что-то совершенно фантастическое написали. Спалился гонщик. На таких мелочах "великие эмбедеры" и замечают что ус отклеился. >> PIO позволяет разгрузить основной процессор при работе с периферией > Только в тех случаях, когда соответствующего интерфейсного блока не предусмотрено. На самом деле по своему круто. Мало того что 2 ядра Cortex M0 так еще и программируемые PIO движки с своим простым микрокодом. Никогда не хотели синтезировать RF напрямую прям в лоб? Или вот красавы - HDMI до 720p изобразили прям софтварно. Секрет в том что там отдельный clock lane и "хост" в принципе может и притормозить немного с передачей данных если хочет. > набором переферийных блоков можно выпускать только один МК с двумя универсальными > блоками PIO. Не есть эквивалентная замена. STM32 например юзают - за широкое портфолио. Надо много лап - вот вам QFP100. Надо мелкий размер - вот вам прыщик в TSSOP20 или QFN, а то и SO8 какой. А то и вовсе WLCSP если вы к такому готовы. В более поздних RPi мк они вроде pio как раз и выпилили, если не ошибаюсь. К большому облому DIY, ибо так то забавная штука для БЫСТРОГО синтеза кастомных протоколов и проч "почти как FPGA". >> Большей проблемой зачастую при работе с Micropython является память и сборка мусора. > страницы RAM с выключением питания остальных страниц и флеша. А на > тех же STM8L152 выполнение кода из RAM дает трехкратную экономию потребления, > по сравнению с флешем. В случае STM32 разница не настолько огромная, но из SRAM немного экономнее и немного быстрее. Да вы не боитесь, вон то будет и RAM bus и flash bus грузить :) Забавно тут еще и то что часть клонов перегружает код Flash -> RAM на старте. Флеха может быть отдельный кристалл на SPI вообще. В том же корпусе. Так дольше старт - но потом код из якобы флеша на самом деле в 1-cycle SRAM и на этой почве некоторые клоны по таймингам - другие. И таки - быстрее оригинала. Порой и потребление ниже - процесс тоньше. Только для МК это вовсе даже и не фича иной раз. Ибо - хлипче, и ожидаемый срок жизни - хуже. И качество китайского флеша, и спек на него и через сколько лет он утечет - открытый вопрос. Что для управляющих необслуживаемых девайсов раскидываемых пачками везде и всюду все ж аргумент.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 21:43
	>> LIR2032 со своими долговременными 3мА RP2040 даже не потянет по нагрузочной способности > Для такого STM32L0/L1/G0 какой-нибудь скорее уместен А что-то иное писал? >> RP2040 минимум потребляет 180мКА, > Ну то-есть при емкости типичного CR2032 в 200 mAh оно если ничего > кроме спячки не делать проживет - около месяца. Вы вообще кому отвечаете?
	Ответить | Правка | Наверх | Cообщить модератору

	94. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (-), 12-Окт-25, 18:34
	> PIO в RP2040/RP2050 - это лишь универсальная замена блокам CAN, USB, DVI, > USART, SPI и т.п. Зато может - сделать нестандартный интерфейс, или интерфейс не характерный для этого класса девайсов. Скажем - кто-то HDMI до 720p так ухитрился. Софтварно. А отрастите HDMI софтварно на чем-то еще? Чтоб с непохабными параметрами? Он конечно позволяет притормозить хосту ибо CLK формирует - он, но чтоб передать по сериальному протоколу МНОГО данных для картинки нормального разрешения с адекватным FPS - лапами надо дергать весьма резво и желательно все же не очень сильно сбивая тайминги. > вот то, что любая структура данных, напрямую обрабатываемая на C/C++/Rust, требует > в Python, фактически, сериализации и десериализации из объектов и в них > - это уже проблема при ограниченных возможностях МК. Да оно и не только в МК проблема. А везде где скорость важна. В случае как минимум полного питона проблема еще и в том что с статическим анализом там почти никак. Все падает, виснет или икает эксепшнами прям в рантайм. Очень круто когда через месяц все виснет - и попробуй воспроизвести это. Диагностики по нулям, аннотаций намерений кодера тоже - have a nice debug session! > пережить, хоть и с утерей конкурентоспособности даже на средней по величине > партии. А вот при батарейном питании - это уже катастрофа. Я желаю им удачи на одном только питоне например просто поток с ADC на хотя-бы 1MSPS ухватить - и попытаться хоть какую-то обработку результата с него при этом, ну там усреднение, чтоли. А, ну да, зачем шум с ADC фильтровать, нехай глюкавит плюс-минус лапоть. Особенно если он рядом с прожорливым нагруженным процом соседствует, ему точно зайдут короткие мощные импульсы от цифры.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	102. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от ptr (ok), 12-Окт-25, 22:43
	>> PIO в RP2040/RP2050 - это лишь универсальная замена блокам CAN, USB, DVI, >> USART, SPI и т.п. > Зато может - сделать нестандартный интерфейс, или интерфейс не характерный для этого > класса девайсов. Приведите пример, имеющий практическую ценность. > Скажем - кто-то HDMI до 720p так ухитрился. Софтварно. Во-первых, если уже пишите о чем-то, то зачем врать? Или Вы случайно ошиблись в три раза? https://cnx-software.ru/2021/03/03/platy-raspberry-pi-rp2040.../ Во-вторых, в других МК HDMI есть готовый. Например, на STM32H743 я получал FullHD, что уже в 7 раз более, чем максимум, на который способно PIO. > А отрастите HDMI софтварно на чем-то еще? Чтоб с непохабными параметрами? Ну если 640*480 для Вас непохабно, то мы, похоже, живем в разные века ))) >> вот то, что любая структура данных, напрямую обрабатываемая на C/C++/Rust, требует >> в Python, фактически, сериализации и десериализации из объектов и в них >> - это уже проблема при ограниченных возможностях МК. > Да оно и не только в МК проблема. А везде где скорость важна. Прозводительность важна не так уж часто. По факту, даже в процедурах и функциях PostgreSQL переходить на plrust мне приходится очень редко, так как plpgsql или plpython хватает. Да и переписать на компилируемый язык критичные участки Python позволяет. А вот нарастить оперативку в MK и ПК - задачи очень сильно различающиеся по стоимости и сложности. > Я желаю им удачи на одном только питоне например просто поток с > ADC на хотя-бы 1MSPS ухватить - и попытаться хоть какую-то обработку > результата с него при этом, ну там усреднение, чтоли. Знаю, как и больше пережевывали на MicroPython с DFSDM даже на вышеупомянутом STM32H743 с весьма скромными характеристиками, по сравнению с STM32N6. Но, как я указал выше, на МК это может быть ещё как-то оправдано для единичного экземпляра, но уже для мелкой серии незначительная экономия на стоимости разработки не может компенсировать дополнительную стоимость более мощного МК.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (-), 13-Окт-25, 12:45
	> Во-первых, если уже пишите о чем-то, то зачем врать? Или Вы случайно > ошиблись в три раза? Я набредал на проект, где заявляли до 720p, правда, вроде, 30FPS. В таком протоколе можно понизить FPS, подняв разрешение: бандвиз тот же. Есть фокус, когда по HDMI 1.2 и т.п. который 1080p@60FPS, проталкивают 4K@30FPS. Это как я понимаю это такого же плана. Нашару бонус имхо неплохой. > Во-вторых, в других МК HDMI есть готовый. Например, на STM32H743 я получал > FullHD, что уже в 7 раз более, чем максимум, на который способно PIO. И это прекрасно, но 1) Ценник и доступность? За топовые STM32 дистрибуторы дерут, особенно в розницу, и не в любом ларе есть. RPI 2040 попадался по 3-5 баксов, валяется везде. Правда еще чип SPI надо, и в целом более дурацкий. Но 2 ядра + PIO = EPIC WIN. Можно логику разделить и упростить кастом, который по иному только на FPGA. FPGA это *другой* опыт, по тулчейнам и эзотерике. Я считаю быстрый кастомный ногодрыг жирной фичой МК. 2) H743 - либо многолапый QFP, либо BGA недружественный к прототипам и DIY. Разводить канительнее, 2040 не такой разлапистый. Если я хотел поприкалываться с HDMI, ниоткуда не следовало что я хотел 100+ лап: пойнт сериального протокола - проводов мало! Маркетинг STMicro решил иначе. Маркетинг MS вообще делает временами странные вещи, настолько что китайские клоны уже дают им мастеркласс как надо было, делая например сравнимый чип в менее разлапистом корпусе. Порой STMicro делает "реверс клон" тоже выкатив более малолапый и дешевый вариант выпускавшегося чипа. Но до этих - сия благодать явно не дошла. 3) MIPI DSI. Его правда и без такого хардкора пару господ делали. Одни на FPGA, другие на ESP вообще. На самом деле там неудобнее всего трансляция уровней. А скорость - опять же хост может притормозить, тем более что у не больших LCD - RAM в стекляшке. Да, конечно, он местами есть в МК. Но опять же - только в топовых. С специфичным экспериенсом. 4) В пачку WS2812 и т.п. на скорость данные толкать, параллельно в несколько lanes, чтоб красивые RGB анимации с годным FPS гонять. Нет, у STM32 _нет_ железки для _этого_ протокола. При сильном желании можно подпереть DMA+таймером. Но как вы понимаете, спихать это на 1 ядро + pio и из второй части только координацию кидать, а оно само отрисует - удобнее. На самом деле - подобный диалект протоколов бывает много где. Часть RF пультов, 1-wire, ... - на самом деле это частично потому что "хардварная" инкарнация ЭТОГО делается из shift регистра + RC и по 1 проводу и данные и клок (RC задерживает клок и можно защелкнуть или 1 или 0, меняя тайминги). 5) Опять же кастомные протоколы. От беспроводной зарядки до type-C PD какого, RFID, всякие RF протоколы ISM диапазона, как минимум модуляция и анализ. Конечно, можно найти МК где есть и что-то такое. А чтобы нужное сочетание, не в убер-корпусе и не по цене крыла самолета? А вот это уже - как повезет! У STM32 есть нехилые загоны маркетинга как видим. И если кто думал что они смогут меня доить и лошить за то что я разучил их чипы, у меня другие идеи на этот счет. >> А отрастите HDMI софтварно на чем-то еще? Чтоб с непохабными параметрами? > Ну если 640*480 для Вас непохабно, то мы, похоже, живем в разные века ))) 1) Там 720p@30FPS у кого-то было, отрисовать менюху или статусы - сойдет. 2) Можно взять _мелкий_ монитор, по типу автомобильных и проч. Там норм будет. Если мне 4K ворочать припрет, я одноплатник на линухе возьму, на нем UI можно сделать куда приличнее того "свинства". И отладить поначалу - прям на моем десктопе. > Прозводительность важна не так уж часто. У меня как-то сильно более другой опыт такого плана. > По факту, даже в процедурах и функциях PostgreSQL Вот тут я ничего не скажу - ибо не DBA. Зато насколько я вижу допустим идея пожевать геоданные - это си, си++, ну может Rust иногда. OSMщики думали в свое время что во, XML, читаемо, ща мы его. Получился XML который СЕЙЧАС для планеты - в распакованном виде около терабайта, чтоли. И что-то как-то и софт быстрый всем понадобился, и бинарный сжатый формат в protocol buffers запилили и фиг с читаемостью, ибо мало какой редактор терабайт XML вообще сжует, но даже это оказывается не пределом мечтаний и оказывается что можно и еще круче в разы. А процессинг таких чушек ессно cpu time кушает очень даже. Можете питоном процессить, мне не жалко, заодно и посмотрим как вам перфоманс не надо. > участки Python позволяет. А вот нарастить оперативку в MK и ПК > - задачи очень сильно различающиеся по стоимости и сложности. Да как сказать? Если мы про топовые STM то у них external bus есть и странные люди на них даже Linux для mmu-less систем гоняют, донавесив RAM на шину. Так что в ядре линя есть дрова для периферии топовых МКшных STMок. Это несколько изврат, да. Но если очень хочется - можно и так. > Знаю, как и больше пережевывали на MicroPython с DFSDM даже на вышеупомянутом > STM32H743 с весьма скромными характеристиками, Я бы не назвал H743 скромным по МКшным меркам. Это топовый МК, для ЭТОГО монстра с 400MHz прожевать 1MSPS - никак не "достижение". И вот смысл этого комбо? Получить довольно сложную, дорогую систему использующую могучий чип на 10%? И это круто потому что что? И кому это все надо кроме автора вообще? И зачем? > по сравнению с STM32N6. Но, как я указал выше, на МК это может быть ещё как-то оправдано > для единичного экземпляра, но уже для мелкой серии незначительная экономия на > стоимости разработки не может компенсировать дополнительную стоимость более мощного МК. Стоимость разработки штука многофакторная. Разводить 100+лапые корпуса, и в целом иметь дело с разлапистой и сложной системой - совершенно не обязано разработку ускорить. И может добавить глюков и особенностей. Например, 400 МГц цифра тому же ADC не товарищ, и требования к подсистеме питания станут здорово более другие. И то что это с 1 итерации вообще будет культурно работать - ниоткуда не следует. В целом - наверное какому-то лоху такую "гамнину" которая похабнее даже ардуины наверное и можно скормить. Но в целом - лично я вообще "счастливчиков" с ЭТИМ не встречал. И если скорость разработки была единственным фактором - качество всего этого будет под стать, чудес не бывает. И тот кто получит это на свою голову - попаданец скорее всего. К счастью благодаря этому у всяких ардуин и прочих микропитонов репутация как раз под стать.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 13-Окт-25, 18:26
	>> Во-первых, если уже пишите о чем-то, то зачем врать? Или Вы случайно >> ошиблись в три раза? > Я набредал на проект, где заявляли до 720p Да всем тут безразлично, что и когда Вам снилось. А я предоставил пруфы. Причем с расчетом того, что больше, чем 640*480 из PIO не выжать. Читайте стандарт: "The lowest pixel format required by the DVI specification is 640x480@60 Hz (clock timing of 25.175 MHz)" А большую частоту в этом случае PIO уже не тянет. > Есть фокус, когда по HDMI 1.2 и т.п. который 1080p@60FPS, проталкивают 4K@30FPS. 4K single-link не поддерживает. >> Во-вторых, в других МК HDMI есть готовый. Например, на STM32H743 я получал >> FullHD, что уже в 7 раз более, чем максимум, на который способно PIO. > И это прекрасно, но > 1) Ценник и доступность? За топовые STM32 дистрибуторы дерут, особенно в розницу, > и не в любом ларе есть. RPI 2040 попадался по 3-5 > баксов, валяется везде. Но на RP2040 Вы никакими силами FullHD не получите. Поэтому такое сравнение совершенно не имеет смысла. > 3) MIPI DSI. Тоже самое. Реализация средствами PIO на RP2040 будет в разы уступать готовому блоку по всем параметрам. Если вообще будет работать. > 4) В пачку WS2812 Я даже на AVR его делал средствами SPI или PWM. Ничего сложнее там не требуется. На CH32V003 можно подключить DMA. Так что это явно не так задача, для которой необходим PIO. > 5) Опять же кастомные протоколы. И точно так же или они реализуемы средствами SPI/PWM/UART + DMA без загрузки CPU. Или для них есть специализированные аппаратные блоки, как в случае CAN. Просто выбирайте МК под задачу, а не пытайтесь сделать из одного МК "золотой молоток" для любых задач. >>> А отрастите HDMI софтварно на чем-то еще? Чтоб с непохабными параметрами? >> Ну если 640*480 для Вас непохабно, то мы, похоже, живем в разные века ))) > 1) Там 720p@30FPS у кого-то было, отрисовать менюху или статусы - сойдет. Еще раз, всем тут плевать на Ваши фантазии и сны ))) Итого, Вы не смогли привести ни одного примера, где PIO смог бы составить конкуренцию специализированному аппаратному блоку. >> Прозводительность важна не так уж часто. > У меня как-то сильно более другой опыт такого плана. И где примеры? >> По факту, даже в процедурах и функциях PostgreSQL > Вот тут я ничего не скажу - ибо не DBA. Не надо быть DBA, чтобы понимать необходимость оптимизации при обработки больших объемов данных. Вот только к МК это отношение не имеет. > я вижу допустим идея пожевать геоданные - это си, си++, ну > может Rust иногда. С/C++ небезопасен, поэтому хранимых процедур и функций на нём Вы не увидите. Надо быть полным идиотом, чтобы позволить пользователям создавать процедуры и функции, которые могут уложить не только весь сервер, но и саму БД. > Получился XML который СЕЙЧАС для планеты - в распакованном виде около > терабайта Надо совсем поссориться с головой, чтобы обрабатывать терабайты на МК. При этом, при наличии извилин в голове, совсем не обязательно обрабатывать многогигабайтные файлы, загружая их в память целиком. >> участки Python позволяет. А вот нарастить оперативку в MK и ПК >> - задачи очень сильно различающиеся по стоимости и сложности. > Да как сказать? Если мы про топовые STM Мы говорим вообще-то про CH32V003 или ESP32-C3, в которые это поделие на MicroPython всунуть не удалось. Или о RP2040 с PIO, который может конкурировать со специализированными блоками только тех МК, которые несущественно отличаются от него по стоимости. А вот конкуренцию специализированным аппаратным блокам более дорогих МК, RP2040 составить уже не может. >> Знаю, как и больше пережевывали на MicroPython с DFSDM даже на вышеупомянутом >> STM32H743 с весьма скромными характеристиками, > Я бы не назвал H743 скромным по МКшным меркам. Это топовый МК, > для ЭТОГО монстра с 400MHz прожевать 1MSPS - никак не "достижение". Но ни DFSDM, ни даже медианную фильтрацию на PIO RP2040 не сделаете, так как упрётесь в максимальный размер программы (32 команды) и ограниченность доступных регистров (2 штуки). > И вот смысл этого комбо? Смысл PIO, которому, как минимум, лет 70 от роду (вспомним IBM/360, где эта концепция была применена) - унификация в серии МК для сокращения его себестоимости. Иного смысла вот в упор не вижу. Так как специализированный аппаратный блок выигрывет у PIO по всем параметрам, кроме, разве что, дополнительных издержек для обхода ошибок в аппаратном блоке, когда такие случаются. Но эта проблема сейчас решается возможностью перепрошивки микрокода, в который почти никто, кроме производителя специализированного устройства не лезет. Время покажет, насколько этот подход оправдан в новой реинкарнации. В IBM/360 - IBM/390 этот подход в итоге не взлетел. И о случаях самостоятельного написания канальных программ я слышал очень и очень редко. Причем почти всегда для фана, а не по практической необходимости.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (-), 14-Окт-25, 11:11
	> "The lowest pixel format required by the DVI specification is 640x480@60 Hz > (clock timing of 25.175 MHz)" > А большую частоту в этом случае PIO уже не тянет. Теперь увидьте 30FPS, посчитайте клок еще раз, до того как ерничать. Еще мне приснилось что те слегка профачили электрический уровень HDMI, развязкой через кондеры, и потом фиксили. Почаще бы такие сны. Сегодня я ленивый, поискарем сами поищете, если надо. >> Есть фокус, когда по HDMI 1.2 и т.п. который 1080p@60FPS, проталкивают 4K@30FPS. > 4K single-link не поддерживает. А реально - можно вместо 1080@60FPS сделать 4K@30FPS. Можете найти поискарем гайды для линуха как сие сделать. Это работает. Наверное, эти гайды мне тоже приснились. Для отрисовки каких-нибудь менюшек или статусов на небольшом мониторе типа автомобильного, 720p@30FPS хватит. Заметьте: если фреймов в 2 раза меньше - бандвиз в 2 раза меньше. А сами по себе тайминги HDMI вообще привязаны к линии клока, которую хост притормозить может если хочет. Такие протоколы хорошо описал кадр сделавший MIPI DSI через GPIO на ESP32. Можно рассматривать как "быструю дифференциальную версию SPI". Какой клок у SPI? Какой хост выдаст. Клок ниже - при прочих равных - притормозит трансфер кадра и понизит FPS. Странно, да? > Но на RP2040 Вы никакими силами FullHD не получите. Если я FHD захочу, я одноплатник с Linux возьму. Ибо его ценник VS FHD монитор будет малозаметен. Хоть 4K, если надо, даже с HW decoder видео, если надо. И нормальными либами граф тулкитов, а не вон тем. И это все прям на десктопе отпротипить можно и просто пересобрать на таргет 1 в 1. Но это другая весовая категория. Напоминаю: в случае RPi мы говорим про мк 3-5 баксов в розницу валяющийся везде. > Поэтому такое сравнение совершенно не имеет смысла. На мой вкус 1080P с МК - имеет мало смысла. Такой аппетит говорит о нужде взять нормальный апликушник с линем и сделать это нормально. Заниматься таким хардпорном на STM32 я не планирую. >> 3) MIPI DSI. > Тоже самое. Реализация средствами PIO на RP2040 будет в разы уступать готовому > блоку по всем параметрам. Если вообще будет работать. Его вон там на spritemods сделали на SPI в ESP32. И пойнт - малолапый ифейс, существующий в дешевых дисплеях от мобил и проч. У небольших стеклях (примерно до 320x480) RAM - в контроллере на стекле, скорость линка вообще пофиг, влияет только на скорость перерисовки картинки. А тайминги LCD панели сам контроллер делает гоня картинку из его RAM. У DSI есть 3 режима. Командный, когда хост командами льет в дисплей апдейты регионов и проч, а дисплей сам тайминги LCD делает, картинка в его RAM. Ограничено размером SRAM который можно впихнуть в чип на стекле и потому примерно до 384х480. Фреймбуфер - в самой стекляхе, чипе контроллера. Есть "видео" режим с трансфером всего кадра. Там каждый раз передается весь фрейм с синтезом таймингов на манер HDMI. Это подразумевает фреймбуфер уже у хоста, как и с HDNI. И есть гибрид - контроллер с RAM покрывающей частичный регион стекляхи. ТАк что при powersave - частичная картинка из того буфера, на часть панели или с низким разрешением, автономно. А при желании рисовать на всю панель с полным разрешением извольте весь кадр с его таймингами. Сильно тайминги парят только в RAM-less штуках типа больших MIPI DSI, и прочих HDMI, и там как видим - клок можно и притормозить. С точки зрения протокольной логики это 100% валидно. CLK для того и сделан. Границы применимости ессно - варьируются. > Я даже на AVR его делал средствами SPI или PWM. Ничего сложнее > там не требуется. Пока не захочется пачку светодиодов с приличным FPS прокачать, где AVR жутко сольется. Что для длинного стринга не катит - значит надо лить в N более коротких. Ну то-есть можно всю AVRину на только это и выделить но она тогда больше не сможет - почти ничего вообще. У меня есть undisclosed проект, который сложный, но может быть имхо прикольный. И там challenge - я на самом деле хотел бы апдейт состояний LED типа WS этак 30 000 раз в секунду. Это даже с параллельным заливом в WS2812, по 1 диоду на пин, параллельно - на грани возможного. > На CH32V003 можно подключить DMA. Так что это явно не так задача, для которой необходим PIO. Я как бы видел реализацию с DMA. Но... 1) Это прогружает системные шины на каждый бит. 2) Жрет таймер. 3) Синтез протокола требует некоего отдельного внимания и конверсий данных. В этом смысле "выпихали блок данных в отдельный CPU core - и пусть он + pio сам разбирается!" в принципе позволяет сделать проект куда логичнее, проще и эстетичнее. Так логика сплитуется на 2 части, координатора и low level реализацию и не надо упихивать все на 1 ядро. >> 5) Опять же кастомные протоколы. > И точно так же или они реализуемы средствами SPI/PWM/UART + DMA без загрузки CPU. До некоторой степени да. Но STMicro и тут ступил местами, в ряде младших M0(+) based DMA не может сунуться в "ресурсы проца" в виде GPIO. Поэтому - "крутой single-clock IO". Который нельзя подпереть DMA :\. У тех которых IO на AHB или APB это ессно не проблема. > Или для них есть специализированные аппаратные блоки, как в > случае CAN. Просто выбирайте МК под задачу, а не пытайтесь сделать > из одного МК "золотой молоток" для любых задач. А таки - пожалуй удобно для малотиража, экспериментов, прототипов и проц. Да и идея разнести более низкий уровень и координатора - ничем не плоха. А выбирать H743 с его ценами и доступностью - да нафиг, я пешочком постою. Если STMicro ополовинит розничные цены, будет дружественнее к опенсорсу и DIY (на RPi2040 даже сорц boot rom отдали) и это будет валяться в каждом ларе - я подумаю. Мне нравится инженерия STM32, особенно младших, но это не обяхывает меня все потуги STMicro не задавая вопросов. > Итого, Вы не смогли привести ни одного примера, где PIO смог бы > составить конкуренцию специализированному аппаратному блоку. А вы не смогли привести примен решения за 3 бакса в розницу с HDMI. И это не только HDMI, но и куча иных возможностей. Любых которые мне приспичит. В этом смысле я считаю идею втулить 2 ядра M0 + PIO довольно крутой идеей. Можно довольно много "асинхронных" движков удобных в программизме понаделать. Для почти чего угодно. Не, на STM32 так не очень получится. >> У меня как-то сильно более другой опыт такого плана. > И где примеры? Возможно у меня просто другие хотелки. Но вы можете показать апдейт пачки WS2812 своим питоном 30 000 раз в секунду. Это и не питоном то на грани возможного. И у меня довольно много такой хрени среди хотелок. > Не надо быть DBA, чтобы понимать необходимость оптимизации при обработки больших объемов > данных. Вот только к МК это отношение не имеет. Ну вы сами зачем-то с постгром ко мне полезли. Откуда я знаю что вы там делали с ним и хранимыми процедурами. > С/C++ небезопасен, C++ можно сделать достаточно безопасным, я видел на нем оверлоад [] и даже аналог борова. Да и C, если согласииться на subset рулесей типа MISRA. И это на самом деле больше организационные мероприятия. А вот что я видел - вулны на питонодобре. Вплоть до RCE и проч. А уж прсто сервак вынсти - каждая 2-я приблуда. > поэтому хранимых процедур и функций на нём Вы не увидите. Мне вообще не интересен и не актуален этот юзкейс - я не DBA. И там вероятно компилируемость яп все же неудобна. Но я от этого далек. > Надо быть полным идиотом, чтобы позволить пользователям создавать процедуры и функции, > которые могут уложить не только весь сервер, но и саму БД. На мой вкус давать заливать реемотным пользователям код хоть на чем - так себе идея. Так, глядя на JS rowhammer'ы, утечки а то и искажение данных через OoO execution. Вот так совершенно случайно пропатчат при случае кернелмод. Хоста. Поклав на все уровни изоляции оптом. Потому что технически как оказалось - бывает можно и такое. > Надо совсем поссориться с головой, чтобы обрабатывать терабайты на МК. Ну вы ж постгра притащили? И как он там у вас, на мк хорошо работает? :) > не обязательно обрабатывать многогигабайтные файлы, загружая их в память целиком. Спасибо Капитан. Но в случае питона просто сам факт жевания этого - потребует аццкие времена. Они потом начинают миндфак с кусочками на си. А суммарно их за это go и rust пришлепнут много где. Ибо разучивать 2 совсем разных ЯП с разным синтаксисом - булшит. > Мы говорим вообще-то про CH32V003 или ESP32-C3, в которые это поделие на > MicroPython всунуть не удалось. Или о RP2040 с PIO, который может > конкурировать со специализированными блоками только тех МК, которые несущественно отличаются > от него по стоимости. Нихрена "несущественные" - раза в 2 дороже, огромных корпусах или вообще BGA, а по сумме факторов поганая доступность в розницу: для DIY неудобные. У меня нет желания осваивать нечто типа H743 с теми соотношениями. А немного конкуренции еще никому не мешало, ибо маркетинг STMicro периодически наглеть начинал с искусственными ограничениями. Для лечения этого и есть конкуренты и клоны. Или например у STM32 что-то нет ничего типа CH32V003. Эта штука с его ценами на рынок pic/attiny наезжает от души. > А вот конкуренцию специализированным аппаратным блокам более дорогих МК, > RP2040 составить уже не может. Он может то, для чего программируемые штуки и созданы - быть универсальным. Это жирное достоинство относительно fixed function hardware. Мы программируемые системы юзаем за ЭТО. > Но ни DFSDM, ни даже медианную фильтрацию на PIO RP2040 не сделаете, > так как упрётесь в максимальный размер программы (32 команды) и ограниченность > доступных регистров (2 штуки). Я рассматриваю это как тул для тупого быстрого ногодрыга. Который для МК достоинство если позволяет нужное сделать без эзотерики типа FPGA. > Смысл PIO, которому, как минимум, лет 70 от роду (вспомним IBM/360, где > эта концепция была применена) - унификация в серии МК для сокращения > его себестоимости. А также - универсальный репрограммируемый под задачу хардвар это epic win. Особенно с 2 ядрами когда можно low level загнать вон туда и общаться потом с ним в виде "пульни мне этот пакет" или "вот вам пакет". Так логика проекта адекватнее получается. Не напоминая брейнфак. И я бы не отказался если бы вот именно ЭТИ идеи и другие бы содрали. А DMA это хорошо, но GPIO он сам по себе вообще не работает без подпора например таймером. Точнее, на TX вроде работает, но я не знаю - скипает ли он циклы, если как mem2mem трансфер блока -> GPIO с макс скоростью втулить (и в любом случае шины нехило прогрузит). > специализированный аппаратный блок выигрывет у PIO по всем параметрам, кроме, разве > что, дополнительных издержек для обхода ошибок в аппаратном блоке, А также универсальности, перепрограммируемости под задачу и - постоянного гимора с поиском чипа на полшишечки отличающегося от вон того - что может и задолбать. Программируемые системы победили fixed function много где. И на то были причины. Даже если это менее эффективно. Если утрировать - часть того что МК делает можно на жесткой логике собрать. Но поменяй немного условия задачи и это полный фэйспалм. В МК - настроечки сменить, накрайняк фирмвар перелить, а в жесткой логике - под пресс и заново с ноля. > когда такие случаются. Но эта проблема сейчас решается возможностью перепрошивки > микрокода, в который почти никто, кроме производителя специализированного устройства > не лезет. Кроме всего прочего - я вообще совсем не хочу какой-то иметь дело с левым кодом "от богов" без сорцов и целиком уповая на милость вендора. > Время покажет, насколько этот подход оправдан в новой реинкарнации. В IBM/360 - > IBM/390 этот подход в итоге не взлетел. И о случаях самостоятельного > написания канальных программ я слышал очень и очень редко. PIC (микрочиповский) если что расшифровывается как peripheral interface controller. И сказать что он ну совсем не взлетел все ж не совсем правильно. Это немного не то но позиционирование сравнимое. Только архитектура совсем уж брейнфак.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (53), 11-Окт-25, 23:50
	Очень круто, есть смысл изучать python.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	26. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Крокодил (?), 11-Окт-25, 14:47
	А почему не elua или emblua? В условиях ограниченных возможностей имхо есть смысл экономить
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	39. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+3 +/–
	Сообщение от Аноним (14), 11-Окт-25, 17:13
	В случае с micropython, он намного более зрелый и на деле проверенный. Ну и всё-таки официально поддерживается самой Raspberry и поэтому с поддержкой PIO нет никаких проблем. Вообще как бы странно ни звучало, но при работе с Micropython у меня не было проблем каких-либо со стабильностью работы самого Micropython, зато очень оценил то, насколько легче и быстрее дебажить код. Ну и ещё лично мне симпатична встроенная поддержка асинхронности с использованием привычного синтаксиса async/await, что также позволяет писать более лаконичный код. Но это мой личный опыт и у вас разумеется вполне может быть другое мнение касательно этого.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Крокодил (?), 11-Окт-25, 18:42
	Благодарю! Для меня, как-то незаметно, Micropython стал стандартом в сфере. Я не имею отношения к программированию микроконтроллеров, но интересуюсь ради кругозора.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от IdeaFix (ok), 11-Окт-25, 19:22
	Покуда lvgl с elua никак, будет то, с чем у lvgl всё хорошо. Если вопрос звучит похоже на "почему не асм?" то... просто не надо его задавать. Ответ известен.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Хайль_тоталитарный_Либерализм_РФиНАТО (ok), 12-Окт-25, 00:50
	> Micropython стал стандартом в сфере. НЕ удивительно, как и Python == 666...
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	62. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 03:04
	> Micropython стал стандартом в сфере. Не знаю, о какой сфере Вы ведете речь, но для сравнения. У меня есть выносные датчики температуры и влажности на STM8L152C6T6 и nRF24L01+, отображающие эти показатели на LCD индикаторе и передающие данные, или при изменении этих показаний, или раз в 10 минут. Для их питания одной таблетки СR2032 хватает больше, чем на год. На любом МК, на котором можно запустить MicroPython, среднее потребление менее 1мА в этом сценарии точно не получим. А значит, СR2032 хватит дней на десять максимум. Разницу замечаете? На мой взгляд, MicroPython на МК может быть оправдан только для единичных DIY проектов с питанием от сети. В остальных случаях на МК ему делать нечего.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	63. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Еще один Аноним (?), 12-Окт-25, 03:44
	Ну вы и Micropython на 8-битном микроконтроллере не запустите. Ну и в общем то ваш случай разумеется не очень подходит при использовании с Micropython.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 04:10
	> Ну вы и Micropython на 8-битном микроконтроллере не запустите. Я просто давно это делал. Сейчас тоже самое и с тем же результатом можно сделать и на 32-х битных STM32L152, тоже содержащих встроенный LCD контроллер с ультранизким потреблением. > Ну и в  общем то ваш случай разумеется не очень подходит при использовании с Micropython. И какой случай с батарейным питанием подходит для MicroPython? Или какой случай подходит даже для мелкосерийного проекта в несколько сотен экземпляров? Очень незначительное снижение стоимости разработки тут никак не компенсирует повышение стоимости аппаратной части даже на десять центов. Для примера, между CH32V003 и RP2040 разница в цене намного больше.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Еще один Аноним (?), 12-Окт-25, 06:54
	При работе с аккумулятором важно как можно быстрее отработать и выключиться, поэтому MicroPython становится не самой большой проблемой. Например если необходимо для дальнего дачного участка организовать аварийную сигнализацию с использованием LoRa, но с большим аккумулятором (Li-Ion). Делается это достаточно во многих участках владения, где невозможно полноценно питание подвести. С учетом нестабильности многих паленых модулей, динамическое исполнение Micropython позволяет сделать работу несколько надежнее и что самое главное поддерживаемым с приемлемыми затратами. Было еще несколько задач, которые получалось реализовать, но это мелочи. Были и более мелкие задачки, но с LR2032. Некоторые делались на Micropython как прототип, но в итоге получалось в стиле "нет ничего более постоянное чем временное" и при хорошей оптимизации получалось выжать неплохо. Опять же я ничуть не пытаюсь сказать, что Micropython является какой-либо заменой C/C++/Rust, ибо это безусловно бред. Он просто еще один инструмент со своими плюсами и очевидными минусами. При проектировании естественно надо это все учитывать. Я например также пробовал еще и TinyGo и хоть я и люблю Go, но вот надежность решения и поддерживаемость на TinyGo ужасна. Но очень надеюсь что и он прокачается до полностью готового инструмента. P.S. Прошу прощения за длинные портянки текста.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 10:24
	> При работе с аккумулятором важно как можно быстрее отработать и выключиться, поэтому > MicroPython становится не самой большой проблемой. Во-первых, нужно ещё сохранить состояние перед выключением и восстановить его после. И если на C я могу точно знать страницу SRAM, питание которой нужно оставить, то на MicroPython я об этом не знаю ничего. Во-вторых, быстро выключиться не сложно. Сложно включиться с минимальным потреблением, так как переферия, особенно внешняя просыпается не сразу. А на 32-38 КГц тактовой MicroPython становится совершенно непредсказуем по задержкам, так как каждая миллисекунда имеет значение. А в MicroPython не то что 30-40 тактов CPU, 3000-4000 тактов могут улетатать куда-то. > Например если необходимо для дальнего > дачного участка организовать аварийную сигнализацию с использованием LoRa, но с большим > аккумулятором (Li-Ion). То есть, вместо CR2032 которых хватит для простейшей аварийной сигнализации на 3-5 лет, Вы предлагаете "большой аккумулятор" на порядок большей стоимости, который и года не протянет без зарядки в средней полосе России? И это ради ничтожной экономии при разработке на MicroPython? Вы думаете, что в это можно поверить? > С учетом нестабильности многих паленых модулей, динамическое > исполнение Micropython позволяет сделать работу несколько надежнее и что самое главное > поддерживаемым с приемлемыми затратами. Как использование другого языка может повлиять на надежность работы модуля? Кроме того, что всяческие workaround описанные и не описанные в ERRATA намного проще реализуются на C и, порой, вообще не реализуемы на MicroPython из-за жестких таймингов.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от ptr (ok), 12-Окт-25, 10:42
	> Опять же я ничуть не пытаюсь сказать, что Micropython является какой-либо заменой > C/C++/Rust, ибо это безусловно бред. Он просто еще один инструмент со > своими плюсами и очевидными минусами. Он создавался изначально для прототипирования, когда наличие интерпретатора внутри МК позволяет экономить массу времени, исключая перекомпиляцию и перепрошивку для каждой итерации тестов. И тут он вполне оправдан, так как прототипируя с FT2232H так же используешь Python в качестве интерпретатора. А уже в DIY, где дополнительные $5 не имеют существенного значения, его стали использовать для реализации проектов. Что же касается непрекращающихся попыток продавать DIY решения вместо системных программных продуктов, экономя на порядок в разработке (в соответствии с Фредериком Бруксом) - это уже совсем отдельная тема.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	78. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–2 +/–
	Сообщение от Аноним (78), 12-Окт-25, 11:36
	> Он создавался изначально для прототипирования, когда наличие интерпретатора внутри МК > позволяет экономить массу времени, исключая перекомпиляцию Вы издеваетесь? Микроконтроллерная фирмварь типично компилится несколько секунд. И в любом случае будет действо по передаче нового кода на таргет, сетап и выполнение которого еще несколько секунд. Что вы там оптимизировать собираетесь? Аж 5-10 секунд на все действо? Которое при желании можно автоматически делать? > и перепрошивку для каждой итерации тестов. А у вас новый код на таргет - телепортируется чтоли? > И тут он вполне оправдан, так как прототипируя с FT2232H > так же используешь Python в качестве интерпретатора. Притягивание за уши как оно есть. И что вы там отпрототипировать сможете? МК вообще интересны в основном для сурового реалтайма (==питон в пролете), развитого аналога (процессинг приличных потоков с ADC в цать раз тормознее тоже не айс) и тому подобного. Да малое потребление - чему код работающий в цать раз медленнее точно не помощник. Если это все не надо - можно хоть писюк взять и програмить на чем угодно. > А уже в DIY, где дополнительные $5 не имеют существенного значения, его > стали использовать для реализации проектов. При том все эти проекты как на подбор максимально г-нарская наколенщина. К счастью среди DIY есть не только г@вн@ри с синдромом утенка.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (97), 12-Окт-25, 21:12
	> нового кода на таргет > новый код на таргет Ты завис, перезагрузись... > МК вообще интересны в основном для сурового реалтайма > развитого аналога > тому подобного Тебе - возможно. Мне, допустим, ценой и размером. Не надо всех под одну гребенку. > Да малое потребление - чему код работающий в цать раз медленнее точно не помощник Да и плевать. Я не в лесу, а БП на 5 вольт в "любом ларьке" на сдачу можно взять. > Если это все не надо - можно хоть писюк взять и програмить на чем угодно. Ну, дай мне писюк размером с монету и стоимостью в эту монету. > с синдромом утенка > Синдром утенка — психологический феномен в человеко-компьютерном взаимодействии, при котором пользователи демонстрируют предпочтение знакомым интерфейсам, сопротивляясь внедрению обновлённых версий. Знакомый интерфейс для МК - Си/Сипп. Что-то новое - Пыхтон. > Отказ программистов переходить на новые языки программирования, предпочитая старые новым, несмотря на тот факт, что освоение нового языка может послужить развитию как и персонала, так и проекта > все эти проекты как на подбор максимально г-нарская наколенщина > К счастью среди DIY есть не только г@вн@ри В данном контексте твоё прысканье слюной выглядит как... ну, там двумя цитатами выше уже написано, лень переписывать.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 21:37
	>> Он создавался изначально для прототипирования, когда наличие интерпретатора внутри МК >> позволяет экономить массу времени, исключая перекомпиляцию > Аж 5-10 секунд на все действо? То есть Вас и загрузка страниц в веб по 5-10 секунд устраивает? Может и реакция GUI на клик мыши в 5-10 cекунд для Вас тоже OK? ))) > И что вы там отпрототипировать сможете? Коммуникацию с другими устройствами, в том числе и на МК, формируя тесты обмена по SPI/I2C/USART/CAN/USB и т.п. >> и перепрошивку для каждой итерации тестов. > А у вас новый код на таргет - телепортируется чтоли? Почти, так как в случае интерпретатора исключаются этапы компиляции и прошивки, а код выполняется интерактивно сразу. > МК вообще интересны в основном для сурового реалтайма Да пофиг на реалтайм при отладке и тестировании протокола обмена по I2C/CAN/LIN/ModBus и т.п. Зато можно моделировать внештатные ситуации, которые в железе раз в год случаются.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	75. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (75), 12-Окт-25, 10:57
	> При работе с аккумулятором важно как можно быстрее отработать и выключиться, поэтому > MicroPython становится не самой большой проблемой. Вообще-то код работающий в 10 раз дольше - это как раз серьезный удар по потреблению. > исполнение Micropython позволяет сделать работу несколько надежнее и что самое главное > поддерживаемым с приемлемыми затратами. Какие-то совершенно притянутые за уши выводы - которые вообще ниоткуда не следуют. Хотя общий сетап "какой яп такой и модуль" выглядит что надо. > Были и более мелкие задачки, но с LR2032. Некоторые делались на Micropython > как прототип, но в итоге получалось в стиле "нет ничего более > постоянное чем временное" и при хорошей оптимизации получалось выжать неплохо. Неплохо - по сравнению с чем? Как именно сравнивалось? Конкретные цифры? Соотношения? Без этого похоже - на синдром утенка в жесткой форме, уж извините.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	70. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Ан248ним (ok), 12-Окт-25, 09:27
	> И какой случай с батарейным питанием подходит для MicroPython? Такой, что МК не сможет завалиться в спячку в ...цать раз дольше. И значит батарейка будет жить в ...цать раз меньше. Это видимо killer feature :D. Battery killer feature.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	90. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (91), 12-Окт-25, 16:06
	> На любом МК, на котором можно запустить MicroPython, среднее потребление менее 1мА в этом сценарии точно не получим. А значит, СR2032 хватит дней на десять максимум. А у вас в теплице что, электричества нет? Оно сейчас есть в любом производственном помещении, подвале, гараже, складе.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	101. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 21:55
	>> А значит, СR2032 хватит дней на десять максимум. > А у вас в теплице что, электричества нет? Оно сейчас есть в > любом производственном помещении, подвале, гараже, складе. Пришлите, пожалуйста, видео, как Вы по полю площадью в десятки гектаров электропроводку к датчикам температуры и влажности почвы прокладываете. Я очень зантересовался этой технологией, так как Вы взялись доказать, что она дешевле, чем ежегодная замена CR2032 по 30 рублей штука.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 17:11
	Прислать тебе видео как вcpaтый АЛТАЕЦ в адских щебенях вбивает по своему участку - "колышки"? (На колышке фонарик, датчик света, конденсатор вместо аккумулятора и солнечная батарейка в ладошку - фонарику хватит. Да, на али заказал, а не сам спаял.) Чтоб по пьяни ночью пойдя посцать - в речку не свалитцо. Если ты не можешь собрать такой же "колышек" для своего поля в cц@ть гектаров (причем из готовых деталей с али и за три копейки) - тебя надо в компостную кучу зак0п@ать прямо там же. Ты не инженер а оно, которое туда и сбрасывают. Инженер должен быть в курсе современных технологий, а не двадцатилетней давности.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (-), 14-Окт-25, 11:20
	> А у вас в теплице что, электричества нет? Оно сейчас есть в > любом производственном помещении, подвале, гараже, складе. Может туда 220 подвести? Чтобы лишний раз получить шанс что кого-то в потенциально сыром помещении - прибьет нахрен, наверное.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	136. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 17:27
	>> А у вас в теплице что, электричества нет? Оно сейчас есть в >> любом производственном помещении, подвале, гараже, складе. > Может туда 220 подвести? Чтобы лишний раз получить шанс что кого-то в может. Километровые 12вольтовые пробросы - так себе идея, если ты не в курсе. > потенциально сыром помещении - прибьет нахрен, наверное. Ну и хорошо - горе-инженеришку из заборостроительного посадят и найдут нового, с дипломом хотя бы МВТУ. Он знает, как (на самом деле больше - из чего) монтировать 220 в сыром помещении, чтоб никого не убить, на третьем курсе проходил.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (-), 12-Окт-25, 17:30
	Ada is unequivocally better 😉. https://pico-doc.synack.me/#getting_started https://github.com/JeremyGrosser/pico_examples
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	103. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от ptr (ok), 12-Окт-25, 23:10
	> Ada is unequivocally better 😉. Не отрицая многие преимущества Ada, следует отметить, что Rust имеет те же преимущества, но более низкую стоимость разработки. Другой вопрос, что отсутствие стандарта на Rust приводит к сложностям сертификации продукции, его использующей. Исправление ошибок и уязвимостей в старых версиях не производится, а использование новых версий требует повторной сертификации.
	Ответить | Правка | Наверх | Cообщить модератору

19. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–3 +/–
Сообщение от ымдлопрмип (?), 11-Окт-25, 13:03
> "Быстрой разработки прототипов" Быстро, быстро, дыщ, дыщ... А потом интернет вещей полностью дырявый. Интересно, когда-нибудь появится не "быстро-ОС", а "секурити-ОС", изначально заточенная так, чтобы не допускать дыр в безопасности? Её будут писать нерды, и она окажется никому не нужна. Потому что удобство и безопасность - противоположные вещи.
Ответить | Правка | Наверх | Cообщить модератору

	21. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
	Сообщение от Пыщь (?), 11-Окт-25, 13:54
	QNX не подходит?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (91), 11-Окт-25, 16:02
	Неа, проприетарщина.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (29), 11-Окт-25, 15:35
	Таких достаточно много, но они не общего назначения. Нужна секурити ОС для игры в стим и сидения вконтакте? Серьезно? А кому нужна,  2.5 анонимам? Ну пишите.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	38. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (38), 11-Окт-25, 17:13
	GrapheneOS?
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	93. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (-), 12-Окт-25, 18:01
	seL4 и, возможно, MirageOS. Слышал ещё про M2OS, HIRTOS, Ironclad.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	133. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от нах. (?), 14-Окт-25, 17:13
	интернет вшей полностью дырявый совершенно не из-за пихона. А из-за того что вы не умеете писать софт, не требующий облачков и белогривых лош@ариков. Это от языка не зависит, если что.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

20. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
Сообщение от Аноним (23), 11-Окт-25, 13:53
ФАНТОМ ОС всё таки зарелизилась?
Ответить | Правка | Наверх | Cообщить модератору

	49. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от 1 (??), 11-Окт-25, 19:51
	Давно, но её не видно потому что фантом.
	Ответить | Правка | Наверх | Cообщить модератору

25. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–3 +/–
Сообщение от Аноним (25), 11-Окт-25, 14:37
Куда засунуть тормозной жрйщий память язык? Правильно, на микроконтроллер, где ресурсы и без того ограничены.
Ответить | Правка | Наверх | Cообщить модератору

	30. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–2 +/–
	Сообщение от Аноним (29), 11-Окт-25, 15:37
	А вы давно питон видели? С jit у него производительность недалеко от С. А микропитон заточен на низкое потребление памяти и вообще уже стандарт в микриках. Если вы не профик, зачем писать флуд?!
	Ответить | Правка | Наверх | Cообщить модератору

	42. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (25), 11-Окт-25, 18:17
	>А вы давно питон видели? С jit у него производительность недалеко от С. Недавно. >https://www.opennet.dev/opennews/art.shtml?num=64029#144 >Pypy, Node.js и Rust обогнали CPython 3.14 в первом тесте в 4.93, 4.88 и 69.82 раз Супер тормозной язык, отстающий от нативной реализации в семьдесят раз. >А микропитон заточен на низкое потребление памяти и вообще уже стандарт в микриках. Писать под микроконтроллеры на нормальных компилируемых языках? Бред какой-то, давайте лучше бидон возьмём.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (47), 11-Окт-25, 19:38
	>>Pypy, Node.js и Rust обогнали CPython 3.14 в первом тесте в 4.93, 4.88 и 69.82 раз >>Супер тормозной язык, отстающий от нативной реализации в семьдесят раз. Речь о MicroPython, а не CPython. В следующий раз попробуй читать не задницей.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (25), 11-Окт-25, 22:08
	>Речь о MicroPython Вы утверждаете, что реализация для микроконтроллеров, с их ограниченными ресурсами способна на большие оптимизации, чем cpython? Самим не смешно?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (-), 12-Окт-25, 08:54
	> Вы утверждаете, что реализация для микроконтроллеров, с их ограниченными ресурсами > способна на большие оптимизации, чем cpython? Самим не смешно? В свое время адепты BASIC то же самое рассказывали. И где они все теперь? И их программы? С питоном такая же хрень случается - мало программ живет более пары лет. Исключения есть но они лишь подтверждают правило.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от ptr (ok), 12-Окт-25, 00:52
	> С jit у него производительность недалеко от С Не может язык с динамической типизацией даже приблизиться к C по потреблению памяти (для каждого объекта тип приходится хранить) и к производительности (почти перед каждой операцией надо тип проверять). Что и видим в тестах: https://www.semanticscholar.org/paper/Performance-Evaluation... Если лениво изучать статью, вот результаты: https://figures.semanticscholar.org/a829c5608ae5d9cf051ab6e5...
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	80. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (-), 12-Окт-25, 11:45
	> А вы давно питон видели? С jit у него производительность недалеко от С. Как показали вон там бенчи в новости - уже почти совсем не тормозит, всего раз в 10 разница. И это только если есть на чем прогретьсся. И генерация сколь-нибудь оптимального кода - тоже внезапно проц грузит. Вот только если поставить вопрос ребром и выбрать между завершением задачи за 1 минуту или 10 - тут почему-то у всех совсем другие идеи. Кроме утят, конечно, которым свое - не пахнет. Но даже гугло нанюхался - и сделал Go. Потому что когда питоннетормозит - прямо на своих серверах, и за свой счет - все почему-то резко сообразительные. > А микропитон заточен на низкое потребление памяти и вообще уже > стандарт в микриках. Если вы не профик, зачем писать флуд?! Профик? :)) Стандарт? Это "стандарт" разве что в самых гунявых наколенных проектах вида "сделал какую-то фекалину на висючем китайском модуле за выхи". Как вы понимаете - в масспрод проектах, индустрии и проч это все - не применяется. Так что да - "профики". Да что уж там, "профаны".
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	95. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
	Сообщение от Аноним (10), 12-Окт-25, 20:16
	В 10 раз - это если с наивным кодом сравнивать, без simd, без внимания к кэш френди дизайну. А так кратно больше может быть.
	Ответить | Правка | Наверх | Cообщить модератору

28. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+/–
Сообщение от Аноним (-), 11-Окт-25, 15:01
Помимо контроллеров микропитон вроде как окружение Linux поддерживает, а сабж вроде как можно на amd64 запускать. Если так, то помимо реального железа можно в виртуалках использовать и в контейнерах, а экран шарить через VNC/RDP/Spice. До сих пор было несколько свободных микроосей: FreeDOS, ELKS, KolibriOS, но андроидоподобной еще небыло. Приложухи можно как альтернативу Web-интерфейсам использовать. Возможно будет полезно для тех кто не хочет с HTML заморачиваться.
Ответить | Правка | Наверх | Cообщить модератору

	31. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
	Сообщение от Аноним (29), 11-Окт-25, 15:50
	А нафига? Микропенис - это чисто микриковская сильно урезанная ради оптимизация тема. На дженериках то он зачем?! Чтобы сладко было?!
	Ответить | Правка | Наверх | Cообщить модератору

	68. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+1 +/–
	Сообщение от Аноним (68), 12-Окт-25, 08:51
	> Приложухи можно как альтернативу Web-интерфейсам использовать. Возможно будет полезно > для тех кто не хочет с HTML заморачиваться. У HTML относительно питона есть жирное достоинство - не ломается каждые пару лет в хлам. Так что доисторический сайт с видом "на дворе 1999" по прежнему нормально открывается. Теперь попробуйте запустить вообще скрипт на питоне сравнимой древности.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

43. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	–1 +/–
Сообщение от Аноним (43), 11-Окт-25, 18:22
документации нормальной нет
Ответить | Правка | Наверх | Cообщить модератору

50. "MicroPythonOS - ОС с графическим интерфейсом для микроконтро..."	+2 +/–
Сообщение от Аноним (50), 11-Окт-25, 20:23
Это чтобы из коробки всё тормозило?
Ответить | Правка | Наверх | Cообщить модератору

67. "MicroPythonOS - ОС с графическим интерфейсом для микроконтроллеров"	+/–
Сообщение от Аноним (68), 12-Окт-25, 08:49
> Опубликован выпуск проекта MicroPythonOS 0.0.11, разрабатывающего операционную систему > для микроконтроллеров, таких как ESP32, Прочитал как MontyPythonOS. Призадумался что это название подходило бы ей намного больше.
Ответить | Правка | Наверх | Cообщить модератору

	74. "MicroPythonOS - ОС с графическим интерфейсом для микроконтроллеров"	+1 +/–
	Сообщение от Аноним (74), 12-Окт-25, 10:50
	Рождённый интерпретироваться летать не может.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "MicroPythonOS - ОС с графическим интерфейсом для микроконтроллеров"	+/–
	Сообщение от Аноним (89), 12-Окт-25, 16:00
	> Рождённый интерпретироваться летать не может. Ползающий цирк монти пайтона :). MontyPython Crawling Circus.
	Ответить | Правка | Наверх | Cообщить модератору

130. Скрыто модератором	+/–
Сообщение от Аноним (130), 14-Окт-25, 14:52
Python - лучший ЯП!
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема