STM32 Ассемблер. Идеи и приёмы написания, Правила хорошего тона и макросы Опции

[allsettingsdone]

По ассемблеру для арм документации и разного рода примеров гораздо меньше для С. Начал осваивать и возникли сомнения, правильный ли подход частого использования макросов и где та грань, свыше которой не стоит заморачиваться с написанием кода. В ассемблера я не силён, в основном по-любительски пишу на С. Но вот раз начал осваивать асм, сделал несколько элементарных макросов для битовых операций, настройки и использования портов. Вопрос в том правильно ли это делать и использовать таким образом (когда в коде используются много макросов), или может быть есть более рациональный способ, как лучше писать на асме для арм. Вот примерчик:
STM32F100RB.
И что конкретно делает команда bfi R1,R2,#$Pin,#4 ?
Определение макросов:

Код

;--------------------------------------
;Start_GPIO_Conf $Port,$PinRange - начало настройки порта, где $Port - имя порта (GPIOA,..), $PinRange - верхняя/нижняя тетрада порта (GPIO_CR_H/GPIO_CR_L)
        macro
        Start_GPIO_Conf $Port,$PinRange
        mov32            R0,#$Port        ;загружаем в регистр "R0" имя порта (его код) из памяти
        ldr             R1,[R0,#$PinRange];загружаем в регистр "R1" значение по адресу из памяти "R0 + #GPIO_CR_H(0x00)" или "R0 + #GPIO_CR_H(0x04)"
        mend
;--------------------------------------
;GPIO_Conf          $Pin,$Mode - настройка ножек выбраного порта, где $Pin - номер ножки (CNF_Pin_0,..), $Mode - режим ножки (GPIO_OUT_50_PP,..)
        macro
        PinConfig         $Pin,$Mode
        movs             R2,#$Mode
        bfi             R1,R2,#$Pin,#4
        mend
;--------------------------------------
;End_GPIO_Conf      $Port,$PinRange - конец настройки порта, где $Port - имя порта (GPIOA,..), $PinRange - верхняя/нижняя тетрада порта (GPIO_CR_H/GPIO_CR_L)
        macro
        End_GPIO_Conf     $Port,$PinRange
        str             R1,[R0,#$PinRange];загружаем в память по адресу "R0 + #GPIO_CR_H(0x00)" или "R0 + #GPIO_CR_H(0x04)" значение "R1"
        mend
;--------------------------------------
;SetBit_GPIO    $Port,$Pin
        macro
        SetBit_GPIO        $Port,$Pin
        mov32            R0,#($Port + GPIO_BSRR)
        mov32            R1,#$Pin
        str                R1,[R0]
        mend
;--------------------------------------
;ResetBit_GPIO    $Port,$Pin
        macro
        ResetBit_GPIO    $Port,$Pin
        mov32            R0,#($Port + GPIO_BRR)
        mov32            R1,#$Pin
        str                R1,[R0]
        mend
;--------------------------------------

Использование в программе:

Код

;--------------------------------------
            Start_GPIO_Conf GPIOC,GPIO_CR_H
        PinConfig         CNF_Pin_9,GPIO_OUT_50_PP
        PinConfig         CNF_Pin_8,GPIO_OUT_50_PP
        End_GPIO_Conf     GPIOC,GPIO_CR_H
;--------------------------------------
        SetBit_GPIO        GPIOC,PIN9
        SetBit_GPIO        GPIOC,PIN8
;--------------------------------------

Пробный проект в Keil 5 прикреплен:

Сообщение отредактировал allsettingsdone - Jan 15 2014, 22:55

Прикрепленные файлы

 test11_ASM.7z ( 93.49 килобайт ) Кол-во скачиваний: 28

 

[Golikov A.]

Так вам про это и долдонят битый час

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

UART -> DR = Data;

а в ассемблере берется адрес + смещение этого регистра как константа, и в нее пихается содержимое регистра отвечающего за data.

Меняем процессор, меняем данные, меняем уарт, нажимаем откомпилировать код и все поехали дальше.

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

Может утрированно, но смысл именно такой. Ассемблерный код чтобы он был эффективный должен быть крайне порезан.

в С мы можем себе позволить
Data = (int)126/24*432/12.5;

но после компиляции в адрес даты будут пихать константу, и если допустим конструкция
TimeInHour = Tic/CPU_FREQ * 60 * 60; - понятно

то в асме будет деленный регистр в котором лежат данные Tic на константу, значение который фиг разгадаешь глядя на нее...
2.1428571428571428571428571428571e-5
а по уму должно быть не деление а умножение на
46 666.666666666666666666666666667
для клока 168 МГц.

И вот как по 46 667 через год вспомнит чего вы хотели, зачем и почему это должно изменится при смене клока.... ?

[jcxz]

в С мы можем себе позволить
Data = (int)126/24*432/12.5;
но после компиляции в адрес даты будут пихать константу, и если допустим конструкция
TimeInHour = Tic/CPU_FREQ * 60 * 60; - понятно
то в асме будет деленный регистр в котором лежат данные Tic на константу, значение который фиг разгадаешь глядя на нее...
2.1428571428571428571428571428571e-5

Вы не правы. Все современные ассемблеры точно так же умеют вычислять значения константных выражений. И даже 10 лет назад уже умели.
И даже более того - средства макроязыка в ассемблерах как правило более мощные чем препроцессор си.
Мне часто очень не хватает макро-возможностей асма в си, когда вспоминаю что мог позволить себе в асме...
Но си скован стандартом, а ассемблер - нет.
Хотя я совсем не поддерживаю ТС в его утопическом стремлении к чистому ассемблеру - жизнь его научит и отрезвит (в лице работодателя например)
(если он конечно будет профессионально заниматься программированием, а не как любитель).

PS: Кстати - совсем не согласен с тем кто тут писал что ассемблер ARM - сложный. Из всех асмов что я когда-либо изучал, этот - самый простой.
Достаточно хотя-бы взглянуть на асм TI DSP 5000-ного семейства.

[mantech]

Хотя я совсем не поддерживаю ТС в его утопическом стремлении к чистому ассемблеру - жизнь его научит и отрезвит (в лице работодателя например)
(если он конечно будет профессионально заниматься программированием, а не как любитель).

Если ТС уж так хочет сравнить си и асм, то пусть попробует написать поддержку файловой системы через УСБ флешку И потом еще попробует перенести все это счастье на другой проц... А мы посмотрим, сколь лет ему на это понадобится

ЗЫ. Мы все стремимся, используя более высокоуровневые языки, облегчить себе жизнь, потому что у заказчиков требования тоже растут неплохо. Если 5-10 лет назад им было достаточно настройки устройства через простейшую менюшку с кнопками вниз\вверх, то теперь подавай удаленный доступ, желательно через инет, обновление прошивки по 1 тычку кнопки и т.д. Идите в ногу со временем, а не занимайтесь глупостями в виде чистого асма!