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

[bezzabotna]

Теперь понятно. Спасибо.
То есть получается для continious mode точно установить частоту дискретизации не получится и дергать ацп остается только по таймеру.

[WiseLord]

Я тоже в своём текущем проектике было думал над тем, чтобы как-то запустить continius scan, но в нём действительно сложновато настроить нужный период опроса. Поэтому в итоге - обычный scan (на два канала), запускаемый на один раз по таймеру (настроен 20кГц), а результат складывающий в DMA буфер (256 * 2). В итоге в буфере - чередующаяся выборка с левого/правого каналов на 256 значений каждая.

[jcxz]

[uquote="bezzabotna",url="/forum/viewtopic.php?p=3446698#p3446698"]Теперь понятно. Спасибо.
То есть получается для continious mode точно установить частоту дискретизации не получится и дергать ацп остается только по таймеру.[/uquote]
А таймер - чем не точно? Программируете его на нужную частоту и он будет точно дёргать АЦП.

[WiseLord]

Плюс, если мне не изменяет память, иногда можно даже без прерывания - АЦП можно запускать по некоторым (но не всем) триггерам, связанным с переполнением/совпадением таймера. Я у себя поленился, сделал через прерывание.

[jcxz]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3446787#p3446787"]Плюс, если мне не изменяет память, иногда можно даже без прерывания - АЦП можно запускать по некоторым (но не всем) триггерам, связанным с переполнением/совпадением таймера. Я у себя поленился, сделал через прерывание.[/uquote]
При правильной организации прерывания от АЦП не нужны. АЦП, когда у него готовы данные, должен дёргать DMA. А уже DMA должен дёргать прерывание когда переслал некоторое количество сэмплов из АЦП в память (закончен DMA-блок).
Итого: сигнал таймера запускает преобразование одного или группы каналов (период таймера должен быть рассчитан заведомо не менее максимального времени требуемого на преобразования всех каналов в группе, которую запускает данный таймер); сигнал готовности очередного сэмпла от АЦП дёргает DMA - "перешли эти данные в память"; DMA, когда переслал блок из N сэмплов в память, дёргает NVIC, сообщая программе обработать данный блок в ISR (сам DMA в это время продолжает пересылку следующего блока (двойная буферизация)).
Если для АЦП заданы не только скан-группы каналов, но и инжектированные (я вижу такие есть в STM32F4), то период таймера нужно увеличить на время, необходимое чтобы иногда пропускать на преобразование инжектированные каналы.

Обрабатывать данные по одному сэмплу, дёргаясь с частотой 40кГц в прерывание и читая данные из АЦП программно, без DMA - пустая трата производительности ЦПУ на кучу лишних входов/выходов в ISR. Данные от АЦП нужно обрабатывать пакетно, раз они потоковые.

[a5021]

[uquote="jcxz",url="/forum/viewtopic.php?p=3446799#p3446799"]При правильной организации прерывания от АЦП не нужны. АЦП, когда у него готовы данные, должен дёргать DMA. А уже DMA должен дёргать прерывание[/uquote]
По хорошему, кроме, как в немногочисленных случаях специально сконструированных программ, прерывания вообще не нужны. Опрос флагов и/или статусов вполне себе способ, чтобы оперативно обрабатывать поступающие данные. Нужно только правильно построить рабочий цикл.

[jcxz]

[uquote="a5021",url="/forum/viewtopic.php?p=3446809#p3446809"]По хорошему, кроме, как в немногочисленных случаях специально сконструированных программ, прерывания вообще не нужны. Опрос флагов и/или статусов вполне себе способ, чтобы оперативно обрабатывать поступающие данные. Нужно только правильно построить рабочий цикл.[/uquote]
Чушь! Прерывание нужны для реакции процессора на асинхронные события от периферии. Делать такое поллингом - впустую гробить кучу процессорного времени. Ничего более менее серьёзного так не напишешь.

[a5021]

[uquote="jcxz",url="/forum/viewtopic.php?p=3446844#p3446844"]Чушь! Прерывание нужны для реакции процессора на асинхронные события от периферии.[/uquote]
Настоящая чушь в категоричной форме -- это когда кроме прерываний, другие способы "реакции процессора на асинхронные события от периферии" не рассматриваются.

