Согласен на все 100, за исключением "жаль". Потому что его архитектура - ад для конвейера.
А для микроконтроллера такая архитектура - и вовсе тормоз.
Во мне и ностальгия говорит. Работал я с ним, а ещё с VAX.


Я-я. Иллюстрирующий пример:


MSP - 27 тактов
AVR - 30 тактов.
Угадайте, кто быстрее.


Нащёт "замечательно" - пока не уверен - ещё не отполировал до конца. Но справляется.

Если по теме. Ассемблер жил и будет жить, это очевидно. Но необходимость в нём с каждым днём уменьшается. Помнится, было где-то прекрасное исследование оптимизации некоторых компиляторов С для х86. Так вот, компиляторы оптимизировали так, что рядовому программисту на ассемблере и не снилось. Это и понятно. Оптимизацию для хорошего компилятора пишут профессионалы, которые на этой архитектуре десяток собак съели, а программисту приложений вникать во все тонкости просто времени нет - у него план горит.
Если же брать ассемблер AVR, то он довольно мутный (PIC, конечно, ещё хуже), но обычно хватает возможностей по оптимизации того же IARа. Если и пишу сейчас на ассемблере небольшие кусочки, то только очень примитивные по функциональности, как например, те самые 12 каналов ШИМ.

Цитирую дословно:Assembler-компонующая программа,программа сборки.А язык зашит в каждом
микроконтроллере аппаратно.И для каждого микроконтроллера нужен свой ассемблер.Более того,
компиляторы Си,Паскаль и т.п. для микроконтроллеров я тоже не считаю языками ЯВУ.Они настолько урезаны , что от них остался только ассемблер.Сколько пустых споров что лучше IAR,Keil,Hi-Tech и др.
А сторонники C++ и Delphi вообще убивают друг друга.
Я согласен с dxp , что это инструмент, а мы инструмент в руках разработчиков МК. Они нашими руками
заставляют работать свои микроконтроллеры.Да, мы умные , но они умнее.Пока будет рынок, будет
много типов МК и ассемблеров.Иначе незьзя.Так диктует рынок.Они нас заставили писать на ассемблере.И мы пишем.Засунут Бейсик -будем писать на Бейсике. Многие думают , что они выбирают
микроконтроллеры.Нет это МК выбирают вас.
А если предположить , что это "они" инструмент в наших руках.Тогда давайте диктовать им свои
условия, но если мы счастливы писать на ассеблере, то ничего не изменится.
Я думаю, ассебблер на том уровне на котором он сейчас, не имеет перспектив.Его время ушло.
Кроме того специалисты по ассемблерам уже не нужны рынку.В мире уже сложились монополии на все.
Что-то там изменить сложно.Высшая школа выпускает уже не инженеров , а специалистов.Только еще
мы (осколки бывшего Союза) можем позволить себе пустые и ненужные споры.
Кто не читал, то прочитайте Айзека Азимова -"Профессия". Это про нас.

Те кто выжил в катаклизме пребывают в пессимизме
Да все определяет рынок. А деньги мера труда. И если завтра будет значительно легче и быстрее сделать девайс на жеской логике (ну например ПЛИСины будут продаваться по цене резисторов), послезавтра микроконтроллеры умрут как класс.

Мы не знаем как устроено железо. Мы можем об этом только догадываться. Но мы знаем систему команд и их двоичные коды.Этим кодам присвоены удобные названия - это и есть ассемблер. По другому нельзя, всегда будет точка соприкосновения между разработчиком и пользователем. Можно писать на ЯВУ и не знать ассемблера, но полный контроль над процессом разработки будет только при его знании. Сравню это с программированием на том же Билдере - да новичок, может быстро нарисовать форму с кнопками, НО, если он не знает как работает главное окно, зачем и как ходят сообщения, дальше этой формы он не пойдет. Поэтому ассемблер не есть самоценным для программиста. Это такой же бэкграунд как знание работы транзистора, для разработчика электроники. Это понимание процесса от и до.


А вот это утверждение меня откровенно порадовало. Приведите пожалуйста возможности стандартного С99, недоступные для работы на какой-нибудь Тини26 ? Насколько я знаю - только ограничения на использование *alloc(), что определяется не компилятором, а малым объемом доступной памяти.

???<<Те кто выжил в катаклизме пребывают в пессимизме >>

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

???<<Поэтому ассемблер не есть самоценным для программиста. Это такой же бэкграунд как знание работы транзистора, для разработчика электроники. Это понимание процесса от и до.>>

Совершенно верно.Выросшему на Си-компеляторе,ассемблер вообще не нужен.

