Чувствую необходимость качественного шага - пошел изучать этот ОСРВ...

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

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

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

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

мне уже доводилось работать с диспетчером задач в ассемблере (точнее в АлгоритмБилдере) - согласен изящная штучка, вот и подумал что в С должно быть чтото ещё интереснее. застрял пока на приведенном выше уровне - сам диспетчер подзадач вызывается таймером обычно это всё это связано с дин. индикацией семисегментника - от неё и тактируется, и делитель берётся тоже зависимый от номера включенного в данный момент разряда. удобно сканировать привязанную к анодам (катодам) клавиатуру, или производить другие не сильно критичные ко времени подзадачи - время сна процессора при таком "раскладе" часто доходит до 80% и более и при этом не наблюдается никаких тормозов интерфейсов.

Добавлено after 1 minute 11 seconds:
это точно, шкура - она такая...

Добавлено after 4 minutes 38 seconds:
Аlex, а не подскажете, может есть какая не слишком замудреная чтобы начать...

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

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

Добавлено after 3 minutes 50 seconds:
у меня тоже обычно проще, но, каждый раз приходится чегото придумывать... хочу стройный и универсальный шаблон, чтобы таскать его из задачи в задачу как Ваш настройщик семисегментника...

Я сам начинал с OSA и всегда начинающим её советую. Но всё зависит от компилятора, она не все поддерживает.

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

нет конечно, в цикле в майне у меня вообще только #asm("sleep") и всё

вы любитель крайностей

Ivanoff-iv, дак у Вас всё (автомат, флаги всякие, возвраты, ...) крутится из обработчика прерываний ?

Да. я обычно завожу один таймер и по максимуму всё подчиняю его прерыванию: сначала критичные процессы (переключение сегмента...) потом SEI, а дальше менее критичные ко времени задачи, отсюда же запускаю и АЦП и сдесь же ловлю и обрабатываю результат (предыдущего)

Добавлено after 1 minute 1 second:
просто код пишу максимально линейный и быстрый чтобы гарантированно до следующего вызова завершился

Добавлено after 47 seconds:
итак практически РТОС выходит
но самопальная

Добавлено after 5 minutes 22 seconds:
хотя можно и флаг устанавливать об окончании выполнения цикла: если не стоит - делаем холостой ход (делаем только неизбежное: переключение сегмента, да ход счетчиков и выпадаем) а выпадаем в завершение прошлого цикла (согласен - будет проскок, но это лучше чем переполнение буфера)

ну и в чем смысл? навороченный обработчик напрасно тратит ОЗУ на сохранение рабочих регистров, хотя нужды в этом нет. на сохранение/восстановление этих регистров расходуется время, хотя нужды в этом нет. "потом SEI" - это риск повторного входа в обработчик, если он слишком долгий.

ради чего всё это вы делаете? ради пустого главного цикла?

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

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

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

И зачем себя так ограничивать ?
Запустите всё в основном цикле, и пусть там всё крутится. И за время выполнения можно не переживать... А всё, что нужно сделать точно по времени, синхронно с системными тиками - можно и в прерывание засунуть.

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

Добавлено after 5 minutes 14 seconds:
может както и вручную время можно выбрать - не пробовал... но эти две характеристики присутствуют

Добавлено after 33 minutes 45 seconds:
а у меня нет навороченного обработчика и переходов к над/подпрограммам - просто линейный код разбвавленный IF и switch-case...

Добавлено after 10 minutes 47 seconds:
кстати приложу ртос с которым работал...это не С конечно..., но вот чтото подобное хочу для С найти:
// Диспетчер задач обеспечивает независимый (паралельный) запуск Задач в соответствии с их парамерами (Period_Task период запуска - может быть 1-255)
// Для основной программы диспетчер "невидим" - не затрагивает стека, не изменяет регистров.
// Диспетчер необходимо периодически вызываеть с постоянной установленной частотой (это можно делать по таймеру или даже по W.Dog-таймеру)
// Период вызова задачи равен периоду вызова диспетчера умноженного на значение Period_Task для этой задачи.
// Период вызова диспетчера должен быть больше чем время выполнения самого диспетчера (иначе он будет вызываться непрерывно)
// Время затрачиваемое на работу диспетчера (22+10*количество_задач)тактов.

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

И причём тут "опасный производственный объект" я, например, так и не понял. Там есть требования - делать именно такой алгоритм ?
Если есть какой-либо контроль кода, то Вы хоть какую ОСь найдёте - её не пропустят.

имхо, отвратительнейший стиль программирования, т.н. макаронный (мешанина длинных макаронин, перепутанных между собой). не делайте так. как у вас происходит модификация кода? вот что-то добавить-изменить или тем паче убрать - у вас же сразу потянутся соседние участки, которые зависимы между собой!

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

Добавлено after 8 minutes 21 second:
приведу простой пример - традиционный термометр на DS18x20 и семисегментниках
из кода сразу виден весь основной алгоритм. при этом вы можете заменой функций вывода переделать его на вывод на ЖКИ или запись на SD-карту. переделав функцию получения температуры, вы можете использовать любой другой датчик. и основной алгоритм остается прозрачным.

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

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

по сравнению с вашим подходом - исключительно одни плюсы.

После запроса температуры нужно подождать, для 12 бит - целых 750ms, так что твой код очень далек от идеала.

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