Форум РадиоКот

ARV писал(а):ваш опыт не может сдвинуть линию общего тренда...

Больная мозоль. В среднем, из всех проектов, которыми я руководил или архитектурой которых занимался, только в половине удается добиться написания оптимизированного кода до окончания ОПЭ, а не только после того как, у клиента объем обрабатываемых данных вырастет на несколько порядков и он начнет писать возмущенные письма.
И это при том, что проекты большие, некоторые длились годами и все были вокруг баз даных объемом до нескольких терабайт.
Но "линию общего тренда" при этом, как Вы правильно заметили, сдвинуть не удается. Копроэкономика... (

Доброго времени суток! По не многу начинаю изучать ассемблер для AVR. Написал небольшую программу счетчика. Сама программа компилируется, а когда пытаюсь запустить программу в Proteus, то он начинает ругаться. Подскажите в чем тут может быть дело? Проект в архиве.

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

Считать она должна нажатия на кнопки (при нажатии на кнопку PD4 - должен счетчик увеличиваться, а при нажатии на кнопку PD7 - уменьшаться). Если кнопки отбросить и сделать счетчик без кнопок, то все работает, происходит возвращение по команде ret.
Проблема в данной части кода если я ее закомментирую, то все работает.

Да вы хотя бы поменяли rjmp pause на rcall, и стек инициализируйте!!!
Может и заработает тогда что-то, и то, только в протеусе. В железе это не заработает
никогда(вы о дребезге слыхали?). Менять ВСЁ начиная с алгоритма.

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

Ну бляяяу!!! Да почитайте, наконец, Ревича:
" Практическое программирование МК Atmel AVR на языке ассемблера "
Или ссылку еще дать?

ptr128 писал(а): Не эффективно, это когда "овчинка выделки не стоит".
То есть, когда трудозатраты на ассемблерное кодирование оказались больше, чем экономический эффект от них.
То есть эффективно - это верно выбранный баланс между тем, какой код проекта следовало писать на ЯВУ, а какой на ассемблере.

Что вы понимаете под ассемблерным кодированием?
Писать на классическом ассемблере сложно, трудно, давно на нём не пишу, на мой взгляд, это сейчас анахронизм.
На макроассемблере писать просто и в тоже время можно быстро «опуститься» на ассемблерный уровень.
Практически,весь текст на макроассемблере представляет собой макрокоманды, вызов подпрограмм (функций, процедур) и т.д. В этом плане говорил, что он приближён к ЯВУ.
Пример функции уже приводил — логарифм, вызвав которую сразу получаете более 1 КБ. Это, кстати, не самый большой библиотечный элемент.

ARV писал(а): на сегодняшний день вопрос прироста производительности не стоит вообще, т.к. быстродействие даже микроконтроллеров AVR достигла такого уровня, что задумываться о быстродействии практически не приходится. если же взять мир 32-битных и тем паче 64-битных контроллеров, то там и подавно. про PC вообще молчу.

«задумываться о быстродействии практически не приходится»
Сомнительное утверждение. Электронщику часто приходится сталкиваться с быстродействием.
То импульсы нужны микросекундные, то в быстрой следящей системе нужно успеть рассчитать управляющий сигнал, то нужно провести скоростные измерения в быстротекущем процессе.
Большей частью с помощью ассемблера и АВР эти задачи легко решаются, зачем применять более сложные и дорогие решения.
Благодаря РОН АВР довольно быстро работает. Только, на мой взгляд, в простых микроконтроллерах явно не хватает аппаратного умножения 2 на 2 байта. По цене, наверно, это стоить копейки, а существенно ускорит расчёты.

dimmer писал(а):Во-первых не нужно извращать мои слова. Я нигде не писал, что 8 - 16 Кб это порог для ассемблера. Дословно было:"Я думаю, что если в будущем понадобится писать что-то больше 8 - 16Кбайт, то одним ассемблером наверно не обойдусь."
Имел в виду, что как будет подходящая возможность, то хочется попробовать что-то другое (скорее всего С++).
Во-вторых, если коротко по поводу остального, что Вы написали - это по ту сторону Добра и Зла.

Не собирался извращать ваши слова.

«по ту сторону Добра и Зла» - это, вроде как, что-то из большой философии. А программирование на макроассемблере — при некотором навыке это обыденно и просто.

AQ29 писал(а):

ptr128 писал(а): То есть, когда трудозатраты на ассемблерное кодирование оказались больше, чем экономический эффект от них.

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

Я не знаю, что Вы называете "классическим ассемблером", так как когда я впервые начал писать на ассемблере 8080 в 1984 году, то использовал для этого макроассемблер IBM/370 в режиме кросс-компиляции. То есть каждой машинной команде 8080 соответсвовал свой макрос.
С тех пор ни разу, ни для какой платформы мне не макроассемблеры не попадались.
Даже тупой ассемблер на Синклере для Z80 был макроассемблером.
Исходя из того, что макроассемблер IBM/370 был аннонсирован, и широко использовался для кросс-компиляции, за год до выпуска первого микропроцессора 4004 (1970 vs 1971), я даже не представляю, где и на каких платформах Вы откопали "классический ассемблер", не являющимся макроассемблером.

Другое дело, что на макроассемблере я давно не пишу. За ненадобностью. Механизма ассемблерных вставок в C мне хватает с головой. Не так уж часто необходимо высчитывать такты каждой команды и экономить наносекунды.
Так что под ассемлерным кодированием я подразумеваю, в первую очередь, оператор asm языка C.

AQ29 писал(а): он приближён к ЯВУ.

Категорически не согласен. Код на языке высокого уровня всегда можно написать кроссплатформенным. Код на ассемблере - никогда.
Код на ЯВУ может быть автоматизировано проанализирован на предмет надежности и безопасности. Для ассемблера я таких анализаторов не встречал.

Именно потребность в надежном и кросcплатформенном коде и привела к тому, что в рамках промышленного производства ПО для МК все большее количество производителей приходят к стандартам MISRA.
IMHO, если планируете профессионально программировать МК, то учите С, а макроассемблеры оставьте в покое. Даже несмотря на то, что использование asm в С требует несколько большей писанины, чем написание модуля на макроассемблере. В итоге, оно окупается сторицей на всех этапах жизненного цикла ПО. Привыкните. Как я, например, уже физически не могу написать даже простейший код без включения его в систему контроля версий. Рефлекс однако )

