FreeRTOS - передача семафора в задачу.

Selivanov_Sasha · 14.10.2021, 15:06

Всем добрый день!

На работе поручили заняться разработкой нового прибора на микроконтроллере STM32 (исходя из технической задачи мой выбор пал на STM32F407VE) с обязательным условием - использование ОСРВ FreeRTOS.
С микроконтроллерами знаком, разрабатывал на их основе пару приборов, но с данной ОСР не работал никогда, и поэтому хочу попросить здесь совета. Работаю в STM32CubeIDE.

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

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

Вставлять в прерывание функцию вращения двигателем я, разумеется не стал. Вместо этого я решил в зависимости от статуса кнопки пересылать в функцию управления двигателем семафор. Условно говоря, код выглядит так:

Код:

void EXTI3_IRQHandler(void) //Кнопка вращения двигателя вверх
{
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_3);

  if(HAL_GPIO_ReadPin(GPIOD,GPIO_PIN_3) == GPIO_PIN_SET) //Если на входе высокий уровень, то пока ничего не делаем
  {
	asm("nop");
  }
  else //Если уровень изменился, то
  {
	  xSemaphoreGiveFromISR(sem_curr_upHandle,NULL); //Даём семафор из прерывания
  }
}

//

void EXTI4_IRQHandler(void) //Кнопка вращения двигателя вниз
{
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_4);

  if(HAL_GPIO_ReadPin(GPIOD,GPIO_PIN_4) == GPIO_PIN_SET) //Если высокий уровень, то ничего не делаем
  {
	asm("nop");
  }
  else //В противном случае выдаём семафор
  {
	  xSemaphoreGiveFromISR(sem_curr_downHandle,NULL);
  }
}

Задача, в которой я собираюсь вращать двигателем, выглядит так:

Код:

void poll_button(void const * argument)
{
  for(;;)
  {
	  if(xSemaphoreTake(sem_curr_upHandle,portMAX_DELAY) == pdPASS) //Если семафор на вращение вверх принят функцией и равен одному (время ожидания семафора максимальное)
	  {
		  HAL_GPIO_WritePin(GPIOA,GPIO_PIN_9,GPIO_PIN_SET);
	  }
	  else if(xSemaphoreTake(sem_curr_downHandle,portMAX_DELA  Y) == pdPASS) //Если семафор на вращение вниз принят функцией и равен одному (время ожидания семафора максимальное)
	  {
		  HAL_GPIO_WritePin(GPIOA,GPIO_PIN_10,GPIO_PIN_SET);
	  }
  }
}

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

1. Правильна ли моя идея с использованием семафоров в принципе для данной ситуации? В любом случае, эту ОСРВ мне надо изучать по работе;
2. После отдачи семафора по нажатию кнопки - как его вернуть обратно после её отжатия?
3. Задача poll_button не реагирует на полученный семафор. Если в одном из условий изменить "== pdPass" на "!= pdPass", то светодиод будет гореть, но если так сделать в двух условиях, то
всё равно будет гореть только один светодиод, будто бы задача по какой-то причине зависает. Что это может быть?

Заранее всех благодарю за ответы.

NewWriter · 14.10.2021, 15:58

Пардоньте за мнение, но зачем для столь мелкой задачки, как управление коллекторным моторчиком, вообще ставить ОСРВ???
Ну хорошо, надо так надо, пусть будет.
Далее, если никода с ОСРВ не работали доселе, придется сразу принимать новые правила игры.
В числе которых - оставьте... оооох, блин, почитал дальше у вас по тексту. Да, тут же надо всё с начала. Итак. Цикл русскоязычных статей по FreeRTOS, автор Курниц: http://easyelectronics.ru/img/ARM_ku...TOS/Kurniz.pdf
До тех пор, пока не прочтете ВСЁ от и до (или хотябы две трети), мы не сможем друг друга понимать.

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

Сообщение от Selivanov_Sasha

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