???<<Сравню это с программированием на том же Билдере - да новичок, может быстро нарисовать форму с кнопками, НО, если он не знает как работает главное окно, зачем и как ходят сообщения, дальше этой формы он не пойдет. >>

Пойдет и дальше вас.

???<<Приведите пожалуйста возможности стандартного С99, недоступные для работы на какой-нибудь Тини26 ? Насколько я знаю - только ограничения на использование *alloc(), что определяется не компилятором, а малым объемом доступной памяти.>>

Тем более это не в пользу ассемблера.

И вообше-то я совсем не против ассемблера.Я вырос на нем.Но надо трезво смотреть на жизнь.

Если вы внимательно читали мои посты, заметили бы - я сторонник ЯВУ.

А вот это зря, плясать надо от печки. Прежде всего с МК, потому как требуеться очень четкое понимание о работе с битами и байтами. Кроме того отладка на МК имеет принципиальнольное отличие - в значительном количестве случаев система безголова и риалтаймова, а значит в окошко отладчика, далеко не всегда можно посмотреть.
Как пример знаменитый "курс" и его отголоски на форуме.

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

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

<<Тут можно сделать лирическое отступление - да, корпоративному миру нужны дешевые кодировщики тривиальных задач, которыми можно легко помыкать, но мы то хотим быть хорошими спецами-универсалами, которые могут взяться за любую работу, да и денег не просить, а требовать>>

Я тоже хочу писать ленточки (А.Азимов). Победу сборной

При всем уважении люди нужны разные. Возмем OrCad и его регистрацию chm и txt файлов на себя , возьмем подбор компонентов в других программах, поведение при клике мыши (proteus)... Не знаю как насчет нужны чтоб помыкать, но спецы для таких тривиальных задач точно нужны.

PS. Прошу прощения если офтоп

АSM не помрет никогда особенно в критических ситуациях, но и далеко на нем вы не уедите. К примеру, в моем текушем проекте под 15 000 строк кода на C. Не представляю как бы я все это писал на асме и как долго . Нет кто угодно только не я .

А что за программа такая на 15 000 строк.... Если не секрет раскажите что пишите?

Potter, это не так много, на самом деле - примерно полный объём памяти программ ATmega128.

Совершенно правильно. 15 тыс. строк действительно совсем немного и может даже поместится в Атмегу64. Это средней сложности коммерческое изделие с использованием модулей GSM(CDMA)+GPS(AGPS) со всякими дополнительными возможностями.

Если почитать ответы, то на мой взгляд переплетаются две темы. Особенности ASM AVR. И ASM, как таковой.
Хочу высказаться по обоим, но давайте сначала определюсь. Так сказать "заужу" рамки. Дело в том, что AVR разрабатывался как МП использующийся для задач управления. Т.е. датчики, моторы, протоколы передачи разные, регуляторы, предварительная обработка сигнала и т.п. Это было конкретно описано на сайте и видно из примеров. Основные конкуренты - PIC, MSP430, Ubicom, 51(варианты в том числе Sygnal), mitsubishi, ну и некоторые др. менее распространённые.
Конечно мы хотели бы прибамбахать туда ОС MS Windows XP , ну и брюзжим по тиху, типа что-то ресурсов маловато будет.
Но давайте исходить из первоначального назначения. Итак что мы видим:
1) Большое колличество регистров практически избавляет от использования памяти в задачах управления. (Нет равных)
2) Результат операции можно поместить в любой регистр. (сравнима msp430)
3) При любой ариф/лог операции выставляются флаги и их полный набор. (Сравнима msp430)
4) Легко организуются буфера, т.к. три указательные пары регистров и автоинкр/декр, косвенная индексн. и т.д. Прост доступ к таблицам данных во флэш. (Нет равных)
5) Очень малое время засыпания/просыпания и перехода по прерыванию. (Нет равных)
6) Хороший булевый процессор. (Сравнима 51)
7) Высокое быстродействие (Сравнима Sygnal, Ubicom)
8) Большая номенклатура, оснащение, наличие отлад. средств доступность.
9) Малая стоимость (Сравнима PIC)

Таким образом пинок на AVR, что мол инкремент ячейки памяти - три команды, - это пол правды. Допустим надо сложить r3:r4 и r5:r6.
На 51 выглядит так
mov a,r4
add a,r6
mov r4,a
mov a,r3
addc a,r5
mov r5,a
Для AVR
add r4,r6
adc r3,r5
Отсутствие аккумулятора - просто супер!!! Для создания библиотек и т.п.
Для любителей MSP430 отмечу, что 16 бит арифметика - это класно. В одном случае хотел перейти (уж оч. много 16-бит операций было) И что получилось, - там одно прерывание надо было обработать. Посмотреть один бит и выставить другой (в голове обработанный), так на 8-ми МГц я не сравлялся. Вот и 16-бит!
Для любителей PIC просто промолчу. Как сказал мне один приятель - слишком много отладочных средств купили. Теперь сложно ....

