Плохо читали тему. Речь идет о GNU AVR ассемблере, который все это умеет. Отлаживайтесь на уровне исходного кода, сколько влезет.


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

вот пример из моих файлов:

на выходе получаем 4 десятичные цифры в ASCII коде, готовые к выводу на дисплей.

Может так проще и быстрее?

Спойлер

.equ AtBCD0 = 4 ;address of r4 для подпрограммы BIN2_BCD
.equ AtBCD2 = 6 ;address of r6

BIN_BCD:
; Input (r17:r16) output BCD number (r6:r5:r4:r3:r2).
; High registers used: 4(r16,r17,r18,r19)
; Pointers used: Z

ldi r18,16 ;Init loop counter
clr r6 ;clear result (3 bytes)
clr r5
clr r4
clr ZH ;clear ZH (not needed for AT90Sxx0x)
bBCDx_1:
lsl r16 ;shift input value
rol r17 ;through all bytes
rol r4 ;
rol r5
rol r6
dec r18 ;decrement loop counter
brne bBCDx_2 ;if counter not zero
; распределим числа по ячейкам
ldi r18,0x0F
mov r2,r4
and r2,r18
swap r4
mov r3,r4
and r3,r18
mov r4,r5
and r4,r18
swap r5
and r5,r18
ret ;return

bBCDx_2:
ldi r30,AtBCD2+1 ;Z points to result MSB + 1
bBCDx_3:
ld r19,-Z ;get (Z) with pre-decrement
subi r19,-$03 ;add 0x03
sbrc r19,3 ;if bit 3 not clear
st Z,r19 ;store back
ld r19,Z ;get (Z)
subi r19,-$30 ;add 0x30
sbrc r19,7 ;if bit 7 not clear
st Z,r19 ;store back
cpi ZL,AtBCD0 ;done all three?
brne bBCDx_3 ;loop again if not
rjmp bBCDx_1

На "гномике" его преимущества и заканчиваются По сравнению с тем же fasm-ом GAS убог по части макроязыка. Вероятнее всего потому что он не ориентирован на использование в качестве самостоятельного инструмента.

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

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

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

Спойлер

Код:

bin_to_4_decimal_digit:
clr R13
clr R12                    ; очистим старшие байты
ldi R17, high(10)
ldi R16,  low(10)
rcall div_32_16_16_16
mov R13, R12
rcall div_16_8_8_8
mov R12, R11
clr R11                    ; очистим старший байт
rcall div_16_8_8_8
ldi R18, '0'               ; символ "0"
add R13, R18
add R12, R18
add R11, R18
add R10, R18
ret

невооруженным глазом видно, что длина кода значительно короче.
к тому же, у меня вообще не используется обращение к ОЗУ.

Проверил программы преобразования "двоичного числа, (не более 9999), в 4 десятичных цифры"
Для проверки выбрано одно число 9876
dr.doc
777 тактов
Starichok51
397 тактов
адаптированная программа отсюда
294 такта

Пытался узнать как работает преобразователь у Atmel. Бросил, слишком много нужно дефайнить. Может для ценителей символики будет интересно.

10:38
Проверил программу от Atmel. Получилось
297 тактов

Спойлер

Код:

   .include "m8def.inc"
.def   rmp=r20

.def   rBin1L=r21
.def   rBin1H=r22

.def   rBin2L=r24
.def   rBin2H=r25
; Bin2ToBcd5
; ==========
; converts a 16-bit-binary to a 5-digit-BCD
; In: 16-bit-binary in rBin1H:L, Z points to first digit
;   where the result goes to
; Out: 5-digit-BCD, Z points to first BCD-digit
; Used registers: rBin1H:L (unchanged), rBin2H:L (changed),
;   rmp
; Called subroutines: Bin2ToDigit

GO:
   LDI   XH,HIGH(RAMEND)
   LDI   XL,LOW(RAMEND)
   OUT   SPH,XH
   OUT   SPL,XL

   LDI   rBin1H,HIGH(9876)
   LDI   rBin1L,LOW(9876)
   RCALL   BIN_BCD
   RJMP   GO
BIN_BCD:
Bin2ToBcd5:
   CLR   ZH
   LDI   ZL,10