Не, это не так делается. Чисто логически, цикл работы кнопки представляет собой два фронта - нисходящий и восходящий - кнопку нажали и кнопку отпустили.
А чисто практически сюда вмешивается механика кнопки и ложные импульсы, генерируемые дребезгом контактов в момент замыкания и размыкания. По этой причине при опросе кнопок редко применяют прерывания - из-за навороченности алгоритма обработки. Гораздо проще опрашивать входы кнопок через равные интервалы времени, примерно 5 - 25 мс. Это гарантирует "устаканивание" дребезга и однозначный результат.
Для гашения дребезга еще электрически ставят конденсаторы примерно на 0,1 мкФ параллельно кнопке.

Следовательно. Следовательно, в РТОС нужно создать задачу, которая будет опрашивать входы кнопок, декодировать их, определять события (отслеживая предыдущие состояния), и складывать эти события в очередь. Задача должна запускаться с выбранным интервалом времени опроса кнопок.

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

Ну и как бы вот еще раз повторюсь, что РТОС совершенно не является необходимостью. Такие штуки запросто делаются без нее, на алгоритмах КА.
А ставя РТОС, нужно во-первых, очень хорошо владеть её инструментами, во-вторых, иметь четкую структуру всей системы. Прежде, чем написать хоть строчку кода, нужно на бумаге нарисовать всю (или хотябы половину) структуры в виде блок-схем. Иначе - будет завал и множество багов от того, что ОСРВ имеет сложную структуру взаимодействия.

mike-y-k · 14.10.2021, 16:06

Selivanov_Sasha, таки здесь почитать…
Есть много другой информации.
Таки Вам нужна удочка, а не очередная рыба по конкретному поводу.

PS NewWriter, может стоит писать ОСРВ и RTOS для начинающего ТС?

Selivanov_Sasha · 14.10.2021, 16:15

NewWriter, спасибо за столь развёрнутый ответ! Я написал, что управление моторчиком - одна из возможностей моего девайса, т.е. не единственная.

Получается, что любая задача в ОСРВ, даже если она не очень большая, всё равно должна быть разбита на более мелкие задачи? За материал спасибо, для меня
он будет особенно полезен.

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

mike-y-k · 14.10.2021, 16:29

Selivanov_Sasha, если обязательным условием является использование ОСРВ и в Вашем резюме не затесалось про "ОСРВ/RTOS", то у Вас должен быть лаг времени на освоение новой предметной области…

Обговорите этот вопрос с начальством и приступайте к освоению…
Серию статей с хабра пользовать как практикум начинающего

NewWriter · 14.10.2021, 22:10

Сообщение от mike-y-k

писать ОСРВ и RTOS для начинающего

Пожалуй, да

Лень было переключать раскладку.

Сообщение от Selivanov_Sasha

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

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

Сообщение от Selivanov_Sasha

любая задача в ОСРВ, даже если она не очень большая, всё равно должна быть разбита на более мелкие задачи?

Нет. Тут принцип вообще несколько иной.
Вы вначале прочтите хотябы первые пару-тройку глав из вышеприведенных материалов, чтобы хотябы понимать, о чем мы тут.
Просто не хочется повторяться и писать много букав, поскольку базовые принципы уже описаны по вышеприведенным ссылкам.
И в дополнение официальный мануал на актуальную (10-ю) версию FreeRTOS: https://www.freertos.org/features.html

И скажу честно, что во многом, написать ПО для подобной задачи (которая изложена в теме) без RTOS методами обычных КА (конечные автоматы, теория автоматного проектирования) гораздо легче, чем правильно развернуть систему ОСРВ, чтобы она работала безглючно и не тормозила.

Кстати, нынче активно продвигается ОСРВ Azure, заточенная в основном под IoT.

PS. Глядя на ваш кусок текса проги, думается, вам бы подтянуть обычные алгоритмы и обычные знания и опыт работы с МК. В частности, работу с кнопками. Иначе, рискуете вообще завязнуть во всем этом.

