Micro Python: Python for microcontrollers

Нет, я тебя слушаю. Давай, рассказывай мне, чем высокоуровневый язык с GC хорош в МК. Т.е. нафиг это нужно.

рассказывай мне, чем высокоуровневый язык с GC хорош в МК. Т.е. нафиг это нужно.

Программы писать быстрее и проще. Ну и дураков троллить тоже неплохо получается.

А как же tinypy

По ссылке есть ответ (насчет PyMite тоже).

Да. Правда, это было во времена, когда 8051 был роскошью.

На асме небось? Тогда всё ясно...

Да.

Я вас не обзывал. Вы первым перешли на личности.

Из тебя тролль, как из собачьего хвоста - сито.

Я бы посмотрел, как ты написал бы что-то на питоне для того же AVR. Смеху было бы...

Прочитал тред, среди адекватных аргументов против сабжа нашел один - не взлетит в промышленым масштабах. Согласен, так и есть.

Но какая проблема этим налабать всякие простые вещи с исходниками в пару сотен строк простейшей логикой «если-то»? Prototyping? Нет, я не спрашивал проще это на С или не проще. Какая проблема если кто-то будет этим пользоваться и им будет удобнее?

</thread>

<если-то> реализуется на всех языках одинаково, причем на C будет проще из-за готовых средств сборки, а также отладки/симулирования. Кстати, про отладку этого счастья я ничего не нашел.

При более сложном он рискует соснуть из-за невозможности выдержать тайминги (например, когда на слабом МК реализуется быстрая передача/разбор сигналов). Вот тут на наличие в сабже GC и смотришь дикими глазами.

А по простоте для примитива и прототипирования выигрывает Arduino, причем в одни ворота. При всей нелюбви народа к нему.

</thread>

Не ты его открывал, не тебе его Тарас Бульба.

Вот тут на наличие в сабже GC и смотришь дикими глазами

Я так понял тут или reference counter или статическое проставление free где надо компилятором. Уж точно не mark and sweep, поверь ))

А по простоте для примитива и прототипирования выигрывает Arduino

Но выигрывает наверное готовностью, так как это не готово. Было бы интересно потыкать когда это допилят

Я так понял тут или reference counter или статическое проставление free где надо компилятором. Уж точно не mark and sweep, поверь ))

Рассказать, где refcounting сосёт, или сам вспомнишь?

Но выигрывает наверное готовностью, так как это не готово.

Выигрывает тем, что - купил, скачал SDK, запустил, в их блокноте быра налабал и одной кнопкой залил на девайс. Проще просто некуда, потому идеал для прототипированя. При этом низкого уровня нет вообще, а есть только функции, которые что на С, что на Питоне, что на Java будут одни и те же - что нивелирует разницу в языках до нуля.

Было бы интересно потыкать когда это допилят

когда это допилят

Ты что, первый раз opensource увидел? Когда допилят, ты уже состаришься.

Рассказать, где refcounting сосёт, или сам вспомнишь?

Я знаю, но бездумно нельзя программировать.

На асме небось?

На Си.

Тогда всё ясно...

Тебе было всё ясно и с MicroPython, но твоя «ясность» никак не была связана с реальностью.

Вы первым перешли на личности.

Прокурору расскажешь, что выражение «для особо одаренных» - это не переход на личности.

Из тебя тролль, как из собачьего хвоста - сито.

Ты поразил меня в самое сердце.

Я бы посмотрел, как ты написал бы что-то на питоне для того же AVR. Смеху было бы...

Пройди уже по ссылке, эмулятор дебила. Там приведены минимальные требования к железу.

Рассказать, где refcounting сосёт, или сам вспомнишь?

О, а расскажи мне, причем тут refcounting.

На Си.

Тогда может расскажете нам всем, что есть такого хорошего в питон что оправдывает 10-кратный оверхед на микроконтроллерах. Жду сравнения с сишкой, раз вы на ней писали. Именно в контексте применения на МК.

Прокурору расскажешь, что выражение «для особо одаренных» - это не переход на личности.

