Как я накололся с stm32f10x.h, врагу не пожелаю Опции

[ViKo]

Cоздаю свои SystemInit функции (как и все остальные, по мере понимания). Очередная - не работает! Процессор вылетает неизвестно куда, в фаулты, даже до обработчика HardFault не добирается! В Кейле, в отладчике, на реальной плате вижу.
Хотя предыдущая функция (в том же файле была, повезло) - работает. Ищу отличия - не нахожу! Смотрю в отладчике - все биты RCC одинаковые.
Там с десяток выражений, что только не сравниваю, заменяю, комментирую - везде одинаково. Добрался до латентности. В нерабочей:

Код

/* Задать использовать буфер предвыборки Flash, 2 цикла ожидания */
    FLASH->ACR =
    FLASH_ACR_LATENCY_0 * 2 |  // LATENCY[2:0] bits (Latency)
    FLASH_ACR_HLFCYA    * 0 |      // Flash Half Cycle Access Enable
    FLASH_ACR_PRFTBE    * 1;      // Prefetch Buffer Enable

В рабочей:

Код

/* Задать использовать буфер предвыборки Flash и 2 цикла ожидания
   (half cycle access can only be used with a low-frequency clock of less than 8 MHz
   that can be obtained with the use of HSI or HSE but not of PLL) */
  FLASH->ACR = FLASH_ACR_PRFTBE
             | FLASH_ACR_LATENCY_1;    // 2 WS

Смотрю в stm32f10x.h. А там биты заданы так:

Код

#define  FLASH_ACR_LATENCY                   ((uint8_t)0x03)               /*!< LATENCY[2:0] bits (Latency) */
#define  FLASH_ACR_LATENCY_0                 ((uint8_t)0x00)               /*!< Bit 0 */
#define  FLASH_ACR_LATENCY_1                 ((uint8_t)0x01)               /*!< Bit 0 */
#define  FLASH_ACR_LATENCY_2                 ((uint8_t)0x02)

То есть, не так, как везде, описываются именно биты, как, например:

Код

#define  RCC_CFGR_PLLMULL_0                  ((uint32_t)0x00040000)

а состояния латентности.
В результате, латентность у меня не устанавливалась, доступ к памяти сбоил. Когда задал

Код

    FLASH->ACR =
    FLASH_ACR_LATENCY_2 |    // LATENCY[2:0] bits (Latency)
    FLASH_ACR_HLFCYA    * 0 |    // Flash Half Cycle Access Enable
    FLASH_ACR_PRFTBE    * 1;    // Prefetch Buffer Enable

все заработало.
Что интересно, и вторая функция была с неправильной установкой латентности = 1, но, тем не менее каким-то чудом работала. На 72 MHz, STM32F103.
Уже чешутся руки взяться за правку stm32f10x.h, но боюсь запутаться между проектами.

[ViKo]

Для STM32F100, 103. Такты задаю раньше, одной командой для всех устройств.

CODE

/*! Port bit configuration table */
typedef enum {
IN_ANAL, GO_PP10, GO_PP02, GO_PP50, // Input Analog, GP Output Push-pull 10-2-50MHz
IN_FLOA, GO_OD10, GO_OD02, GO_OD50, // Input Float*, GP Output Open-drain 10-2-50MHz
IN_PDPU, AO_PP10, AO_PP02, AO_PP50, // Input Pull-down/Pull-up, Alt Func Push-pull
CM_NONE, AO_OD10, AO_OD02, AO_OD50 // none(illegal), Alt Func Open-drain 10-2-50MHz
} CONF_MODE;

/*!****************************************************************************
*
@brief Port Low/High byte configuration
@details Конфигурация байтов порта целиком
@param PORT - имя порта (A..G)
@param CM00..CM15 - конфигурация битов 0..15
@note Используется перечисляемый тип CONF_MODE
@note Для IN_PDPU нужный pull-down/pull-up задается в ODR
*/
#define GPIO_CONF(PORT, \
CM00, CM01, CM02, CM03, \
CM04, CM05, CM06, CM07, \
CM08, CM09, CM10, CM11, \
CM12, CM13, CM14, CM15); \
GPIO##PORT->CRL = ((uint32_t) \
CM00 << 0 | CM01 << 4 | CM02 << 8 | CM03 << 12 | \
CM04 << 16 | CM05 << 20 | CM06 << 24 | CM07 << 28); \
GPIO##PORT->CRH = ((uint32_t) \
CM08 << 0 | CM09 << 4 | CM10 << 8 | CM11 << 12 | \
CM12 << 16 | CM13 << 20 | CM14 << 24 | CM15 << 28);