Делать такое поллингом - впустую гробить кучу процессорного времени.

Не надо ничего гробить. Проверили флажок, если он не взведен, перешли к другой задаче.

Ничего более менее серьёзного так не напишешь.

Насчет "серьёзного" тут могут быть варианты.

[Sergi]

Пробовал по способу а5021 ловить байты в USART. Иногда не успевал. Перешел на прерывания и все наладилось. Кроме USART1_IRQHandler() других обработчиков не понадобилось. Осваиваю SWITCH технологию.

[pvit]

[uquote="a5021",url="/forum/viewtopic.php?p=3446809#p3446809"][uquote="jcxz",url="/forum/viewtopic.php?p=3446799#p3446799"]
По хорошему, кроме, как в немногочисленных случаях специально сконструированных программ, прерывания вообще не нужны. Опрос флагов и/или статусов вполне себе способ, чтобы оперативно обрабатывать поступающие данные. Нужно только правильно построить рабочий цикл.[/uquote]
Вы таким макаром рискуете сделать связный код, который будет ломаться от каждого чиха. И добавите гимора в поддержку и сопровождение подобного кода. Технически так делать можно, но это не очень рационально.

Поллинг нормально прокатывает для вполне конкретного случая - когда у вас ровно две задачи. Одна выгребает данные из одного источника, вторая обрабатывает. И даже в том случае предварительную обработку и выставление флагов удобнее выносить в прерывания. А как только задач три и больше - без какого-то аналога RTOS с сообщениями код станет месивом.

[jcxz]

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

[uquote="a5021",url="/forum/viewtopic.php?p=3446899#p3446899"]Не надо ничего гробить. Проверили флажок, если он не взведен, перешли к другой задаче.[/uquote]
Реальное устройство - десятки источников прерываний, Вы видимо будете эти десятки флажков в суперцикле проверять? И какова будет частота прохода этого цикла (период опроса флажков)? И какое в результате время реакции на флажок? А если флажок оказался взведён (нужно обслужить периферию), как это будете делать? Вот так в этом суперцикле начнёте и обслуживать? А если это не пара мкс, а довольно сложные и тяжёлые вычисления - как будут в это время жить флажки, которые Вы перестали опрашивать? Начнут в это время терять данные?
А если ещё и питание батарейное - как будете выкручиваться с вашим суперциклом?

[uquote="a5021",url="/forum/viewtopic.php?p=3446899#p3446899"]Насчет "серьёзного" тут могут быть варианты.[/uquote]
Так ответьте на вопросы.

PS: Ущербность Вашего подхода вроде очевидна. Разве что ардуинщики так делают....

Добавлено after 6 minutes 21 second:
[uquote="pvit",url="/forum/viewtopic.php?p=3446946#p3446946"]Поллинг нормально прокатывает для вполне конкретного случая - когда у вас ровно две задачи. Одна выгребает данные из одного источника, вторая обрабатывает.[/uquote]
Даже в этом случае - как например экономить энергию если процессор всё время молотит?
Или обработка занимает значительное время: получили полный фрейм, только после этого можно обрабатывать, пока обрабатывали -> не могем поллить периферию -> данные потеряли.

[a5021]

[uquote="pvit",url="/forum/viewtopic.php?p=3446946#p3446946"]Поллинг нормально прокатывает для вполне конкретного случая - когда у вас ровно две задачи.[/uquote]
В простейшем случае поллинг может без проблем обслуживать много источников данных при условии, что время процедуры обработки пришедших данных много меньше периода поступления этих данных. Если моменты взведения флагов полностью асинхронны, то поллинг будет гарантированно успевать обрабатывать все поступающие данные, если суммарное время работы всех обработчиков меньше, чем период поступления данных от самого шустрого источника. Это самый худший случай. Вообще же, использованием DMA и правильной организацией обработки входных потоков, режим поллинга обеспечивает большую производительность уже хотя бы из за отсутствия расходов на переключение контекста. Напомню, что только на вход в прерывание у Cortex-M уходит 12 тактов. Есть еще затраты на выход. В плане расхода процессорного ресурса -- это непроизводительные потери. В режиме работы с прерываниями эти потери есть, а в поллинге нет.

