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

[a5021]

[uquote="ARV",url="/forum/viewtopic.php?p=4706668#p4706668"]С точки зрения программиста еще неизвестно, что лучше: сразу знать, что происходит, или вспоминать карту адресов...[/uquote]
и какие воспоминания каких адресов на вас норовят нахлынуть при виде такого кода?

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

TOGGLE_REG_BIT(GPIOC->ODR, GPIO_ODR_ODR13);

в том и красота приведенных макросов, что ни о чем больше не надо заботиться, если хочется щелкнуть каким-нибудь битиком.

Во-первых, в R2 и R4 адреса из воздуха материализовались?

пост не о таинстве экономии парочки байтов.

Во-вторых, ни на чём кроме некрофильского F1 это не работает, ибо порты не попадают в область BB.

ложное утверждение. еще как работает на F1, F2, F3, F4 и L1. и, да, я считаю, что STM32F103C8T6 по прежнему весьма хорош.

В-третьих, опять макросы, которые даже не подумают предупредить что параметры заданы неверно.

разве мысль о том, что в регистр TIM1->CR1 не стоит пихать что-то отличное от TIM_CR1_чегототам, является такой уж сложной для понимания? надо ли увлекаться гиперопекой в этом случае?

[ARV]

Вы не поверите: если всё обернуть в макрос, то и щелканье битиком даже с управлением по интернету через океан ничем от вашего примера отличаться не будет!

[JackSmith]

[uquote="a5021",url="/forum/viewtopic.php?p=4706742#p4706742"]разве мысль о том, что в регистр TIM1->CR1 не стоит пихать что-то отличное от TIM_CR1_чегототам, является такой уж сложной для понимания? надо ли увлекаться гиперопекой в этом случае?[/uquote]
не надо валить все в одну кучу. когда у меня в коде встречается именованная константа, то я могу навести на нее мышкой и посмотреть значение:

а когда я вижу что-то вроде:

#define GET_BIT(AREA, ADDR, BIT) *(__IO unsigned *)(AREA ## _BB_BASE + 32 * ((unsigned)&ADDR - AREA ## _BASE) + 4 * __builtin_ctz(BIT))

я считаю что автор пытается обфусцировать код. потому что:
1. профита от использования bit-banding никакого.
2. при портировании кода на другие архитектуры, все эти макросы придется переписывать. очевидно автор считает, что это будет делать не он.

[a5021]

[uquote="JackSmith",url="/forum/viewtopic.php?p=4706897#p4706897"]не надо валить все в одну кучу. когда у меня в коде встречается именованная константа, то я могу навести на нее мышкой и посмотреть значение:[/uquote]
а в моем случае, что вам мешает сделать то же самое? там ровно те же регистры и макроопределения, что и у вас.

1. профита от использования bit-banding никакого.

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

2. при портировании кода на другие архитектуры, все эти макросы придется переписывать. очевидно автор считает, что это будет делать не он.

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

[VladislavS]

[uquote="a5021",url="/forum/viewtopic.php?p=4706742#p4706742"]ложное утверждение.[/uquote]Посмотрите скриншот в моём сообщении, там видно адрес порта. Не может он там работать. Собственно, и не работает.

Добавлено after 8 minutes 32 seconds:
[uquote="a5021",url="/forum/viewtopic.php?p=4706742#p4706742"]надо ли увлекаться гиперопекой в этом случае?[/uquote]Надо. Если вы полезете BB в порты GPIO на том же F3, то компилятор должен, как минимум, покрутить у виска и не дать этого сделать.

[uldemir]

Силабы (Silicon Labs) сделали проще. В самой функции:

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

__STATIC_INLINE unsigned int BUS_RegBitRead(volatile const uint32_t *addr,
                                            unsigned int bit)
{
#if defined(BITBAND_PER_BASE)
  uint32_t aliasAddr =
    BITBAND_PER_BASE + (((uint32_t)addr - PER_MEM_BASE) * (uint32_t)32) + (bit * (uint32_t) 4);

  return *(volatile uint32_t *)aliasAddr;
#else
  return ((*addr) >> bit) & 1UL;
#endif
}

Если есть - пользуем бит-банд, а если нет - маску.

А ST до этого в HAL или LL - не додумался?

[VladislavS]

Это плохо. Ты рассчитываешь на атомарность, а он тебе RMW влепит.

[jcxz]

[uquote="JackSmith",url="/forum/viewtopic.php?p=4706897#p4706897"]а когда я вижу что-то вроде:

#define GET_BIT(AREA, ADDR, BIT) *(__IO unsigned *)(AREA ## _BB_BASE + 32 * ((unsigned)&ADDR - AREA ## _BASE) + 4 * __builtin_ctz(BIT))

я считаю что автор пытается обфусцировать код. потому что:
1. профита от использования bit-banding никакого.[/uquote]На чём основано это утверждение?

