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

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3448804#p3448804"]Отмазка так себе, особенно на фоне того, что конечно M0 умеет Tail-Chaining. Гораздо проще все объясняется тем, что у тебя очень смутные представления об архитектуре используемых мк.[/uquote]
Вы сделали мелкое уточнение по второстепенным деталям, но при этом не упустили возможности раздуться так, будто выиграли все споры наперед. Оно, конечно, забавно, но если для вас так важно быть правым хотя бы в малом, то мне ничего не остается, как с пониманием покачать головой.

Я ничего старательно не выбирал, самый первый мой пример был с задачей выполняющейся 1 ms и ты сначала убеждал, что никаких проблем с этим нет, потом оказалось

А врать-то зачем? Я в самом первом концепте кода написал в комментариях, что обработка малыми частями. Где я "убеждал сначала" ? За свои слова отвечать, разумеется, не приучены?

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

Не вижу никакой трагедии. На поллинге дискретизация обработки -- часть изначальной концепции. Вы собственные "прерывательские" страхи пытаетесь распространять на ситуацию, где они купированы by-design. И то, как вы акцентируете этот момент показывает, что для ардуина-стайла дискретизация обработки тот еще капец. Ну бойтесь.

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3448822#p3448822"]А врать-то зачем? Я в самом первом концепте кода написал в комментариях, что обработка малыми частями. Где я "убеждал сначала" ? За свои слова отвечать, разумеется, не приучены?[/uquote]
Ну малыми частями и что с того? Я с самого начала хотел услышать, что разбиение на части усложняет код и добавляет тормозов, но вместо этого от человека уверенного в своем методе получал такой-же уверенный, но уклончивый ответ в духе "вот псевдокод, там все по-русски написано". В переводе это может означать, что никаких проблем, нужно лишь разбить тяжелую задачу на части... Или что проблемы появляются, но признавать их не очень хочется. Естественно я продолжил уточнять понимаешь ли ты какие дополнительные трудности и расходы связаны с разбиванием задач, раз уж сам постоянно напоминаешь о нескольких десятках тактов затрачиваемых на прерывание, и только под конец услышал, что оказывается подбираю неудобные задачи Сразу нужно было признать наличие проблем и с относительно длительными задачами и со скоростью реакции на поступающие события, после этого бы мы перешли от недостатков к преимуществах поллинга, которые, однако, не имеют особого значения, т.к. людям использующим прерывания поллить никто не запрещает и они точно так же могут этими преимуществами воспользоваться.

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3448860#p3448860"]В переводе это может означать, что никаких проблем, нужно лишь разбить тяжелую задачу на части... Или что проблемы появляются, но признавать их не очень хочется. Естественно я продолжил уточнять понимаешь ли ты какие дополнительные трудности и расходы связаны с разбиванием задач, раз уж сам постоянно напоминаешь о нескольких десятках тактов затрачиваемых на прерывание, и только под конец услышал, что оказывается подбираю неудобные задачи [/uquote]
Я неоднократно просил a5021 привести способ работы Ethernet-драйвера и TCP-стека по его методике. Он всегда игнорил.
Его задачи включения/выключения светодиодов легко укладываются в суперлуп и разбиваются на части. А других задач для него не существует.

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3448860#p3448860"]Ну малыми частями и что с того?[/uquote]
Да не, ничего. Врать не нужно. Только и всего.

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

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

Я неоднократно просил a5021

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

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3448888#p3448888"]Да не, ничего. Врать не нужно. Только и всего.[/uquote]
Хорошо, не буду, но я не могу гарантировать того, что если в следующий раз ты опять что-то недопоймешь, то я опять не окажусь лжецом

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

Кто утверждал, что вместо суперлупа следовало бы говорить об event-driven programming? Открываем на вики статью про EDP, тыкаем в первый попавшийся документ, глава "The Handlers Design Pattern", в ней написано, что события приходят в диспатчер, внутри которого event loop где события обрабатываются и вызываются соответствующие обработчики, в точности как у тебя. Проматываем пару страниц, следующая глава называется "The Extended Handlers Pattern", там речь уже о том, что иногда диспатчер не успевает обрабатывать события так быстро, как они поступают, в таком случае между(т.е. перед) ним и генератором событий добавляется очередь. Где эту очередь можно добавить на мк? Правильно, в прерывании, что я и проделал когда говорил, что можно в прерывании добавлять байты в очередь или только выставлять флаг при необходимости длительной операции, а потом в суперлупе эти данные неспеша забирать. Фактически то и другое - это event-driven programming, только ты осилил его самую простую реализацию, что совсем не удивительно, т.к. и прерывания постигла та же участь. В мк всегда были прерывания(это я утрирую, а то вдруг найдешь какой-то древний мк без таковых и опять заявишь об обмане), какой в этом смысл, если они совсем не нужны...