А как только задач три и больше - без какого-то аналога RTOS с сообщениями код станет месивом.

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

Единственное, что следует учитывать -- это требования к квалификации пишущего. Работа через прерывания прощает и получасовые заседания внутри дилеев, писать можно, как напишется. Для поллинга такой номер, естественно, не прокатывает, т.ч. лучше продумывать структуру заранее и к реализации отнестись ответственно. Тогда и месива никакого и масштабируемость, какая потребуется.

Добавлено after 26 minutes 1 second:
[uquote="jcxz",url="/forum/viewtopic.php?p=3447048#p3447048"]Реальное устройство - десятки источников прерываний,[/uquote]
Это какое-то типовое устройство, самое массовое, которое на данном форуме собирают или устройство существующее исключительно в ваших фантазиях для удобства доказывания недоказуемого? А че только десятки? Давайте уже сотни источников прерываний, тысячи.

Вы видимо будете эти десятки флажков в суперцикле проверять? И какова будет частота прохода этого цикла (период опроса флажков)? И какое в результате время реакции на флажок?

Десятки флажков? По времени -- это чепуха.

А если ещё и питание батарейное - как будете выкручиваться с вашим суперциклом?

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

PS: Ущербность Вашего подхода вроде очевидна. Разве что ардуинщики так делают....

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

Даже в этом случае - как например экономить энергию если процессор всё время молотит?

Референс почитать, не?

получили полный фрейм, только после этого можно обрабатывать

Полный фрейм чего, простите?

[jcxz]

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Вообще же, использованием DMA и правильной организацией обработки входных потоков, режим поллинга обеспечивает большую производительность уже хотя бы из за отсутствия расходов на переключение контекста. Напомню, что только на вход в прерывание у Cortex-M уходит 12 тактов. Есть еще затраты на выход. В плане расхода процессорного ресурса -- это непроизводительные потери. В режиме работы с прерываниями эти потери есть, а в поллинге нет.[/uquote]
Да ладно!?
А не задумывались сколько времени будет тратиться на пустые опросы флагов когда событий от них не поступает? Скажем - есть быстрая периферия (SPI на несколько десятков МГц) которая часто генерит события, и есть медленная (в тысячи раз реже). И медленной - большинство. Крутить цикл поллинга придётся в расчёте на быструю периферию, получается десятки тысяч опросов медленной периферии будут впустую тратить процессорные такты. Не задумывались?
Экономите на пуговицах, а теряете....
12 тактов - ну раз Вам их так жалко - возьмите ARM7 или ARM9 - там вход в прерывание много короче.

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

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Десятки флажков? По времени -- это чепуха.[/uquote]
Сколько в тактах? А тот тут распинались по поводу 12 тактов на вход в прерывание...

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Скажите, Вы же про WFE ничего и никогда не слышали?[/uquote]
У меня то WFE во всех проектах есть. А куда Вы его будете в свой суперцикл впендюривать, позвольте узнать?
Да и всё-таки хотелось бы услышать о времени реакции на событие в периферии? Вот с прерываниями, если мне нужно будет реагировать быстро на какое-то событие, я просто увеличу приоритет его прерывания. А Вы то своим суперциклом как выкручиваться будете, когда он до этого события только через сотни тактов после добредёт, проверив кучу неустановленных флагов?

PS: Ущербность Вашего подхода вроде очевидна. Разве что ардуинщики так делают....

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

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Референс почитать, не?[/uquote]
Так Вы же адепт суперцикла, с прерываниями тут никаких проблем нет.

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Полный фрейм чего, простите?[/uquote]
Предположим - Ethernet-фрейм. Который в себе содержит IP, содержащий в себе TCP, содержащий в себе HTTP, содержащий в себе... ну вот тут суперцикл и приплыл.....

[pvit]

