Враги украли плату индикации

Ни как ОНО узнает об этом без обратной связи то?
ERROR лишнее состояние, да и IDLE тоже.

fsm->state можно и в прерывании сменить на ERROR чтобы вся схема перешла в это состояние.
таких автоматов может быть много. Еще хорошо бы состояние RESET или INIT, из которого схема в IDLE переходит.

Ага, еще нужны состояния ALARM, WARNING, FAULT, HARD FAULT, PANIC и т.д.

откуда вообще взялся светодиод в энтом абстрактном примере? Придираетесь, профессор?

да, да назовем IDLE "константа 65535" и захардкодим, чтобы джедаи не догадались

Т.е. нынче принято обсуждать что угодно, но только не то, что спросил TC?



Боюсь вы термину IDLE придумали некое свое семантическое значение. Если оно вам помогает , ну и хорошо.
Только автоматов разных может быть много в программе и не упасётесь разными вариациями: IDLE1, IDLE2, IDLE3 ...

ну ТС хотелось "контекста". В общем случае "контекст" может выглядеть так:

В качестве data и *proc м.б. struct fsm и fsm_proc из предыдущего примера с небольшой доработкой.
Или принципиально затачивать каждый пример для светодиода?

Это верно только в одном частном случае - когда границы критической секции не выходят за пределы таких коммутируемых функций.
А если выходят - как быть?
Также тут предполагается, что моменты переключения задач всегда на границах таких функций. Это корпоративная многозадачность.
А если длительность таких функций очень (на порядки различается)?
А если нужно выполнять функции, реагирующие на реалтайм-события, критичные к времени реакции. И в то же время среди функций есть тяжёлые (длительные) вычислительные функции, к тому же если время их выполнения заранее не известно.
Как в этом случае быть?

А где здесь сохранение контекста?
Здесь изображен просто синхронный вызов функций с неким указателем неизвестно на что.
А если брать struct fsm как контекст задачи в применении к светодиоду, то это будет точно то же что я и продемонстрировал если вам дописать недостающий код, но будет более раздуто, так как состояниям будет выделяться дополнительная величина в управляющем шаблоне.

Указатель на "контекст" хранится в *data, не нужно ТС никаких downloadContext. Т.е.

да, будет почти тоже самое. В этих примерах все абстрактно. Но, пмсм, так проще для понимания.

Насколько вообще понимаю суть вопроса, ТС просит обьяснить, как писать реентерабельные функции.

Вопрос был как сохранить контекст, а не где его хранить!

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

Мой пример тоже основан на этом.
Но! Только для светодиодов, соленоидов и прочей односигнальной мелочи.

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

не могут выходить, функции так создаются


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


ну собственно вы сейчас называете все недостатки такого подхода и почему появились операционки. Отсюда ответ на ваш вопрос использовать операционку!

Извините, но это жесть что влезаю из топика "С vs C++", но этот код можно сделать еще лучше.


pattern_start_ptr и pttn_ptr нет ну никакого смысла делать указателями, только лишние разименовывания. По смыслу это индекс позиции. Дать им имена pos и startPos или index и startIndex.
Чистая вкусовщина - меня коробит от сочетания в именах больших букв и подчеркиваний ну и typedef struct туда-же. Выделять типы данных префиксом "T_" нет смысла - современный редактор цветом покажет, что данный символ - тип данных. Т.е. меняем на



Здорово бы комментарии поддержать кодом, введя тип данных


Тогда такая комбинация

сокращается до


Тут мне не все понятно, вроде бы эта функция вроде конструктора SolenoidPattern. Не хватает определения функции Set_solenoids_voltage.


Ну и может быть отказаться от конструкции

в пользу

тогда из цикла пропадает индекс, но так сделать не всегда можно, иногда он нужен.

чего то я видать безнадежно устарел

вот это что за на?

А если таких элементов миллион и обработка - одна простая операция?
Будет чудовищный оверхед - 10% времени будет выполняться полезная работа и 90% - входы/выходы в функцию и разные проверки.
Вы конечно скажете - "в таком случае нужно не по 1-му, а по 100 элементов за раз обрабатывать".
Но тогда получается программа привязывается к среде выполнения и кроме решения задачи каждый раз нужно учитывать ещё кучу условий.
А если длительность обработки каждого элемента заранее неизвестна?
А если вызываете функции некоей сторонней библиотеки, где тоже время выполнения заранее неизвестно?


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


Вся эта си-плюс-плюсная объектно-инкапсулированная хрень хороша только для тех, кто не заглядывает в файлы листинга компилятора.
А если Вы задумываетесь об оптимальности не исходников (как здесь), а результирующего кода (скорости выполнения и размера), то выбирайте наиболее стандартные конструкции, типа for (int i = 0; i < n; ++i). Оптимизаторы компиляторов на них наиболее "натасканы" и код будет оптимальным.

Я, после опыта оптимизации по скорости DSP-кода, взял это себе за правило - если хочется чтобы код был наиболее оптимален после компилятора, конструкции в исходнном коде должны быть наиболее простыми.
На входе у меня был вот такой вот весь правильный С++ код, со всеми конструкторами/деструкторами и т.п. и при этом он безбожно тормозил и алгоритм не успевал обработать поток данных. После убиения всей этой плюсовой красоты и полного переписывания на простой си-код, скорость выполнения того-же самого алгоритма увеличилась в несколько сотен раз!
Потому что оптимизатор простой код сумел многократно распараллелить.