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

[JackSmith]

Кто-нибудь знает ответ на вопрос, зачем потребовалось объявлять данные регистры в виде массива? Должна же быть какая-то причина.

так делается для работы с ними в циклах.

[a5021]

Если честно, я как-то не очень представляю назначение альтернативных функций выводам МК в цикле. Нет, делать это, разумеется, можно. Делать сколь-нибудь осмысленно, с этим проблема.

[JackSmith]

Если честно, я как-то не очень представляю назначение альтернативных функций выводам МК в цикле. Нет, делать это, разумеется, можно. Делать сколь-нибудь осмысленно, с этим проблема.

немного погугил. часто используется такая конструкция: GPIOx->AFR[Pin>>3]
https://github.com/LonelyWolf/stm32/blo ... iph/gpio.c

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

void GPIO_af_cfg(GPIO_TypeDef *GPIOx, uint16_t Pin, uint8_t AF) {
	uint32_t AFR = GPIOx->AFR[Pin >> 3];

	// Set the alternative function for a GPIO pin
	AFR &= ~GPIO_AF_MSK(Pin & 0x07);
	AFR |=  GPIO_AF_SET(Pin & 0x07,AF);

	// Write new value of the alternate function register
	GPIOx->AFR[Pin >> 3] = AFR;
}

[a5021]

Три раза протер глаза, но цикла в данном примере так и не увидел.

[BorisSPB]

Все логично. При описании регистров AFR в виде массива проще вычислять регистр по номеру пина, а не так что для пинов 0...7 AFRL, а для 8...15 AFRH. Как-то так ...

[dosikus]

Если использовать такую конструкцию и воспринимать порт как два по 8 бит, то все просто и прозрачно :

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

GPIOx->AFR[Port_Part]|=(AFR_volume<<(4*Pin_Number));

Где единственное магическое число -нибл ...

[a5021]

И куда оно выдвинет пятнадцатый пин, например?

[BorisSPB]

Задумка следующая:

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

GPIOx->AFR[Pin>>3] |= (Pin_value) <<((Pin & 0x7)<<2);

[a5021]

Это я уже проверил, сочинив два макроса, чтобы не "воспринимать порт как два по 8 бит":

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

#define SELECT_AF(GPIO, PIN, AF) GPIO->AFR[PIN >> 3] |= (AF << 4 * ((PIN > 7) ? PIN - 8 : PIN));

#define CONFIGURE_AF(GPIO, PIN, AF) if (PIN > 7) {\
                                      GPIO->AFR[1] |= AF << (4 * (PIN - 8));\
                                    } else {\
                                      GPIO->AFR[0] |= (AF << (4 * PIN));\
                                    }

Во втором варианте "GPIO->AFR[n]" легко бы мог быть заменен на GPIO->AFRx.

Компилятор по ним генерирует идентичный код. Ваш вариант, также оформленный макросом

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

#define PIN_AF(GPIO, PIN, AF) GPIO->AFR[PIN >> 3] |= AF << ((PIN & 0x7) << 2)

ничего не меняет. Код получается тот же самый.

Еще я узрел в хедерах нижеследующий блок, который вообще все только запутывает:

Спойлер

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

/****************** Bit definition for GPIO_AFRL register  ********************/
#define GPIO_AFRL_AFRL0_Pos             (0U)                                   
#define GPIO_AFRL_AFRL0_Msk             (0xFU << GPIO_AFRL_AFRL0_Pos)          /*!< 0x0000000F */
#define GPIO_AFRL_AFRL0                 GPIO_AFRL_AFRL0_Msk                    
#define GPIO_AFRL_AFRL1_Pos             (4U)                                   
#define GPIO_AFRL_AFRL1_Msk             (0xFU << GPIO_AFRL_AFRL1_Pos)          /*!< 0x000000F0 */
#define GPIO_AFRL_AFRL1                 GPIO_AFRL_AFRL1_Msk                    
#define GPIO_AFRL_AFRL2_Pos             (8U)                                   
#define GPIO_AFRL_AFRL2_Msk             (0xFU << GPIO_AFRL_AFRL2_Pos)          /*!< 0x00000F00 */
#define GPIO_AFRL_AFRL2                 GPIO_AFRL_AFRL2_Msk                    
#define GPIO_AFRL_AFRL3_Pos             (12U)                                  
#define GPIO_AFRL_AFRL3_Msk             (0xFU << GPIO_AFRL_AFRL3_Pos)          /*!< 0x0000F000 */
#define GPIO_AFRL_AFRL3                 GPIO_AFRL_AFRL3_Msk                    
#define GPIO_AFRL_AFRL4_Pos             (16U)                                  
#define GPIO_AFRL_AFRL4_Msk             (0xFU << GPIO_AFRL_AFRL4_Pos)          /*!< 0x000F0000 */
#define GPIO_AFRL_AFRL4                 GPIO_AFRL_AFRL4_Msk                    
#define GPIO_AFRL_AFRL5_Pos             (20U)                                  
#define GPIO_AFRL_AFRL5_Msk             (0xFU << GPIO_AFRL_AFRL5_Pos)          /*!< 0x00F00000 */
#define GPIO_AFRL_AFRL5                 GPIO_AFRL_AFRL5_Msk                    
#define GPIO_AFRL_AFRL6_Pos             (24U)                                  
#define GPIO_AFRL_AFRL6_Msk             (0xFU << GPIO_AFRL_AFRL6_Pos)          /*!< 0x0F000000 */
#define GPIO_AFRL_AFRL6                 GPIO_AFRL_AFRL6_Msk                    
#define GPIO_AFRL_AFRL7_Pos             (28U)                                  
#define GPIO_AFRL_AFRL7_Msk             (0xFU << GPIO_AFRL_AFRL7_Pos)          /*!< 0xF0000000 */
#define GPIO_AFRL_AFRL7                 GPIO_AFRL_AFRL7_Msk                    