[uquote="jcxz",url="/forum/viewtopic.php?p=3447048#p3447048"]Даже в этом случае - как например экономить энергию если процессор всё время молотит?[/uquote]
Не везде надо, но если флаги взводятся по прерываниям, то внутрь while(flag) вставляется wfi. Напоминаю, я не ратую за поллинг, а формализую условия, где он может прокатывать.
[uquote="jcxz",url="/forum/viewtopic.php?p=3447048#p3447048"]Или обработка занимает значительное время: получили полный фрейм, только после этого можно обрабатывать, пока обрабатывали -> не могем поллить периферию -> данные потеряли.[/uquote]
Значит с большой вероятностью у вас больше 2 задач. Например третья парсит протокол во фреймах (если они не заворачиваются полностью в DMA, как отсчеты АЦП).

[a5021]

[uquote="jcxz",url="/forum/viewtopic.php?p=3447071#p3447071"]А не задумывались сколько времени будет тратиться на пустые опросы флагов когда событий от них не поступает?[/uquote]
Не имею привычки задумываться о каких-то там сферических флагах или таких же прерываниях. Если нет хотя бы общего описания процесса или устройства, то и говорить-то, в общем, не о чем.

Скажем - есть быстрая периферия (SPI на несколько десятков МГц) которая часто генерит события

Как часто? Со скоростью "несколько десятков МГц" / 8 ? А не слишком ли это дофига даже для ваших фантастических примеров?
Пусть эта "быстрая" через DMA работает и будет помедленнее. Умельцы тут на форуме динамическую индикацию демонстрировали. Молотит через SPI+DMA во весь опор, не то, что без прерываний, а и вовсе полностью аппаратно. Говорю же, как процесс организовать.

12 тактов - ну раз Вам их так жалко - возьмите ARM7 или ARM9 - там вход в прерывание много короче.

На название темы что-ли посмотрите. Мож тогда дойдет, что древние ARM7-9 тут не в тему малость.

Десятки источников прерываний - обычная ситуация в любом более-менее серьёзном устройстве сложнее абдурины.

Видать сильно секретные все эти устройства, раз вы их даже назвать не решаетесь.

Сколько в тактах? А тот тут распинались по поводу 12 тактов на вход в прерывание..

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

У меня то WFE во всех проектах есть. А куда Вы его будете в свой суперцикл впендюривать, позвольте узнать?

В начало или конец, а что?

Да и всё-таки хотелось бы услышать о времени реакции на событие в периферии?

Давайте я проведу вам маленький ликбез, а то чувствую, вы еще долго в глупостях упражняться будете. Картина с этими событиями такая: если прерывание разрешить в периферии, но не разрешить в контроллере прерываний NVIC, то каждый раз, когда периферия будет "генерировать" прерывание, вызова обработчика происходить не будет, но будет взведение флага в регистре NVIC->ISPR. Вот этот регистр и надлежит мониторить на предмет смены значения. А мониторить его не просто, а очень просто:

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

#define DEFAULT_ISPR_STATE 0x...
// ...

for (;;) { // тут весь процессинг
  while (DEFAULT_ISPR_STATE == NVIC->ISPR[0]) {
    // делаем то, что мы должны делать в свободное время
    // например, сортируем и обрабатываем принятые данные
    // небольшими порциями, чтобы надолго не отвлекаться
  }
  // если  мы тут, то периферия сгенерировала событие и нужно выяснить, какое.
  // проверку начинаем с самых частых событий
  if (NVIC_GetPendingIRQ(DMA1_Channel2_3_IRQn)) {
    // SPI1 data arrived
    NVIC_ClearPendingIRQ(DMA1_Channel2_3_IRQn);
    // ... 
    continue;
  } else if (NVIC_GetPendingIRQ(DMA1_Channel4_5_IRQn)) {
    // USART1 data arrived
    NVIC_ClearPendingIRQ(DMA1_Channel4_5_IRQn);
    // ...
    continue;
  } else ....
  }
}

Это для Cortex-M0.

Так Вы же адепт суперцикла, с прерываниями тут никаких проблем нет.

То, что вы по неизвестной причине называете суперциклом, лучше бы по сложившейся практике именовать event-driven programming. Следующая ступень после ардуиновских прерываний на все случаи жизни, если что.

