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



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


У Вас первая фраза противоречит последней. Для примера, час работы даже низкоквалифицированного программиста обходится не менее, чем в $20 (я не говорю, что этот индус столько получит на руки - если интересно, расчет могу привести). МК с бОльшим объемом флеш, если оно и потребуется, будет стоить, от силы, на полдоллара дороже. Отсюда получаем, что день работы индуса, в теории, имеет шансы окупиться только на тираже свыше нескольких сотен экземпляров. Проблема в том, что на нескольких сотнях дополнительный флеш станет стоить десяток центов. И мы так итерационно прийдем к тысячным тиражам. А если оценить шансы (когда памяти для C не хватает, а ассемблером можно еще вписаться) и учесть то, что поддерживать и контролировать ассемблерный код в разы дороже, то написание всего проекта на ассемблере не окупится вообще никогда. Именно поэтому, при производстве ПО, на ассемблере пишут программисты себестоимостью от $50 в час и только очень незначительную часть кода всего проекта, где использование ассемблера действительно необходимо. А при таком подходе, понятно, что использование ассемблера в виде ассемблерных вставок на C очевидно выгодней.
На мой вгляд, целиком на ассемблере сейчас проекты пишут только два типа людей:
1. Те, для кого ассемблер просто хобби. Ради фана, при наличии свободного времени.
2. Безработные, которым время все равно девать не куда.

Безусловно, для проектов на МК умение программировать на ассемблере желательно. Но уже давно это умение не является необходимым. А вот умение программировать на C, IMHO, необходимо любому программисту.
Другое дело, что народ из крайности в крайность бросается, начиная городить объектно-ориентированные модели на МК. Но это уже из другой оперы. Я о C++ вспоминаю, только если у меня памяти заведомо больше, чем может потребоваться проекту даже в дальней перспективе.

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

Ладныть...
Усе хорошо в меру умеренного потребления и для соответствующего места (иначе потравиться и лечебным препаратом можно).
По вопросу ассемблера...
Когда делается небольшая самоделка (полностью на своей схемотехнике) без такового не обойтись.
Когда используется уже кем-то разработанное устройство то для сокращения времени разборов с конфигурацией и прочими наворотами предпочтение высокоуровневому языку (а то, что какой-то разработчик ранее позаботился о создании библиотек,
БИОС и прочего для данного блочка нас вобщем уже не интересует).
НО... стоит только отступить от "стандартных правил использования" или попытаться намутить "отсебятинку" как в большинстве случаев у "начинающих" появляется призрак бело-пушистого... (не котейки!)...
Теперь про библиотеки-макросы в применении к ассемблеру от Атмел (студио 4.19 и проччее...)...
Библиотечные решения хороши для абстракций, отвлеченных от железа - математика, всяческие преобразования - то, что основано на ядре и системе команд, но не касается прикладных аппаратных модулей.
Макрос - больше как создание "недостающих" микрокоманд, возможно целевых блоков программной конфигурации аппаратных средств (своеобразный базовый БИОС для конкретного кристалла).
И при всем прочем раскидаем проект по разным файлам, имеющим соответственные задачи.
Воть как-то так...

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

В общем случае, без ассемблера на любой платформе не обойтись. В ядре любой ОС есть ассемблерные вставки. Ведь даже в том же C нет операторов ввода-вывода. Я призывал не увлекаться ассемблером, так как этим не только увеличиваете трудозатраты, но и понижаете надежность и безопасность кода.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

От АСМа сейчас толку не больше, чем от применения коммутаторных лампочек вместо светодиодов.
Это некоторые не могут обойтись, а другие обходятся и вполне успешно. Для новичков АСМ вообще неподъёмный груз, а профи его практически не юзают.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Объясните, пожалуйста, как на C можно что-то вывести в порт или прочитать из порта, если вдруг архитектура не позволяет обратиться к порту через адресное пространство памяти? (например, x86)
Так же очень интересно было бы увидеть код на C, останавливающий выполнение команд (sleep), обеспечивающий задержку на 1-2 такста, запрещающий и разрешающий прерывания.

Я прошу именно код на С, а не вызов функции C, уже содержащей в себе ассемблерную вставку.

Достали! Тема называется Ассемблер (ASM) для AVR в вопросах и ответах.

Зависит от кривизны toolchain. В общем случае - да, подходят.
"If your code needs to support multiple assembler dialects (for example, if you are writing public headers that need to support a variety of compilation options), use constructs of this form:
{ dialect0 | dialect1 | dialect2... }"
Пруф: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html


Докажите.

Код где?

