STM32 новичку в ARM что к чему

[polyname]

так там как раз проще - атомарное чтение бита одной командой, вместо нескольких команд - чтения порта, лог.И с маской, и проверка на 0.

[menzoda]

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

Посему делаю вывод, что использовать эту конструкцию нужно только, если есть необходимость именно в атомарном изменении битов (например, всякие семафоры и прочие объекты синхронизации).

Да, такой код я бы тоже не использовал:

Код: Выделить всё

code[cod_bit] = (GPIOA->IDR&(1<<5))!=0;

Лучше мой вариант:

Код: Выделить всё

code[cod_bit] = GPIOA->IDR >> НОМЕР_БИТА & 1;

Потому-что логическая операция != может превратиться в инструкцию сравнения (которая, обычно, выполняется за большее кол-во тактов) и не дай бог ветвления (которая 100% выполняется за большее кол-во тактов и вероятно сбрасывает конвейер).

[urry]

Потому-что логическая операция != может превратиться в инструкцию сравнения (которая, обычно, выполняется за большее кол-во тактов) и не дай бог ветвления (которая 100% выполняется за большее кол-во тактов и вероятно сбрасывает конвейер).

мля... ну пусть меня на этом месте забанят...
ну нельзя же настолько не знать си !!!

[polyname]

это все-таки специфичная штука, которая есть не у каждого МК

она есть у всех Cortex (ссылку я дал выше), и тема вроде бы про STM32

фича сделана для атомарной модификации битов

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

Код: Выделить всё

code[cod_bit] = (GPIOA->IDR&(1<<5))!=0;

можно записать и так:

Код: Выделить всё

code[cod_bit] = !!(GPIOA->IDR&(1<<5));

на счет лишних инструкций - можно надеяться на разумность компилятора

[Аlex]

menzoda, идея с копированием битов в массив уже изначально хреновая. Так что разницы нет, что будет стоять после code[cod_bit] =, т.к. в любом случае, конструкция будет конвертироваться в байт/слово/....

Потому-что логическая операция != может превратиться в инструкцию сравнения .........

Тут я полностью солидарен с urry. Я не видел ни оного компилятора, разворачивающего конструкцию типа (var & (1<<n))!=0 в какие-то сдвиги с проверками на ноль. Разьве что самый тупой компиль на свете...
По этому, Ваш вариант не лучше, он просто-напросто другой. В моём варианте конструкция имеет логическое выражение (true или false), а в Вашем - значение, состоящие из n-ного кол-во байт, со всеми сброшенными битами, кроме 0-вого. Причём, как раз, именно Ваша конструкция и будет разворачиваться в чтение и сдвиги с последующей операцией "И".

зато код все равно короче за счет ненужности лог.И и сдвига в 0й бит.

Какой код короче ? Если исходный, то может быть, но не АСМ:

В Вашем коде и моём, 3 первых команды одинаковые, дальше, в моём коде идёт переход, а в Вашем ещё что-то делается...
Назревает вопрос. С чего Вы взяли, что Ваша конструкция атомарна, а моя нет ?

PS: Кстати, Ваш код у меня не заработал. Может адреса периферии не те, не знаю...

[polyname]

во 1х перед BITP нужна звездочка * для чтения по заданному адресу, во 2х "if" не нужен - содержимое нужного бита попадает сразу в 0й бит, поэтому достаточно прямого присваивания:

Код: Выделить всё

code[cod_bit] = *BITP(&GPIOA->IDR, 1);

[Аlex]

перед BITP нужна звездочка *

Добавил. Программа стала улетать куда-то, но это, наверное, из-за адресов. Но по коду не изменилось ничего, кроме добавления ещё двух команд (код стал "тяжелее"). 3 первых команды остались те-же. В чём отличие тогда, в плане атомарности, я до сих пор не понял...

во 2х "if" не нужен - содержимое нужного бита попадает сразу в 0й бит, поэтому достаточно прямого присваивания

А если мне нужно условие ?.

[urry]

code[cod_bit] = !!(GPIOA->IDR&(1<<5));
это был песец, по словам потапа и насти каменских
они, в отличии от вас, проверяют слова, прежде чем постить...
Последуйте их примеру.
Мне так откровенно жаль времени это опровергать.

[polyname]

но это, наверное, из-за адресов

адреса у всех кортексов одни и те же.

вот это:

Код: Выделить всё

   volatile U8 code[10];
   code[0] = *BITP(&GPIOA->IDR, 1);
   code[1] = *BITP(&GPIOA->IDR, 1);

у меня компилируется в это:

Код: Выделить всё

 8000564:   4b35         ldr   r3, [pc, #212]   ; (800063c <main+0xdc>)
 8000566:   2000         movs   r0, #0
 8000568:   781a         ldrb   r2, [r3, #0]
 800056a:   f88d 2004    strb.w   r2, [sp, #4]
 800056e:   781b         ldrb   r3, [r3, #0]
 8000570:   f88d 3005    strb.w   r3, [sp, #5]
 800063c:   42210104    .word   0x42210104

видно что чтение - одна команда.

это был песец, по словам потапа и насти каменских

что вас так испугало ?

Код: Выделить всё

code[2] = !!(GPIOA->IDR&(1<<5));
 8000574:   4b35         ldr   r3, [pc, #212]   ; (800064c <main+0xec>)
 8000576:   689b         ldr   r3, [r3, #8]
 8000578:   f3c3 1340    ubfx   r3, r3, #5, #1
 800057c:   f88d 3006    strb.w   r3, [sp, #6]

вполне приличный код.
Смотрим описание команды ubfx: http://infocenter.arm.com/help/index.js ... hjhee.html
Вроде все корректно и компактно. Двойное отрицание "!!" компилятор заменил прямым копированием бита.

Теперь попробуйте аргументированно поспорить.

[urry]

а смысл ? "Похвала глупости "
ну сами приведите код, где это работает, последовательные числа и все такое.
В процессе дойдет.
дальше
code[0] = *BITP(&GPIOA->IDR, 1);
code[1] = *BITP(&GPIOA->IDR, 1);
ну что это такое...

[спящий]

Подскажите как пользоваться в ИАРе printf? это какую библеотеку подключать?#include "stdio.h" чет непомогает(

[oleg110592]

тут почитайте: http://we.easyelectronics.ru/Soft/forma ... lerov.html
у Ti для Stellaris есть своя библиотека в utils/uartstdio.h в ней есть UARTprintf

[menzoda]

Буду парировать в порядке очередности. Но для начала эксперименты в Keil

Код: Выделить всё

array[index] = (GPIOA->IDR & (1 << 5)) != 0;
array[index] = GPIOA->IDR >> 5 & 1;

LDR      r0,|L1.24|            ; Загрузка адреса регистра GPIO
LDR      r0,[r0,#0x10]         ; Загрузка содержимого регистра GPIO
LDR      r2,|L1.32|            ; Загрузка адреса массива
LDR      r1,|L1.28|            ; Загрузка адреса индекса
UBFX     r0,r0,#5,#1         ; Извлечение бита
LDRSH    r2,[r2,#0]  ; index   ; Загрузка значения индекса
STRH     r0,[r1,r2,LSL #1]      ; Сохранение бита в ячейку массива


array[index] = (GPIOA->IDR & (1 << 5)) == 0;

LDR      r0,|L1.24|            ; Загрузка адреса регистра GPIO
LDR      r0,[r0,#0x10]         ; Загрузка содержимого регистра GPIO
LDR      r2,|L1.32|            ; Загрузка адреса массива
MOVS     r1,#1               ; Все понятно
BIC      r0,r1,r0,LSR #5      ; Извлечение бита
LDR      r1,|L1.28|            ; Загрузка адреса индекса
LDRSH    r2,[r2,#0]  ; index   ; Загрузка значения индекса
STRH     r0,[r1,r2,LSL #1]      ; Сохранение бита в ячейку массива


array[index] = (GPIOA->IDR >> 5 & 1) ^ 1;

LDR      r0,|L1.28|            ; Загрузка адреса регистра GPIO
LDR      r0,[r0,#0x10]         ; Загрузка содержимого регистра GPIO
UBFX     r0,r0,#5,#1         ; Извлечение бита
EOR      r0,r0,#1            ; Инвертирование бита
LDR      r1,|L1.32|            ; Загрузка адреса массива
LDR      r2,|L1.36|            ; Загрузка адреса индекса
LDRSH    r2,[r2,#0]  ; index   ; Загрузка значения индекса
STRH     r0,[r1,r2,LSL #1]      ; Сохранение бита в ячейку массива


array[index] = *BITP(&GPIOA->IDR, 1);

LDR      r0,|L1.20|            ; Загрузка адреса отображенного регистра
LDRB     r0,[r0,#0]            ; Загрузка содержимого отображенного регистра
LDR      r1,|L1.24|            ; Загрузка адреса массива
LDR      r2,|L1.28|            ; Загрузка адреса индекса
LDRSH    r2,[r2,#0]  ; index   ; Загрузка значения индекса
STRH     r0,[r1,r2,LSL #1]      ; Сохранение бита в ячейку массива

ну нельзя же настолько не знать си !!!

Что не так? Во что превратиться логическая операция в худшем случае?! Отвечай на мой ответ! Из эксперимента видим, что армовский компилятор умный и все сделал хорошо, но это не значит, что другие так же сделают. Например пиковский HI-TECH делал из такой конструкции ветвление! Ветвление черт-побери! Поэтому не надо использовать логические операции, если можно обойтись без них. Как говорят иностранцы - это rule of thumb.

она есть у всех Cortex (ссылку я дал выше), и тема вроде бы про STM32

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

разворачивающего конструкцию типа (var & (1<<n))!=0 в какие-то сдвиги с проверками на ноль

Я не про сдвиги говорил, а про CMP- и BRANCH-инструкции.

Я не видел ни оного компилятора

HI-TECH PIC Compiler, v9.71a вроде.

В моём варианте конструкция имеет логическое выражение (true или false)

В Си нету логических типов, но это все равно холиварная тема.

а в Вашем - значение, состоящие из n-ного кол-во байт, со всеми сброшенными битами, кроме 0-вого.

Первую часть предложения не понял. Какое кол-во байт? Но не суть, что у меня, что у вас одно и тоже на выходе: 0, если заданный бит сброшен (ваш false) и 1, если он установлен (ваш true).

Причём, как раз, именно Ваша конструкция и будет разворачиваться в чтение и сдвиги с последующей операцией "И".

Ну ясень пень! Ведь я же и использую операции сдвига и логического И.

Какой код короче ? Если исходный, то может быть, но не АСМ:

Как раз таки АСМ и короче, хотя на Си выглядит, как непонятная каша. Хотя, я не проверял как работает этот bit-banding, а просто скопировал и скомпилировал то, что человек тут запостил.

[Аlex]

В Си нету логических типов

Я не про типы говорю, а про выражение. В моём случае, после знака "=", находится условие, а в Вашем - результат выполнения неких инструкций (сдвиг, "И", ....). Разницу чувствуете ?

Ну ясень пень! Ведь я же и использую операции сдвига и логического И.

А почему же тогда Вы считаете свой вариант лучше ? А главное - чем лучше ?

Как раз таки АСМ и короче

Толи лыжЫ не едут, толи ......
Я привёл дизасм с условиями, в котором 2 разных варианта проверки бита. Где он короче ? Объясните тупому....
Так-же, объясните про разницу этих 2-х кусков, в плане атомарности.

PS: всё это не спора ради. Мне реально это интересно, т.к. я начал изучать эти МК всего пару недель назад.

[menzoda]

Ладно, насчет того, что же лучше != или & - бессмысленно спорить. Просто я руководствуюсь тем, что некоторые компиляторы могут из логических операторов сгенерировать не самый лучший код (пример с HI-TECH я приводил). Но я вполне допускаю, что и != может давать хорошие результаты. Получается, что надо смотреть на конкретном примере и выбирать лучшее решение, если, кончено, это даст хоть сколько-нибудь ощутимого преимущества.

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

Я привёл дизасм с условиями, в котором 2 разных варианта проверки бита. Где он короче ?

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

Насчет атомарности. Про нее имеет смысл говорить только при модификации бита, а не чтения! Например, у нас есть 16-битная переменная и нам необходимо изменить 3-й бит. Как это будет выглядеть в обычном случае? Читаем всю переменную в регистр процессора, модифицируем там 3-й бит, записываем получившиеся значение обратно в переменную. Между моментами чтения переменной и записи нового значения, ее содержимое может быть изменено кем-то другим. Не зная об этом, мы благополучно запишем в нее наше значение с модифицированным третьим битом, потеряв таким образом произошедшие с ней изменения. Это и есть не атомарность. Битбандинг (или как его там) позволяет этого избежать. Все. Зачем в этом посте начали связывать чтение и атомарность я не понимаю.

[Foks]

menzoda, насчет PeriphLib: разумеется, что программист должен знать аппаратные особенности МК, то бишь уметь программировать его на ассемблере. Однако писать сложный проект на асме - большие затраты по времени, поэтому большинство программистов работают на Си. Разумеется, нужно при этом читать/проверять/отлаживать листинг асм-кода, который в итоге генерируется, нужно знать тонкости своего компилятора и т.д.
Теперь проведём аналогию к библиотеке периферии: она дает тот уровень абстракции, который программист может удержать в голове и быстро им воспользоваться, зная насквозь как устроена эта библиотека, и понимая МК на аппаратном уровне. Однако, в этом случае программисту не нужно в голове держать многочисленные названия регистров, номера битов и т.д. Заодно программа становится намного более читабельной для других людей.
------
По поводу "кривого кода", я так понял намёк был в сторону GCC, и старого спора о его "компетентности". Так вот, лишние операции в асм-листинге удаляются только путём оптимизации. Каждой строке Си-кода (она может быть намного глубже Вашей программы, т.к. есть еще определения встроенных функций, в Си++ - даже простейшие мат. операции определены) сопоставляется блок асм-операций. Разумеется, что если взять не отдельную операцию на Си, а их блок, то в его листинге появится много повторяющихся/лишних и т.д. команд, которые убираются оптимизацией. Если какой-нибудь IAR генерирует вам сразу красивый код, то это только от того, что часть алгоритма оптимизации от Вас скрыли и запретили отключать. Весьма спорное преимущество. Не бывает алгоритмов, которые бы сразу из большого Си-кода сгенерировали оптимальный асм.
А по поводу работоспособности неоптимизированного кода, сгенерированного с помощью GCC, претензий вроде бы ни у кого и никогда не было.

(этот высер не имеет отношения к спору выше. плохо вставать в 4 часа вечера.)

[Аlex]

Про нее имеет смысл говорить только при модификации бита, а не чтения!

Зачем в этом посте начали связывать чтение и атомарность я не понимаю.

Вот они, ключевые фразы, которые я так долго ждал !
Я сам прекрасно понимаю, что при чтении данных, речи про атомарность и быть не может (если только чтение идёт не за один раз, например побайтно), по этому, мне так-же не понятно было зачем завели эту тему.
Спасибо за ответы.

[спящий]

Подскажите: чтобы использовать Fatfs на STM32L152,нужно ее подключить на машинном уровне? тоесть это в diskio.с (или еще где?) ,а остальное идет уже сама FAT?

#define SD_DI 0
#define SD_DO 1
#define SD_CLK 2
#define SD_CS 3
#define SD_INS 4
#define SD_WP 5
и еще пол файла переделать?) - я правильно думаю?

у когонить есть FATfs для STM32L152?или чтобы переделывать поменьше?


Написать отправку по SPI я смогу но совместить с Fatfs чет пока недопру.

[SubDia]

Вы должны обеспечить discio.c функциями аппаратного уровня, такими как запись/чтение сектора, инициализация карты, отправка команды карте и так далее. Исходник discio.c - это уже часть FatFS. Вообще, Чен указывал, какие функции разработчик должен писать самостоятельно для успешной работы с FatFS.
Поищите в сети, примеры должны быть. Год назад я использовал FatFS с STM32F407, но там все делалось на скорую руку, с "ногодрыжным" SPI, все это коряво и некрасиво.

[HHIMERA]

menzoda, насчет PeriphLib: разумеется, что программист должен знать аппаратные особенности МК, то бишь уметь программировать его на ассемблере. Однако писать сложный проект на асме - большие затраты по времени, поэтому большинство программистов работают на Си. Разумеется, нужно при этом читать/проверять/отлаживать листинг асм-кода, который в итоге генерируется, нужно знать тонкости своего компилятора и т.д.

Что-то это высказывание противоречит вашему нижеследующему высказыванию...
"Знать или не знать, вот в чём вопрос!"(С)

Теперь проведём аналогию к библиотеке периферии: она дает тот уровень абстракции, который программист может удержать в голове и быстро им воспользоваться, зная насквозь как устроена эта библиотека, и понимая МК на аппаратном уровне. Однако, в этом случае программисту не нужно в голове держать многочисленные названия регистров, номера битов и т.д.

Заезженный штамп горе-студентов-кармодрочеров с ДиАхтунга...
Себя хоть обманывать не надо... а то привыкнете...
Все "названия регистров, номера битов и т.д." лежат в h-файле МК...
СТДлиб предназначены для начального вхождения... и только... А дальше - всё наоборот... Чем больше проект содержит взаимодействия с периферией, тем больше проявляются ущербность, избыточность, тормознутость и неоптимальность... и чем выше уровень знаний, тем больше это проявляется и в итоге просто начинает раздражать...
И уж никакой "тот уровень абстракции", ни переносимость и пр. тут не при чём... никаких привелегий СТДлиб не даёт, не надо выдумывать... достаточно посмотреть вопросы на разных ресурсах... в итоге всё сводится к "читайте даташит и референс мануал, там всё написано"...

Заодно программа становится намного более читабельной для других людей.

Ну... если хочется быть другим... тогда ладно...