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

a5021

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

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

Говоря про 24 такта нужно сделать оговороку, что здесь и дальше их число может отличаться в зависимости от ядра. Цифра означает некую близкую величину, не претендующую на абсолют.

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

Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний. Речь идет о возвращении из обработчика прерывания, которому "посчастливилось" случиться на пол-такта позже, чем прерыванию с более высоким приоритетом. Тогда более приоритетное прерывание вернет управление через 24 такта и еще столько же уйдет на обслуживание того, латентность которого замеряется. Итого 48 тактов, без учета времени выполнения кода в обработчиках. Дофига, надо заметить. Поллинг при дуплете двух самых приоритетных событий отработает за чуть больше десятка тактов. Выводы очевидны.

Реклама

Ярослав555

[uquote="Reflector",url="/forum/viewtopic.php?p=3448226#p3448226"][uquote="a5021",url="/forum/viewtopic.php?p=3448192#p3448192"]Не "хоть в твоем любимом", а только в нем и получится. Оставшийся вариант -- это 1мс в обработчике сидеть. Вижу, что вы готовы и такой подход рассматривать.[/uquote]
Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.[/uquote]
У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.

Добавлено after 4 minutes 1 second:
Есть критичные задачи - их вешаю на таймер с высоким приоритетом, который тикает каждые несколько мС. Остальное не критичное к времени раскидываю на разные софтверные системные таймеры, которые крутятся от одного железного с более низким приоритетом. А потом на тестах смотрю успевают ли все задачи.

Реклама

Reflector

[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний. Речь идет о возвращении из обработчика прерывания, которому "посчастливилось" случиться на пол-такта позже, чем прерыванию с более высоким приоритетом. Тогда более приоритетное прерывание вернет управление через 24 такта и еще столько же уйдет на обслуживание того, латентность которого замеряется. Итого 48 тактов, без учета времени выполнения кода в обработчиках. Дофига, надо заметить. Поллинг при дуплете двух самых приоритетных событий отработает за чуть больше десятка тактов. Выводы очевидны.[/uquote]
Никаких 48 тактов тут не будет. После выхода из первого прерывания из стека не будут удаляться сохраненные регистры, соответственно они не будут и заново сохранятся для второго прерывания, итого от 24 тактов останется 6, суммарно 30.

Касательно твоих замечательно работающих комов на скорости 921600 бод... А чему там тормозить? На такой скорости байты приходят каждые 8.7 us, добавь туда задачу длительностью 1ms и посчитай на сколько частей ее придется разделить, чтобы не терялись данные. Наверно сотни на две, а это и дополнительные расходы на само дробление, и после каждого из заходов будут опрашиваться флаги, возможно все, возможно суммарное число лишних проверяемых флагов достигнет нескольких тысяч. А еще попробуй любую задачу разбить на нужное количество частей... Вот создал я массив на 20 значений отсортированных в обратном порядке, вызвал стандартный sort, он отрабовал за 16 us, это больше 8.7 us, нужно сортировку выполнить захода за 3, как это сделать?

jcxz

[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Если кому-то вопрос латентности тоже покажется интересным, то говорить надо не о максимальном времени, а скорее о лучшем и худшем случае.[/uquote]
Очередной бред. Ну да - в лучшем случае - 4 такта, а в худшем - 400 тактов. В лучшем случае - устройство будет работать, а в худшем - будет терять данные. Сейчас - работает, через миллисекунду - глючит, ну что-ж - так звёзды сложились.

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

[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Горе-счетовод, высчитавший "максимальную латентность", неизвестно с какого перепугу просто посчитал частный случай.[/uquote]
тут похоже до фанатичного адепта суперлупа наконец то стала доходить одна из проблем его обожаемого метода.

[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний.[/uquote]
Если б у Вас были хотя бы зачатки мозга, вы смогли бы осилить понятие "Tail-chaining" из мануала на Cortex-M в который Вы всех тут неоднократно посылали.
И не несли бы очередной вздор.

Реклама

a5021

[uquote="Reflector",url="/forum/viewtopic.php?p=3448620#p3448620"]Никаких 48 тактов тут не будет. После выхода из первого прерывания из стека не будут удаляться сохраненные регистры, соответственно они не будут и заново сохранятся для второго прерывания, итого от 24 тактов останется 6, суммарно 30.[/uquote]
Может и 30, может и 64. Cortex-m0, напомню, не умеет Tail-Chaining и вход/выход у него по 16 тактов. Я ж специально в тексте приписку сделал, что число тактов примерное, т.к. имеются варианты.

Касательно твоих замечательно работающих комов на скорости 921600 бод... А чему там тормозить?

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

Вот создал я массив на 20 значений отсортированных в обратном порядке, вызвал стандартный sort, он отрабовал за 16 us, это больше 8.7 us, нужно сортировку выполнить захода за 3, как это сделать?

Мне нравится, как мои оппоненты старательно выбирают примеры, чтобы на прерываниях оно еще могло как-то работать, а с поллингом уже пришлось бы заморачиваться с планированием подзадач. Я же уже приводил пример с задачами "А", "Б" и "В", где та же самая проблема встает во весь рост и с использованием прерываний. Если с поллингом к такому приходится быть готовым всегда, то вы со своим ардуино-сварщецким подходом, чего делать будете? Плакать и мамку звать?

Добавлено after 9 minutes 48 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3448656#p3448656"]Очередной бред.
[...]
И не несли бы очередной вздор.[/uquote]
Я не увидел в вашем "крике души" возражений по технической части, как и какой-либо конкретики вообще. Свои личные духовные ценности, в любимом вами стиле "визжащие бабы на базаре", обсуждайте без меня.

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3448532#p3448532"]У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.[/uquote]
О примерно таком подходе я и говорил, когда упоминал "специально сконструированные". У слушателей курсов "Ардуино для слесарей и сварщиков", однако, упоминание об этом ведет к деструктивным процессам в головном мозге и когнитивным расстройствам. Истерики на этом форуме тому подтверждения.

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

Реклама

Reflector

[uquote="a5021",url="/forum/viewtopic.php?p=3448772#p3448772"]Может и 30, может и 64. Cortex-m0, напомню, не умеет Tail-Chaining и вход/выход у него по 16 тактов. Я ж специально в тексте приписку сделал, что число тактов примерное, т.к. имеются варианты.[/uquote]
Отмазка так себе, особенно на фоне того, что конечно M0 умеет Tail-Chaining. Гораздо проще все объясняется тем, что у тебя очень смутные представления об архитектуре используемых мк.

Мне нравится, как мои оппоненты старательно выбирают примеры, чтобы на прерываниях оно еще могло как-то работать, а с поллингом уже пришлось бы заморачиваться с планированием подзадач. Я же уже приводил пример с задачами "А", "Б" и "В", где та же самая проблема встает во весь рост и с использованием прерываний. Если с поллингом к такому приходится быть готовым всегда, то вы со своим ардуино-сварщецким подходом, чего делать будете? Плакать и мамку звать?

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

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

Реклама

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]
Да не, ничего. Врать не нужно. Только и всего.

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

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

jcxz писал(а):Я неоднократно просил 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:
Все, проблема решилась. Ошибка в названии обработчика.