Предположим - Ethernet-фрейм. Который в себе содержит IP, содержащий в себе TCP, содержащий в себе... ну вот тут суперцикл и приплыл.....

Без разницы, что он там в себе содержал. Обработка точно такая же, как и для любых данных, принятых по любому интерфейсу.

[pvit]

[uquote="a5021",url="/forum/viewtopic.php?p=3447059#p3447059"]Единственное, что следует учитывать -- это требования к квалификации пишущего.[/uquote]
У меня для вас плохие новости. Когда в проекте больше 1 человека, то на QA проверяют, чтобы код НЕ зависел от квалификации пишущего. Потому что требуется простота поддержки. Допускать зависимость проекта от одного гения будет либо идиот либо вредитель.

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

Для примера - у меня последний код написан именно на поллинге. Но с пониманием причин, рисков и не в ущерб поддерживаемости.

[arkhnchul]

[uquote="jcxz",url="/forum/viewtopic.php?p=3447071#p3447071"]Десятки источников прерываний - обычная ситуация в любом более-менее серьёзном устройстве сложнее абдурины.[/uquote]к слову, большая часть промавтоматики, на которой заводы работают, имеет примерно три источника прерываний - АЦП, таймер и изменение уровня на ноге aka EXTI. Ну пусть еще RXNE для модбаса.

Добавлено after 1 minute 47 seconds:
[uquote="pvit",url="/forum/viewtopic.php?p=3447079#p3447079"]Когда в проекте больше 1 человека, то на QA проверяют[/uquote]чочоч, больше одного землекопа - и вот так сразу QA появляется?)

[pvit]

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3447084#p3447084"]чочоч, больше одного землекопа - и вот так сразу QA появляется?)[/uquote]
Чтобы делать ревью кода, нужно хотя бы 2 программиста (толково ревьючить можно только чужой код). Поэтому у "мастера на все руки", занимающегося задачами в одно жало, подобные условия не сложатся даже в теории.

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

[a5021]

[uquote="pvit",url="/forum/viewtopic.php?p=3447079#p3447079"]У меня для вас плохие новости. Когда в проекте больше 1 человека, то на QA проверяют, чтобы код НЕ зависел от квалификации пишущего.[/uquote]
Критерии в двух словах не обрисуете, на основании которых QA принимает решение, зависит ли код от квалификации пишущего или нет?

Потому что требуется простота поддержки. Допускать зависимость проекта от одного гения будет либо идиот либо вредитель.

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

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

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

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

Как в вашей галактике борются с ситуацией, когда за ревью садятся два "мастера на все руки" ?

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

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

[pvit]

[uquote="a5021",url="/forum/viewtopic.php?p=3447089#p3447089"]Критерии в двух словах не обрисуете, на основании которых QA принимает решение, зависит ли код от квалификации пишущего или нет?[/uquote]
Если совсем по-простому, то при замене программиста не должно быть воплей что проект писали дебилы и этот кусок говна проще переписать с нуля .

Я не знаю универсальных метрик. Могу сказать только про лично свои, для тех опенсорных проектов что выкладываю на гитхабе. Каждый кусок кода должен быть понятен случайному человеку, не совсем идиоту. Без необходимости погружаться в весь проект целиком и держать в голове кучу особенностей.

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

К сожалению, принципиально новые понятия, типа оценки рисков, объяснить простыми словами вроде "вот из-за этой строчки кода сорвутся сроки сдачи", не всегда возможно. Ну по крайней мере лично я не умею.
[uquote="a5021",url="/forum/viewtopic.php?p=3447089#p3447089"]Шуточки про форсированные коммиты в мастер весьма популярны в программерской среде. На деле же, никто сходу коммитить не даст.[/uquote]
При чем тут форсированные коммиты в мастер? Я вам про ревью объяснить пытался. Коммитят всегда в бренч, потом ревью, потом мерж. Ну вот на ревью за выкрутасы с поллингом в main loop и будет много неприятных открытий. Если конечно нет немедленных пояснений, что причины не "я художник, я так вижу", а более рациональные для проекта.