К примеру я переводил одну прогу с 8051 на 90s8515. Переводил механически типа команда в команду. Выкинул аппаратную примочку (51-ая не справлялась) и в результате.
а) Длина проги уменьшилась на 10% (Это при том что команда AVR 2 байта).
б) На критическом участке быстродействие (в тактах) возросло на 30%. При большей работе.
А если её сразу написать ориентируясь на AVR, - результат был бы ещё более впечатляющий.

Теперь по второму вопросу. На мой взгляд выигрыш ASMа чисто виртуальный. Т.е. я выигрываю тем что более грамотно распределяю ресурсы. На тех задачах о которых я писал выше почти не требуется ячейки ОЗУ. Практически все данные влазят в регистры. Обычно использую две рабочих пары, Z и регистр FLAG(для битов). Самые часто используемые - в регистрах. В озу - самые редко используемые.
Приведу пример статистики для средней "классической" моей проги.

Длина: ------------------------- 5429 строк. (~6k занято)
память: рабочие ячейки ----- 31 байт
------- внешние ячейки ----- 25 байт
------- стеки RS232 -------- всё остальное (- стек проги)

Использование Ld/st -------- 200 раз (в основном константы времени)
Использование Push/pop ----- 2 раз в голове

уровень стека в прерывании - 8 максимальный
уровень стека в п/п -------- 6 максимальный

Очевидно, что СИ (Например IAR) Отводит две регистровых пары под указатели стека данных (-4регистра). Ну и уровень стека раза в три-четыре больше.
Что я вижу при обращении к static памяти типа:
NumbActiveKom++; // Ввод команды завершён
В голове
LDD R16, Z+53
DEC R16
STD Z+53, R16
в прерывании
rcall ?Subroutine96

где

?Subroutine96:
MOVW R31:R30, R27:R26
LDD R16, Z+53
DEC R16
STD Z+53, R16
RET

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

Но всё-таки мне кажется, что постепенно уровень компиляторов станет ещё выше, команды АСМа ещё заумнее, ресурсов и быстродействия у камней ещё больше, а АСМа - всё меньше.
На моей памяти редактор текста для Радио86РК влазил в 2К. 4К - Бэйсик, Паскаль. 720К - прародитель Heroes - KB. А теперь Герои на DVD едва-едва. Короче скоро будем Windows Robotics вставлять и из под неё на визуал Си светодиодами моргать!

Всё сказанное - мой взгляд на вещи.

SasaVitebsk
ну, скажем, KB на Спектруме и в сто килобайт влезал

Полноценных регистров 16. Нижняя половина не умеет работать с константами - ни грузиться, ни сравнивать. Итого 8 регистровых пар. У MSP430 12 регистров. Про 16-разрядность говорить не будем, тут все более, чем очевидно.

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


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


3 аппаратных указателя, из которых полноценных только два. У MSP430 их 12. Все полноценные. Эффективная адресная арифметика (с указателями) на AVR ограничена прибавлением костанты максимальным размером в 63. Для большинства случаев в программах для AVR хватает, но иногда бывает этого мало. MSP430 этим не ограничен - полная 16-разрядная арифметика. При работе с флешью на MSP430 все прозрачно - хоть флешь, хоть ОЗУ. Адресуемся любым способом из любого регистра. AVR пролетает по обоим пунктам.


MSP430 исходно строился как процессор с малым потреблением, причем рекордные показатели тут достигаются не столько технологией, сколько организацией подхода. Главная идея - как только работы нет - спать. Как только работа появилась, проснуться и делать ее, потом снова спать. Для этого в MSP430 внедрена специальная развитая система тактирования из 3 клоков, ядро процессора и периферийные устройства могут тактироваться от разных клоков. Некоторые периферийные устройства - в частности, UART, имеют специальные фичи для обеспечения работы при низких значениях клоков. Например, в упомянутом UART'е в Baud Rate генераторе используется специальная фича - modulator, которая позволяет, например, работать на скорости 4800 бод при тактировании UART'а от 32768 Гц.

Само ядро процессора рекомендуют тактировать от DCO (встроенный RC генератор, так же имеющий ,modulator для коррекции скорости, если это необходимо), в этом случае проц может мгновенно засыпать и практически мгновенно просыпаться - 6 мкс время пробуждения. В то время, как ядро спит, UART может метать байты, тактируюясь от 32768 Гц. Сколь все это потребляет, сами понимаете.