;   push rBin1H ; Save number
;   push rBin1L
;   ldi rmp,HIGH(10000) ; Start with tenthousands
;   mov rBin2H,rmp
;   ldi rmp,LOW(10000)
;   mov rBin2L,rmp
;   rcall Bin2ToDigit ; Calculate digit
   ldi rmp,HIGH(1000) ; Next with thousands
   mov rBin2H,rmp
   ldi rmp,LOW(1000)
   mov rBin2L,rmp
   rcall Bin2ToDigit ; Calculate digit
   ldi rmp,HIGH(100) ; Next with hundreds
   mov rBin2H,rmp
   ldi rmp,LOW(100)
   mov rBin2L,rmp
   rcall Bin2ToDigit ; Calculate digit
   ldi rmp,HIGH(10) ; Next with tens
   mov rBin2H,rmp
   ldi rmp,LOW(10)
   mov rBin2L,rmp
   rcall Bin2ToDigit ; Calculate digit
   st z,rBin1L ; Remainder are ones
   sbiw ZL,4 ; Put pointer to first BCD
;   pop rBin1L ; Restore original binary
;   pop rBin1H
   ret ; and return
;
; Bin2ToDigit
; ===========
; converts one decimal digit by continued subraction of a
;   binary coded decimal
; Used by: Bin2ToBcd5, Bin2ToAsc5, Bin2ToAsc
; In: 16-bit-binary in rBin1H:L, binary coded decimal in
;   rBin2H:L, Z points to current BCD digit
; Out: Result in Z, Z incremented
; Used registers: rBin1H:L (holds remainder of the binary),
;   rBin2H:L (unchanged), rmp
; Called subroutines: -
;
Bin2ToDigit:
   clr rmp ; digit count is zero
Bin2ToDigita:
   cp rBin1H,rBin2H ; Number bigger than decimal?
   brcs Bin2ToDigitc ; MSB smaller than decimal
   brne Bin2ToDigitb ; MSB bigger than decimal
   cp rBin1L,rBin2L ; LSB bigger or equal decimal
   brcs Bin2ToDigitc ; LSB smaller than decimal
Bin2ToDigitb:
   sub rBin1L,rBin2L ; Subtract LSB decimal
   sbc rBin1H,rBin2H ; Subtract MSB decimal
   inc rmp ; Increment digit count
   rjmp Bin2ToDigita ; Next loop
Bin2ToDigitc:
   st z+,rmp ; Save digit and increment
   ret ; done
.exit

Так и в моем примере обращение к ОЗУ не нужно. вся работа выполняется в РОН. А наращивание разрядности насколько сложно в Вашем коде? В предложенном мной - добавить несколько строчек.

извини, я совсем упустил из виду, что по Z можно обращаться и к регистрам.
нарастить разрядность в моем коде можно, так как моя подпрограмма деления (div_32_16_16_16) принимает в себя 32 бита. но время выполнения вырастет значительно.
да, такой алгоритм, как сделано у тебя, мне сразу понравился (еще несколько страниц назад, когда была дана ссылка на такой алгоритм). разрядность наращивается совершенно без проблем.
в одной программе я получаю 6 десятичных разрядов. так пришлось сначала разделить число на 10000, а потом обрабатывать полученные части числа.
но я "примерю" этот алгоритм к своему 6-разрядному числу. возможно, получится выгоднее, чем у меня сделано сейчас с разбиением числа на части.

Добавлено after 2 hours 27 minutes 39 seconds:
сделал я примерку алгоритма от dr.doc для обработки 6-разрядного десятичного числа.
у меня
- получение 6 цифр,
- анализ на лидирующие нули (где поставить точку),
- преобразование в ASCII,
- вывод на индикатор
занимает 45 строк.

а по алгоритму от dr.doc только получение 6 цифр заняло 43 строки. а еще нужно сделать
- анализ на лидирующие нули (где поставить точку),
- преобразование в ASCII,
- вывод на индикатор

таким образом, менять свой алгоритм я не вижу смысла.

А причем CPP, если тут обсуждаются возможности ассемблеров? Да, GAS как самостоятельный инструмент - это УБОЖЕСТВО, и я не устану это повторять, хоть это и больная мозоль адептов гнутых компилеров. Если писать исключительно на асме, то GAS по сравнению с тем же fasm - это тьма беспросветная и жуть жуткая. Кто утверждает обратное - тот очевидно не знаком с fasm.

Компилятор соответствует структуре ядра и принятой системе адресации для конкретного семейства.
Нет смысла добавлять АВРкам свойства I8086 - там и имеющегося при правильном/полном использовании с избытком сделано. Ежли охота "экстриму" - попробуйте ассемблер для STM8...

Другое дело, что в большинстве случаев народ понимает под работой с ассемблером или написание примитивов "по Заецу" или написание коротких вставок под общей обработкой в СИ.

Потому что использование GNU ассемблер без С препроцессора (CPP), сродни использованию fasm без макросов. В GNU toolchain AS лишь один из компонентов, и не надо его выдирать отдельно. Вам же не приходит в голову ездить на автомобиле без двигателя, запрягая лошадь? )
А когда утверждения тупо повторяют без доказательств, это называется догматизм. Потому и я подумал, что Вы священнослужитель. У них именно так принято )