ps. Вспомнил, что когда-то читал книгу Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems, дернул оттуда картинку, естественно очередь между прерываниями и диспатчером там так же присутствует.

Спойлер

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3449174#p3449174"]Хорошо, не буду, но я не могу гарантировать того, что если в следующий раз ты опять что-то недопоймешь, то я опять не окажусь лжецом[/uquote]
Лжецом вам случилось стать совсем по другой причине. Вы ее знаете, но и тут пытаетесь приврать. Дважды. Хобби, наверное, такое.

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

Если вам почему-то кажется, что из прерывания можно по быстрому скинуть принятый байт в очередь, а из поллинга нельзя, то вы опять заблуждетесь. Вот тут:

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

    /* N */ } else if (NVIC_GetPendingIRQ(xxxx_IRQn)) {
      NVIC_ClearPendingIRQ(xxxx_IRQn);
      // ...
      continue;
    /* N + 1 */

между ClearPending и continue я могу размещать код, который будет очереди заполнять и давать сигналы начала обработки. Чем это отличается от обработчиков прерываний? Да ничем.

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3449201#p3449201"]Лжецом вам случилось стать совсем по другой причине. Вы ее знаете, но и тут пытаетесь приврать. Дважды. Хобби, наверное, такое.[/uquote]
Уже дважды? В следующий раз, наверное, будет трижды

Схема ваша неудачная и к обсуждаемому вопросу прикручивается плохо.

Под моей схемой подразумевается traditional event-driven programming из книг? Так ведь авторы этих книг без зазрений совести пользуются прерываниями и по этой причине ничего толкового написать не могут.

События буферизируются в NVIC->ISPR, и ни в какой очереди на входе нет нужды.

Я вчера еще застал первую редакцию сообщения в которой говорилось, что NVIC->ISPR - это и есть аппаратная очередь Подумал ну все, с утра придется объяснять что такое очередь, стек, может даже байт и бит, так что спасибо, что избавил от такой незавидной участи, правда я совсем не уверен насчет того, что меня опят не обвинят во лжи, ты же просто не мог написать такую глупость... Или мог?

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

Если вам почему-то кажется, что из прерывания можно по быстрому скинуть принятый байт в очередь, а из поллинга нельзя, то вы опять заблуждетесь. Вот тут:
между ClearPending и continue я могу размещать код, который будет очереди заполнять и давать сигналы начала обработки. Чем это отличается от обработчиков прерываний? Да ничем.

Прерыванию не важно какой код выполняется в суперлупе, ведь оно его, собственно, прерывает. И тяжелой обработки там обычно нет тоже, а при чистом поллинге она там есть и может занимать значительное время, во время которого ничего в очередь добавить не получится, разве что придется дробить задачи на достаточно мелкие, что ты сам делать не особо любишь, да и все равно это лишь полумера. На прерывание тратится 12+10 тактов, если прерывания накладываются, то каждое последующее добавляет лишь 6 тактов, т.е. если достаточно часто вызывается 5 обработчиков, то затраты варьируют от 22+4*6=46 до 22*5=110 тактов. При поллинге, если проверять десяток флагов, то в худшем случае, а чтобы не терять данные он нас и интересует, сработают флаги из второй половины и если считать из расчета по 5 тактов на проверку(4 инструкции, последняя - BEQ), то получим 50+45+40+35+30=200 тактов, плюс сюда нужно добавить расходы на дробление крупных задач. И все равно мы ограничены не только этими тактами, но и временем выполнения самой длительной задачи вызываемой между опросами флагов, т.е. так быстро как в прерываниях добавлять в очередь в любом случае не получится.

[Ярослав555]

Отвлеку Вас уважаемые от срача. Разбирается кто в Иарах? Я столкнулся с досадным бажком - иногда глючит интерфейс в режиме отладки и на паузе не хочет ставить/снимать брекпоинты. Иногда помогает передвинуть окно, иногда подвигать границы областей... Мб слышал кто о таком? Винда десятка.

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3449339#p3449339"]Я вчера еще застал первую редакцию сообщения в которой говорилось, что NVIC->ISPR - это и есть аппаратная очередь [/uquote]
По способу заполнения -- это буфер, по способу выборки -- очередь. Не понимаю, на что вы возбудились.

Подумал ну все, с утра придется объяснять что такое очередь, стек, может даже байт и бит, так что спасибо, что избавил от такой незавидной участи, правда я совсем не уверен насчет того, что меня опят не обвинят во лжи, ты же просто не мог написать такую глупость... Или мог?

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

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

Да без разницы, кто и каким образом друг друга прерывает. Не принципиально, как регистрировать входные события. Обработку же все равно по принципу многозадачности делать, кусочками, чтобы оперативно отслеживать появление более приоритетных заданий и/или данных. Вам один фиг к своим прерываниям придется городить свою очередь и свой поллинг. Точ такой же поллинг, что вы тут поносите.

Вы цепляетесь так за прерывания, скорее всего потому, что _всегда_, в нарушение всех рекомендаций, делаете _всю_ обработку прямо в обработчике. Отсюда и столь кривое восприятие, что в прерываниях весь цимус. Как только вы начнете действовать по правилами и мыслить категориями распределенной обработки, исключительная привлекательность использования прерываний сильно поблекнет.

На прерывание тратится 12+10 тактов, если прерывания накладываются, то каждое последующее добавляет лишь 6 тактов, т.е. если достаточно часто вызывается 5 обработчиков, то затраты варьируют от 22+4*6=46 до 22*5=110 тактов. При поллинге,

Измерять можно по разному. При продумывании функционала диспетчера представляется очевидным, что под самые частые события имеет смысл выделить обработчики с минимальными показателями латентности. Таким образом, если построить модель, когда за период наблюдения первый обработчик отработает 10 раз, второй -- 9 и так до 5-го, который отработает 6 раз, то общее число событий будет равно сорока, а процессорное время на обработку их поллингом окажется где-то в районе 550 тактов. Время, затраченное процессором на отработку такого же количества прерываний, составит 880, если считать без учета Tail-Chaining. С последним получится поменьше, но ожидать, что это снижение составит около 40%, чтобы сравняться с поллингом, никак не представляется возможным.

[a5021]

Сегодня в теме про STM8 сказал про онлайн-компиляторы. Подумал-подумал и полез посмотреть, а как там они поживают. Попался на глаза занятный сайт под названием COMPILER EXPLORER. На нем можно набросать год, оформить в виде процедуры и посмотреть, что из этого получится после компиляции. Есть там и компиляторы для ARM -- несколько версий GCC и несколько версий MSVC. Можно играться разными опциями и наблюдать, как это отражается на результате. Посравнивал, как в плане оптимизации выглядят GCC vs MSVC. Показалось, что GCC лучше оптимизирует.

PS. AVR-GCC и MSP430-GCC там тоже есть.

[bezzabotna]

Здравствуйте. Я снова со своим АЦП.
В общем попробовала я его в двух режимах Scan continious и scan с запуском от TRGO. При этом данные забирает DMA. Получилось, но не выполняется основная программа в цикле. Та простой инкремент переменной и вот в отладчике он не инкрементируется, когда работает DMA в обоих случаях. Как будто все ресурсы мк направлены на работу с ацп. При этом, первые 10-20 циклов переменная инкрементируется, а потом остановка. А если задержку поставить в цикле, то программа вообще вылетает через некоторое время.
Это ведь ненормально? Куда копать? Это главный вопрос.
И еще почему-то DMA не генерирует прерывание по завершению обработки. Я даже брекпоинт поставить в обработчик не могу. Какую-то настройку упускаю?

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

int main(void){
	HAL_Init();
        SystemClock_Config();	
	HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);	
	HAL_NVIC_SetPriority(DMA2_Stream0_IRQn, 0, 0);
	HAL_NVIC_EnableIRQ(DMA2_Stream0_IRQn);	
	HAL_NVIC_SetPriority(ADC_IRQn, 0, 0);
        HAL_NVIC_EnableIRQ(ADC_IRQn);	
	HAL_NVIC_SetPriority(TIM3_IRQn, 0, 0);
	HAL_NVIC_EnableIRQ(TIM3_IRQn);	
        GPIO_Init();;
	TIM3_Init();	
	HAL_TIM_Base_Start(&htim3);
	HAL_TIM_Base_Start_IT(&htim3);
	ADC1_Init();
	HAL_ADC_Start_DMA(&hadc1,(uint32_t*)ADC1_buffer, 3);
	while (1){	
		temp++;
}}

