@cckyi_boxxx
Спасибо за ответ.
Я на уровне железок, мало что понимаю, но интересно :)
Полная версия: неведомый глюк в питоне
Я на уровне железок, мало что понимаю, но интересноя и сам к сожалению не могу назвать себя крутым спецом но если понадобиться помощь в этом плане обращайтесь - помогу
@cckyi_boxxx
Спасибо :)
Спасибо :)
@cckyi_boxxx
я находил транслятор питонокода в ассемблерный код под 8-и битную архитектуру камня
Что? Компилятор питона в нативный код?
что за слово нативный я не знаю но если под этим словом подразумевалось что конечный результат получаеться таким-же как от кода на С или С++ то да именно так , причем проект был найден на соурсфордже
по сути там особых сложностей возникать не должно , достаточно запилить для каждого МК свою отдельную либу в которой прописать адреса регистров , а затем самая сложная часть из-за которой я отказался от затеи сделать то-же самое под 8-и битные avr-ки это переработка логики написанной на питоне в код понятный камню , впринципе сделать возможно но пришлось-бы столько времени убить что оно того не стоит
как более упрощенный вариант можно расссматривать транслятор питонокода в код на асме и последующую компиляцию сгенеренного кода
ps: тот проект так и не ковырнул из-за неуважения пиков но по описанию и беглому просмотру сорцов (в коде увидел знакомые GP0 , GP1 , GP2 , TOCS , TOSE и прочие регистры ) все было однозначно понятно
по сути там особых сложностей возникать не должно , достаточно запилить для каждого МК свою отдельную либу в которой прописать адреса регистров , а затем самая сложная часть из-за которой я отказался от затеи сделать то-же самое под 8-и битные avr-ки это переработка логики написанной на питоне в код понятный камню , впринципе сделать возможно но пришлось-бы столько времени убить что оно того не стоит
как более упрощенный вариант можно расссматривать транслятор питонокода в код на асме и последующую компиляцию сгенеренного кода
ps: тот проект так и не ковырнул из-за неуважения пиков но по описанию и беглому просмотру сорцов (в коде увидел знакомые GP0 , GP1 , GP2 , TOCS , TOSE и прочие регистры ) все было однозначно понятно
@cckyi_boxxxссылку?
причем проект был найден на соурсфордже
@cckyi_boxxxТы действительно понимаешь о том что пишешь? Питон слишком динамичный язык и для него невозможно написать компилятор/транслятор в нативный/машинный/ассемблерный код. Можно только куски как это делает pypy.
по сути там особых сложностей возникать не должно , достаточно запилить для каждого МК свою отдельную либу в которой прописать адреса регистров , а затем самая сложная часть из-за которой я отказался от затеи сделать то-же самое под 8-и битные avr-ки это переработка логики написанной на питоне в код понятный камню , впринципе сделать возможно но пришлось-бы столько времени убить что оно того не стоит
sergeek , снова тратить 5 часов на поиски не возникает желания , но если память не изменяет то вот оно http://projectproto.blogspot.ru/2009/12/python-for-pic-mcus.html
понимаю , пусть нельзя будет юзать классы , всякие прикольные фичи типа вставления в строку переменной при помощи %s , %c , %i или лябмда выражения и оставить только самое важное - тогда такое вполне возможно хотя всеравно ужасно сложно
я так предполагаю что вы тоже имеете дело с МК раз так заинтересованы и я надеюсь что вы согласитесь что даже настолько порезанная версия питона была-бы в разы удобнее чем тот-же си
Ты действительно понимаешь о том что пишешь? Питон слишком динамичный язык и для него невозможно написать компилятор/транслятор в нативный/машинный/ассемблерный код. Можно только куски как это делает pypy.
понимаю , пусть нельзя будет юзать классы , всякие прикольные фичи типа вставления в строку переменной при помощи %s , %c , %i или лябмда выражения и оставить только самое важное - тогда такое вполне возможно хотя всеравно ужасно сложно
я так предполагаю что вы тоже имеете дело с МК раз так заинтересованы и я надеюсь что вы согласитесь что даже настолько порезанная версия питона была-бы в разы удобнее чем тот-же си
@cckyi_boxxx
порезанная версия питона была-бы в разы удобнее чем тот-же си
По моему опыту разработчики под контроллеры не то что питон не готовы использовать а даже c++ не используют, хотя для этого вообще ничего не надо изобретать или дописывать. Складывается впечатление что это проблема обучения а не техническая проблема написания компилятора или интерпретатора.
Для современных контроллеров, интерпретатор питона не проблема, и классы он потянет и лямбды. Питон хорош для интеграции различных готовых компонент и тут засада. Даже для С практически нет стандартизированных библиотек (одинаковых для avr, nxp, stm,…), полезных при программировании для контроллеров. Думаю как они появятся, появится и питон.
@cckyi_boxxxОно похоже еще в зачаточном состоянии. Там и не планируется поддержка всего языка, непонятно зачем оно нужно в таком виде.
вот оно http://projectproto.blogspot.ru/2009/12/python-for-pic-mcus.html
@cckyi_boxxxэто все как-раз таки можно транслировать, нельзя то, что может быть вычислено только в рантайме - setattr, globals, eval и т.п
понимаю , пусть нельзя будет юзать классы , всякие прикольные фичи типа вставления в строку переменной при помощи %s , %c , %i или лябмда выражения и оставить только самое важное - тогда такое вполне возможно хотя всеравно ужасно сложно
@cckyi_boxxxнет
я так предполагаю что вы тоже имеете дело с МК
@cckyi_boxxxнет
надеюсь что вы согласитесь что даже настолько порезанная версия питона была-бы в разы удобнее чем тот-же си
Зачем он такой нужен в этих МК? Он будет тормозной, без библиотек, без трейса исключений . Как с памятью будет работать - непонятно. Как там без типов жить можно будет? Если битность у чисел будет больше битности процессора - то все будет тормозить ведь. Если равна, то что делать если захочется больше? Все равно же придется их как то указывать. Я хоть и дилетант в низкоуровневом, но мне почему-то кажется это все жутко нерациональным.
из скриншота по вашей ссылке
def delay(): for i in xrange(0, 255): pass
По моему опыту разработчики под контроллеры не то что питон не готовы использовать а даже c++ не используют, хотя для этого вообще ничего не надо изобретать или дописывать. Складывается впечатление что это проблема обучения а не техническая проблема написания компилятора или интерпретатора.
используеться во всю , с++ реже , чаще всего пишут на с (сам пишу на нем), но во-первых если сравнить синтаксис этих 2-х языков с питоновским то от них блевануть хочеться , во вторых при максимальной оптимизации очень часто возникают глюки а без нее хавает много памяти (в 90% случаев лечиться кейвордом volatile) , что-же касаеться ассемблера то его мне учить лень , попросту atmel оптимизировала alu своих микроконтроллеров для работы с кодом на си , в чем именно заключаеться эта оптимизация сказать не могу , но ее результатом стало то что до нее код на асме давал прирост скорости порядка 30% по сравнению с си , на сегодняшний день этот прирост не более 5 - 10 %
насчет проблемы обучения вы правильно подметили я летом еще очень плохо знал си и часто косячил + жутко бесило что оно запускаеться с функции main() а не как питоноскрипт вот и начал поиски , на сегодняшний день уже нормально справляюсь с задачей но если когданибудь все-же появиться возможность делать все на питоне то я тут-же перейду
Для современных контроллеров, интерпретатор питона не проблемадля stm-ок и аналогичных по мощности да , а вот 8-битные avr хоть и могут работать с ним но как я писал выше падение скорости станет ощутимым и сделать можно будет уже далеко не все
Оно похоже еще в зачаточном состоянии. Там и не планируется поддержка всего языка, непонятно зачем оно нужно в таком виде.
я не предлагаю это использовать , оно только доказывает возможность написания такого софта , сам более подробно не ковырял так как я лучше сдохну чем что-то начну разрабатывать на пиках , я юзаю онли atmel avr
это все как-раз таки можно транслировать, нельзя то, что может быть вычислено только в рантайме - setattr, globals, eval и т.п
для МК это и не нужно , по сути мы имеем некие регистры которые управляют всем железом и в зависимости от обстоятельств нам надо записывать в них значения и чем более простой код это делает тем больше скорость выполнения программы вцелом
нет Зачем он такой нужен в этих МК? Он будет тормозной, без библиотек, без трейса исключений . Как с памятью будет работать - непонятно. Как там без типов жить можно будет? Если битность у чисел будет больше битности процессора - то все будет тормозить ведь. Если равна, то что делать если захочется больше? Все равно же придется их как то указывать.
Я хоть и дилетант в низкоуровневом, но мне почему-то кажется это все жутко нерациональным.
как я упоминал выше самые основные его плюсы относительно си это обалденный синтаксис + выполнение не с функции main() а как скрипта с самого начала , библиотеки-же которые вы используете для кодинга под камп там вобще не требуються , нужны свои для работы с прерываниями , таймерами , протоколами передачи (spi , usart … ) итд
есть конечно bascom avr , там пишут на бейсике но работать можно только под виндами а я линуксоид , в нем хоть синтаксис и говеннный зато выполненирпе программы идет аналогично питоновской
с типами думаю тоже можно что-то придумать пусть даже костыль но все-же
там разве не должно быть соотвествующих прерываний для нормально sleep? Это же ужас
понятно что нам показан быдлокод и все должно делаться более грамотно но этот пример не говорит что это невозможно сделать