если из любви к искусству - то ассемблер

если быстро наговнокодить, х*як-х*як и в продакшен, то С

если хорошо знаешь целевой ASM - конечно пиши на нём, в чём проблема?

зы. ни разу кстати не слышал эквивалента «быдлокод» в отношении asm. то-ли изрыгатели неосилили, то ли по смыслу не подходит :-)

зы. ни разу кстати не слышал эквивалента «быдлокод» в отношении asm.

mov ax, 0

ни разу кстати не слышал эквивалента «быдлокод» в отношении asm. то-ли изрыгатели неосилили, то ли по смыслу не подходит :-)

Пример: для выравнивании количества тактов в 2-х ветвях программы жёсткого реального времени я иногда использовал пакеты [NOP, NOP, ..., NOP] — задержка просто считается «на пальцах» и думать «не нужно» © :)

где я могу хранить переменную в отдельном регистре под нее, avr-gcc предпочитает хранить ее в памяти

Ключевое слово register? Ну или патчить GCC, чтобы он лучше дружил с avr. А то под те же итаниумы пару лет назад у GCC были серьёзные проблемы с разворачиванием циклов.

быстро наговнокодить, х*як-х*як

и не влезло в память.

покупаем более мощный контроллер )

Си конечно, если делом заниматься, а не для искусства.

Думать где хранить переменные можно на мелких проектах, на реальных задачах крыша поедет быстрее, особенно если на пол пути придется поменять процессор.

Для ARM GCC генерит нормальный код и ситуация постоянно улучшается. Для AVR GCC генерит что генерит и все только хуже становится с новыми версиями. Но смысла возиться с AVR особого нет.

Но смысла возиться с AVR особого нет.

а не ты вроде в Atmel работаешь?

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

Ассемблерные вставочки могут помочь. Это компромисс. Да и на Си по-разному писать можно. Чего там такого избыточного, чтоб не влезло ?

Да, и? Я что должен везде пихать Atmel и AVR, даже если в этом нет смысла?

У Atmel-а полно хороших МК на ARM и все идет к тому, что их будет больше и больше. Все хотят ARM и никто не хочет vendor lock-in.

xor ax, ax

ЭТО ЖЕ ОЧЕВИДНО!

Хотя да, если говнокодить, то никуда не влезет )

Тут меня убеждали что ваш XOR AX,AX используют сейчас только ламеры и пенсионеры

Как такие кощунственные вещи говорить можно! :)

Да и ARM для многих вещей избыточен

кстати, чем оно лучше?

На современных процессорах - ничем, но Ъ хакиров это не останавливает.

Как такие кощунственные вещи говорить можно! :)

Я тут не для рекламы, рекламой пусть маркетологи занимаются.

Да и ARM для многих вещей избыточен

Согласен, но с каждым днем разница все меньше и меньше. Начинать с AVR точно смысла нет. Это подтверждает и то, что Atmel University Program переехала с AVR на ARM с этого года.

иногда использовал пакеты [NOP, NOP, ..., NOP] — задержка просто считается «на пальцах» и думать «не нужно» © :)

это-же фича, наглухо отсутствующая в ближайшем С.

Согласен, но с каждым днем разница все меньше и меньше. Начинать с AVR точно смысла нет.

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

я показал пример быдлокода на асме.

Почти все последние изменения в семействе AVR - это die shrink уже существующих МК, так что тех процесс близок.

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

Но если схемотехника настолько плоха, что помехи реально мешают МК, то в любом случае нужно переделывать.

И да, были случаи когда устройство работало на более дубовой версии МК и не работает на новой, хотя они 100% совместимы по параметрам. Но во всех этих случаях Abslute Maximum Ratings были нарушены, просто старые чипы менее чувствительны.

ARM для многих вещей избыточен

Для мыргания светодиодом и AVR избыточен. А на более серьёзных приложениях ARM-ы удобнее в разы, что на сях, что на ассемблере.

Не, нафиг ASM. Работа замедляется значительно, увеличивается цена разработки, ухудшается сопровождаемость. Если очень надо, то лучше писать на Си, а какие-то критические куски оптимизировать на ассемблере.

Ну или патчить GCC

Да там весь register allocator с нуля переписать надо!

Умничать надо на собеседовании.

Инструкция получается короче как минимум (1 байт против 3 в 16-битном режиме и 5 в 32-битном).

А если железка уже выпущена и это доработка прошивки?

Начинать с AVR точно смысла нет.