void ADC1_Init(void){
  __HAL_RCC_ADC1_CLK_ENABLE();
  GPIO_InitTypeDef GPIO_InitStruct;
  ADC_ChannelConfTypeDef sConfig;
  
  GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_4;
  GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
//Частота дискретизации fconv = 1/(Tconv1+Tconv2+Tconv3) 
  hadc1.Instance = ADC1;
  hadc1.Init.ClockPrescaler = ADC_CLOCK_SYNC_PCLK_DIV4;		//ADCclk=Pclk/div, cycle=1/ADCclk
  hadc1.Init.Resolution = ADC_RESOLUTION_12B;				//разрешение 12 бит, преобразование займет 12 тактов + SamplingTime
  hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
  hadc1.Init.ScanConvMode = ENABLE;						//сканирование нескольких каналов
  hadc1.Init.ContinuousConvMode =DISABLE;									
  hadc1.Init.DiscontinuousConvMode = DISABLE;
  hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_RISING;
  hadc1.Init.ExternalTrigConv = ADC_EXTERNALTRIGCONV_T3_TRGO;			
  hadc1.Init.NbrOfConversion = 3;									//количество регулярных каналов
  hadc1.Init.DMAContinuousRequests = ENABLE;							//запрос DMA после преобразования каждого канала
  hadc1.Init.EOCSelection = ADC_EOC_SEQ_CONV;
  if (HAL_ADC_Init(&hadc1) != HAL_OK){
    _Error_Handler(__FILE__, __LINE__);
  }
	//конфигурация 1 канала 
  sConfig.Channel = ADC_CHANNEL_1;							//номер канала
  sConfig.Rank = 1;											//порядок измерения
  sConfig.SamplingTime = ADC_SAMPLETIME_112CYCLES;				//время преобразования одного канала: Tconv1=(SamplingTime+12)*cycle; 
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK){
    _Error_Handler(__FILE__, __LINE__);
	}
	//конфигурация 2 канала
  sConfig.Channel = ADC_CHANNEL_2;
  sConfig.Rank = 2;
  sConfig.SamplingTime = ADC_SAMPLETIME_112CYCLES;						
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK){
    _Error_Handler(__FILE__, __LINE__);
	}	
	//конфигурация 3 канала
	sConfig.Channel = ADC_CHANNEL_4;
  sConfig.Rank = 3;
  sConfig.SamplingTime = ADC_SAMPLETIME_112CYCLES;						
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK){				
    _Error_Handler(__FILE__, __LINE__);
	}	
	//настройка DMA
  __HAL_RCC_DMA2_CLK_ENABLE();  
  hdma_adc1.Instance = DMA2_Stream0;
  hdma_adc1.Init.Channel = DMA_CHANNEL_0;
  hdma_adc1.Init.Direction = DMA_PERIPH_TO_MEMORY;
  hdma_adc1.Init.PeriphInc = DMA_PINC_DISABLE;
  hdma_adc1.Init.MemInc = DMA_MINC_ENABLE;
  hdma_adc1.Init.PeriphDataAlignment = DMA_PDATAALIGN_HALFWORD;
  hdma_adc1.Init.MemDataAlignment = DMA_MDATAALIGN_HALFWORD;
  hdma_adc1.Init.Mode = DMA_CIRCULAR;
  hdma_adc1.Init.Priority = DMA_PRIORITY_MEDIUM;
  hdma_adc1.Init.FIFOMode = DMA_FIFOMODE_DISABLE;
  hdma_adc1.Init.FIFOThreshold = DMA_FIFO_THRESHOLD_HALFFULL;
  hdma_adc1.Init.MemBurst = DMA_MBURST_SINGLE;
  hdma_adc1.Init.PeriphBurst = DMA_PBURST_SINGLE;
  HAL_DMA_Init(&hdma_adc1);
  __HAL_LINKDMA(&hadc1,DMA_Handle,hdma_adc1);
}

