Комментарии 35
Полностью поддерживая вывод поста, тем не менее хотел бы отметить, что нет языка Ардуино, а есть:
1) Самый обычный gcc компилятор.
2) Набор библиотек для работы с аппаратурой (DigitalWrite и т.д.).
3) Препроцессор, снимающий с программиста часть механической работы, вроде объявления main, написания #include и т.п.
1) Самый обычный gcc компилятор.
2) Набор библиотек для работы с аппаратурой (DigitalWrite и т.д.).
3) Препроцессор, снимающий с программиста часть механической работы, вроде объявления main, написания #include и т.п.
После этого перестал читать дальше. Автор хотя бы погуглил бы стоимость процессоров и час работы программиста, способного написать серьёзный код на ассемблере, плюс не стоит забывать о поддержке кода и расширяемости.
Поэтому разработчики серийных продуктов, как правило, пишут коды на низкоуровневых языках. С тем, чтобы разместить программу в контроллере с меньшей памятью. Тут работают законы экономики — контроллер с меньшими ресурсами стоит дешевле, следовательно себестоимость изделия становится ниже.
Поэтому разработчики серийных продуктов, как правило, пишут коды на низкоуровневых языках. С тем, чтобы разместить программу в контроллере с меньшей памятью. Тут работают законы экономики — контроллер с меньшими ресурсами стоит дешевле, следовательно себестоимость изделия становится ниже.
Не могу согласиться. Оплата работы программиста — ничто по сравнению с дополнительными потерями/прибылью при многотысячном… многомиллионном тираже товара.
если планируется многомиллионный тираж достаточно сложного устройства — для софта нужен подход, который за вменяемое время для ассемблера не обеспечить.
накладные расходы у Си немногим выше, чем у ассемблера — но пишется/тестируется гораздо быстрее, удобнее…
накладные расходы у Си немногим выше, чем у ассемблера — но пишется/тестируется гораздо быстрее, удобнее…
если планируется многомиллионный тираж достаточно сложного устройства — для софта нужен подход, который за вменяемое время для ассемблера не обеспечить.
накладные расходы у Си немногим выше, чем у ассемблера — но пишется/тестируется гораздо быстрее, удобнее…
Согласен! Но повторю ваши слова: «если планируется многомиллионный тираж достаточно сложного устройства ...». Вы правы — в таких случаях и подходы другие.
Если планируется многомиллионный тираж простого устройства — там требования к софту ниже, и его проще написать на си. Если планируется небольшой тираж сложного устройства — требования к софту высоки, и стоимость работ программиста высока — дешевле и проще написать на Си. И если планируется небольшой тираж простого устройства — предыдущее начинает работать еще сильнее, дешевле и проще написать на си. Круг применения ассемблера сейчас стал очень узким. уникальные проекты (и то, чаще ограничиваются ассемблерными вставками), и поделки гиков (котрые уникальны, «ручная работа» и все такое — но почти всегда не «промышленное программирование»)
Сомнительный довод.
В большом сложном embedded проекте ассемблер не даст выигрыша, тк тяжело писать хороший большой, структурированный код на ASM. Еще надо искать команду любителей писать на ASM или человека на замену в случае увольнения.
Код для большинства серийного embedded оборудования пишется на Си или даже на С++. Оптимизатор делает свое дело прекрасно, иногда оптимизируя некоторые места так как человек бы в жизни не догодался бы.
В большом сложном embedded проекте ассемблер не даст выигрыша, тк тяжело писать хороший большой, структурированный код на ASM. Еще надо искать команду любителей писать на ASM или человека на замену в случае увольнения.
Код для большинства серийного embedded оборудования пишется на Си или даже на С++. Оптимизатор делает свое дело прекрасно, иногда оптимизируя некоторые места так как человек бы в жизни не догодался бы.
Какой большой структурированный код нужен для управления, допустим, кофеваркой? Кроме того, в посте я категорично нигде не утверждаю — Ассемблер и никаких вариантов. Понятие «оптимизация» у меня тоже встречается.
Зависит от кофеварки, полагаю если совсем тупая и простая логика ее можно сделать и без всяких МК. А так есть кофеварки с Bluetooth и кучей режимов, еще к тому же желательно чтобы используя одну кодовую базу можно было собирать прошивку для разных моделей кофеварок.
Еще чипы нужно покупать с расчетом на то чтобы их не перестали производить(а такое бывает), а если перестанут производить то переходить на другую серию МК или даже производителя. В этом случае хорошая кодовая база на Си спасет ситуацию, кодовая база на ASM сделает очень много боли.
Также желательно чтобы проект можно было чекнуть статическим анализатором и покрыть тестами(что в embedded к сожалению не очень принято) — все это лучше делать на Си.
Для расширения вашего кругозора ASM в принципе используют для совсем простых китайских игрушек, поддержку которых никто не планирует, там чипы стоят меньше цента, также для каких нибудь быстрых числодробилок на DSP, но это совсем другая история.
Еще чипы нужно покупать с расчетом на то чтобы их не перестали производить(а такое бывает), а если перестанут производить то переходить на другую серию МК или даже производителя. В этом случае хорошая кодовая база на Си спасет ситуацию, кодовая база на ASM сделает очень много боли.
Также желательно чтобы проект можно было чекнуть статическим анализатором и покрыть тестами(что в embedded к сожалению не очень принято) — все это лучше делать на Си.
Для расширения вашего кругозора ASM в принципе используют для совсем простых китайских игрушек, поддержку которых никто не планирует, там чипы стоят меньше цента, также для каких нибудь быстрых числодробилок на DSP, но это совсем другая история.
Зависит от кофеварки, полагаю если совсем тупая и простая логика ее можно сделать и без всяких МК.
Побродите, пожалуйста, по форумам ремонтников бытовой техники. Я к тому же, в свою кофеварку заглядывал. Предположения и реалии — разные вещи.
Я занимаюсь разработкой в embedded уже много лет, мне лень вступать в срач на тему как должна выглядеть кофеварка. Если анализировать работу самых простых образцов которые я видел, то эту логику можно реализовать на дискретной логике без возни с ASM.
Дальше я вам привел примеры того какие требования предъявляются к кодовой базе в больших серийных продуктах и почему использование ASM — не лучшая идея.
Дальше я вам привел примеры того какие требования предъявляются к кодовой базе в больших серийных продуктах и почему использование ASM — не лучшая идея.
Я тоже имею опыт проектирования на ТТЛ-, МОП-структурах, который исчисляется десятилетиями. Но однозначно утверждать, что построить управление простого бытового прибора на дискретных элементах дешевле, чем на одном контроллере стоимостью десяток-другой центов — не стану. Впрочем, жизнь подтверждает — никто этого и не делает. Заранее благодарю за понимание.
а я не понимаю, за что минусы. Да, это и ёжику понятно, что машинный код жрёт меньше ресурсов.Да, это легко гуглится. Но автор провел работу, сравнительные анализы, привел конкретные примеры, написал статью.
Дико благодарен!
За то что автор написал сомнительную статью, запутался в терминологии с самого начала — ставя в один ряд Arduino, С, ASM и выдал пару сомнительных заключений далее по тексту.
Если автор хочет писать такие статьи — то надо брать gcc и играться с оптимизацией непосредственно в нем, тогда будет интересно и получит свои плюсы.
Если автор хочет писать такие статьи — то надо брать gcc и играться с оптимизацией непосредственно в нем, тогда будет интересно и получит свои плюсы.
Статью ради статьи, при этом даже не потрудился разобраться с предметной областью. Не понимает как работает СИ и то что он обзывает ардуиной. Да и постановка вопроса не совсем корректна. Я ожидал что внутри автор напишет про гениальность ардуинских библиотек, сосем не в плане их толщины и тормознутости, ибо сие не самые большие грехи, а то и вовсе фичи, если вы захотите собрать проект под что-нибудь отличное от avr.
Но, нет, автор кидает в воду кирпичи, в надежде на прямоугольные круги, и делает вывод что они всё-таки круглые :-)
А сравнивать СИ с ассемблером для МК лучше бы оставили тем, кто реально в теме. Если кратенько то ассемблер используется когда для этого есть причины, в большинстве случаев компиляторы СИ для МК совсем не плохи, и никак не исключают использования ассемблера по мере необходимости. Но если какой-то гений, на подключает туда стандартных библиотек ради привычны по десктопу функций, то это будет ещё та абдурина :-) но это никак не недостаток языка.
Раз уж по размеру откомпилированной программы сравнивать, то нужно сравнивать при различных режимах оптимизации компилирования. На сколько помнится, в ArduinoIDE по умолчанию не самый лучший режим стоит.
Здесь так много ошибок и бреда, что пришлось бы разбирать каждую строку. Поэтому вместо разбора каждой ошибки опишу свои мысли по данному вопросу.
1. Языки высокого уровня для МК (Rust, C++, C) часто компилируются в один и тот же ассемблер при решении одной задачи. Как минимум, для С и С++ это на хабре было описано.
2. Выбор языка и железа обусловлен стоящей задачей. Для единичной поделки будет разумно взять Распберри/Джетсон и накидать скрипт на питоне за полчаса. Для миллиона тостеров, где каждая сотая цента имеет значение, будет выгодней тупейший микроконтроллер и полкило ассемблера, а то и ASIC.
3. digitalWrite будет работать на любом МК, куда портирована Ардуино. DDRB привзяывает вас не только к AVR, но и конкретному чипу, т.к. для Arduino Mega, например, порт и пин для 10-го вывода могут уже отличаться от Mini. Это опять выбор — компактность+скорость или портируемость. Крайне неверно считать, что одно лучше другого. Это разные задачи, требующие разных решений.
В итоге, для каждой конкретной задачи нужно понять на каком языке её выгоднее решать и насколько сильно нужно абстрагироваться от железа.
1. Языки высокого уровня для МК (Rust, C++, C) часто компилируются в один и тот же ассемблер при решении одной задачи. Как минимум, для С и С++ это на хабре было описано.
2. Выбор языка и железа обусловлен стоящей задачей. Для единичной поделки будет разумно взять Распберри/Джетсон и накидать скрипт на питоне за полчаса. Для миллиона тостеров, где каждая сотая цента имеет значение, будет выгодней тупейший микроконтроллер и полкило ассемблера, а то и ASIC.
3. digitalWrite будет работать на любом МК, куда портирована Ардуино. DDRB привзяывает вас не только к AVR, но и конкретному чипу, т.к. для Arduino Mega, например, порт и пин для 10-го вывода могут уже отличаться от Mini. Это опять выбор — компактность+скорость или портируемость. Крайне неверно считать, что одно лучше другого. Это разные задачи, требующие разных решений.
В итоге, для каждой конкретной задачи нужно понять на каком языке её выгоднее решать и насколько сильно нужно абстрагироваться от железа.
3. digitalWrite будет работать на любом МК, куда портирована Ардуино.грамотными макросами эта задача решается куда лучше.
Впрочем, в реальности кроссплатформенный ногодрыг используется довольно редко. Чаще на соответствующих ногах висит какая-то периферия, с которой AVR работает через тот же ногодрыг, а вот ARM может себе позволить использовать встроенный модуль. Тут оптимизация digitlWrite или даже макросов особой выгоды не даст — лучше написать платформо-зависимую библиотеку.
Если есть возможность загрузить в контроллер код на выбор – ArduinoIDE, C, Assembler, с одинаковым временем «сна», то в каком из трех предложенных вариантов батарейки сядут раньше (позже)?Вот тут хорошо бы провести сравнение. Код на Си и Ардуино у вас есть, замерьте время его работы и посчитайте во сколько раз быстрее батарейки сядут. Мало ли, вдруг они оба 90% времени тупо ждут ответа от датчика, так что разницы и незаметно будет.
хотел бы отметить, что нет языка Ардуино, а есть
Ну надо же как-то отличать ардуинский стиль программирования от обычного. Автор назвал разными языками, не вижу ничего плохого.
Разве что стоило это явно отметить в тексте мол «да, я знаю что „язык“ Ардуино это всего лишь avr-g++, густо обмазанный специализированными библиотеками и костылями, но чтобы отличать от программирования на Си в рамках статьи буду называть его „языком Ардуино“».
Мало ли, вдруг они оба 90% времени тупо ждут ответа от датчика, так что разницы и незаметно будет.
Все это я давно прошел. Посмотрите, пожалуйста, тут. По ключевым словам «Операционное время функции измерений параметров воздуха, состояния батареек» найдите таблицу. В ней приведено время выполнения операций и потребление. Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту.
Разве что стоило это явно отметить в тексте мол «да, я знаю что „язык“ Ардуино это всего лишь avr-g++, густо обмазанный специализированными библиотеками и костылями, но чтобы отличать от программирования на Си в рамках статьи буду называть его „языком Ардуино“».
Спасибо за замечание, учту. Я не подозревал, что настолько болезненно воспримется мой сленг. Конечно, нет никакого языка Ардуино!
Все это я давно прошел. Посмотрите, пожалуйста, тут.Вы пишете, что Си дает выигрыш перед Ардуиной. Стоило бы привести циферку насколько этот выигрыш велик. Стоит ли вообще обращать на него внимание.
Ну и когда я для себя считал потребление разных модулей, свел в табличку среднее потребление с учетом соотношения сна и рабочего режима. Ну там, eink: 10 мА*1.2с, T=1мин => ~0.2 мА
Так и у вас: Ардуино: 10 мА*0,39с, T=1мин + 1 мА*(T-0.39c) => 1.06 мА, Си: 10 мА*0,3с, T=1мин + 0.01 мА*(T-0.3c) => 0.06 мА. Разницу потребления в режиме сна я принял исходя из схемотехники: в платке Ардуины она так себе, если же делать под себя, можно выжать гораздо больше. Ну и в любом случае это всего лишь пример
Так и у вас: Ардуино:...
Тут в метеостанции у меня не плата Ардуино, а «голая» Atmega328P и кварц. Прототип делал для себя и добился поставленной цели: потребление устройства на уровне автономных промышленных продуктов.
Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту.Здесь Вы несколько не правы — если контроллер пробуждается из сна по сторожевому таймеру, то максимальная его задержка у Atmega328 8 секунд. То есть измерение то Вы проводите раз в минуту, а пробуждаете контроллер гораздо чаще. «Холостые» пробуждения, в принципе, требуют всего несколько тактов процессора на «перезарядку» сторожка и много энергии не сожрут, но тут «внезапно» всплывает то, что для тактирования Вы зачем-то используете кварц, а время его раскачки много больше, чем встроенного RC генератора (и много больше, чем время исполнения этих нескольких инструкций).
Я все это написал к тому, что если уж говорить о минимизации потребления, то, помимо «вылавливания блох» между C и ассемблером, нужно так же грамотно подходить и к общему проектированию системы.
Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту
… но тут «внезапно» всплывает то, что для тактирования Вы зачем-то используете кварц, а время его раскачки много больше, чем встроенного RC генератора (и много больше, чем время исполнения этих нескольких инструкций).
Вы вырвали фразу мою фразу из контекста. «Внезапно» всплывает — это для Вас. Советую посмотреть мой пост хотя бы по диагонали. Там встроенный RC-генератор. Методика измерений характеристик тщательно продумана — для этого разработаны несколько вспомогательных скетчей и т.п. Никаких замечаний по поводу методики и результатов измерений не было.
Я все это написал к тому, что если уж говорить о минимизации потребления, то, помимо «вылавливания блох» между C и ассемблером, нужно так же грамотно подходить и к общему проектированию системы.
«Блохи» я не ловлю, поскольку Ассемблера не знаю, а анализирую и сопоставляю то, что уже сделано, иногда компилируя коды составленные другими. Говорю о тенденциях. Грамотность проектирования системы (метеостанции) подтверждена «железом» и полученными техническими характеристиками. Недостатки проекта тоже знаю и их не замалчиваю.
Вы вырвали фразу мою фразу из контекста. «Внезапно» всплывает — это для Вас. Советую посмотреть мой пост хотя бы по диагонали. Там встроенный RC-генератор.Смотрю Ваш пост по ссылке, и вижу там схему (даже две) с кварцевым резонатором
Assembler не освоить за несколько месяцев.
Это смотря какой. 8051 — осваивается на раз-два, AVR — не намного сложнее. Самая жесть приходит на современных МК с богатой периферией и кучей памяти, например тот же stm32.
Да и осваивать не имеет особого смыла — коды на С можно оптимизировать иногда до размеров не намного больше, чем в Ассемблере.
Опять зависит от камня. Где то на си особо не разгуляться. Особенно если это какая нибудь древность с малым объемом ресурсов (8-ми битный AVR уже отношу к древности).
Так что я бы вывод перефразировал — кодить на асм смысла нет, если разработка ведется на современных МК.
Но при этом понимать как работает МК без хотя бы поверхностного представления об асме — затруднительно, поэтому из академического интереса изучить асм как минимум полезно.
Опять зависит от камня. Где то на си особо не разгуляться. Особенно если это какая нибудь древность с малым объемом ресурсов (8-ми битный AVR уже отношу к древности).Судя по упоминанию выше 8051, Вы его имели ввиду? Если да, то это было справедливо до появления компилятора C от Keil. До этого C для 8051 был действительно игрушкой, поскольку существующие компиляторы (Intel, Avoset(за правильность написания за давностью лет не ручаюсь) и т.д.) были классическими древними C компиляторами, которые все параметры функций и все локальные переменные размещали в стеке, которого в 8051 кот наплакал с его 128 байтами RAM на все про все. А вот с Keil-ом уже можно было писать на C реальные проекты. В начале 90-х, после ассемблера с его постоянной головной болью, это был просто праздник, который, похоже, запомнился на всю жизнь.
Так что я бы вывод перефразировал — кодить на асм смысла нет, если разработка ведется на современных МК.
Но при этом понимать как работает МК без хотя бы поверхностного представления об асме — затруднительно, поэтому из академического интереса изучить асм как минимум полезно.
Логично. Свой вывод уточнил.
FGV, cпасибо!
Спасибо за упоминание
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На распутье — Ардуино, Cи или Ассемблер?