DanilinSA · 15.10.2021, 13:48

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

Цитата:

любая задача в ОСРВ, даже если она не очень большая, всё равно должна быть разбита на более мелкие задачи?

Нет. Делить нужно на логически связанные задачи с минимальным взаимодействием.
Условно например:
1) Сканирование матрицы клавиатуры.
2) Отрисовка экрана.
3) Работа с портами обмена.
4) Опрос входов.

Каждая задача работает автономно и только изредка получает(или передает) сообщение другим задачам.

mike-y-k · 15.10.2021, 13:59

Selivanov_Sasha, на закуску

3 года назад была тема - посмотрите еще и там.

NewWriter · 17.10.2021, 10:10

Ну что, автор малость почитал мануалы по FreeRTOS? Тогда выкладываю демо-проект по описанной в начале задаче (во вложении ниже).
В нем не используются семафоры. Вместо этого задействован механизм Task Notifications - уведомления, направляемые в задачу. Разработчики FreeRTOS предлагают этот новый механизм как менее ресурсоёмкий, чем семафоры.

Чисто физически, уведомления представляют собой дополнительные поля (массив полей) в структуре TCB (блок управления задачей). И когда откуда-либо нужно отправить уведомление конкретной задаче о каком-то событии, в эти поля записывается флаг уведомления и 4-байтное значение полезной нагрузки.
Отправка уведомления:
xTaskNotify(pxMotor, command, eSetValueWithOverwrite);
где pxMotor - дескриптор задачи, в которую отправляется уведомление, command - прикрепленная инфа, eSetValueWithOverwrite - способ записи инфы (перезаписать).
Задача будет ожидать получение уведомления xTaskNotifyWait(0, 0, &command, 0xFFFF), находясь в приостановленном состоянии. Как только уведомление получено, задача переходит в активное состояние, читает пришедшее значение и выполняет его.

Отличие уведомлений от семафоров в том, что уведомления направляются напрямую в конкретную задачу. Семафор же - безадресный.
Если в настройках FreeRTOS включен configUSE_TASK_NOTIFICATIONS (1), то каждая задача имеет как минимум один канал уведомлений. Следовательно, не нужно создавать семафоры.

В принципе, я бы автору темы настоятельно рекомендовал вначале потренироваться в простом программировании без ОСРВ, научиться опрашивать кнопки, строить простые взаимодействия через if(flag) DoIt(); . Даже на таком простом принципе, комбинируя прерывания и проверку флагов (конечные автоматы), можно замесить все требуемые ингредиенты в программу. В прерываниях исполняются все быстрые или неотложные алгоритмы, такие как чтение входов от кнопок с декодированием и выставлением флага готовности, получение байтов извне по интерфейсу. А в общем цикле выполняются все медленные алгоритмы, такие как отрисовка дисплея и тп.

Потому как отлаживать ОСРВ гораздо сложнее, и такие базовые потребности, как опрос кнопок, работа с прерываниями и т.п. уже должны быть изучены и отработаны. А чтобы научиться понимать операционку, нужно не только читать мануалы и примеры, но и самолично залезть руками в нее и пощупать её во время исполнения, посмотреть, как меняются байты, из чего состоят задачи, очереди, семафоры, как всё это укладывается в память.
Ну и на будущее - не беритесь за те задания, которые не можете выполнить.

Selivanov_Sasha · 18.10.2021, 13:29

NewWriter, да, малость почитал, и понял, что будет "больно", так как знания новые, и они для меня кажутся сложными (но освояемыми).

Признаться честно, даже не вериться, что вы под мою задачу сделали демо-проект. Хочу выразить вам свою благодарность и признательность за потраченное на это время. Уверен, он очень поможет мне в освоении ОСРВ.

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

По поводу вашего последнего совета: безусловно, так и надо делать, но у меня, к сожалению, сейчас нет иного выбора. По совету mike-y-k обговорил детали с руководством. Всё поняли, время выделили.

Спасибо всем ответившим!