Микроконтроллеры STM32 - тонкости работы, отладочные платы

smacorp

Например, неправильный startup файл. Проверьте в list действительно ли обработчик прерывания таймера линкуется и отображается в векторах прерываний.

А вообще, причин может быть немало.

Реклама

HardWareMan

Не вижу работу с TIM3->DIER.

Реклама

lubitel5

HardWareMan писал(а):Не вижу работу с TIM3->DIER.

Спасибо, так и есть. Не все прочитал, еще меньше понял. Еще и счетчик включить нужно, сначала думал что он и обновляется и запускается сам.

Добавлено after 6 hours 21 minute 50 seconds:
Re: Микроконтроллеры STM32 - тонкости работы, отладочные платы
Не могу сообразить еще одно. Таймер настроен на 1 МГц, т. е. 1000 в TIM3_CNT = 1 мсек. Старт-бит у моего пульта 4,5 мсек. импульс + 4,5 мсек. пауза. Должно ведь быть в регистре ТМ3_ССР1 = 9000? А там 18000, ну и все остальные импульсы так же. Если таймер настраивать для отсчета времени, то все совпадает, а почему в этом режиме нет?

HardWareMan

Зависит от настроек каптуры. А ещё, смотрите что от пульта приходит, иногда несущая не фильтруется.

Реклама

lubitel5

В общем я глянул на блок диаграмму в даташите, а там не указано что на таймеры стоит умножитель частоты. В общем все правильно- частота 84 МГц а не 42 МГц.

Реклама

HardWareMan

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

Реклама

Silicoid

Господа, есть кубический вопрос

В проекте я использую специфический синтаксис с++. Собсно, настроил Сubeide как в мануале, плюс переименовал main.c в main.cpp (как предлагали на форуме STM)
всё отлично компилируется.

Но если я пользуюсь визуальным конфигуратором (.ioc который), он вновь создает пустой файл main.c, который потом приходится мержить с проектом руками.
Подскажите плиз, есть ли какой-нибудь способ заставить создавать (вернее вносить правки) файл с нужным расширением?

HardWareMan

Чтобы не мержить нужно вставлять свой код в аккурат между комментами типа "Place your code here/End of user code". И тогда он, по идее, перенесёт код в новую версию.

Silicoid

HardWareMan, Вы видимо невнимательно прочитали вопрос.
Куб Создает новый файл, а не вносит изменения в текущий. Не перезатирает его.

Ни в одном конфиге я целевого файла не нашел, скорее всего расширение захардкожено.
Но надежда умирает последней.

tonyk

Silicoid писал(а):Подскажите плиз, есть ли какой-нибудь способ заставить создавать (вернее вносить правки) файл с нужным расширением?

А в чём сложность? Не понял.

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

/* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_ADC1_Init();
  /* USER CODE BEGIN 2 */

    my_cpp_main();

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

Добавлено after 6 minutes 55 seconds:
Re: Микроконтроллеры STM32 - тонкости работы, отладочные платы

Silicoid писал(а):Но если я пользуюсь визуальным конфигуратором (.ioc который), он вновь создает пустой файл main.c, который потом приходится мержить с проектом руками.

То, что вы хотите получить, полная чушь. Если используете МХ для настройки периферии, то тогда пишите на С, ну а коли решили использовать С++, то пишите работу с периферией сами, иначе ваша программа будет вызывать рвотный рефлекс как у адептов С, так и плюсовиков. Не знаю, как сейчас, но раньше С++ тошнило от кода МХ вплоть до ошибок компиляции. Так что следуйте совету из старого анекдота: "Абрам Моисеевич, вы или крестик снимите, или трусы наденьте!"

Silicoid

tonyk писал(а):А в чём сложность? Не понял.

Сложности нет. неудобство присутствует.

Тут штука в том, что визуально гораздо понятнее с какими ногами работаем. Когда у вас 64 ноги и на 58 из них что-то висит и самое плохое, что это что-то иногда еще и переползает с ноги на ногу, то держать в голове (или notepad++) где что подключено, ну очень неудобно.
А тут хоть можно подписать какой вывод за что отвечает.
Ну а когда всё устаканится, то перепишу. да.

ps. ошибок компиляции ++ не замечал

linux_rulezz

Когда у вас 64 ноги и на 58 из них что-то висит и самое плохое, что это что-то иногда еще и переползает с ноги на ногу, то держать в голове (или notepad++) где что подключено, ну очень неудобно.

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