А что, выходной код на АСМе? Не будьте так смешны! Бросайте свои РС-привычки, МК это вам не РС.

И потом, вам уже сказали открытым текстом

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


Внимательно прочитайте название темы. Видите слово "Микроконтроллеры"? Ну так приведите пример проекта для МК, который обходится без указателей на любом языке.

Добавлено after 3 minutes 48 seconds:

Я прошу Вас доказать, что Ваше утверждение

истинно. Каким образом Вы можете это доказать, я написал:

Поддерживаю мнение!
От себя добавлю...
Высказывания некоторых Котов, при всем уважении к их породистости,
вместо развития темы навыков использования компиляторов ассемблера
весьма напоминают собор святой инквизиции на тему
"осуждение и обоснование запрета изучения неверной трактовки
великого СИ, представляемой еретиками-ассемблеристами и вселенской ереси
их (сторонников демона-асмодея) высказываний и учений".

Ежли у кого чего в ответ - просю в личку, дабы тему не размывать.

Парни помогите, компилирую это в avrasm2:

получаю бред какой-то:

это глюк компилятора, или закон какой-то против меня?

Однако:

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

Для оперативного управления с помощью МК каким-либо процессом часто важна скорость, что хорошо реализуется в макроассемблере. Думаю, поэтому по этой причине не только безработные и «для хобби» пишут на макроассемблере.
Ну и ещё и гибкость. Например, легко рассчитать нужный логарифм под потребности задачи (медленный и точный, быстрый и не такой точный).

Не вижу проблем в поддержке и контролировании кода на макроассемблере.

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



Что значит часто? По мне, когда она нужна - тогда и делаем ассемблерную вставку. Получается ~1-2% всего кода, если, конечно не весь проект из сотни строк.


Расскажите. Я действительно не в курсе. Для C я знаю множество автоматизированных средств контроля за надежностью и безопасностью кода. Наиболее распостранены MISRA, PVS, ITS и т.п.
С поддержкой тоже не понятно. Разве 10 библиотек для 10 архитектур менее проблематично поддерживать, чем одну C библиотеку для этих же 10 архитектур?

Народ, помогите юзверю.
на тини 13 нужно прерывание по совпадению, а оно судя по моделированию не происходит. перепроверил уже по 100500 раз все регистры - вроде все верно установлено. В режиме "по переполнению" все фурычет.

Суть программы:
в осн цикле выводим в порт данные для 5-ти сдвиговых регистров (матрица 8*32)
Во время прерывания идет вмена выводимых данных (кроме 1-го, который мотает в основном цикле для динамического отображения по 8-ми столбцам)

код прилагаю:

Спойлер

.include "output\tn13def.inc"
;======================



;======================

;******************************* обзываем переменные ****************************

.def Temp=R16
.def Temp1=R17
.def Temp2=R18
.def Temp3=R19
.def countsht=R20



.dseg
;******************************** ЗДЕСЯ **********************************
;******************************** выпрашиваем у компилятора чуток ОЗУ **********************************
;******************************** для хранения "личных данных" **********************************
stroka: .byte 4
stolbik: .byte 1
.cseg
;*************************** Вектора прерываний ************************
.org 0
rjmp RESET
rjmp INT_0 ; External Interrupt 0
rjmp PCI0 ; External Interrupt Request 0
rjmp OVF0 ; Timer/Counter0 Overflow
rjmp ERDY ; EEPROM Ready
rjmp AnaComp ; Analog Comparator
rjmp OC0A ; Timer/Counter Compare Match A
rjmp OC0B ; Timer/Counter Compare Match B
rjmp WDT ; Watchdog Time-out
rjmp ADCC ; ADC Conversion Complete

;RESET:
INT_0:
PCI0:
OVF0:
ERDY:
AnaComp:
;OC0A:
OC0B:
WDT:
ADCC:
reti

;********************** обработчик прерывания переполнения таймера *********************
;********************** TIMER0_OVF *********************
OC0A: in R15,SREG
ldi Temp,0
out TCNT0,Temp ;обнуляем счетный регистр
rcall effects

exitoc0a:
out SREG,R15
reti





RESET:

;*********************** инициализация МК **********************
ldi countsht,0
ldi Temp,1
sts stroka,Temp
ldi Temp,2
sts stroka+1,Temp
ldi Temp,3
sts stroka+2,Temp
ldi Temp,4
sts stroka+3,Temp
ldi Temp,1
sts stolbik,Temp

ldi Temp,0b11111111 ;настройка портов
out DDRB,Temp