Т.ч. насчет "нет равных" это Вы погорячились - AVR (и другие) только только подходит к тому, что MSP430 умеет от рождения.


Не сравнимый. У 51-го можно адресовать отдельный бит. У AVR же, как и любого обычного процессора - маски. Собсно, плохого тут ничего нет, это у 51-го битовый процессор от бедности был - память экономили, а сейчас и с масками AVR, MSP430 или любой другой современный проц работает быстрее (по сравнению с оригинальным 51-м).


Это уже обсуждалось бурно в этом же топике выше. Быстродействие обычное, не чемпионское. Чемпионским оно кажется только при сравнении с 12-тактовым MCS-51.


Нашли с чем сравнивать. Ну вот Вам MSP430:
add r12,r14

Еще с АРМом сравните.

Z80:
ADD HL,DE
А в общем-то он 8-разрядным считался

dxp ну не буду я с тобой спорить! MSP мне тоже оччень понравился. И семейство мощное. И аппаратный умножитель со сложением есть куда применить. И ещё я насмотрел целую кучу вкусностей.
Но вот такой пример. Конкретный. Захотел я его применить. Стал ваять и что вижу. В 70-80% приходится работать с байтом. Ну это не страшно. Он для этого приспособлен великолепно. Но у меня надо обработать сигнал (телефония) с частотой 32кГц. 0/1 отличается длительностью сигнала 2/4мкс. потом задержка 2мкс и ответный сигнал 2мкс. Итак надо отличить сигнал 2мкс от 4мкс. Т.е. для MSP430 16 тактов от 32 тактов. По прерыванию плавает, по моему больше чем у AVR. У AVR не более 2 тактов если умножение не использовать. Короче точность на пределе. И разрядность здесь не прилепишь. Разрядность как раз (как правило) в медленных участках нужна. И всё! Покрутил - покрутил ну и вот держу в руках изделие на mega8 на 14.7456!

Ну и цена .... конечно. Mega8 берём 1.2$. А программа - она ведь один раз пишется.

По поводу регистров младших. Никогда от них не отказывался. Вполне приятно с ними работать. Во-первых не всё же время с константами работать. Иногда например использую под флаги. Думаете - неудобно? Нормально. Переходы sbrs/sbrc работают а установку делаю например так:
set
bld flag,bready
Очень наглядно. Короче они абсолютно не пустуют. А раз не пустуют, то как же можно написать что их нет?
Лукавишь dxp!

Я не спорил, а отвечал на вполне конкретные тезисы, в которых было заявлено, что, дескать, AVR вне конкуренции. Было показано, что это не так. Только и всего.

С тем, что MSP430 не закрывает 100% ситуаций, что AVR имеет по совокупности требований кое-где (и не редко) преимущества, т.ч. его применение оказывается предпочтительным, я не спорил и сам на это указывал.

C я так понял - арифметика. Но когда скорость (особенно прерывание)- только ASM - контролируешь каждое слово хоть это и грустно, но важно... Хоть как не грузи что все есть на ASMе - там с арифметикой трудновато, ну я ж искал, делал. Это вчерашний день. Кому допустим нада 32/8 - та нахер не нада - сам мути когда скорость, а и наче 32/32 но время то идет. Бывает такое что за 25 мкс нужно сделать все - АЦП (а может и d-s), двух-канальный датчик импульсов 20кГц (+-999999), ЦАП, UART, настройка шкалы и т.д. Всем огромное спасибо за высказывания.

Насчет прерываний. Попробуйте соптимизировать код обработки прерываний, сгенерированный компилятором. Интересно, во сколько раз он станет после этого меньше и быстрее?

Метакомпиляция



Обычный процессор, запрограммированный на Assembler-е тоже выполняет скомпилированный код. Те кто программировал непосредственно в кодах, пускаем слезу умиления (ох, CD 10 00 DA 00 02 C9)

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



Две страны где он был особенно долго популярен (не считая родины) - Корея и СССР. По вполне понятной причине - реализуемости "на коленке" - нежелании зависеть от западных разработчиков компиляторов. На западе закат Форта начался уже давнооооо. Только идеи, лежащие в его основе, заставляют снова и снова будить мертвеца



Имеется логическое противоречие "специалист-универсал" . Вообще-то существут специалисты и дженералисты, и противоречия между ними, старые как мир

При достаточно хорошем владенни С вполне можно писать код настолько же плотный как и на ассемблере.
1.inline - убирает самую расходную часть кода - call и пролог/эпилог.
2.nacked/task - дает возможность написать пролог/эпилог самому.
3.Сишный код компилируеться в ассемблер и правиться руками.