А как конвертится число, лежащее в двух регистрах в 4-х значное десятичное (0000, с разложением в 4 регистра)? Тут катит только способ последовательного приближения через "10" или бывают "умные конверты" "в два счёта"?

Что-то я не могу создать локальную метку в макросе. И что-то не гуглится правильный синтаксис метки. (gnu preprocessing assembler )
Приму любую помощь по созданию локальных меток в макросе, лучше деньгами .

Серый_ писал(а):А как конвертится число, лежащее в двух регистрах в 4-х значное десятичное (0000, с разложением в 4 регистра)? Тут катит только способ последовательного приближения через "10" или бывают "умные конверты" "в два счёта"?

Пока самое лучшее, что применяю. Легко адаптируется.

Z_h_e писал(а):Что-то я не могу создать локальную метку в макросе.

Вот что нагуглил, вроде оно. Сейчас попробую разобраться.

Серый_ писал(а):бывают "умные конверты" "в два счёта"?

http://www.avr-asm-tutorial.net/avr_en/ ... ml#bin2asc

Еще есть красивый вариант, но на С. Впрочем, перевести его на ассемблер, при желании, не сложно.
https://bugs.debian.org/cgi-bin/bugrepo ... bug=627899

P.S. А что, религия запрещает пользоваться C? Или родной GCC ассемблер чем-то не устраивает при кодировании ассемблерных вставок в С?

Z_h_e писал(а):Вот что нагуглил, вроде оно. Сейчас попробую разобраться.

Да, получилось с циферными метками.

ptr128 писал(а):P.S. А что, религия запрещает пользоваться C?...

Офф: Никогда не юзал и не понимаю. В своё время посмотрел на засилие скобок, и уже на этом косвенном основании - оценил язык как неадекватный для восприятия. Фундаменталистика чем-то интересней и для малых проектов катит.

В этой теме не OFF, а самое то.

Серый_ писал(а):

ptr128 писал(а):P.S. А что, религия запрещает пользоваться C?...

Офф: Никогда не юзал и не понимаю.

А как же MISRA, категорически запрещающая использовать ассемблер для МК, кроме как в виде ассемблерных вставок на С?

Да не, это уже офф, ребят...

ptr128 писал(а):А как же MISRA, категорически запрещающая...

1) запрещает только тот, кто в состоянии запрещать
2) MISRA возможно недопонимает, что благодаря "американскому праву", её могут обязать
отписать все свои особняки - мне (и вам часть ), если во вставках на C обнаружится хоть немного "сифы"
3) были даже целые запрещающие эпохи, которые... дозапрещались!

Серый_ писал(а):Да не, это уже офф, ребят...

С чего бы это? Ассемблерные вставки обрабатываются GNU AVR Assembler. С каких пор он стал оффтопиком здесь?

Серый_ писал(а): 1) запрещает только тот, кто в состоянии запрещать

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

Значит все же есть какие-то причины, почему ассемблер запрещают использовать вне ассемблерных вставок C?