Комментарии 84
Статья бы имела хоть какую-то ценность, хоть маломальскую, если бы автор писал на ассемблере, и отвязался от компилятора. А так, очередная поделка. Тут самое время пригласить olartamonov
Даже если на ассемблере… Можно оптимизировать даже программу в машинных кодах (сам, лично, делал чтение с дисковода на К580ВИ80 (радио 86 рк), не хватало чуть чуть, поэтому прога сама себя переписывала перед каждой операцией (так на пару тактов было быстрее). А с учётом всяких там STM32 на армовском ядре — я уже не смогу, компилятор умнее (
Не-не, не надо Олега, пока не начались очередные военные действия.
Я не хочу вас расстраивать, но asm под avr тоже компилируется. И отвязаться от компилятора не возможно, если конечно не писать .bin в ручную.
Не хочу тут переходить в наезды и спор. Но у меня только один случай был, когда старинная AVR Studio некорректно ассемблеровскую мнемонику перевела в машкоды. В остальное что ассемблируешь, то и дизассемблируешь. Что не скажешь о языках высокого уровня.
Проще говоря, ассемблер — это идентично машкодам, только в языке удобном человеку.
Проще говоря, ассемблер — это идентично машкодам, только в языке удобном человеку.
ассемблер — это идентично машкодамсначала так. потом хочется локальных меток и макровычислений. потом — полноценных макроподстановок/препроцессора… а там уже и до хотения ЯВУ недалеко.
ну, первые си-компилеры тоже делали «понятно что». более того, они часто делали не исполняемый модуль, и не объектник — а ассемблерный.
но оптимизирующие компиляторы — они позволяют работать быстрее.
а с учетом того, что «железо» нынче дешево — ассемблеры пора оставить профессионалам.
А можете откопать этот пример, я бы с удавольствием проверил это, на разных версиях тулчейна.
Можно быстрее. Запрещяете прерывания и пишите через всю память порт 0, порт 1. Счетчик команд циклический, а порт, если мне не изменяет память, по умолчанию — out. получаете меандр на половине тактовой частоты.
Часто «для переноса кода на другие платы» аппаратно-зависимые вещи выделяют в отдельные (условно — «низкоуровневые») блоки, которые правят под конкретное железо. А «логика» портируется без изменений.
Хотелось бы отделить мух от котлет. Для 99% типичных задач, которые решаются на Ардуино, нет абсолютно никакой разницы с какой скоростью работает digitalWrite. А для тех задач, где принципиальна скорость — используем соответствующие решения — ассемблерные вставки, прямое программирование портов, мощные контроллеры или вообще уходим от парадигмы Ардуино и используем «профессиональные» решения.
Не нужно создавать проблемы на ровном месте и противопоставлять Ардуино и «взрослые» решения.
Не нужно создавать проблемы на ровном месте и противопоставлять Ардуино и «взрослые» решения.
всё верно, если 99% задач — помигать светодиодом.
вентилятор, вентилятор в туалете забыли!!!
Если в туалете включён свет, и с мобильника по вайфаю пошёл трафик на хабр/реддит, то включаем вентилятор?
Вот он, умный дом.
Вот он, умный дом.
я пошел дальше :D
сделал на arduine geomagnetic magnetometer
github.com/IvanKor/geomagnetic-magnetometer
который круче (полоса пропускания шире более чем в три раза ) чем используется здесь
geodata.izmiran.ru
сделал на arduine geomagnetic magnetometer
github.com/IvanKor/geomagnetic-magnetometer
который круче (полоса пропускания шире более чем в три раза ) чем используется здесь
geodata.izmiran.ru
если нужна скорость — нужно не «ассемблерные вставки», а выкидывать ардуину…
Вот, вот, это статья как-раз и нацелена на то, чтобы никто не делал такое ошибочное суждение, ибо arduino это всего лишь uart загрузчик. Никто не просит использовать её IDE и тем более arduino core.
тогда от дуйни ничего и не остаётся. если выкинуть ядро — выкинешь и все наработки, всё сообщество. а в этом и есть вся ценность дуйни для начинающих. ну и сейчас, в 201х, использовать ассемблер. тем более, устаревшего железа… зачем? начинающему проще перелезть на нуклео, а грамотный и без дуйни справится
В целом, вы просто процитировали статью.
Совершенно верно! Каждый инструмент для своих задач. На ардуине быстро и легко создавать новые проекты. Под неё вон сколько библиотек есть. Я сам за вечер сделал с нуля термометр на балкон на базе датчика DS18B20 и матричного светодиодного индикатора. При этом с ардуино ранее вообще не работал!
Но в то же время в какое-то серийное изделие на мой взгляд ардуина не особо вписывается.
Но в то же время в какое-то серийное изделие на мой взгляд ардуина не особо вписывается.
ровно так же вы могли сделать это же на STM по статье olartamonov
Ну на STM, PIC, AVR я действительно мог бы и сам сделать, потому что работаю с ними уже давно. Просто однажды мне стало интересно поиграться с ардуиной. Оказалось, что порог вхождения там очень низкий, что меня весьма порадовало. Для своего сегмента это просто отличное решение!
для mbed порог вхождения не выше (ну или не сильно выше).
Mbed не набор либ, а операционная система. Сказать что и как она делает почти не реально. Поэтому все используют free rtos. Вспомнил вот что по этому поводу: habr.com/post/387299
на STM в среде arduino термометр на базе датчика DS18B20
github.com/IvanKor/DS18B20_USART_DMA_STM32
без «ногодрыга» в режиме реалтайм за пару вечеров :D
github.com/IvanKor/DS18B20_USART_DMA_STM32
без «ногодрыга» в режиме реалтайм за пару вечеров :D
Согласен с Вами. Самый простой и быстрый путь проверить например какой-то новый экранчик, с которым ещё не работал — это Ардуина. У неё есть библиотеки почти под все устройства.
Проблема не в качестве решения, проблема в том что 90% ардуинщиков не понимают что они пишут. Статья для того чтобы показать что код собирается не магией, а авровским тулчейном.
Максимальная частота анализатора 24 MHz следовательно её необходимо уравнять с частотой контроллера — выставить 16MHz
Но зачем? Частота анализатора должна быть выше чем частота сигнала, что бы снять его точно, нет?
Тут вот какое дело, если частота будет 24 Мгц, то мы не сможем нормально померить время. Полученные результаты просто не будут пропорциональны времени такта. Пример: минимальное время полученное в статье соответствует времени между 2мя измерениями анализатора и это 62,5 нс, если мы поставим 24 Мгц то анализатор успеет сделать 2 измерения и время будет 83,3 нс, что не соответствует действительности. Так что нет, частота анализатора должна быть пропорциональна частоте контроллера для получения точных результатов.
Да и если нам очень нужно генерировать ровный меандр, можно взять stm32 с dma или внешнюю микросхему таймера вроде NE555.Скажите, а вы слышали когда-нибудь о таймерах? Говорят, они даже в ардуине есть.
Данная статья полезна для понимания устройства работы mega328p и arduino в целом.Хм, не уверен.
Слышал, про них даже в моей статье можно прочитать, речь о том чтобы генерация меандра не занимала тактов контроллера.
Но ведь генерация меандра таймером не занимает тактов контроллера.
Если только на этом таймере висит дма, а так нужен обработчик.
Если только на этом таймере висит дма, а так нужен обработчик.Для генерации меандра таймеру не нужен ни DMA, ни обработчик.
Вы правы, как оказалось, я забыл про режир работы тактового генератора, да и если с шимом поколдовать тоже можно что-то подобное сделать. Выдержка из даташита:
Channel Counter
• Clear Timer on Compare Match (Auto Reload)
• Glitch-free, Phase Correct Pulse-Width Modulator (PWM)
• Frequency Generator
• 10-bit Clock Prescaler
• Overflow and Compare Match Interrupt Sources (TOV2, OCF2A, and OCF2B)
• Allows Clocking from External 32 kHz Watch Crystal Independent of the I/O Clock
Channel Counter
• Clear Timer on Compare Match (Auto Reload)
• Glitch-free, Phase Correct Pulse-Width Modulator (PWM)
• Frequency Generator
• 10-bit Clock Prescaler
• Overflow and Compare Match Interrupt Sources (TOV2, OCF2A, and OCF2B)
• Allows Clocking from External 32 kHz Watch Crystal Independent of the I/O Clock
Мне Arduino никогда не казалась медленной. 16-20 MIPS — это очень много, '16 MIPS должно хватить всем' и этого достаточно даже для генерации монохромного видеосигнала чисто кодом. Разумеется, где критична скорость, не должно быть никаких высокоуровневых библиотек и скрытых прерываний. Обычно хватает прямой работы с портами на C, но Arduino IDE позволяет и ассемблерные вставки (с диким синтаксисом), если что. И конечно таймеры.
В прошлом году ради интереса делал перенос на Arduino пяти 1-битных синтезаторов звука с ZX Spectrum, в которых довольно хитроумный, максимально оптимизированный код на Z80. Оригинальные алгоритмы ложились на новую платформу довольно занимательным образом, на чистом C, без вставок ассемблера. Наиболее интересный пример: randomflux.info/1bit/viewtopic.php?id=127
В прошлом году ради интереса делал перенос на Arduino пяти 1-битных синтезаторов звука с ZX Spectrum, в которых довольно хитроумный, максимально оптимизированный код на Z80. Оригинальные алгоритмы ложились на новую платформу довольно занимательным образом, на чистом C, без вставок ассемблера. Наиболее интересный пример: randomflux.info/1bit/viewtopic.php?id=127
Очень полезная статья. По-моему, для новичков очень важно знать, что высокоуровневый код никогда не даст такой скорости и точности, как низкоуровневый и масштабы этого явления. От себя добавлю, что примерно то же самое происходит и с памятью кода. Когда я решил сделать один из своих проектов не на С, как обычно, а на ардуиновском диалекте, для меня было большой неожиданностью, что ATMega2560 закончилась буквально на 400 строке. Насколько я понимаю, особенно прожорлива местная объектная модель.
Хочу заметить, что практическая полезность определяется не абстрактными «скоростью и точностью» (которые нужны только на специфических задачах), а решением насущных проблем, с которыми Ардуино справляется на ура (и тут её популярность говорит сама за себя).
Что касается памяти, то её тоже «нужно уметь готовить» — на Меге в Ардуино нет никаких проблем с объёмными (как по оперативной, так и по флеш памяти) проектами. Чужие библиотеки действительно могут очень вольно обращаться с памятью, но это скорее проблема не объектной модели программирования, а уровня знаний и прилежания самого автора библиотеки.
Что касается памяти, то её тоже «нужно уметь готовить» — на Меге в Ардуино нет никаких проблем с объёмными (как по оперативной, так и по флеш памяти) проектами. Чужие библиотеки действительно могут очень вольно обращаться с памятью, но это скорее проблема не объектной модели программирования, а уровня знаний и прилежания самого автора библиотеки.
все нормальные люди знают, что низкоуровневый код [для всех систем] работает быстрее, но пишется дольше и сложнее. и наоборот. и что ЯВУ разменивают скорость разработки на скорость работы. людям, которым для осознания этого требуется статья — она уже не поможет.
Кажется можно сделать быстрее если вместо присвоения использовать xor на соответствующем бите порта B. При этом в идеале загрузить битовую маску в регистр нужно 1 раз, до начала цикла.
Спасибо за статью и за упоминание.
С первой публикацией на хабре!
Все конечно хорошо, но саму платформу arduino(как и любых других МК) рассматриваю как утилитарную вещь для решения определенных прикладных задач, пускай уже и тысячу раз реализованных.
Поэтому за парктроник, пускай и на столе работающий — проголосовал, а за сферический blink в вакууме — увы — нет.
Вот если с помощью ардуино квадрокоптеры сбивать, да хоть пуляя микроконтроллерами из рогатки — это был-бы FUN ;-)
сын делал в 8 классе на конкурс по робототехнике стрелялку по вертолету. как раз на ардуине. сам спаял ее из фридуиновского набора.
точность невелика — но довольно эффектно. но как раз перед демонстрацией сгорела катушка соленоида «электоспуска». было обидно.
точность невелика — но довольно эффектно. но как раз перед демонстрацией сгорела катушка соленоида «электоспуска». было обидно.
Вот если с помощью ардуино квадрокоптеры сбивать
Думал над концепцией такого обвеса для автоматического оружия, которое позволит определять лазерным дальномером дистанцию до дрона, и имея прошитые данные по баллистике применяемого боеприпаса, а также данные с сенсоров температуры, давления и силы ветра (опционально) находить и показывать бойцу, в какое положение необходимо поставить оружие для максимальной вероятности поражения коптера. Такой себе баллистический компьютер для бедных.
Добавить сервомоторы, турель… Человек тут лишний, пулять в зенит из ручного оружия очень неудобно, а роботу все равно.
Ну, так-то на коротком расстоянии можно и утиной дробью без проблем снять коптер.
А вот буржуи придумали патрон — из того-же гладкоствола до 1км обещают.
видел подобное 4 года назад здесь
Простите, но то что Wiring Ардуиновский медленный — это уже даже баян не новость. Там ведь куча проверок с защитой от дурака новичка, которые тратят на себя драгоценные такты. Хочется скорости — Wiring в мусорку и вперёд. Он ведь именно на простоту рассчитан.
Не понимаю, почему нельзя
PORTA=value завернуть в макрос, который под каждую платформу будет правильно реализован?Кроме портов, в нутре контроллера есть еще много платформозависимого. Заворачивать все в правильно портируемые макросы… В результате будет еще одно arduino, только на макросах.
Долго, дорого, лань, почти в каждом avr разные названия регистров, а если присмотрется то ардуинок в сотни раз меньше чем мег.
Я вот честно вообще не понимаю таких заявлений, что дуина медленная. Там те же самые AVR и т.п. и естественно, если хотите выжать максимум, то все упирается в: тактирующий резонатор — это раз, в необходимое количество тактов на команду — это два и минимум мусора в коде — три. Берете АСМ и выжимаете максимум. Просто надо понимать, что есть задачи которые решаются на 51-й серии, а есть требующие серьезных ARM.
З.ы. да я тот динозавр 25 Голиков пишушиший на АСМ(
З.ы. да я тот динозавр 25 Голиков пишушиший на АСМ(
25 годиков пишущий на АСМ* (верните смартфоны с физической клавиатурой)
а смысл этого извращения? «C» с включенной оптимизацией все равно напишет лучше в том же ASM :D
Ну насчёт лучше, это скорее всего нет, а вот то, что 90+% кода совпадет по итогу — реально. Просто мне, как инженеру АСМ ближе. Естественно речь не об ARM, там С и только местами АСМ.
На Arduino в time critical задачах компилятор лучше не напишет, 100%. Хотя я регулярно встречаю в среде Arduino'щиков людей, без тени сомнения утверждающих, что напишет, но без примеров. Видимо была какая-то 'авторитетная' статья.
я вообще то начинал в 1975 году с фортрана, и с тех пор непрерывно пишу на всяких всячинах, и проверял многократно самолично. Что может быть проще, получаеш asm с С и пытаешся его улучшить. На DE0-Nano-SoC последний раз проверял.
В этом году и на arduino попробывал, понравилось, очень удобно без напряга извилин, правда все же свалил на на stm32duino, там уже привычный бардак и мрак :D
В этом году и на arduino попробывал, понравилось, очень удобно без напряга извилин, правда все же свалил на на stm32duino, там уже привычный бардак и мрак :D
Не надо пытаться улучшить ассемблерный выхлоп компилятора. Разумеется, это тупиковый путь. Надо писать решение на ассемблере изначально, тогда будет заметная выгода.
При выигрыше в производительности кода в 10%, проигрываем в производительности программиста в 1000% — отличный результат.
Это совершенно случайные цифры, взятые с неизвестно какого потолка, с единственной целью доказать свою (оп)позицию. Они не имеют ничего общего с действительностью. Обратите внимание, это свойственно всей аргументации 'компилятор пишет лучше программиста'.
Переписать критичный ко времени участок кода на ассемблер (обычно внутренний цикл в тяжёлых вычислениях или небольшой обработчик прерывания) — недолго и ничем не сложнее написания реализации на C. Выигрыш измеряется не в процентах, а в решении задачи. Код не успевает — задача не решена (надо менять платформу и т.д.). Код успевает — задача решена. Решение задачи вполне стоит лишнего часа-двух работы.
Переписать критичный ко времени участок кода на ассемблер (обычно внутренний цикл в тяжёлых вычислениях или небольшой обработчик прерывания) — недолго и ничем не сложнее написания реализации на C. Выигрыш измеряется не в процентах, а в решении задачи. Код не успевает — задача не решена (надо менять платформу и т.д.). Код успевает — задача решена. Решение задачи вполне стоит лишнего часа-двух работы.
Эх, на ходу меняем мнение.
Надо писать решение на ассемблере изначальноРечь о том что писать весь код — глупая затея. А если писать только, для улечшения производительности в отдельных местах — это и есть
улучшить ассемблерный выхлоп компилятора.Если выбирать для решения большой задачи асм, то мы лишаем себя всех луществующих сишных либ. Если задача помигать светодиодом то разницы нет, а если нужно много сенсоров + обработка информации + цветной дисплей к этому всему, не думаю что это пару часов.
Я полагаю, что тут собрались опытные люди, понимающие, что в контексте time critical 'решение' — это именно time critical часть, а не весь проект. Очевидно же, что это не имеет никакого смысла, писать некритичный код вручную.
Я также полагаю, что это очевидно для опытных embedded программистов — ничего общего между написанием (критичного ко времени исполнения фрагмента!) кода на ассемблере и оптимизацией ассемблерного выхода компилятора ЯВУ нет. Компилятор понятия не имеет, какая задача решается, он предлагает просто рабочее решение в рамках формальной логики, и потом оптимизатор его оптимизирует на микроуровне. Но это решение изначально неоптимально. Когда человек делает то же самое на ассемблере, он знает, какая задача решается, где и какие углы можно срезать, и какие параметры в решении ему важнее.
Я также полагаю, что это очевидно для опытных embedded программистов — ничего общего между написанием (критичного ко времени исполнения фрагмента!) кода на ассемблере и оптимизацией ассемблерного выхода компилятора ЯВУ нет. Компилятор понятия не имеет, какая задача решается, он предлагает просто рабочее решение в рамках формальной логики, и потом оптимизатор его оптимизирует на микроуровне. Но это решение изначально неоптимально. Когда человек делает то же самое на ассемблере, он знает, какая задача решается, где и какие углы можно срезать, и какие параметры в решении ему важнее.
Дуйня-это не только AVR. Это и ядро, и IDE, и библиотеки, и сообщество — именно то, что обеспечивает начинающим лёгкий старт. Вы предлагаете оставить от дуйни лишь формфактор.
Речь-то немного не про то. Просто заявление «дуина медленная» не совсем корректно, ибо медленным является именно код с использованием дуиновских средств разработки. И это нужно держать в уме. Ну и если не хочется отказываться от удобства дуины — паяльник в помощь =)
да как раз про то. дуина — компромисс, как и любая техническая система. в данном случае сильной стороной является простота и низкий порох вхождения. а платой за это — некотрый объем ядра и некоторые тормоза.
для начинающих дуйня — великолепный инструмент (хотя уже устаревший). если ее начинает не хватать — значит, ее пора выкидывать — это будет быстрее и проще, чем переписывать на ассемблере, и т.п.
путей выкидывания много — от применения вместо «классической на AVR» на STM с той же средой «дуино» (если человек не планирует заниматься разработкой более-менее профессионально или часто), до нормального проектирования нормальных устройств (если он планирует двигаться в сторону профессионализма)
для начинающих дуйня — великолепный инструмент (хотя уже устаревший). если ее начинает не хватать — значит, ее пора выкидывать — это будет быстрее и проще, чем переписывать на ассемблере, и т.п.
путей выкидывания много — от применения вместо «классической на AVR» на STM с той же средой «дуино» (если человек не планирует заниматься разработкой более-менее профессионально или часто), до нормального проектирования нормальных устройств (если он планирует двигаться в сторону профессионализма)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Arduino такая медленная и что с этим можно сделать