Раскрою свою мысль - есть кодер, который набил руку, например в рисовании формочек для запросов к базе данных, он способен лепить подобные программы с немыслимой скоростью. При необходимости использования, например каких-либо системных вещей, скорость его работы катастрофичеки падает.
Есть универсал - который знает не конкретную визульную библиотеку, а бэкраунд на котором она основана. Такой человек дает среднюю скорость, но способен к работе в совершенно различных направлениях. При проблемах на рынке труда первому перестроиться крайне сложно, второй проблем с работой не испытывает. Кризис в Штатах в конце 90-х это показал достаточно наглядно.

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

Да, это и есть Enter с нулевой вложенностью стековых кадров. Чтобы понять, что такое вложенные стековые кадры, вспомните Паскаль - там внутри одной процедуры можно описать другую процедуру, из которой будут видны локальные переменные объемлющей процедуры, но внутренняя будет недоступна для основного кода модуля. Так вот, при входе во внутреннюю процедуру вызывается Enter с параметром вложенности 1, копируя в текущий стековый кадр адрес стековых кадров всех объемлющих процедур (в данном случае одной, но можно до 31).
А вложенность уровня 0 - это просто 2 инструкции
sub SP,const
mov BP,SP
То, что эту последовательность двух команд обозначили одним новым словом, почти не даёт преимуществ (по крайней мере никакого торжества Фуджиков по этому поводу не намечается).

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


Ключевое слово - "ручками". Они у всех разные. Если вы изучаете асм по Сишным листингам и учитесь у составителей компилятора - то и ручки будут соответствующими. А если осмыслить всю задачу изначально без ЯВУ-шных предвзятостей, то ручки будут творить чудеса и простор вашей фантазии поразит вас самого. Сама психология следования традициям общих подходов, применяемых в компиляции с ЯВУ, ущербна.



Есть и исключение - копирование в AVR регистровой пары в другую регистровую пару - 1 такт.

Излишнее количество адресных пространств не даёт никакого проигрыша в скорости обращения к ним. К расширенным портам ввода-вывода обращение эквивалентно обращению к памяти (так, как вам и нравится).


За 1 такт - выводом единичного бита в нужный пин одной инструкцией OUT PINB,reg



Очень правильная последняя фраза. В ней сокрыто основное преимущество АСМа, роль которого никогда не перестанет быть важной.



В рамках своей идеологии компиляторы генерят код насколько могут хорошо. Но рядовой (или не очень) программист на ассемблере просто сделает шаг в сторону от натоптанной компиляторами дорожки и получит выигрыш в разы. Жаль, что многие обсуждающие эту тему (например, в этой ветке), не понимают этого, зашоренные стандартными подходами. Для программиста на АСМе нет прокрустова ложа (то есть, грамматики ЯВУ), стоящего между семантикой исходной задачи и возможностями железа. Нет этого посредника, обязательность присутсвия которого увеличивает накладные расходы (в смысле оптимальности получаемого кода). Единственное оправдание ЯВУ - это время разработки софта и универсальность обучения кодеров. То есть, жертвуя оптимальностью программы, мы удешевляем её разработку. Использование ЯВУ - это баланс между техническими и экономическими интересами, а вовсе не "светлое будущее" программирования.



Экий самоуверенный разработчик с претензиями Икара.



Вот-вот, видимо о таком и речь.

Вот и я поддерживаю данное высказывание на 100%. Правда по другой причине. Вылизывание Сишного кода (примеров на форуме очень много) всегда опирается на особенности компилятора. Это фактически уже тот же ассемблер с вывертом. Поясню. Когда очень долго пишешь на ASMе, то не пишешь операторами, а в голове у тебя давно сидят целые куски когда-то вылизанные. И пишешь то легко и спокойно. Я на спор написал прогу с ЖКИ, редактором, I2C, ADC, DAC, Modbus на ASMе. Быстрее программиста на Си. И отладил быстрее. И прога значительно красивее работала (в смысле редактора). Её и за основу взяли.
Но .... Си нужен для хорошей портируемости. Возможности развития програмного продукта. Его сопровождения. И выверты в данном случае приведут к необходимости переписывания проги при каждой смене кристала или компилятора. Так нафига тогда Си вааще...
Надо выбирать платформу с запасом, писать максимально независимо, укрупнять где возможно, предусматривать возможность развития.

Конечно это чисто мой взгляд на вещи. Я тут обжёгся с одним изделием. Начинал ещё на 51+мелочёвка. Потом перенёс на 4414+1200, потом на mega8. А теперь смотрю с отвращением, а оно живёт! Придётся на at91sam7s переносить. Фактически заново разрабатывать! Я его уже ненавижу!