/****************** Bit definition for GPIO_AFRH register  ********************/
#define GPIO_AFRH_AFRH0_Pos             (0U)                                   
#define GPIO_AFRH_AFRH0_Msk             (0xFU << GPIO_AFRH_AFRH0_Pos)          /*!< 0x0000000F */
#define GPIO_AFRH_AFRH0                 GPIO_AFRH_AFRH0_Msk                    
#define GPIO_AFRH_AFRH1_Pos             (4U)                                   
#define GPIO_AFRH_AFRH1_Msk             (0xFU << GPIO_AFRH_AFRH1_Pos)          /*!< 0x000000F0 */
#define GPIO_AFRH_AFRH1                 GPIO_AFRH_AFRH1_Msk                    
#define GPIO_AFRH_AFRH2_Pos             (8U)                                   
#define GPIO_AFRH_AFRH2_Msk             (0xFU << GPIO_AFRH_AFRH2_Pos)          /*!< 0x00000F00 */
#define GPIO_AFRH_AFRH2                 GPIO_AFRH_AFRH2_Msk                    
#define GPIO_AFRH_AFRH3_Pos             (12U)                                  
#define GPIO_AFRH_AFRH3_Msk             (0xFU << GPIO_AFRH_AFRH3_Pos)          /*!< 0x0000F000 */
#define GPIO_AFRH_AFRH3                 GPIO_AFRH_AFRH3_Msk                    
#define GPIO_AFRH_AFRH4_Pos             (16U)                                  
#define GPIO_AFRH_AFRH4_Msk             (0xFU << GPIO_AFRH_AFRH4_Pos)          /*!< 0x000F0000 */
#define GPIO_AFRH_AFRH4                 GPIO_AFRH_AFRH4_Msk                    
#define GPIO_AFRH_AFRH5_Pos             (20U)                                  
#define GPIO_AFRH_AFRH5_Msk             (0xFU << GPIO_AFRH_AFRH5_Pos)          /*!< 0x00F00000 */
#define GPIO_AFRH_AFRH5                 GPIO_AFRH_AFRH5_Msk                    
#define GPIO_AFRH_AFRH6_Pos             (24U)                                  
#define GPIO_AFRH_AFRH6_Msk             (0xFU << GPIO_AFRH_AFRH6_Pos)          /*!< 0x0F000000 */
#define GPIO_AFRH_AFRH6                 GPIO_AFRH_AFRH6_Msk                    
#define GPIO_AFRH_AFRH7_Pos             (28U)                                  
#define GPIO_AFRH_AFRH7_Msk             (0xFU << GPIO_AFRH_AFRH7_Pos)          /*!< 0xF0000000 */
#define GPIO_AFRH_AFRH7                 GPIO_AFRH_AFRH7_Msk                    

[dosikus]

Любовь к макросам всегда печальна, хотя клоуну объяснять что-то бесполезно, пока сам не получит этими же граблями и заявит что сам все нашел...

[a5021]

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

[aam]

Здравствуйте! Как лучше сделать Фурье на STM32F030? Слышал, у ST есть библиотека для DSP. Стал смотреть - она вроде как для старших семейств F3/F4. Есть еще какие-то решения или лучше самому написать? Стал смотреть в Сети - как-то грустно все в плане стандартных библиотек для Фурье. Все почему-то сами для себя пишут, что для STM, что для AVR.

[scorpi_0n]

Любовь к макросам всегда печальна

Дв всё нормально. Новичковые вопросы от новичка в новичковой теме. СТМ предоставил несколько вариантов работы с AFR. Осталось дождаться результата. Ведь к чему-то a5021 ведёт? Только пока непонятно к чему.

[a5021]

Дв всё нормально. Новичковые вопросы от новичка в новичковой теме.

Старички, меж тем, не спешат делиться своими старичковыми представлениями, нафига AFR объявлен массивом, а в мануале описан двумя отдельными регистрами. Один особо бойкий старичок было предложил сдвигать маску AF влево, вплоть до шестидесяти позиций, но это скорее стоит списать на старческий маразм, чем на продукт мыслительного процесса.

СТМ предоставил несколько вариантов работы с AFR.