Ок. mono

что есть такого хорошего в питон

Классы, cписки, кортежи, исключения. И, прикинь, я совершенно не скучаю по выходам за границу массива и повисшим указателям.

оправдывает 10-кратный оверхед на микроконтроллерах.

Расскажи, откуда взялась цифра 10 и почему тебя вообще волнует оверхед.

Жду сравнения с сишкой, раз вы на ней писали

Я не писал на «сишке» (что это вообще такое?). Я писал на Си. И до сих пор пишу, правда, не для микроконтроллеров.

А можно узнать, зачем?

Управление памятью на МК вовсе не такой уж и ад, как в Си на десктопах. МК находится на каком-то строго определённом месте схемы и выполняет там какую-то строго определённую функцию, и не надо там постоянно память перекраивать, занимая и высвобождая её под разные объекты для разных задач. Я даже malloc-то не использую, утечек памяти нет, и gc оказывается не нужен. Всё в глобальных и статических переменных прекрасно хранится, которые используются от включения до выключения.

Если где-то и используются больше объёмы данных, то это обычно какие-то константные таблицы данных или константные же текстовые сообщения, пересылаемые по UART для отладки, которые размещаются в памяти программ, и под них не надо RAM высвобождать.

Необходимости защищать данные одного процесса от другого на системном уровне тоже нет, нет ситуации, как на десктопе, когда неизвестно кто будет работать параллельно неизвестно с чем, всё спроектировано и написано мной, и ничего нового там в принципе запуститься не сможет. Сложного в том, чтобы не лезть куда не надо, тоже ничего нет даже на уровне предположений, потому что структура памяти статическая.

Так что же я могу получить от ЯП высокого уровня?

исключения

Есть прерывания же.

Короче, резюмируя вышесказанное: ЯП высокого уровня решают проблемы, возникающие на вычислительных устройствах общего назначения, и решаемые ими проблемы в значительно меньшей степени актуальны на встраиваемых вычислительных устройствах, имеющих узкоспециализированное назначение.

исключения

Есть прерывания же.

Ты правда предлагаешь использовать прерывания для обработки исключительных ситуаций?

ЯП высокого уровня решают проблемы, возникающие на вычислительных устройствах общего назначения

По мере прогресса электроники микроконтроллеры всё более становятся «вычислительными устройствами общего назначения».

Ты правда предлагаешь использовать прерывания для обработки исключительных ситуаций?

Про иные исключения хочется сказать «неужели кто-то правда додумался использовать в этой ситуации что-то вместо прерываний?». Ну а деление на ноль отлавливать исключениями вместо проверки входных данных, по-моему, вообще за гранью. А потом мы удивляемся, что тойоты не тормозят.

По мере прогресса электроники микроконтроллеры всё более становятся «вычислительными устройствами общего назначения».

Они начинают решать разные задачи, переползая с одного места в схеме на другое?

Ты правда предлагаешь использовать прерывания для обработки исключительных ситуаций?

Про иные исключения хочется сказать [...]

И это относится к моему вопросу... как именно?

Они начинают решать разные задачи, переползая с одного места в схеме на другое?

У меня десктопный компьютер тоже с одного места на другое не ползал, но как-то умудрялся решать разные задачи.

И, прикинь, я совершенно не скучаю по выходам за границу массива

нубская ошибка же, тем более при программировании МК

и повисшим указателям

вы настолько часто использовали указатели и да, ошибка тоже нубская

почему тебя вообще волнует оверхед.

потому, что сталкивался с ситуациями, хотя оно и редкость, когда функционал программы напрямую зависит от производительности, например чем выше производительность, тем с большим числом устройств можно «общаться» по уарту

Расскажи, откуда взялась цифра 10

а вы возьмите прогу, дизассемблируйте и посмотрите сколько жрёт обращение к переменным (особенно xdata) через указатели

Классы, списки, исключения

для всего этого С++ достаточно, причём без оверхеда на динамику: я так и не услышал, зачем на МК именно динамическая типизация

