Jump to content

    
Sign in to follow this  
xmailer

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

Recommended Posts

Добрый день!

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

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

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
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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this