Кстати, если уж знаете С++, то калокуб там вообще ни к черту: ведь благодаря "плюсовским" шаблонам можно очень красивый HAL сделать. Который не будет вырвиглазным блевотным кодом и реально позволит легко портировать код между семействами (кал от ST на самом деле этого не позволяет).
Еще одним плюсом является то, что g++ все эти шаблоны свернет в итоге в одну операцию. И будет у вас что-то вроде REG = VAL, а не как у индусов от ST, когда 100500 раз идет REG |= FLAGS; REG &= ~FLAGS; …
Видел я, как красиво можно под STM32 писать на С++. Жаль, я его осилить не могу, поэтому пишу на С, выдумывая всякие макросы, и получается вроде такого:

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

    GPIOB->ODR = 0;
    GPIOB->AFR[0] = AFRf(2, 0) | AFRf(7, 3) | AFRf(10, 5);
    GPIOB->AFR[1] = AFRf(1, 8) | AFRf(7, 10) | AFRf(5, 13) | AFRf(5, 14) | AFRf(5, 15);
    GPIOB->MODER = MODER_AF(0) | MODER_O(1) | MODER_O(2) | MODER_AF(3) | MODER_O(4) | MODER_AF(5) | MODER_O(6)
                 | MODER_I(7) | MODER_AF(8) | MODER_I(9) | MODER_AF(10) | MODER_I(11) | MODER_O(12) | MODER_AF(13)
                 | MODER_AF(14) | MODER_AF(15);
    GPIOB->OSPEEDR = OSPEED_HI(0) | OSPEED_HI(5) | OSPEED_HI(8) | OSPEED_MED(13) | OSPEED_MED(14) | OSPEED_MED(15);

Zikon

Вот на C++ пишу библиотечку - более простую чем "Желе"

Интересно получается
это для PY32F030 (003,002A)
все альтернативы забил в enum-ы для каждого порта

Спойлер

tonyk

Silicoid писал(а):А тут хоть можно подписать какой вывод за что отвечает.

Ну так и подпишите, вариантов масса.

Спойлер

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

////////////////////////////////////////////////////////////////////////////////
//
//  Глобальные параметры. Устанавливаются при запуске программы
//
////////////////////////////////////////////////////////////////////////////////

// Обрати внимание на имена пинов у I2C здесь и в файле реализации!
// Они должны совпадать, инече не заработает сброс шины!