Я не писал на «сишке» (что это вообще такое?). Я писал на Си. И до сих пор пишу, правда, не для микроконтроллеров.

а почему не на Питоне?

У меня десктопный компьютер тоже с одного места на другое не ползал, но как-то умудрялся решать разные задачи.

Между ВУ общего и узкоспециализированного назначения разница в том, что первое является центром схемы. Вся обвязка предназначена, чтобы обеспечить его интерфейсами ко всем возможным видам данных, которые может понадобиться обработать, и к торрентами, где можно скачать все возможные виды софта для обработки. Встраиваемое ВУ устанавливается в какую-то часть схемы, где оно заменяет кучу релюшек, операционников, компараторов и дискретной логики, и остаётся там до конца дней, выполняя свою работу, принимая один определённый набор сигналов и выдавая другой. В этом его задача, и задача средств разработки — обеспечить, чтобы эту задачу он выполнял хорошо. Именно эту, а не превращать его в устройство с какими-то другими задачами, подключать к торрентам и запускать тетрис.

И это относится к моему вопросу... как именно?

Весь класс эксепшенов EnvironmentError, мне кажется, это костыли вместо использования прерываний и обработки флагов. Другие эксепшены, может, и были бы полезны, но ИМХО они или для Си неактуальны, или для ВС узкоспециализированного назначения неактуальны, или должны отсутствовать во время исполнения by design во встраиваемых системах, управляющих реальным железом.

нубская ошибка же
ошибка тоже нубская

«И вы тоже говорите» (ц)

почему тебя вообще волнует оверхед.

потому, что сталкивался с ситуациями, хотя оно и редкость, когда функционал программы напрямую зависит от производительности,

Вот именно - редкость. И для борьбы с этой редкостью в Micropython предусмотрены... хотя зачем я это рассказываю, если ты до сих пор не удосужился сходить по ссылке.

Расскажи, откуда взялась цифра 10

а вы возьмите прогу, дизассемблируйте и посмотрите [...]

Я так и думал.

Я писал на Си. И до сих пор пишу, правда, не для микроконтроллеров.

а почему не на Питоне?

Ты считаешь, что одно исключает другое? На Python я пишу немногим меньше, чем на Си.

Встраиваемое ВУ устанавливается в какую-то часть схемы, где оно заменяет кучу релюшек, операционников, компараторов и дискретной логики, и остаётся там до конца дней, выполняя свою работу

Тебе знакомо слово «прототипирование»? «Хоббисты»?

Весь класс эксепшенов EnvironmentError, мне кажется, это костыли вместо использования прерываний и обработки флагов.

Начинает брезжить тусклый свет понимания... ты по специальности электронщик, физик или что-то такое? У них такие же неандертальские^Wоригинальные взгляды на программирование.

«И вы тоже говорите» (ц)

по делу ответить вам нечего, ясно

хотя зачем я это рассказываю, если ты до сих пор не удосужился сходить по ссылке.

расскажите уж для ТруЪ

На Python я пишу немногим меньше, чем на Си.

Но зачем? Если питон настолько лучше Сишки, зачем юзать Сишку вообще?

И да, я так и не услышал от вас, зачем на МК нужна динамическая типизация.

по делу ответить вам нечего, ясно

Зачем отвечать на слегка завуалированную фразу «ты нуб»?

расскажите уж для ТруЪ

Я уже процитировал, повторять не стану.

Если питон настолько лучше Сишки, зачем юзать Сишку вообще?

Что за «сишку» ты всё время вспоминаешь?

И да, я так и не услышал от вас, зачем на МК нужна динамическая типизация.

Ну кто ж виноват, что ты не слушаешь.

такие же неандертальские^Wоригинальные взгляды на программирование.

Я даже и не спорю, я потому и залез в эту тему со словами «можно узнать?», а не «вы тут все быдлокодеры и нифига не понимаете, а настоящие пацаны пишут на ассемблере!» Вот мне реально интересно, в чём заключается неандертальство моих взглядов, и где я могу вырасти над собой.

