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

"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. Сообщение от Аноним (1), 11-Окт-25, 08:55	–17 +/–
pip поддерживает? встроенный редактор с проверкой синтаксиса есть? глобальный лок на месте? cphyton и pytorch все библиотеки поддерживает? если нет, то зачем?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #107

2. Сообщение от заполнить поле Name (?), 11-Окт-25, 09:00	+11 +/–
>pytorch >на ESP Ахахахаха. Хорошая шутка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10

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

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

7. Сообщение от pofigist (?), 11-Окт-25, 09:36	+2 +/–
man forth
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #104

10. Сообщение от Аноним (10), 11-Окт-25, 10:39	+/–
Распознование лиц и детекцию объектов делают же ж на ESP32, там simd есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #23, #76, #81

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

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

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

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

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

18. Сообщение от _kp (ok), 11-Окт-25, 12:46	+2 +/–
Быстрее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #56

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

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

21. Сообщение от Пыщь (?), 11-Окт-25, 13:54	+2 +/–
QNX не подходит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #33

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

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

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

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

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

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

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

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

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

33. Сообщение от Аноним (91), 11-Окт-25, 16:02	+/–
Неа, проприетарщина.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

34. Сообщение от Аноним (34), 11-Окт-25, 16:30	+4 +/–
> А потом интернет вещей полностью дырявый. дырявым он как раз будет, если будут (не ты, ты только тут газировать лужи горазд) писать на си или крестах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #79

38. Сообщение от Аноним (38), 11-Окт-25, 17:13	+/–
GrapheneOS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

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

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

42. Сообщение от Аноним (25), 11-Окт-25, 18:17	+1 +/–
>А вы давно питон видели? С 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ообщить модератору
Родитель: #30 Ответы: #47

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61. Сообщение от 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. Если питание от сети, то это ещё можно пережить, хоть и с утерей конкурентоспособности даже на средней по величине партии. А вот при батарейном питании - это уже катастрофа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #64, #94

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

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

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

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

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

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

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

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

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

71. Сообщение от 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ообщить модератору
Родитель: #64 Ответы: #85

72. Сообщение от 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ообщить модератору
Родитель: #66

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

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

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

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

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

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

79. Сообщение от Аноним (78), 12-Окт-25, 11:40	+/–
> дырявым он как раз будет, если будут (не ты, ты только тут > газировать лужи горазд) писать на си или крестах Учитывая что парочку потыканых палочкой сервисов на питоне умирали в первые 5 минут контактов со мной - врядли у вас IoT сильно лучше получится. И тоже умрет в первые 5 минут его тыкания палочкой. Но это другое, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #100

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

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

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

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

85. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #71 Ответы: #99

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

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

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

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

92. Сообщение от Аноним (-), 12-Окт-25, 17:30	+1 +/–
Ada is unequivocally better 😉. https://pico-doc.synack.me/#getting_started https://github.com/JeremyGrosser/pico_examples
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #103

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

94. Сообщение от Аноним (-), 12-Окт-25, 18:34	+1 +/–
> 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 фильтровать, нехай глюкавит плюс-минус лапоть. Особенно если он рядом с прожорливым нагруженным процом соседствует, ему точно зайдут короткие мощные импульсы от цифры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #102

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

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

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

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

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

100. Сообщение от Аноним (97), 12-Окт-25, 21:45	+/–
> в первые 5 минут контактов со мной Может у тебя руки кривые? Или карма грязная. Почисти карму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

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

102. Сообщение от ptr (ok), 12-Окт-25, 22:43	+1 +/–
>> 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ообщить модератору
Родитель: #94 Ответы: #112

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

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

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

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

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

109. Сообщение от 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ообщить модератору
Родитель: #106 Ответы: #110

110. Сообщение от _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ообщить модератору
Родитель: #109 Ответы: #113

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

112. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #102 Ответы: #114

113. Сообщение от 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ообщить модератору
Родитель: #110 Ответы: #115

114. Сообщение от 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ообщить модератору
Родитель: #112

115. Сообщение от _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ообщить модератору
Родитель: #113

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

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

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