Добавлено after 1 minute 21 second:
[uquote="VladislavS",url="/forum/viewtopic.php?p=4706941#p4706941"]Это плохо. Ты рассчитываешь на атомарность, а он тебе RMW влепит.[/uquote]Там вроде только одно чтение. Причём тут RMW?

[Adrift]

[uquote="uldemir",url="/forum/viewtopic.php?p=4706940#p4706940"]Силабы (Silicon Labs) сделали проще.[/uquote]
Если в функцию volatile аргументы передавать, то дополнительные накладные расходы будут... Вообще самую крутую систему я в Pico видел, там атомарные Or/And/Xor работают практические со всеми регистрами, просто смещение к адресам добавляется. И в отличие от BB, время выполнения таких операций такая же как у обычной записи. А у Pico2 для портов есть сопроцессор и чтобы пин затоглить нужно вызвать соответствующую 32-х битную инструкцию которой только номер пина передается, никаких базовых адресов.

[jcxz]

[uquote="Adrift",url="/forum/viewtopic.php?p=4706950#p4706950"]А у Pico2 для портов есть сопроцессор и чтобы пин затоглить нужно вызвать соответствующую 32-х битную инструкцию которой только номер пина передается, никаких базовых адресов.[/uquote]Toggle GPIO пина на XMC4xxx Infineon:

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

#define Ptog2(port, pin)    (GPIO[port].OM = 0x10001u << (pin))
#define Ptog(port_pin)      Ptog2(port_pin)

Как видно - тоже просто запись в соответствующий IO-регистр.
не Pico единым!

[VladislavS]

[uquote="jcxz",url="/forum/viewtopic.php?p=4706948#p4706948"]Там вроде только одно чтение. Причём тут RMW?[/uquote]Интуиция подсказывает, что там где чтение, там и запись где-то рядом.

[Adrift]

[uquote="jcxz",url="/forum/viewtopic.php?p=4706952#p4706952"]

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

#define Ptog2(port, pin)    (GPIO[port].OM = 0x10001u << (pin))
#define Ptog(port_pin)      Ptog2(port_pin)

Как видно - тоже просто запись в соответствующий IO-регистр.[/uquote]
Допустим нужно затоглить GP40, значит сначала в регистр записывается 40, это делается 16-ти битной MOVS, а в вашем случае константа более жирная и инструкция скорее всего будет 32-х битная. Далее на Pico идет 32-х битная инструкция сопроцессора, а у вас будет запись в порт, перед этим загрузка адреса этого порта и еще отдельно сам этот адрес, суммарно ~96 бит. Или нет?

[jcxz]

[uquote="Adrift",url="/forum/viewtopic.php?p=4706958#p4706958"]Допустим нужно затоглить GP40, значит сначала в регистр записывается 40, это делается 16-ти битной MOVS, а в вашем случае константа более жирная и инструкция скорее всего будет 32-х битная. Далее на Pico идет 32-х битная инструкция сопроцессора, а у вас будет запись в порт, перед этим загрузка адреса этого порта и еще отдельно сам этот адрес, суммарно ~96 бит. Или нет?[/uquote]Я не знаю архитектуры этого самого Pico, потому не могу сказать про него ничего. Но знаю что у каждой архитектуры есть свои преимущества.

А насчёт "константы 40": Если мне нужно "затугглить" не один бит порта, а скажем = 8 соседних? То на XMC4xxx будет ровно та же самая инструкция записи. Только с другой константой. И toggle будет выполнен одновременно всеми пинами.
А на Pico для этого видимо нужно 8 команд? И ни о какой одновременности речи не может идти?

Насчёт выполнения сопроцессором (не знаю что это такое) - манипуляции с пинами на XMC4xxx можно выполнить вообще без процессора. Поручив DMA и таймеру пересылку потока инвертирующих констант в регистр правления GPIO. И не отвлекая основной поток программы от более важных дел. Возможно ли такое на Pico с его сопроцессором?

[a5021]

Посмотрите скриншот в моём сообщении, там видно адрес порта. Не может он там работать. Собственно, и не работает.

беру свои слова назад. по неведомой мне причине заголовочник stm32f303xc.h утверждает, что битбендинг есть, а на самом деле его нет.

Спойлер

из списка устройств поддерживающих бетбендинг семейство f3 должно вычеркнуть.

[Adrift]

[uquote="jcxz",url="/forum/viewtopic.php?p=4706961#p4706961"]А на Pico для этого видимо нужно 8 команд? И ни о какой одновременности речи не может идти?[/uquote]
Нет, для отдельных пинов одни команды, для портов целиком - другие. У Pico2 максимум 48 GPIO, сопроцессору можно передать в качестве аргументов команды две 32-х битных маски и затоглить любые из этих пинов одновременно, т.к. интерфейс сопроцессора 64-х битный. И сопроцессор - это дополнительная фича, у первого Pico его не было, у второго он работает только с M33, а там еще RISC-V есть, потому обычные регистры GPIO позволяющие выполнять атомарные операции тоже есть.