Тебе знакомо слово «прототипирование»? «Хоббисты»?

Но это же не означает, что в МК заливается прошивка,которая будет работать одновременно во всех сделанных на этом МК прототипах и хобби-проектах, да?

Вот мне реально интересно, в чём заключается неандертальство моих взглядов

В том, что ты считаешь нормальной (и даже хорошей) практикой проверку флагов и обработку исключительных ситуаций через прерывания. Исполняющая система языка должна активно помогать обнаруживать и устранять ошибки - исключения как раз предназначены для сообщения и обработки обнаруженных ошибок. Конечно, статически проверяемая безопасность лучше, но от динамических проверок никуда не деться.

Но это же не означает, что в МК заливается прошивка,которая будет работать одновременно во всех сделанных на этом МК прототипах и хобби-проектах, да?

Наверное, я не понял вопроса, но всё же: нет, не означает.

Зачем отвечать на слегка завуалированную фразу «ты нуб»?

это не было никакой завуалированной формой, я правда не понимаю как человек со стажем программирования более года может совершать ошибки выхода за пределы массива, кроме случайных опечаток

Я уже процитировал, повторять не стану.

ссылку

Что за «сишку» ты всё время вспоминаешь?

#define сишка С

так яснее?

Ну кто ж виноват, что ты не слушаешь.

Вы меня с кем-то перепутали. Процитируйте ответ, где вы писали о преимуществах динамической типизации применительно к МК

Наверное, я не понял вопроса, но всё же: нет, не означает.

Наверное, я тоже не понял вопроса, но смысл ответа был в том,что встраиваемые устройства не различаются по способу использования, что в промышленных устройствах, что в прототипировании, что в наколенных поделках. Выполняемая ими функция — строго постоянная, и зависит только от места микроконтроллера в схеме и набора сигналов, которые он должен в этом месте схемы принять и передать. Это устройство, которое, да, может быть устройством общего назначения, но намеренно урезается до устройства узкого назначения (до конца дней или до конца дней работы девайса или до момента его выключения, неважно). Не от плохой жизни, не потому что МК не могут выполнять другие функции, а потому что так надо.

ссылку

Ты по ним не ходишь.

я так и не услышал от вас, зачем на МК нужна динамическая типизация.

Процитируйте ответ, где вы писали о преимуществах динамической типизации применительно к МК

Я так понимаю, скоро ты потребуешь ссылку на мое объяснение того, почему динамическая типизация должна покорить Вселенную. И не пойдешь по ней %)

Выполняемая ими функция — строго постоянная, и зависит только от места микроконтроллера в схеме и набора сигналов, которые он должен в этом месте схемы принять и передать

Очень абстрактное описание. Как насчет USB, CAN, Ethernet, Bluetooth - они входят в «набор сигналов»? Микроконтроллеры давно уже могут больше, чем быть просто кучей переключателей.

Это устройство, которое, да, может быть устройством общего назначения. Не от плохой жизни, не потому что МК не могут выполнять другие функции, а потому что так надо.

Всем-всем-всем надо, без исключений?

обработку исключительных ситуаций через прерывания

Чем прерывание от контроллера интерфейса по ошибке передачи отличается от эксепшена по ошибке передачи?

Конечно, статически проверяемая безопасность лучше, но от динамических проверок никуда не деться.

Позволяет ли динамическая проверка исключить статическую в ситуации, когда «таёта» может неуправляемо разогнаться, установка для радиотерапии — переоблучить пациента, самолёт — попасть в аварию (таких баек я слышал ещё как минимум три — f-16, пересекающий экватор, f-22, пересекающий линию перемены дат, и ещё какой-то самолёт, летящий на высоте ниже уровня моря над Мёртвым морем), да и просто транзистор выгорит, и простым перезапуском его не заменишь? Все ошибки, для отлова которых оставлены исключения, должны быть обойдены ещё на этапе проектирования гораздо более жёсткими проверками, цель которых — аппаратная надёжность схемы.