ptr128 абсолютно прав про использование GNU ассемблера.
Это не инструмент, которым можно заниматься.
А, где можно скачать fasm под AVR? Че-то не могу найти?

Starichok51 писал(а):

Данный алгоритм я впервые встретил у Корабельникова, когда изучал PIC. А уже потом встретил и его родоначальника, но, к сожалению, запямятовал первоисточник.
Еще один плюс данного алгоритма - его обратимость. Когда писал частотомер/цифровую шкалу приходилось переводить вводимую ПЧ, так вот подсчет "в лоб" оказался очень громоздким. Проще вышло инвертировать BIN-BCD в BCD-BIN.

Во-первых, Вы не правы, считая компилятор платформозависимым. Например, LLVM toolchain не содержит ни одного платформозависимого компилятора, что не мешает ему успешно конкурировать с тем же GCC.
Во-вторых, что-что, а уж макросредства ассемблера точно не зависят от целевой платформы. Напирмер, я (и далеко не только я) в свое время успешно использовал макроассемблер IBM/370 при компиляции ассемблерного кода для i8048, i8080 и Z80. И то, что все все мнемоники машинных команд IBM/370 были закрыты макросами, и макросами же генерился бинарный код машинных команд - никак не напрягало. В связи с тем, что макроассемблер IBM/370 изначально был предназначен для написания ассемблерного кода к любому процессору - это был штатный режим его работы. Ведь этим же макроассемблером писались программы и для каналов ввода-вывода, и для сопроцессоров, и даже для некоторых программируемых стоек управления. Все особенности структуры ядря и системы адресации без проблем учитываются при написаннии макроса, формирующего машинную команду или сегмент данных.

главное, все это в теме про ассемблер для AVR очень уместно.

https://flatassembler.net/download.php
flat assembler g

есть реализация под PIC, пробовал - вроде неплохо по сравнению с мплабовским ассемблером.
Народ применяет для 8048, 8080, 8085, Z80...

Да....
Таким образом можно любой макроассемблер приспособить.

https://github.com/avr-llvm/llvm


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

Под классическим ассемблером понимаю написание программ обычными ассемблерными командами: mov, ldi и т.д.
Макроассемблером условно называю язык АБ (Algorithm Builder), в котором широко используются макрокоманды и подпрограммы с параметрами. Встроенные макрокоманды расширяют действия обычных ассемблерных команд на многобайтные переменные. Скажем, а — 4-хбайтная переменная в SRAM, b - 4-хбайтная переменная в EEPROM, сложить эти переменные можно одной встроенной макрокомандой: a + b, наглядно и просто.

На мой взгляд, на макроассемблере АБ будет не «несколько меньше писанины», а глобальное упрощение программирования. Без примера такое заявление звучит неубедительно. Приведу простой пример из практики, измерительный прибор, который по затуханию сигнала определяет концентрацию вещества М.
Для такого измерения центральный МК должен считать с периферийного МК (расположен в блоке 1) опорный сигнал Vopor и измеренный после затухания сигнал Vizmer. Затем разделить один сигнал на другой, взять логарифм, провести калибровку, упаковать для вывода на индикатор и вывести на индикатор. Упрощённо на АБ программа будет выглядеть следующим образом:

Read_Blok_1 (Read_Vopor, Vopor, 4)
Delenie (Vopor, Vizmer, Itog_Delenia, 1)
Log_10 (Itog_Delenia, M)
Kalibrovka_1024 (M, ee_Koef_M)
Upakovka (M, Indicator)
Vyvod_Indikator

Это всё библиотечные элементы, только надо несколько настроить под параметры задачи.
Написать и отладить по времени займет, наверно день, два.
Объём будет довольно приличный . Один логарифм займет более 1 КБ, Read_Blok_1 (чтение данных от другого МК с проверкой, повторными запросами при неудачном обмене, чтением состояния периферийного МК и т.д.), вроде бы, ещё более мощный элемент.
Это, практически, ассемблер с его скоростью, гибкостью и небольшим объёмом кода.

Думаю, если бы АБ развили для других семейств МК, можно было бы программы без проблем переносить на другие семейства. Сошлюсь на вашу фразу: «Все особенности структуры ядра и системы адресации без проблем учитываются при написании макроса, формирующего машинную команду».

Думаю, можно было развить и анализ на надёжность и безопасность и прочее. Вопрос в том, кто будет это делать. Труда много, а этот труд денег не принесёт. Более того, для производителей МК будет ещё и убыток, ведь объём написанных программ будет значительно меньше, значит, будут покупать более дешёвые МК.
Получается, наработались, а прибыли упали. Капиталисты деньги считают.