Jump to content

    

stm32 возможные действия в прерывании и основном цикле

Добрый день!

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

Ситуация с рабочим примером:

1. принимаем с частотой 10-20Гц данные с uart, складываем в переменные

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

И получается такая картина:

Если обрабатывать поступаемые в uart данные в RxCallback сразу, то реация на видео сразу происходит.

Если в RxCallback выставлять флаг и обрабатывать данные в основном цикле, включается какой-то тормоз.

Работа с видео ведется также в прерываниях, только от таймеров.

Спасибо!

 

Share this post


Link to post
Share on other sites
25 minutes ago, xmailer said:

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

А еще можно с пользой применить приоритеты прерываний. Или воткнуть ОСРВ и с не меньшей пользой задействовать приоритеты задач.

Share this post


Link to post
Share on other sites

А почему должен быть тормоз? Ставите прерывание на получение символа '\n' и формируете буфер средствами DMA (либо можете в прерывании по RXNE формировать буфер, без DMA, но анализировать на '\n' внутри прерывания). Как только получили '\n', выставили флаг, а в цикле внутри main тут же этот флаг увидели и делаете что надо с буфером. Сборщик же данных из уарта тем временем меняет буферы.

Я никогда еще с проблемами "тормозов" в подобном случае не сталкивался... В основном цикле происходит обработка кнопок, обработка флагов и т.д., и т.п. - все медленные операции. Внутри прерываний выставляю флаги или делаю "быстрые" операции (и операции, которые невозможно сделать внутри основного цикла, т.к. требуется быстрая реакция - скажем, коррекция SysTick по прерыванию PPS от GPS). При работе с USB тоже много чего нужно делать именно внутри прерывания...

Edited by Eddy_Em

Share this post


Link to post
Share on other sites
1 час назад, xmailer сказал:

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

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

Share this post


Link to post
Share on other sites
2 hours ago, xmailer said:

поясните пож-та вопрос: что можно делать в прерываниях?

Как любой абстрактный вопрос, он не имеет ответа. В прерываниях можно делать ВСЁ! Если ваш микроконтроллер справляется с исполнением программы, то почему вы должны не делать чего-то в прерывании?

 

Но я понимаю суть вашего вопрос, и в общем случая я поступаю следующим образом:

1. Прерывания должно выполняться как можно быстрее.

2. Взаимодействие прерывания и основной программы через средства межпроцессного взаимодйетсвия операционной системы. Без ОС давно уже не пишу.

3. Не тащу работу с динамической памятью в обработчики прерываний.

2 hours ago, xmailer said:

1. принимаем с частотой 10-20Гц данные с uart, складываем в переменные

Может быть лучше в кольцевой буфер?

2 hours ago, xmailer said:

Если в RxCallback выставлять флаг и обрабатывать данные в основном цикле, включается какой-то тормоз.

Работа с видео ведется также в прерываниях, только от таймеров.

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

Share this post


Link to post
Share on other sites

Спасибо за ответы!

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

Share this post


Link to post
Share on other sites
2 часа назад, haker_fox сказал:

Как любой абстрактный вопрос, он не имеет ответа. В прерываниях можно делать ВСЁ! Если ваш микроконтроллер справляется с исполнением программы, то почему вы должны не делать чего-то в прерывании?

Более того: В Cortex-M-ядре предусмотрен такой режим работы, когда процессор работает только в прерываниях, а вне прерываний - только спит. И не зря предусмотрен.

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

Share this post


Link to post
Share on other sites
2 minutes ago, jcxz said:

Более того: В Cortex-M-ядре предусмотрен такой режим работы,

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

Share this post


Link to post
Share on other sites

Все оказалось по другому: иначально код был сгенерен в Cube MX версии xxx для keil, вся работало на ура, по мере обновления куба с какой-то версии стала проявляться нестабильность работы проекта, заметили не сразу, поэтому пытались искать причингы в своем коде. Отсюда вопрос - какие инструменты используете в работе: HAL, периф? вообще куб кто-нить использует?

Share this post


Link to post
Share on other sites
38 минут назад, xmailer сказал:

вообще куб кто-нить использует?

Используют. Начинающие. И те кто сам разобраться в периферии не умеет.  :smile:

Share this post


Link to post
Share on other sites
43 minutes ago, jcxz said:

Используют. Начинающие. И те кто сам разобраться в периферии не умеет.  :smile:

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

jcxz, скажите кратко с чего у Вас начинается новый проект? Вы с нуля пишете руками? или у вас свой набор

Share this post


Link to post
Share on other sites
16 минут назад, xmailer сказал:

библиотека же как бы от производителя, кто лучше то напишет.

В этом Вы ошибаетесь. Ибо - разработкой периферии (схемотехнического её решения) и примеров её использования (Куб и иже с ним) занимаются совершенно разные подразделения "производителя". И второе часто отдано на откуп сторонним командам (студентов?). Да и сами блоки "периферии" в конкретном МК - часто купленные на стороне, а не разработанные самим "производителем". Соответственно и примеры к ним - портированные откуда-то. А потом Вы портируете уже портированное с наследованием всех багов и проблем. Результат закономерен...  :unknw:

Поймите, что в современном мире в крупных конторах (типа STM) очень активно используется субподряд и отдача на сторону непрофильных работ сторонним исполнителям. Времена натуральных хозяйств "всё делаем сами" у них давно прошли.

Цитата

jcxz, скажите кратко с чего у Вас начинается новый проект? Вы с нуля пишете руками? или у вас свой набор

С составления ТЗ -> выбор варианта реализации его требований на какой-то базе (МК, FLASH/FRAM, АЦП и т.п.) -> выбор конкретных чипов из имеющихся, с анализом плюсов и минусов каждого варианта -> изучение периферии выбранного МК -> покупка отладочной платы на выбранном (выбранных) МК с макетированием предполагаемых аппаратно-программных решений на базе этой платы.

Как-то так......

Это если нет какого-то задела по данной тематике на основе ранее выполненных проектов. Если тема пилится с "чистого листа". Если есть - тогда какие-то этапы можно пропустить.

Share this post


Link to post
Share on other sites
1 час назад, xmailer сказал:

вообще куб кто-нить использует?

Используют, чтобы посмотреть что он там и как настраивает в контроллере.

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Проблема с кубом в том, что с ним тоже надо разбираться. Это просто один из инструментов. Если хочешь его использовать, то надо его знать.
Например по началу появилась либа. С описанием. Описание либы - ссылалось на биты. То есть чтобы понять как она работает надо было ВСЁ РАВНО изучить даташит на проц.
Потом они взяли и никому слова не говоря похезали эту либу и появился HAL.
Сейчас, я совершенно случайно увидел вот такое...
stm32f7xx_hal_adc.c
stm32f7xx_ll_adc.c
С описанием "@brief   ADC LL module driver". (Почти по всем модулям МК)
К чему готовимся? Опять переформатирование?
Короче сложно на это всё ориентироваться тому, кто профессионально работает и у кого много проектов и/или они крупные.

Ещё одна причина в том, что универсальные драйвера они "универсальные". А синоним этому - громоздкие и избыточные.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now