void DMA2_Channel0_IRQHandler(void){
  HAL_DMA_IRQHandler(&hdma_adc1);
}

В SPL вроде ненужно в этом режиме ставить команду ADC_Start, но в HAL без этого ацп не заработает.
В обоих режимах частота дискретизации была 10кГц, только в первом случае ( Scan continious) я ее примерно настроила, устанавливая предделитель ацп и sampling time, то есть получалось, ацп работало непрерывно постоянно преобразовывая данные, а в случае с запуском от таймера с более короткими sampling time. То есть даже если бы ацп занимал ресурсы мк, все равно бы оставалось время на то, чтобы инкрементировать temp. В моем понимании ацп как переферия должна вообще независимо от выполнения программы работать, так же как и таймер до тех пор пока не забираешь из нее данные на обработку. Но и дма же как раз для того и существует, чтобы не нагружать этим ядро. То есть данные с ацп в оперативку должны попасть при минимальном "вмешательстве" алу, но не получается.

Видимо, придется забирать данные через прерывания от ацп, но хотелось бы разобраться.

Добавлено after 46 minutes 9 seconds:
Пришла мысль, что отсутствие прерывания по ДМА связано с зависанием главной программы. Буду копать туда

[Мурик]

Посмотрите цветомузыку http://lightportal.info/publ/cvetomuzyk ... /3-1-0-133
В ее коде таймер запускает связку АЦП + DMA.