const PinDescriptor pin[] =
{
#ifdef __STM32F446__

//========================
//  DO
//========================
//  PLC stations.

//  You do not change postions of this descrptors, because they are used for
//  sturtup diagosnostics!

#if ( ( defined (__MEDSINTEZ__) || defined (__NUCLEO_F446RE__) ) )
    { "FAULT_LED",  GPIOC, BIT_2,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },
    { "STOP_LED",   GPIOC, BIT_1,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },
    { "RUN_LED",    GPIOC, BIT_0,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },

    { "RUN-STOP",   GPIOC, BIT_3,  GPIO, INPUT,   PULL_DOWN, INPUT_PIN, LOW_SPEED },
#elif defined (__SK2N_002__)
    { "FAULT_LED",  GPIOC, BIT_3,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },
    { "STOP_LED",   GPIOC, BIT_2,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },
    { "RUN_LED",    GPIOC, BIT_1,  GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },

    { "RUN-STOP",   GPIOC, BIT_0,  GPIO, INPUT,   PULL_DOWN, INPUT_PIN, LOW_SPEED },
#endif

//========================

{ "INIT",       GPIOC, BIT_13, GPIO, INPUT,   PULL_UP,   INPUT_PIN, LOW_SPEED }, //

//
//========================
// Peripherias
//========================

// Console UART (connected to ST-Link on Discovery)
{ "TX2",    GPIOA, BIT_2,  AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
{ "RX2",    GPIOA, BIT_3,  AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },

#if ( defined (__MEDSINTEZ__) || defined(__NUCLEO_F446RE__) )
    //--------------------------------------------------------------------------
    // UART1, EIA-485
    { "TX1",    GPIOA, BIT_9,  AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
    { "RX1",    GPIOA, BIT_10, AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
#elif defined (__SK2N_002__)
    //--------------------------------------------------------------------------
    // UART3, EIA-485
    { "TX3",    GPIOB, BIT_10,  AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
    { "RX3",    GPIOC, BIT_5,   AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
    //--------------------------------------------------------------------------
    // UART1, EIA-422
    { "TX1",    GPIOA, BIT_9,  AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
    { "RX1",    GPIOA, BIT_10, AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
    { "DIR1",   GPIOA, BIT_11, AF07, ALTFUNC, PULL_UP, PUSH_PULL, HIGH_SPEED },
#endif

//------------------------------------------------------------------------------
// SPI2 (W5500)
{ "WIZ_MOSI",   GPIOB, BIT_15, AF05, ALTFUNC, NO_PULL, PUSH_PULL, HIGH_SPEED },
{ "WIZ_MISO",   GPIOB, BIT_14, AF05, ALTFUNC, NO_PULL, PUSH_PULL, HIGH_SPEED },
{ "WIZ_SCLK",   GPIOB, BIT_13, AF05, ALTFUNC, NO_PULL, PUSH_PULL, HIGH_SPEED },
{ "WIZ_CS",     GPIOB, BIT_12, GPIO, OUTPUT,  NO_PULL, PUSH_PULL, HIGH_SPEED },

#if ( defined (__MEDSINTEZ__) || defined (__NUCLEO_F446RE__) )
    { "WIZ_RSTn",   GPIOB, BIT_11, GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED },
#elif defined (__SK2N_002__)
    { "WIZ_RSTn",   GPIOC, BIT_6, GPIO, OUTPUT,  NO_PULL, PUSH_PULL, LOW_SPEED  },
#endif
//------------------------------------------------------------------------------
// SPI3 (W25Q)
{ "W25Q_MOSI",  GPIOC, BIT_12, AF06, ALTFUNC, NO_PULL, PUSH_PULL,  HIGH_SPEED }, // DI
{ "W25Q_MISO",  GPIOC, BIT_11, AF06, ALTFUNC, NO_PULL, PUSH_PULL,  HIGH_SPEED }, // DO
{ "W25Q_SCLK",  GPIOC, BIT_10, AF06, ALTFUNC, NO_PULL, PUSH_PULL,  HIGH_SPEED },
{ "W25Q_CS",    GPIOA, BIT_15, GPIO, OUTPUT,  PULL_UP, PUSH_PULL,  HIGH_SPEED },

// bxCAN1
{ "bxCAN1-TX",  GPIOB, BIT_9, AF09,  ALTFUNC, NO_PULL, PUSH_PULL,  HIGH_SPEED },
{ "bxCAN1-RX",  GPIOB, BIT_8, AF09,  ALTFUNC, PULL_UP, PUSH_PULL,  HIGH_SPEED },
{ 0 }  // the end of the map marker
#endif  // __NUCLEO_F446RE__
};

Ещё нюанс. Потом переписать не получится. Вы же собираетесь использовать прерывания? Тогда нужно создать механизм для их обработки в стиле С++, а сие лучше сделать в стартапе, который тоже придётся переписать, и, желательно, на С++. Тогда появится возможность сделать обработчик прерывания виртуальным методом класса.

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

class HW_Cnt32 : public HW_Timer_base, protected IRQ
{
       ....
    protected:

        virtual void IRQ_Handler( void );

        ......
};

Adrift

ST анонсировала STM32V8: 800MHz Cortex-M85(В 1.5 раз быстрее 600MHz H7), 4MB флеша, 1.5MB RAM и паябельные LQFP-100 корпуса.

Спойлер

VladislavS

[uquote="tonyk",url="/forum/viewtopic.php?p=4759306#p4759306"][quote="Silicoid"]Ещё нюанс. Потом переписать не получится. Вы же собираетесь использовать прерывания? Тогда нужно создать механизм для их обработки в стиле С++, а сие лучше сделать в стартапе, который тоже придётся переписать, и, желательно, на С++. Тогда появится возможность сделать обработчик прерывания виртуальным методом класса.[/uquote]Вот это совсем не нужно и даже вредно в случае линковки с какими-либо библиотеками написанными на Си. А это хоть те же стандартные библиотеки. Куда проще обработчику прерывания добавить extern "C" и дёрнуть из него нужные методы класса.

tonyk

VladislavS писал(а):Вот это совсем не нужно и даже вредно в случае линковки с какими-либо библиотеками написанными на Си. А это хоть те же стандартные библиотеки

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

VladislavS писал(а):Куда проще обработчику прерывания добавить extern "C" и дёрнуть из него нужные методы класса.

Как раз наоборот, проще через виртуальный метод. Обработкой прерывания занимается тот объект, которому это нужно. В случае с extern "C" разрывается логическая связь между объектом и обработчиком. Ну и раз уж мы используем ООП, то не будем уподобляться Абраму Моисеевичу из известного анекдота и чётко определимся, что нам следует надеть, трусы или крестик.

VladislavS

Прерывания принадлежат не объекту, а контрполлеру прерываний и процессору. Вот пример, не STM32, но суть понятна. Данные приходят из RS485, USB или Ethernet и обрабатываются одним и тем же протокольным классом, которому всё равно откуда свалились данные.

Спойлер

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

void __attribute__((fast_interrupt)) UartRS485PC_InterruptHandler()
{
  while(UART_RS485_PC::isDR()) control_if_rs485.ProcessByte(UART_RS485_PC::ReadByte());
}

void __attribute__((fast_interrupt)) UartUSB_InterruptHandler()
{
  while(UART_USB::isDR()) control_if_usb.ProcessByte(UART_USB::ReadByte());
}

void __attribute__((fast_interrupt)) AXIS_FIFO_RX_InterruptHandler()
{ 
  static int32_t occupancy = 0;
  
  if(occupancy==0) occupancy = ETH_PORT::ReadRXFIFIOccupancy();

  int32_t words2read = ETH_PORT::ReadReceiveLength() >> 2;
  for(auto i=0u; i<words2read ; i++) 
  {
    control_if_eth.ProcessWord(ETH_PORT::ReadWord());      
  }

  occupancy -= words2read;
  
  if (control_if_eth.isCommandReceived()) INTC::DisableInterrupt(AXIS_FIFO_RX_InterruptHandler_NUM);
  
  if(occupancy==0) ETH_PORT::ClearRXCInterrupt();  
}

Любой инструмент для чего-то нужен. Плюсы ради плюсов это непотребное чтиво. Ещё и вредное местами.

jcxz

[uquote="tonyk",url="/forum/viewtopic.php?p=4759306#p4759306"]Тогда нужно создать механизм для их обработки в стиле С++, а сие лучше сделать в стартапе, который тоже придётся переписать, и, желательно, на С++. Тогда появится возможность сделать обработчик прерывания виртуальным методом класса.[/uquote]Почему именно нужно "переписывать стартап в стиле си++"? Чем ассемблерный стартап не подходит?

Добавлено after 9 minutes 52 seconds:
[uquote="Silicoid",url="/forum/viewtopic.php?p=4759229#p4759229"]Тут штука в том, что визуально гораздо понятнее с какими ногами работаем. Когда у вас 64 ноги и на 58 из них что-то висит и самое плохое, что это что-то иногда еще и переползает с ноги на ногу, то держать в голове (или notepad++) где что подключено, ну очень неудобно.
А тут хоть можно подписать какой вывод за что отвечает.[/uquote]А в чём проблема описать все ноги в .h-файле?
Вот один мой проект. Он может компилиться для 3-х разных плат (с по-разному распределённой периферией/цепями, даже компоненты некоторые отличаются). Соответственно - в составе исходников есть 3 файла "board_xxx.h" с содержимымм подобным:

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

#ifndef BOARD_..._H
#define BOARD_..._H

#define CLKIN_XTAL    24000000   //[Hz] frequency of external main crystal or oscillator
#define CLKIN_OSCHP   1          //==1 - generator on XTAL1 (Direct Input Mode); ==0 - quartz on XTAL1/2 (Crystal Mode)
#define CLKIN_RTCX    32768      //[Hz] external frequency for RTC

//Allocation USIC-s
#define nUSIC_df          2,  1  //USIC/channel's number for SPI-FLASH
#define nUSIC_rf          0,  1  //USIC/channel's number for RF-unit
#define nUSIC_service     0,  0  //USIC/channel's number for log-UART
#define nUSIC_term        2,  0  //USIC/channel's number for UART of terminal
//Allocation CCU-timers/slices
#define nCCU_intmon       40, 0  //timer/slice numbers for monitoring of duration of interrupts bans (for debug)
#define nCCU_dac_trig     40, 1  //timer/slice numbers for trigger-signals for DAC
#define nCCU_dac_exe      40, 2  //timer/slice numbers for interrupt generation in middle/end of DMA-block of DAC
#define nCCU_adc_trig     41, 0  //timer/slice numbers for trigger-signals for ADC
#define nCCU_adc_res      41, 1  //timer/slice numbers
#define nCCU_buzzer       40, 3  //timer/slice numbers for buzzer

#define PIN_SERV_RX       1,  4  //RX nUSIC_service
#define PIN_SERV_TX       1,  5  //TX nUSIC_service
#define PIN_TERM_RX       5,  1  //RX nUSIC_term
#define PIN_TERM_TX       5,  0  //TX nUSIC_term
#define PIN_LED1          5,  9  //LED1; bool."1" - is lighting
#define PIN_LED2          3,  14 //LED2; bool."1" - is lighting
#define PIN_LED3          6,  0  //LED3; bool."1" - is lighting
#define PIN_BUZZER        0,  12 //==1 - buzzer enable
#define PIN_DAC_GEN       14, 8  //generator's output
#define PIN_DF_SCLK       4,  2  //SCLK for nUSIC_df
#define PIN_DF_MOSI       4,  7  //MOSI for nUSIC_df
#define PIN_DF_MISO       4,  6  //MISO for nUSIC_df
#define PIN_DF_CS         4,  3  //CS for N25Q032A on nUSIC_df
#define PIN_DF_WP         4,  5  //WP for N25Q032A
#define PIN_DF_HOLD       4,  4  //HOLD for N25Q032A
#define PIN_A_IN1         14, 0  //analog input 1
#define PIN_A_IN2         14, 1  //analog input 2
#define PIN_RF_SCLK       3,  0  //SCLK for nUSIC_rf
#define PIN_RF_MOSI       3,  13 //MOSI for nUSIC_rf
#define PIN_RF_MISO       4,  0  //MISO for nUSIC_rf
#define PIN_RF_CS         3,  1  //CS for RF-unit
#define PIN_RF_RST        3,  12 //NRESET for RF-unit; active - bool.0, >=100mcs, >=5ms - startup time
#define PIN_RF_BOOST      0,  13 //BOOST switch control
#define PIN_RF_LF         0,  14 //antenna switch control LF
#define PIN_RF_HF         0,  15 //antenna switch control HF
#define PIN_DIAG          2,  2  //thermal protection input from generator

//Allocation ADC-inputs (group, channel)
#define nADC_in1          0,  0  //analog input 1
#define nADC_in2          0,  1  //analog input 2

//Allocation GPDMA lines (DMALINEx_...) for DLR. Channels are allocated similarly.
#define nDMALINE_dac      1
#define nDMALINE_df_RX    8
#define nDMALINE_df_TX    9
//Allocation of Service Requests for all CCUs. Each element also needs to be added to the list CHK_SRCCU!
#define nCCU_SR_intmon    0, nCCU_intmon    //SR for nCCU_intmon
#define nCCU_SR_dac_trig  1, nCCU_dac_trig  //SR for DAC-triggering
#define nCCU_SR_dac_exe   2, nCCU_dac_exe   //SR generating an interrupt in middle/end of a block of samples transmitted to the DAC
#define nCCU_SR_adc_trig  2, nCCU_adc_trig  //SR for ADC-triggering
#define nCCU_SR_adc_res   1, nCCU_adc_res   //SR reading result from ADC
#define nCCU_SR_buzzer    3, nCCU_buzzer    //SR interrupt for buzzer control
//Allocation of Service Requests for all USICs. Each element also needs to be added to the list CHK_SRUSIC!
#define nUSIC_SR_serv_RX  3, nUSIC_service
#define nUSIC_SR_serv_TX  4, nUSIC_service
#define nUSIC_SR_serv_ERR 5, nUSIC_service
#define nUSIC_SR_term_RX  3, nUSIC_term
#define nUSIC_SR_term_TX  4, nUSIC_term
#define nUSIC_SR_term_ERR 5, nUSIC_term
#define nUSIC_SR_df_RX    0, nUSIC_df
#define nUSIC_SR_df_TX    1, nUSIC_df
#define nUSIC_SR_df_ERR   2, nUSIC_df
#define nUSIC_SR_rf_RX    0, nUSIC_rf
#define nUSIC_SR_rf_ERR   1, nUSIC_rf

#endif

А в остальном коде вычисления всех ног, портов, DMA-каналов, АЦП-каналов и т.п. - выполняются при помощи макросов на основе этих define-ов. И ни одного выражения с магическим номером типа UART1 в коде нет.
Такой код очень легко перебрасывать в другой проект, с другой платой (но таким же МК).

linux_rulezz

Чем ассемблерный стартап не подходит?

Уродство же! Не хватало еще стартап на асме, бэкенд на С, а фронтенд на С++…