Насчёт выполнения сопроцессором (не знаю что это такое) - манипуляции с пинами на XMC4xxx можно выполнить вообще без процессора. Поручив DMA и таймеру пересылку потока инвертирующих констант в регистр правления GPIO. И не отвлекая основной поток программы от более важных дел. Возможно ли такое на Pico с его сопроцессором?

Когда в стартапе пишут что-то типа:

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

SCB->CPACR |= (3 << 20) | (3 << 22);  // set CP10 and CP11 Full Access

то включают сопроцессор для FPU, а у M33+(начиная с какой-то ревизии) появились вендор специфик кастомные инструкции, т.е. возможность добавлять свои сопроцессоры.
У Pico часть периферии висит на Single-cycle IO, в том числе порты, потому тут как с M0+/M23, где DMA не работает с портами. С сопроцессором DMA тоже не работает, но зато есть 12 PIO( programmable input/output block) которые специализированны для работы с портами, т.е. DMA гонит данные в PIO, 32 бита за такт!, и там можно одной командой за 1 такт вывести до 32-х бит в порт начиная с указанного пина, параллельно дергая еще до 5-ти других пинов. И у самомого PIO есть 16.8 делитель частоты, так что даже без дополнительного таймера можно скорость вывода настроить и в отличие от DMA c таймером не будет никакого джиттера.

Добавлено after 19 minutes 41 second:
[uquote="a5021",url="/forum/viewtopic.php?p=4706963#p4706963"]по неведомой мне причине заголовочник stm32f303xc.h утверждает, что битбендинг есть, а на самом деле его нет.[/uquote]
Да есть он там, но по описанной ранее причине не работает с портами и ADC, c остальной периферией должно работать.

[a5021]

Да есть он там, но по описанной ранее причине не работает с портами и ADC, c остальной периферией должно работать.

занятный прикол: если даташит не содержит упоминания некой фичи, а референс не описывает ее, то это не значит, что в железе ее нет. bit-banding у stm32f3 и stm32l4 описывается в документе под названием:
"AN4832 Application note Migrating from STM32F303 line to STM32L4 Series and STM32L4+ Series microcontrollers" и написано там следующее:

Bit-banding on Cortex-M4

STM32F303 line and STM32L4 Series / STM32L4+ Series support bit-banding on the
lowest 1 Mbyte of SRAM and on the peripheral memory region.

However the peripherals mapped in this bit-banding region are not the same on each series
of products.

The peripherals accessible with bit-banding are:
• For STM32F303 line: all the peripherals except FMC, ADC, GPIOx registers.
• For STM32L4 Series and STM32L4+ Series: all the peripherals except FSMC, RNG,
AES, USB OTG FS, GPIOx, ADC registers.

таким образом, исключенный ранее f3 возвращается в список, плюс еще два семейства: l4 и l4+. похоронщики bit-banding'а посрамлены.

[Adrift]

[uquote="a5021",url="/forum/viewtopic.php?p=4707058#p4707058"]занятный прикол: если даташит не содержит упоминания некой фичи, а референс не описывает ее, то это не значит, что в железе ее нет. bit-banding у stm32f3 и stm32l4 описывается в документе под названием:
"AN4832 Application note Migrating from STM32F303 line to STM32L4 Series and STM32L4+ Series microcontrollers"...[/uquote]
BB - это опциональная фича ядра, она и не обязана описываться в DS или RM, для этого есть "Cortex-M4 Generic User Guide" или его ST аналог: "STM32 Cortex-M4 programming manual". Так что сам BB много где есть, даже у некоторых H7, где есть второе ядро M4, но с портами BB работает далеко не везде.

[ARV]

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

Начинающим важнее понять, в чем фишка, чем просто про эту фишку прочесть

[a5021]

[uquote="Adrift",url="/forum/viewtopic.php?p=4707069#p4707069"]BB - это опциональная фича ядра, она и не обязана описываться в DS или RM[/uquote]
она вполне себе описывалась в референсах у всех, где присутствовала, но начиная с f3 перестала. такая непреемственность немного сбивает с толку.

для этого есть "Cortex-M4 Generic User Guide" или его ST аналог: "STM32 Cortex-M4 programming manual"

вчитываясь в которые нифига не понять, почему у g4 битбендинг отстуствует.

Добавлено after 6 minutes 19 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4707091#p4707091"]а разве нельзя без этой атомарности решить задачу[/uquote]
все можно. настольные программисты берут камень пожирнее, вкорячивают ртос и пишут, как на писюке. эмбедеры.

[Adrift]

[uquote="a5021",url="/forum/viewtopic.php?p=4707101#p4707101"]вчитываясь в которые нифига не понять, почему у g4 битбендинг отстуствует.[/uquote]
Я еще в первом своем посте про BB написал, что исключая старье он есть у G4 и F3, но с портами не работает.