И какие это варианты?

Ведь к чему-то a5021 ведёт? Только пока непонятно к чему.

Особо ни к чему не веду. Думал, мож знает кто. Пока же все выглядит, как небрежность STM-овских индусов. Или может старички-знаточки могут пояснить, что означает комментарий к объявлению AFR:

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

  __IO uint32_t AFR[2];       /*!< GPIO alternate function low register,  Address offset: 0x20-0x24 */

Тут про какой-то low register говорят. А где high register тогда?

[ibiza11]

нафига AFR объявлен массивом, а в мануале описан двумя отдельными регистрами.

Вам уже ответили, что для удобства пользования. Или по-вашему в документации к МК нужно было написать, что 2 регистра в МК объявлены массивом? Вы путаете программный продукт и документацию на железо.

Один особо бойкий старичок было предложил сдвигать маску AF влево, вплоть до шестидесяти позиций, но это скорее стоит списать на старческий маразм, чем на продукт мыслительного процесса.

Что-то Вы путаете. Сдвиг там идет на 3 разряда, что равносильно целочисленному делению на 8. 15ый пин попадет как раз в 1 ую ячейку массива (15/8=1).

И какие это варианты?

Либо через массив, либо через L-H регистры.

Тут про какой-то low register говорят

Просто опечатка из-за копипасты.

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

[pokk]

Добрый день, не как не могу понять как работает Serial audio interface (SAI)
Из даташитов понял, что это модуль который настраивается на протоколы I2S, LSB or MSB-justified, PCM/DSP, TDM, AC’97, принимает данные и сохраняет у себя в буфере. Какой размер буфера не видал не где?

Тогда в чем отличие от простого подключения I2S с DMA?

[a5021]

Вам уже ответили, что для удобства пользования.

Это не очень убедительное объяснение. Неудобство возникает уже на этапе вспоминания AFR[0] -- это GPIOx_AFRL или GPIOx_AFRH из референса. Если индекс еще можно вычислять, как pinNo / 8, то сам pinNo все равно придется пересчитывать отдельно и тут все "удобство пользования" исчезает окончательно.

Или по-вашему в документации к МК нужно было написать, что 2 регистра в МК объявлены массивом?

Вообще-то я уже здесь упоминал, что не массив нужно было упоминать в документации, а в файле заголовков описать оба регистра так, как они приведены в документации. Во всей серии F0xx не так много "парных" регистров. Однако, для тех же ресиверов CAN парные регистры описаны раздельно (L и H), точно как в документации, а вот для альтернативных функций зачем-то потребовалось менять подход.

Вы путаете программный продукт и документацию на железо.

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

Что-то Вы путаете. Сдвиг там идет на 3 разряда, что равносильно целочисленному делению на 8. 15ый пин попадет как раз в 1 ую ячейку массива (15/8=1).

Я не про вычисление индекса массива говорил. Это вы, как раз, путаете. Речь шла о крайне неудачном предложении обращаться к регистру следующим образом:

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

GPIOx->AFR[Port_Part]|=(AFR_volume<<(4*Pin_Number));

Здесь 15-й пин не пересчитывается и сдвинет маску на 60 двоичных разрядов.

Либо через массив, либо через L-H регистры.

И как может выглядеть обращение по последнему варианту?

Просто опечатка из-за копипасты.

Копипасты откуда? У всей F0 регистр альтернативных функций в заголовках описан одинаково и везде наличествует этот самый опечаточный "low register".

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

Вы настаиваете, что слово "клоун", дважды и неспровоцированно отпущенное в пренебрежительной манере в мой адрес -- это меньшее оскорбление, чем мое беззлобное передразнивание "новичок-старичок" в ответ?

[dosikus]

Речь шла о крайне неудачном предложении обращаться к регистру следующим образом:

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

GPIOx->AFR[Port_Part]|=(AFR_volume<<(4*Pin_Number));

Здесь 15-й пин не пересчитывается и сдвинет маску на 60 двоичных разрядов.

[

Специально для "крайне неудачных" и было писано - порт как два по 8 , не 10 не 15 , а 8.
А если ты коверкаешь чужое, выставляя в выгодном тебе свете, что это как не клоуанада???

[a5021]

Какая в баню клоунада? Если я привожу код в качестве примера, то как бы кто ни фантазировал насчет пагубности макросов, использовать его можно и работать он будет будет только одним понятным и очевидным образом, плюс к нему не требуется дополнительных словесных пояснений и неких действий за сценой. И фиг кто "исковеркает чужое" и "представит в выгодном ему свете". Параметр Pin_Number вами никак не описан и нигде не оговаривается, что он должен быть "предвычислен" или "приведен" заранее. И получается у вас сдвиг влево на 60 разрядов для самого неблагоприятного случая.

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

[dosikus]

Как обычно , в своей манере высокопарного поноса , так и не заметил сути - то что я привел позволяет устанавливать AF для 8 пинов сразу, в отличии от от других приведенных здесь. Но ты продолжай, продолжай истерить о 15 пинах.