Работал все время с ucos - клоном embos.
Решил протестировать freertos.

Сразу возник вопрос , как реализованы критические секции ?
в embos например

#define OS_EnterRegion() {OS_RegionCnt++; }

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

во фриртосе нашел

#define portENTER_CRITICAL() vPortEnterCritical()

void vPortEnterCritical( void )
{
/* Disable interrupts first! */
__disable_interrupt();

/* Now interrupts are disabled ulCriticalNesting can be accessed
directly. Increment ulCriticalNesting to keep a count of how many times
portENTER_CRITICAL() has been called. */
ulCriticalNesting++;
}

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

На то она и железобетонная критическая секция. Что не мешает делать Вам что-то свое. У меня, например FIQ не запрещаются.

Ерунда какая-то - какие вложенные? Чего в ручную? Причем здесь критическая секция?

Не запускать другие задачи это не "критческая секция" - это "остановить шедулер",
void vTaskSuspendAll() (в новых версиях переименовано в vTaskSuspendScheduler()), что естественно осуществляется без запретов прерываний. Причем во FreeRTOS при xTaskResumeScheduler() для простоявших задач восстановление делается максимально аккуратно.

ну вобщем понятно . в ембосе под критической секцией понимается непереключение задач(как во фриртосе суспенд щедулер ) , а для "железобетона "есть
__disable_interrupts();

а во фриртосе , наоборот - критическая секция это запрет прерывания, а для непереключения стоп щедулера.

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

1. "Просто" запретить/разрешить недостаточно для общего случая вложенных критических секций.
2. Описанный Вами вариант c OS_RegionCnt++ это и есть останов шедулера, только примитивный.

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

2. да и ето я тоже уже сообразил , посмотрел как во фриртосе реализован суспенд_щедулер -- понравилось , хотя глазу приятнее OS_RegionCnt++ (простите за упрямство

Вобщето для доступа к общим ресурсам есть более подходящие способы чем остановка шедулера, в UCOS например семафоры и мютексы, наверно и во freertos такое есть. Другие задачи при этом не останавливаются. Я использую для вызова malloc и доступа к sd карте.

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

Чтобы трагически не закончилась можно делать disable ... restore.

И вводить стек неизвестной длины? Со счетчиком проще. Можно, конечно, в статической переменной при входе в функцию запоминать состояние, но это неоправданный расход ресурсов, и централизация управления нарушается, к тому же операция должна быть атомарной. Хотя я лично себя с таким механизмом почему-то увереннее чувствую.

Это если restore()
1. вообще штатно реализовано;
2. реализовано, так, что не вносит дополнительных ограничений на использование.

Вот пример из CW help




А использование одной локальной переменной не есть на мой взгляд транжирством стека.
И никаких дополнительных ограничений на использование

Ограничение есть - disable() в одной функции а restore() в другой а то и в другой задаче.
Это ограничение.

Это как это - запрещать прерывания в одной задаче и разрешать в другой - я правильно понял?
Если так - то не примите за хамство, но такой стиль программирования, на мой взгляд - просто извращение какое то.
Запрещать прерывания (входить в критическую секцию) я всегда предпочитал лишь для коротких, детерминированных участков кода. Например для LPC это код сброса WDT, который действительно нельзя прервать.

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

Что-то ничего не понял. Ну хорошо, запретили мы прерывания, потом по ходу осоводили какой-нить event который тут же сделал более приоритетную задачу готовой и тут же перешли в её код. Вот и фсе. И нарушится вся логика, так как в той задаче куда перешли шедулер уже не выручит по таймеру в частности. ИМХО - запрет прерываний - вообще не должен быть доступен на уровне написания приложения.

Да.

Обсуждались ограничения применения. Это ограничение. Стоит так бездумно делать? Нет конечно. Можно без такого обойитсь? Наверняка да. Но случаи бывают разными, особено при обработке нештатных ситуаций.
Что касается конкретики - у меня, например, система собирается с двумя вариантами в зависимости от необходимости - c сохранением CPSR в локальной переменной и со счетчиком запретов прерывания. И плюс два подварианта - с запретом FIQ и без.

Это явные запрещения прерываний, которые Вы явно контролируете, но запрещения прерываний неявно используются и для внутрисистемных целей.

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


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