#define GPIO_CONFL(PORT, \
CM00, CM01, CM02, CM03, \
CM04, CM05, CM06, CM07); \
GPIO##PORT->CRL = ((uint32_t) \
CM00 << 0 | CM01 << 4 | CM02 << 8 | CM03 << 12 | \
CM04 << 16 | CM05 << 20 | CM06 << 24 | CM07 << 28);

#define GPIO_CONFH(PORT, \
CM08, CM09, CM10, CM11, \
CM12, CM13, CM14, CM15); \
GPIO##PORT->CRH = ((uint32_t) \
CM08 << 0 | CM09 << 4 | CM10 << 8 | CM11 << 12 | \
CM12 << 16 | CM13 << 20 | CM14 << 24 | CM15 << 28);

/*!****************************************************************************
*
@brief Bit of Low/High byte Port configuration
@details Конфигурация одиночного бита порта
@param PORT - имя порта (A..G)
@param BIT - номер бита (0..15)
@param CM - конфигурация бита
@note Используется перечисляемый тип CONF_MODE
@note Для IN_PDPU нужный pull-down/pull-up задается в ODR
*/
#define GPIO_CONFB(PORT, BIT, CM) \
*(uint32_t *)((uint32_t)(GPIO##PORT) + BIT / 8 * 4) = \
*(uint32_t *)((uint32_t)(GPIO##PORT) + BIT / 8 * 4) \
& (~(0xF << (BIT % 8) * 4)) | (CM << (BIT % 8) * 4)

/* GPIO */
GPIO_CONF(A,
IN_FLOA, IN_FLOA, IN_FLOA, IN_FLOA, // User_Key, _ , _ , _
IN_ANAL, IN_ANAL, IN_FLOA, IN_FLOA, // DAC-1, DAC-2, _ , _
AO_PP50, IN_FLOA, IN_FLOA, IN_FLOA, // MCO, _ , _ , _ , _
IN_FLOA, IN_FLOA, IN_FLOA, IN_FLOA);

А вот листинг

Код

;;;371    /* GPIO */
;;;372      GPIO_CONF(A,
00000e  49e1              LDR      r1,|L1.916|
000010  48df              LDR      r0,|L1.912|
000012  6008              STR      r0,[r1,#0]
000014  1d09              ADDS     r1,r1,#4
000016  48e0              LDR      r0,|L1.920|
000018  6008              STR      r0,[r1,#0]
;;;373        IN_FLOA, IN_FLOA, IN_FLOA, IN_FLOA,    // User_Key, _ , _ , _
;;;374        IN_ANAL, IN_ANAL, IN_FLOA, IN_FLOA,    // DAC-1, DAC-2, _ , _
;;;375        AO_PP50, IN_FLOA, IN_FLOA, IN_FLOA,    // MCO, _ , _ , _ , _
;;;376        IN_FLOA, IN_FLOA, IN_FLOA, IN_FLOA);

[Boriska]

Для STM32F100, 103. Такты задаю раньше, одной командой для всех устройств.
/*! Port bit configuration table */
typedef enum {...

В принципе, нормально. Только может значения CONF_MODE переименовать, чтобы было понятнее? А то IN_ANAL как-то режет глаз Да и AO_PP02 менее понятно, чем GPIO_Speed_50MHz.
Иногда, в проекте под каждый датчик/исполнительное устройство есть отдельный файл, а то и несколько. Как в этом случае задавать настройки: какие порты и другие ресурсы контроллера будут использоваться этим датчиком? Если это делать в заголовочном (*.h) файле самого датчика, то иногда возникают ситуации, когда одни и те же ресурсы используются одновременно несколькими устройствами. Меня подмывает перенести все дефайны распределения ресурсов в один заголовочный файл. Стоит так делать?
Может есть что-нибудь вроде "Best practices in embedded systems programming" для начинающих? Посоветуйте.

[ViKo]

В принципе, нормально. Только может значения CONF_MODE переименовать, чтобы было понятнее? А то IN_ANAL как-то режет глаз Да и AO_PP02 менее понятно, чем GPIO_Speed_50MHz.
Иногда, в проекте под каждый датчик/исполнительное устройство есть отдельный файл, а то и несколько. Как в этом случае задавать настройки: какие порты и другие ресурсы контроллера будут использоваться этим датчиком? Если это делать в заголовочном (*.h) файле самого датчика, то иногда возникают ситуации, когда одни и те же ресурсы используются одновременно несколькими устройствами. Меня подмывает перенести все дефайны распределения ресурсов в один заголовочный файл. Стоит так делать?
Может есть что-нибудь вроде "Best practices in embedded systems programming" для начинающих? Посоветуйте.

Пусть режет. Автору виднее! Каждый думает в меру своей распущенности. На некоторых импортных осциллографах выход калибратора назывался "CAL".
У меня все настройки всего - это одна функция, не такая уж и большая. Правда, USB там нет.