Очень абстрактное описание. Как насчет USB, CAN, Ethernet, Bluetooth - они входят в «набор сигналов»? Микроконтроллеры давно уже могут больше, чем быть просто кучей переключателей.

Если на шинах висят одни и те же устройства, то да, тот же самый случай (у меня в разрабатываемом девайсе драйвер usb-хоста, статически вместе со всем проектом собран, usb-устройство постоянно подключено, постоянно работает. Ничем эта ситуация от вышеописанной не отличается.). Если там может что угодно подключаться, то это уже устройство общего назначения, там не то что питон, там уже надо брать одноплатник и линукс со всеми доступными драйверами поднимать.

Чем прерывание от контроллера интерфейса по ошибке передачи отличается от эксепшена по ошибке передачи?

Чем исключительная ситуация по выходу за границу массива отличатся от прерывания... прерывания... епт, да ведь нет такого прерывания.

Языковые исключения, аппаратные исключения, и прерывания - это 3 разных средства сообщения об исключительных ситуациях в программах (причем прерывания - это, в основном, средство сообщения об асинхронных событиях во внешнем мире). Не сваливай их в одну кучу.

Позволяет ли динамическая проверка исключить статическую

Обычно да, но это очень плохая идея.

«таёта» может неуправляемо разогнаться, установка для радиотерапии — переоблучить пациента, самолёт — попасть в аварию

Все эти байки относятся к алгоритмическим ошибкам и ошибкам дизайна. Системы типов, которые отлавливают практически осязаемую их часть - предмет исследования (и да, они статические).

Все ошибки, для отлова которых оставлены исключения, должны быть обойдены ещё на этапе проектирования гораздо более жёсткими проверками

И ЖИВОТНОВОДСТВО^WВЕРИФИКАЦИЯ!!11 %)

В идеале ты, конечно, прав, но на практике такое не окупается.

цель которых — аппаратная надёжность схемы.

Этого просто не понял.

Если там может что угодно подключаться

Естественно.

там уже надо брать одноплатник и линукс со всеми доступными драйверами поднимать.

Ресурсоемкость Linux на порядок-два выше %)

Все эти байки относятся к алгоритмическим ошибкам и ошибкам дизайна.

А какие ещё ошибки могут быть в неправильно работающей прошивке микроконтроллера? Выход за пределы статического массива — не алгоритмическая ошибка? Она не означает, что вычисление индекса идёт по какому-то не тому алгоритму, который предполагался?

Этого просто не понял.

Исключение отказов железа, которые потребуют ремонта. Отказы софта, если они не привели к отказу железа, решаются перезапуском.

Соответственно, если всё равно брать линукс с железом, которое его тянет, и нормальным питоном, то сабж не нужен?

В идеале ты, конечно, прав, но на практике такое не окупается.

То есть, если верификация на практике оказывается неприменима, то с обработкой входных данных можно вообще не париться на всех этих таётах и f-22? А если париться хоть чуть-чуть, то эксепшены сразу становятся бесполезны, потому что они отлавливают только самые очевидные и примитивные случаи (деление на ноль и границы массивов, да).

Выход за пределы статического массива — не алгоритмическая ошибка?

Нет. Выход за пределы массива не является частью алгоритма.

Она не означает, что вычисление индекса идёт по какому-то не тому алгоритму, который предполагался?

Означает. Но в случае F-16 над Мертвым морем (я слышал эту байку именно про F-16), вычисление шло по обычному штатному алгоритму, который просто не покрывал некоторых случаев (== содержал ошибку).

Соответственно, если всё равно брать линукс с железом, которое его тянет, и нормальным питоном, то сабж не нужен?

Для основной заявленной цели - нет. Но компактный Python с возможностью генерации нативного кода - вещь полезная в хозяйстве. От встроенных скриптовых движков до модулей ядра.

если верификация на практике оказывается неприменима, то с обработкой входных данных можно вообще не париться на всех этих таётах и f-22?

Нет. Вообще не вижу связи между этими двумя утверждениями.