Спорное мнение. На AVR в отличии от ARM нет кучи режимов тактирования, периферия попроще и т. д. При использовании AVR можно вообще использовать только 1 даташит, ничего не гуглить, настроить нужный периферийный модуль в пару строчек в виде присваивания регистрам и работать.

Как помигать светодиодом на AVR?

DDRB |= _BV(1);
while (1) {
PORTB ^= _BV(1);
_delay_ms(500);
}

Как помигать светодиодом на ARM?

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
GPIO_InitTypeDef gpio;
gpio.GPIO_Pin = GPIO_Pin_12;
gpio.GPIO_Mode = GPIO_Mode_Out_PP;
gpio.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOA, &gpio);
while (1) {
GPIO_SetBits(GPIOA, GPIO_Pin_12);
delay(500);
GPIO_ResetBits(GPIOA, GPIO_Pin_12);
delay(500);
}

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

В результате для новичка таки будет проще AVR, с его скромной, зато очень простой и понятной периферией, которая настраивается в пару строчек.

Я до сих пор не могу до конца разобраться с работой с I2C на STM32, хотя на AVR всё заводилось с пол-пинка. То ли я где-то косячу, то ли ошибка в стандартной библиотеке. Самое интересно, что частично оно работает, а через пару секунд чтений зависает.

addq %g0, 0, %g1

Зависит от задачи. Что-то примитивное можно и на асме, можно и на C. А вот большой проект на асме писать тяжко. Сишечка берёт своим количеством готовых функций. Недавно написал человеку для авр на с программку, которая получала два uint16_t и находила логарифм их отношения (децибелятор я делал). Этот мужичок хороший электронщик, но с не знает, всю жизнь писал на асме под pic. Реализовывать эту арифметику на асме он просто замахался бы. Так что вывод очевиден.

C
Плюсом будет то, что не только мк, но и другой код читать/писать можно. Ну и портирование и прочее легче

Просто у avr-gcc плохой кодогенератор. Коммерческие компиляторы для AVR генерят куда оптимальнее.

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

там скорее avr-libc неочень хорош =( генератор-то неплохой

Сколько ни пишут, что компиляторы умеют оптимизировать лучше человека, но факты говорят за себя: код на асме получается короче, чем сгенерированный avr-gcc, даже с -Os. Раза в полтора-два.

хм, насколько помню, там какой-то ещё флажок очень хорошо действовал в плане уменьшения конечного футпринта.

какие ещё флажки юзал кроме Os?

Не совсем. Разница в том, что у AVR более простая периферия. Так за порт ввода-вывода отвечает всего три регистра DDRx, PORTx и PINx (направление ввода-вывода, запись в порт/включения подтяжки в режиме входа, чтение из порта), у которых каждый бит тупо соответствует нужной ножке. В случае использования периферии типа USART или I2C ножки автоматически переключаются из режима GPIO в нужный режим. И много ещё такого.

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

http://www.tty1.net/blog/2008/avr-gcc-optimisations_en.html попробуй флажки которые тут предлагат. Может ещё раза в 1.5 меньше станет размер.

Когда я последний раз смотрел на avr-gcc, он не умел использовать индексные регистры в качестве стека данных, отчего все аргументы функций и локальные переменные адресовались через манипуляции с SP, это серьёзно раздувало прологи/эпилоги функций и код в целом.

C, ясен пень!

gcc давным-давно отлично оптимизирует. Правда, есть проблема с STM8: для них кроме sdcc нет компилятора, а sdcc нихрена не умеет оптимизацию.

Ну и еще: как ты будешь, скажем, TCP/IP реализовывать на ассемблере? Или USB?

А еще сейчас такие офигенные МК появились, что на них вполне можно даже считать float'ы и double'ы (а всего-то лет пять назад на человека, который в коде под МК писал float, тыкали пальцем и крутили у виска).

И да: оптимизация оптимизации рознь! Все на свете не соптимизируешь.

Оно элементарно втыкается как ассемблерная вставка. Изредка эта хрень нужна (например, чтобы при старте main() выдержать паузу, необходимую для инициализации USB).

Понятно, что в основной программе только идиот будет nop'ами задержки на фиксированный промежуток времени выставлять: во-первых, для этого есть таймеры; а во-вторых, первое же прерывание эту фиксированную задержку сделает неопределенной.

P.S.

И да, выкидывай нафиг эти атмели. STM32 рвет их по всем направлениям!

Ну для некоторых вещей attiny самое то. Простая инициализация периферии и мало ног