Инверсия пина в AVR, если Вы не знаете, выполняется, например, так:

Ни разу не один такт!

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

В новых кристалах - например в М88 out в PINx действительно приводит к инверсии установленных в 1 битов. Так что вы зря напали на человека, да еще и в таких выражениях...

Не согласен. inline - стандартная фича переносимая на все 100%. Тот же макрос, но с проверкой параметров. nacked/task не настолько экономен и переносим, но в хорошо вылизанном коде его стоит использовать. Вопрос собсно состоит в том, насколько стоит увлекаться ручной оптимизацией. Если проект разовый наверное нет, если с долгим жизненным циклом - доводить в каждой новой итерации.

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

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

К вопросу грамотного использования макроязыка
ассемблера AVR для структурирования ассемблерных программ

См: http://www.forth.org.ru/~IN4/

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

Или сейчас в почёте у эмбеддеров знание не более чем одного языка ?

Во-первых, надо было уточнять, т.е. прямо сказать, что это, дескать, вчера фича появилась в последнем кристалле, на который и дока-то еще Preliminary. AVR выпускается почти 10 лет и все выпущенные до сих пор кристаллы ничего подобного не имели, и мое высказывание имеет к ним прямое отношение. Кстати, это в значительной мере характеризует Атмел, как произвоидетель МК, и подтверждает лишний раз, что они сперва делают, а потом думают.

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

Что касается ассемблера и ЯВУ, то тут, извините, остаюсь при своем и считаю высказанное на эту тему CD_Eater, мягко говоря, слабо соответствующим действительности.

tiny2313, 13, 25/45/85, mega48/88/168, 640/1280/1281/2560/2561, 165/325/3250/645/6450, 169/329/3290/649/6490, PWM2,3, может быть, еще какие-то забыл.
Не так уж и мало, и совсем не вчера.

Умножитель в AVR тоже не сразу появился...

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

По факту, Атмел не додумался о том, что нужна инверия пинов, не додумался, что нужна команда eori (которая, кстати, не только для инверсии пинов нужна, но и вообще). Как не додумался, что двух указателей мало, что 64 байта IO пространства мало и оно быстро кончится, что помещать регистр результата АЦП в битовоадресуемую область IO пространства расточительно и глупо, что EEPROM без специальных мер будет портиться при выключении питания, что... еще много что можно вспомнить. Теперь он пытается залатать дыры - решение писать в регистр, предназначенный исходно для чтения - просто некрасиво, это костыли. Вот так и обрастает исходно очень неплохая идея геморроем.


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

Аппаратный умножитель ИМХО был стандартной фичей семейства Мега, о чем и говорилось сразу. Причем три основные линии семейства, наследовали друг друга по ядру и IO. На сегодня в AVR полный разнобой - разный мэппинг периферии, разные фьюзы, итп. В одной линейке оказываеться и Tiny13-15 и Tiny26/2313 совершенно различные по идеологии и области применения.
Недавно за отсутсвием М8 купил в новую партию изделий М88 - перепиливал код достаточно достаточно долго.
Вероятно уже начался закат AVR.

Насчёт подавляющего большинства - не согласен. Смотрите:
Нажмите для просмотра прикрепленного файла
Практически половина чипов. Все новые (относительно, год-два), тем не менее, скажем, все наши устройства уже переведены на них.
Вторая половина - почти вся устарела. А дальше - устареют и оставшиеся.



Снова не согласен. Атмел просто перешел от отображения специализации в названии к отображению более мелкой специализации в номере чипа. Другое дело, что можно было сразу с этого начать
С этой точки зрения tiny2313 и 26 - разные линейки, а 25/45/85 - одна.
И с периферией с новых чипах значительно приятнее работать - её больше, она функциональнее и удобнее. Регистры совместимы в пределах линейки, опять же.

Уважаемый dxp, дабы не сесть в лужу, лажая AVR в форуме, посвящённом AVR-микроконтроллерам, не сочтите за труд прочесть даташит, хотя бы на один кристалл не 5-летней давности.
Вообще-то, у AVR за последнее время появилось много полезных фич, которые вы считаете отсутствующими (потому как новые). Например, про picoPower вы тоже ничего не слышали ?

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

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

Вот о том-то и речь! Я тоже побывал в такой ситуации, когда вместо меги163 пришлось поставить мегу16 и полдня ловить приветы от совместимости.


Да не, никуда он не закатывается, наоборот только-только раскрутился. Это просто стиль работы такой - сперва делают, потом думают. И переделывают. Отсюда такая картина.

Это говорит о том что очень спешили на рынок... Думать стали когда на него влезли...
И теперь всем рассказывают что на месте не стоят.

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