ldi Temp,0
out TCNT0,Temp ;обнуляем счетный регистр

ldi Temp,0b00001000 ;разрешить прерывание по переполнению таймера/счетчика 0
out TIMSK0,Temp

ldi Temp,0b00001000 ;Флаг наступления прерывания по переполнению
out TIFR0,Temp

ldi Temp,0b00000010 ;режим работы "сброс при совпадении"
out TCCR0A,Temp

ldi Temp,0b00000100 ;тактовый сигнал = CK/256
out TCCR0B,Temp

ldi Temp,RamEnd ;установка указателя стека
out SPL,Temp

ldi Temp,255 ;регистр сравнения
out OCR0A,Temp

ldi Temp1,0b00000000
sei

;**************************** ****************************
;**************************** Основной цикл программы ****************************
;**************************** ****************************


main:
rcall shifting

cbi PORTB,1
sbi PORTB,1
cbi PORTB,1
rcall dealey
rjmp main

Во вложении полный текст и схема для Протеус 7

Ваш код не смотрел.
Не знаю для всех ли AVR, но в протеусе прерывание по совпадению в нормальном режиме счетчика не работает (не помню на каком МК выяснил). Включаешь СТС - работает.

спасибо за подсказку, помогло

А в прерывании забыл убрать после предыдущего эксперимента )

Но мне не нужно «поддерживать все используемые архитектуры». Вполне достаточно АВР. Здесь есть и библиотека, и отработанные решения, и знание всяческих тонкостей. Отрабатывать всё это на новом семействе МК пока не вижу смысла — большие затраты времени — и для чего?


Не всегда получается 1-2%. Знакомый, умеющий писать на СИ, довольно большую программу писал на АБ — скорость нужна была. Причем что-то серьёзное, для военных. У себя я, естественно, процент не считал, хотя были разные случаи.
Но это, конечно, несущественное замечание.
Основная проблема — удобство написания. Конечно, СИ лучше ассемблера, а вот сравнение с макроассемблером - вопрос.
На мой взгляд, метод программирования в АБ лучше подходит для МК. Но, наверно, автору АБ для зарабатывания денег надо было после существенного усовершенствования новую версию продавать по дополнительной цене. Кто «подсел» на АБ — купит.
Нужна, конечно, отработанная библиотека. Чтобы окупить затраты на создание мощных библиотечных элементов их можно продавать отдельно. Ежели 1000 пользователей, да за 1000 рублей, то тут хорошая сумма получается. Но я тут совсем не специалист.

Для АБ, насколько знаю, нет автоматизированных средств контроля.
Насколько представляю, средства контроля для СИ проверяют правила написания программ для сложного компилятора. В ассемблере сложного компилятора нет.
Что должны делать средства контроля для ассемблера?
Надёжность кода — большая тема.
Для надёжности кода, во-первых, соблюдение ряда правил при написании, во-вторых, тестирование.
Правила при написании простые, например:
- Никаких «боковых» выходов из вызываемых подпрограмм. Только стандартный выход, при необходимости устанавливается флаг.
- Минимум действий в прерывании. Практически почти во всех случаях в прерывании только устанавливаю программный флаг. Флаг из-за специфики АБ выбирать в регистрах РОН.
- Обеспечение выхода из возможных точек зависания.
И т.д.
Неплохо бы, чтобы какая-нибудь программа контролировала выполнения правил, но это малосущественно, правила простые и легко автоматически выполняются при некотором навыке.
Программирование упрощается. Скажем, подпрограммы деления или логарифма в примере можно просто вызывать в любом участке программы не думая о регистрах, о возможности наложения переменных и т. д.
Тестирование — тоже большая тема. Скажем, в программе есть обработки дефектов в работе и аварийных ситуаций. Для проверки надо имитировать такие ситуации, а это канительно и иногда неясно, как сделать. Как имитировать воздействие помехи на кабель, по которому обмениваются два МК? Не знаю, может быть есть специальные генераторы помех, поднёс к кабелю и проверяй.
Тестирование проводят испытатели. Затем аппараты передаются в опытную эксплуатацию пользователям, скажем, на год. После отработки замечаний, вроде как, должно надёжно работать.

Библиотека у меня, как уже писал, только для АВР. Что-то иногда добавить по мелочи или подкорректировать - это не проблема.
Вот когда понадобится мощный библиотечный элемент, а его у меня нет, тогда, конечно, того...
Но, во-первых, такое бывает редко, во-вторых, думаю, такой созданный элемент будет более оптимален для решаемой задачи, в-третьих, создание элементов — увлекательное занятие.