Нет. Вообще не вижу связи между этими двумя утверждениями.

Ты зачем-то написал про верификацию, когда я говорил про проверку входных данных. Ты зачем-то сказал «на практике такое не окупается», что верно про верификацию, но неверно про проверку входных данных. Теперь ты зачем-то делаешь вид, что не понимаешь, о чём речь, а я, пересказывая тебе содержимое предыдущих сообщений, чувствую себя совершенно по-дурацки. Зачем? Ты сегодня тролль, что ли?

Но в случае F-16 над Мертвым морем (я слышал эту байку именно про F-16), вычисление шло по обычному штатному алгоритму, который просто не покрывал некоторых случаев (== содержал ошибку).

Там разве о вычислении индекса массива речь шла? Не считаю это возражением.

Но компактный Python с возможностью генерации нативного кода - вещь полезная в хозяйстве. От встроенных скриптовых движков до модулей ядра.

Тут даже соглашусь.

Ты зачем-то написал про верификацию, когда я говорил про проверку входных данных

Ты говорил о «проверках на этапе проектирования» - это близко именно верификации. Как ты собрался проверять на этапе проектирования входные данные?

Зачем? Ты сегодня тролль, что ли?

Нет. Но, сам понимаешь, я бы в любом случае это сказал.

Но в случае F-16 над Мертвым морем (я слышал эту байку именно про F-16), вычисление шло по обычному штатному алгоритму, который просто не покрывал некоторых случаев (== содержал ошибку).

Там разве о вычислении индекса массива речь шла?

Насколько я знаю, нет. Всё было результатом работы штатного алгоритма, реализованного без ошибок.

Ты по ним не ходишь.

по внеутренним ссылкам я хожу

Я так понимаю, скоро ты потребуешь ссылку на мое объяснение того, почему динамическая типизация должна покорить Вселенную. И не пойдешь по ней %)

ctrl-c + ctrl-v

Ещё раз: питон действительно содержит удобства, которые были бы полезны даже при программировании МК, суть в том, что все те же самые удобства есть и в С++, при этом С++ гораздо ближе к оборудованию и позволяет получать на выходе более быстрый код.

Возникает ес-ный вопрос: зачем делать компилятор питона под мк с 0-я, когда можно было бы просто присоединиться к команде разработчиков аналогичного компилятора под С++.

Нет, надо обязательно придумать собственный велосипед. Который не взлетит. Потому, что велосипед.

Ну и наконец. Если на десктопах питон в 40 раз медленнее чем С++, пруфы на debian benchmark, каким образом он вдруг начнёт быстро работать на МК?

Ты поразил меня в самое сердце.

Видно мозг поразили раньше.

Пройди уже по ссылке, эмулятор дебила. Там приведены минимальные требования к железу.

И че? Ну напиши на петоне под STM32F405 что-то скоростное (начнем с low/full-speed USB через GPIO) - я поржу, как это будет работать.

О, а расскажи мне, причем тут refcounting.

Вот прямо все побежали тебе всё рассказывать каждый раз, когда ты тупишь.

тиньке с 1кб озу

Охренеть, это где такие?

Там приведены минимальные требования к железу.

И че?

И не только они.

Ну напиши на петоне под STM32F405 что-то скоростное (начнем с low/full-speed USB через GPIO) - я поржу, как это будет работать.

*пожимая плечами* Чо ж вы такие тупые - спорите том, о чем не знаете ровно ничего. Дергание битов напиши хоть на асме. Встроенном.

а расскажи мне, причем тут refcounting.

Вот прямо все побежали тебе всё рассказывать

«Я знал, что ты скажешь это» (ц)

спорите том, о чем не знаете ровно ничего

Не знаю? Давай, заливай еще.

Дергание битов напиши хоть на асме. Встроенном.

Тоже так считаю. А питон зачем? Если человек пишет под МК не зная его особенностей, то кина не будет. Если человек пишет под МК зная его особенности, то он и так знает как минимум C. И нафиг ему тогда питон?