Уважаемый CD_Eater! Я уже советовал Вам четко и внятно выражать свои мысли, дабы не создавать двусмысленностей и тем самым не делать заподлянок другим участникам форума. Это раз. Назовите мне AVR 5-летней т.е. от 2001-го давности, где есть фича инверсии пина одной командой?


[1] Я писал на ассемблере достаточно. В том числе и на AVR. И поверьте, не хуже Вашего знаю его достоинства и недостатки. А вот Вы, уважаемый, очевидно, очень слабо знакомы с ЯВУ вообще, и С в частности, иначе не озвучивали бы такие детские заявления!

[2] Что Вы знаете о моей квалификации, чтобы делать публично такие заявления? Вы видели хоть одну мою программу?

[3] Я, допустив несправедливое (хоть и частитчно) замечание в Ваш, уважаемый, адрес, без колебаний извинился, когда мне на это указали, хотя половина вины лежит, уважаемый, на Вас, как выдавшего двусмысленность без уточнений. А вот вы, очевидно, просто хам.

Это что-то вроде следующего:

"Требуется на работу электронщик-программист:
1. с высшим образованием
2. опыт работы более 10 лет
3. возраст - не старше 25 лет"

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

Уважаемый, Вы передергиваете...
Вы любите мясо с кровью, для простого чела - недожаренное? Я - нет.

Поясню точнее что я люблю (это моё личное, как, впрочем, и предыдущее сообщение да и все мои сообщения на форуме, и никому я своего мнения не навязываю).
Я люблю находиться на острие событий, люблю оправданный риск, люблю инновации.
У меня нет предубеждённости, что все МК применяемого мною семейства должны быть абсолютно и во всём преемственны.
Я не люблю утруждать себя формированием бесполезных требований к МК на предмет того, какими они должны быть (кто и кому должен?).
И уж тем более я свободен от иллюзии, что даже через десять лет я дождусь, когда некий сырой МК станет абсолютно совершенным.
Ещё раз напоминаю, что выражаю только собственное мнение и никого не призываю его поддерживать.

Кстати один из моментов который мне ужасно не нравится у Atmel, - это их дикая способность к внесению изменений. Низкий поклон тому собеседнику который писал, что он "уже всё перевёл на новые кристалы". Я ему жутко завидую, но опасаюсь за его рассудок. Если и дальше пойдёт всё такими тэмпами (ну там 888, 8888, .....), то я боюсь не выдержу. Фраза о возможностях новых кристалов, ну скажем несколько оптимистична. Один проект (Причём именно на asme) я перевёл с м8 на м88. Здоровья положил много. Ругался матом в голос. Причём mega8 на рынке просуществовала пару лет! Да у нас утверждение документации длится дольше!

Вы забираете ч/з край уважаемый. Здесь всем нравится и AVR и его ассемблер, но просто люди объективно подходят к оценке возможностей и банально сравнивают. Мне например очень нравится ассемблер и AVR, но это не помешает мне сделать следующий проект на другом камне. А если появится что-то ещё более достойное, тогда будем двигаться дальше. Видишь ли я (как и dxp) на AVR не женился.

Мне кажется затронута ещё одна тема. Любви и привязанности. Что-то сродни старому вопросу что есть программирование - искуство или ремесло. Надеюсь, что все здесь на данный вопрос отвечают - искуство! Так вот можно написать КРАСИВУЮ программу как на СИ так и на ASMе. Потом сидеть и любоваться на себя в зеркало! Это просто разные виды искуства. С этой точки зрения получается что мы спорим что лучше музыка или живопись.
Мне если честно по барабану на чём писать. Лишь бы я чуствовал удовлетворение от сделанного. Удовлетворение от того, что оно там движется, моргает и живёт своей жизнью. Которую ему дал я.

Я тут типа пытался загрузчик сделать так хитро чтоб из его исходников можно было скомпилировать код для любой меги. Рехнутся можно. по моему атмелы сделали все чтобы это стало невозможным - разные названия специальных регистров, обозначающих одно и тоже, разное распределениие их в адресном пространстве, и пр. и пр., по разному работающий УСАРТ. А ведь поверили его только на трех кристаллах mega128, 88 и 8.
И вообще это жуткое западло когда кристаллы снимают с производства оставляя на рынке только "совместимые по выводам".
И вот это

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

Кстати а вы знаете что один и тот же кусоек С кода на mega8 дает меньший размер прошивки чем под mega88? На одной и той же версии IAR.

Вполне логично - все SFR у mega8 расположены в пространстве I/O, у 88-ой же меги половина регистров за него выходит.
Соответственно, код в последнем случае получается объёмнее.