[jcxz]

[uquote="bezzabotna",url="/forum/viewtopic.php?p=3450894#p3450894"]Здравствуйте. Я снова со своим АЦП.
И еще почему-то DMA не генерирует прерывание по завершению обработки. Я даже брекпоинт поставить в обработчик не могу. Какую-то настройку упускаю?[/uquote]
Причин может быть 100500. И почему думаете что не генерит? Может генерит, входит в дефолтный ISR, выходит из него (без сброса состояния прерывания) и сразу же снова входит, потому что прерывание осталось необработанным. Потому что элементарно не прописали свой ISR в таблице прерываний. Тогда такая картина и будет как у Вас. Или ещё 100499 причин.
Калом не пользуюсь - не знаю что он внутри творит. И Вам не советую. А вопросы подобные Вашим как правило возникают у тех, кто калокодит.
И в DMA и в АЦП и NVIC целая куча битов статуса. Вы хоть один из них смотрели? Подозреваю что нет. А содержимое регистров конфигурации после кала проверяли? Тоже думаю что нет.
Первым делом следует открыть мануал на МК.

[bezzabotna]

В проекте по цветомузыке все почти так же.
Полазила по регистрам dma.
биты TCIF0 ,HTIF0 регистра LISR устанавливаются (что указывает на событие успешной передачи) при чем это происходит постоянно, тк при попытке сброса через регистр LIFCR они снова устанавливаются, если установлен EN.
Прерывания у меня разрешены, но смущает момент:
-бит EN никогда не сбрасывается, а должен по завершению передачи

То есть прерывания у меня разрешены, событие есть, а вот самого прерывания просто нет.

Добавлено after 34 minutes 8 seconds:
Все, проблема решилась. Ошибка в названии обработчика.

[Myp3ik]

bezzabotna, может пригодится. Там на SPL сделано для теста (под 103 контроллер, но смысл тот же). Таймер по аппаратному триггеру запускает АЦП каждые 50мс. ДМА складывает это все в массив и после 20 семплов прерывание трансфер комплит.

[bezzabotna]

Спасибо. Не подскажите оптимальный размер буфера для дма?
У меня три канала, информацию по каждому из них нужно складывать в свой отдельный массив из общего буфера.
Можно сделать маленький дма буфер на 3 ячейки и в прерывании данные быстренько раскидать по массивам, или же долго копить данные в большом буфере и потом долго их сортировать, но прерывание вызывать редко. Или наверно какая-то середина между этими крайностями.

[jcxz]

[uquote="bezzabotna",url="/forum/viewtopic.php?p=3450988#p3450988"]Все, проблема решилась. Ошибка в названии обработчика.[/uquote]
Значит я был прав: обработчик в таблице прерываний не был прописан и вызывался дефолтный кало-кубовский.

Добавлено after 4 minutes 11 seconds:
[uquote="bezzabotna",url="/forum/viewtopic.php?p=3451056#p3451056"]Спасибо. Не подскажите оптимальный размер буфера для дма?[/uquote]
Увеличение буфера -> уменьшение частоты прерываний -> уменьшение загрузки CPU, но в то же время и уменьшение скорости реакции системы на событие (уменьшение реалтаймовости обработки данных АЦП и отклика на них). И размер выбирается исходя из задачи. Если бы был какой-то один оптимальный на все случаи жизни размер, то он был бы константно зафиксирован в периферии.
Обычно стараются чтобы частота прерываний не превышала нескольких кГц. По возможности.

[bezzabotna]

Кубом я конкретно для ацп, дма и таймера не пользовалась, но 80% уже написано на HAL, так что менять библиотеку я естественно не буду.
Мне потом одни данные надо через цифровой фильтр пропускать, а другие прореживать.

[Myp3ik]

bezzabotna, например в F4 контроллере 3 АЦП, которые можно настроить в TripleMode. В этом режиме контроллер делает 3 измерения одновременно с трех разных каналов, а ДМА автоматом складывает это все в 3 ячейки массива. Один раз запускаете старт измерения по триггеру от таймера, а в прерывании ДМА забираете разложенные по полочкам результаты.

[bezzabotna]

Вопрос не в этом, а в оптимальном соотношении размера буфера дма и частоты его прерывания по его заполнению.
Зачем включать 3 ацп?