Скажу больше. Я переписал прогу так, чтобы она компилилась на м8 и м88, но только для того, чтобы можно было debugware использовать. Какие-то новые функции этого кристала меня не впечатлили. Выпускаем по прежнему на м8. Дешевле пока.

Эх коллега, я тоже делал такое,для элементарого устройства - по SPI принимем, по УАРТ отдаем. Горы дефайнов, выкрутасы с фьюзми.
Через месяц понял, что поддерживать такой код никакой возможности нет и разделил на два проекта.

Ага. С месяц назад попытался сделать более-менее унифицированную библиотечку для SAM7.Системный таймер, UART, SPI. Вроде бы нет проблем с миграцией, грубо говоря один кристалл, но взаимовлияние периферии похоронило эту идею. Дальше таймера не сдвинулся.Попробую следующий заход сделать на С++, перегружаемыми функциями, но первоначального оптимизма уже нет

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



О, да ! Этого у Атмел не отнять. Сам испытываю подобные проблемы - старые чипы исчезают, а перелопачивать программу под новые - удовольствие небольшое. Здесь Атмел не рулит. Хотя их можно понять - каждый раз, желая сделать новые чипы лучше, хочется разрушить всё старое, а на его месте создать шедевр, правда, который тоже будет недолговечен. А совместимость с предыдущими чипами - это, увы, обуза для инноваций. Наблюдаю подобное в своей практике (моя основная работа - программирование для PC) - каждый год переписываю в общем-то немаленький проект (более 30 тыс.строк кода) почти с нуля, ломая почти всю логику работы программы, дабы сделать её ещё лучше, хотя требуется лишь добавить новую функциональность, правда, не предусмотренную при изначальной постановке задачи. Увы, пожелания заказчика непредсказуемы, но выполнять их надо. А переписываю с нуля для того, чтобы сделать программу как можно более универсальной относительно предполагаемых будущих "сюрпризов" со стороны заказчика. Молюсь, чтобы его очередное "пожелание" не пошло вразрез с хардварной частью (парой сотен устройств на МК, с которыми общается компьютер), до сих пор всё обходилось изготовлением дополнительных устройств (в отдельных корпусах) и подключением их к контактам в/в общего назначения старых устройств - получаются такие "навесные" апгрейды (вам, наверное, смешно...). Когда вспоминаю, что сначала хотел сделать первоначальные устройства вообще без возможностей расширения (ведь изначально ничто не предполагало такой изменчивости пожеланий заказчика), меня пробирает лёгкий холодок ужаса. Вероятно, у многих из вас ситуация другая - разработал, изготовил, продал (или запустил серию) и отдыхаешь, поэтому проблема обслуживания не знакома. Те же, кто делает изделия под одного конкретного заказчика, меня поймут - желание "разрушить всё старое и создать с нуля" постоянно приходит в противоречие с необходимостью "плавного безболезненного (недорогого) апгрейда", ведь с точки зрения заказчика всё просто: "Добавь-ка мне вот такую мелочь в программу"
Справедливости ради следует сказать, что в лидеры по популярности среди 8-битных МК AVR вышел благодаря тому, что Атмел не стал придерживаться старых привычных традиций, а создал своё ядро, абсолютно новое и лучше предшественников. Другие конторы предпочитают не рисковать и делают клоны 51-х МК. Этот смелый шаг Атмела окупился. Так что иногда необходимо "разрушить всё старое".


После написания кода для PC, когда за преемлемое время нужно создать большую и сложную программу, мне приятно отвлечься и поковыряться с каждым байтом отдельно, и написание прошивки в 3-4 тыс.строк на АСМе служит своего рода отдыхом. Гармоничность АСМа AVR-ов играет в этом непоследнюю роль (здесь больше важна красота, а не ортогональность). Маленький островок искусства в океане ремесла.

ИМХО для этого существует ТЗ. Для изменения ТЗ и внесения "такой мелочи" нужно заново составлять ТЗ на доработку или переработку. Чисто что бы всяким даунам все просто не казалось и они не меняли своих пожеланий каждые полчаса. И не надо тогда опасатся что очередное пожелание пойдет в "разрез с". Пусть даже оно и появится - перелопачивать все будете за счет заказчика, а не за свой. По-другому работать вредно для здоровья.

Разумеется, за счёт заказчика, он готов оплатить, но когда я говорю, что эта доработка потребует полтора месяца, он как-то странно на меня смотрит...

Да, вопрос почему нельзя переработать проект с нуля _до завтра _ , это наверное лучший вопрос заказчика, и вечный бич разработчика.
Учить их, учить и учить.... жестко.