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

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

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

Это уже интересно.
В моей "теплице" будет 36 моторов.
Тоже еще думаю на сети ПЛК с языками МЭК делать или на сети из собственных контроллеров типа того который сейчас у меня моргает светодиодами.
Т.е. писать ли программу расчитанную на исполнения в как-бы безопасной и защищенной среде ПЛК либо писать на C для исполнения с полным доступом к процессору и всем ресурсам.
И склоняюсь к второму варианту, что-то мне говорит, что на ПЛК будет дольше. И надежность ПЛК оставляет сомнения после отзывов здесь.

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

Я уже решил как быть и спасибо кстати этой теме. Что именно решил? Смотрите выше, писал.
Но с удовольствием выслушаю все точки зрения, это интересно.

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

Сори, несете ерунду. Самое смешное, что с серьезным видом. Не понимаете о чем я? Займитесь RTOS, ПЛК и ООП и прочими цацами. Эта тема для новичков и тех кто может помочь, посоветовать и поделиться опытом.

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

программа растёт пока не превысит способности программиста (с)
после чего становится сложной (с)

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

"Нет сложных задач, есть ограниченность в их реализации" (С) Jeer

незнание законов мерфи не освобождает от ответственности
хотя таки да, уже многое о вас говорит

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


Так это как и раз называется построение архитектуры приложения. Вам, кстати, про это уже писали.

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

Практический пример - STM32Cube. Как это выглядит - ставите галочки какие блоки задействовать в микроконтроллере, ставите галочки при настройке этих блоков, и на выходе получаете готовый си-код инициализации процессора. Но так как настроек много, кода получилось много и некачественного, то результат получается неоправданно усложненный и плохо поддерживаемый, правда говорят что у многих он нормально работает.

Еще раз пишу: чужой код одновременно! Стек сетевой и USB, плюс WEB сервер и LCD матрица с тачскрином. В качестве вишенки светодиодом моргать с периодом 0.025 сек.
Наверное можно и без ОС, но нужно ли?

А какой критерий "отличности" у вас применяется?

Может можете сказать средний и пиковый процент загрузки процессора. Или пиковое портебление памяти. Или худший джиттер выдачи сигналов или статистику прерываний?
Может у вас есть подробный лог работы пограммы?

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

Да не спорьте, вы правильно пишите. Даже LCD с WEB сервером можно не добавлять.

RTOS еще облегчает отладку и соответсвенно ускоряет разработку.
Только ради этого одного ее оправдано везде применять.
Но почитав про FreeRTOS вы этого не поймете, поскольку эти всякие RTOS сильно отличаются друг от друга.
Начните с uCOS-III и почувствуйте силу.

Элементарно все это реализуется на конечных автоматах безо всяких ртосей!
В крайнем случае можно свой диспетчер задач накидать на systick. Зачем лезть в ртось-болото? Оверхед же жутчайший!
Тупые моргания светодиодом вообще таймером реализуются — даже прерываний никаких обрабатывать не нужно. Экранчик тоже аппаратно обновляется (если достаточно оперативки у МК) — при помощи DMA.

Боюсь содержание вашего github-а не позволяет относится к вашим словам серьезно. Фреймворк ваш в зачаточном состоянии.
И справтесь для начала у себя со сканированием 1-Wire"при помощи DMA"

Огурцов, буду вынужден Вас окончательно забанить за подобную писанину.

Ну так не было еще такого количества задач, чтобы всю периферию объять.

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

Скоро, кстати, буду расширять сниппеты на 0-вую серию (термомониторинг главного зеркала нашего телескопа, чипы STM32F042, связь по CAN, датчики — TSYS01).

Самый главный критерий - всё работает корректно.
Запас по скорости передачи данных есть, единственная проблема - памяти не хватает.


Чужой или свой - побарабану, если ресурсов хватает, конечно нужно.
ОС в любом случае требует дополнительные уровни абстракции и кушает ресурсы.



О как! Вообще-то специальность так и называется инженер-программист.
Но есть просто кодер, это уже уровень техника, тогда да, до инженера расти и расти.

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

И процесс включения - это функция стрелочки:
void NextStepOn()
{
..........................................................
if(step == Кружок_1) goto Кружок_1;
.........................................................
if(step == Кружок_N) goto Кружок_N;
..........................................................
if(step == Кружок_ВсеВключено) return;

..............................................................
Кружок_1:
{
}
step = ......; //
return;
............................................................
Кружок_N:
{
// здесь код соответствующий стрелочке
}
step = Кружочек_K;
return;
...............................................................
}

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

aiwa, если КА реализуется так, как вы нарисовали, то проще создать массив из указателей на функции, а потом делать

Согласен с небольшой поправкой: корректировку step внести внутрь stepfn[step]() так как в общем случае узлы графа невозможно будет линейно упорядочить.

Я всегда говорил - все беды от чрезмерного увлечения машинами состояний.
Скажем те же двигатели.
У них проблема в поддержании безопасной траектории действий.
Каждое движение должно быть осуществлено при соблюдении тучи сопутствующих разрешений от разных механизмов.
Т.е. начали движение и сразу проверяем: счетчик позиции и корректность его работы, состояние конечников, перегрузку по току, перегрев, вибрации, точки перехода на замедление или ускорение, скорость, тучу датчиков в цепи безопасности, работоспособность связи с узлами полевой шины, команды от HMI и т.д. и т.п.
Каждая проверка влечет переход в другое состояние с сопутствующими действиями по управлению другими механизмами и опять проверки всего вышеназванного.

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

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

Это и есть через анус. Топтание на машине состояний с попыткой найти "набор общих для состояний флагов" чтобы крыша не съехала от их разнообразия.

Я же говорил если точнее о цепочке задач. Т.е. очередях задач. В MQX есть такая фишка.
Сами задачи не содержат никаких функций смены состояний, они только оповещают достигли своей цели или нет.
Их просто убивают внешние задачи решатели или они даже сами себя могут убить если видят что не справляются с упралением целевым параметром.

Cъехавшей крыши нет. Как нет в таком случае, помянутого Вами всуе разрастания переходов в другие состояния машины. Ваши "великолепные" задачи ничем не отличаются от состояний нормально спроектированного автомата. А, как вы сказали -"топтание" в состоянии автомата ничем не хуже и не лучше работы запущенной задачи. При этом, естественно, например, для тех же целей мониторинга можно и нужно использовать отдельные задачи изменяющие в случае надобности состояние того-же "главного" автомата. Точно так-же его состояние будут менять и обработчики, например, аварийных прерываний.
По любому, если логика управления достаточно сложна, а не как в Ваших задачах включить/выключить двигатель, пусть и обвешанный несколькими датчиками, то программный код простым не будет, и никакая волшебная операционная система ничего решающего не превнесет. Но разбивку на несколько автоматов и/или упрощение главного автомата, это да - позволит сделать. То есть надо пользоваться комбинацией приемов и методов не возводя ничего в абсолют и панацею от всего.

И что здесь сложного? Управление пятью шаговиками, чтение концевиков и т.п. В том же проекте помимо пяти шаговиков с их концевиками идет управление затвором, чтение 8 платиновых терморезисторов, 8 DS18S20, опциональная работа с внешним АЦП, коммуникация через 2 RS-232 и 1 USB. Еще надо будет добавить туда опрос вакуумметра. И все это нормальными конечными автоматами реализуется.
А здесь так вообще независимо друг от друга три шаговика безо всяких дурацких ртосей работают. Правда, управление уже через другие драйвера — контроля питания нет.

Ну вы граждане даете. О чем тема-то?
Кто не хочет пользоваться ОСРВ - не пользуйтесь.
Также удивляюсь с тех кто им доказывает что ОСРВ панацея. Ну не хотят они, не-хо-тят. Ну и не нужно.
Зачем эти взаимные наезды и упреки? Толерантнее нужно быть, толерантнее.... У каждого свой путь, а понимание множества возможностей приходит только с опытом и годами, советы со стороны тут мало кому помогут- для готовности слушать советы тоже нужен опыт
Никто никому ничего не докажет, а опять перессоритесь только. а зачем?

+1

Да у вас полный трэш.
Куча отдельных переменных, не сгруппировано, в случае изменений количества моторов или при использовании этого как шаблона руками надо будет править не менее 7-и объявлений массивов.
От такого кода TC похоже и хочет избавиться.
И это у вас еще регулировка скорости и PID-ы не появились.
И покажите мне ваши коммуникации, что они у вас там делают и какой трафик могут тянуть.

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

Просто вы не поняли что я написал.

Но для других объясню.

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

Допустим вы делаете без RTOS в суперцикле.
Вы выполняете последовательно в цикле функции проверки действий пользователя и функции управления мотором. Все эти функции в себе содержат автоматы состояний.
Чтобы одни функции могли что-то передать другим вам надо объявить флаги.
В одних функциях эти флаги взводятся в других проверяются и сбрасываются.
Вот вам и сложность. У вас автоматы состояний, которые сами по себе не прозрачны, но еще в них появляются сторонние флаги.
Ваше внимание рассеивается, ваша оперативная память забивается. Вы не можете одновременно помнить более 7-и флагов.
И всё. Начинаете путаться и ошибаться.

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

А MQX убитые задачи перед кончиной еще и вызывают специальный callback, где можно оповестить всех заинтересованных, что задачи больше нет и почему.

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

Ну и где здесь преимущества?

Да все я в отличии от Вас понял . У Вас есть некая игрушка и Вы с ней играетесь в ОЧЕНЬ ПРОСТЫЕ ИГРЫ сводя все к одному приему программирования, и пока не наигрались. С организацией системного подхода к делу у Вас проблемы, посему навороты операционной системы Вас хоть как то систематизируют. Ну, как бы, да, тоже польза.


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

Нет. Если есть законченные автоматы состояний, то они взаимодействуют через изменения СОСТОЯНИЙ друг друга. Так что Все Ваши последующие фантазии про роль флагов, их количество и размазанность по автоматам, к делу не относятся.

Куча - это эмоции. А в цифрах сколько?

Если их для вас пока нет, то не используйте ось. Я вижу преимущества как в КА, в ОС, так и хоть в мэйнлупе Всё имеет право на жизнь в каждом конкретном случае


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

Почему вы думаете, что я вам прописываю RTOS? Если вы не хотите рассказать о своих проблемах, как же я вам помогу?

Если я спрошу, а чем же взаимодействуют автоматы если не флагами, то наверно встречу поток ругани.

Чукча писатель? Но все же читаем:

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

Это очень примитивное объяснение сущности ОС.
Вы пишите "ОС это событийно-ориентированная машина, которая отдаёт время наиболее приоритетной задачи, если ей есть что делать". Но вы забываете. что в функции ОС входит ТАКЖЕ расчет и динамическое изменение приоритетов задач, обеспечение интерфейса для взаимодействия и синхронизации между задачами, а также предотвращение деад локов.


В этом смысле да.
RTOS упрощает жизнь когда нужно чтобы несколько десятков задач (причем разного масштаба времени) реального времени работали параллельно.
После того, как реализовано ядро и базовые сервисы, решение такой задачи сильно упрощается.
Можно разбивать задачу на отдельные слабо связанные или даже не связанные части, которые прозрачно работают квазипараллельно и имеют универсальный интерфейс взаимодействия.
А если еще проработан механизм динамического изменения приоритета и предотвращения деадлоков. то вообще все в шоколаде.

Короче РТОС нужна где есть МНОГОЗАДАЧНОСТЬ (и причем задачи реального времени) и разделение ресурсов.

А у кого и РТОС есть подобная фича?

У меня
Благодаря специально мной спроектированной интеллектуальной дисциплине диспетчеризации у меня невозможно чтобы поток "завис" или "заблокировался".
Ну естественно приоритеты у меня динамические. Точнее сумма стат + дин приоритетов. Типа как в венде
Ими ядро управляет

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

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

Это в той, про которую бородатый анекдот?

Остапа несло ©
P.S.
Общаться с Доктором Туамозесом, Доном Амброзио и прочими реинкарнациями вечно озабоченного бездельника и провокатора, совершенно не о чем.

Может кому-то это покажется смешно, но это ноу-хау.
До которого НИКТО в мире пока не додумался. НИКТО. Я узнавал. И постоянно мониторю инет насчет этого.
Хотя идея достаточно проста и "лежит на поверхности".

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

Теперь можете смеяться сколько влезет. Я все сказал


Я сказал "типа как в венде", а не "точно как в венде".
Поэтому у меня ОС реального времени. а не как венда.

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

Весь секрет в проектировании системы и выборе процессора

А вообще, RTOS и прочее "ногодрыганье" для программиста не сложная задача.
А вот написать какой-нибудь парсер, компилятор, IDE, САПР для 3D, экспертную систему с ИИ - вот это реально "сложные программы"

Ну вылитый неуловимый Джо.

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

В MQX все! сервисы синхронизации имеют таймаут.


Чисто схоластически отмечу, что если автомат напрямую меняет переменную стостояния другого автомата, то это один и тот же автомат.

Уккшенный воблой, если так рассуждать, то как по мне сложным является или искусственный интеллект или программа байт реверса для авр на асме меньше 12 ти комманд и 13 тактов. и если первое рано （без всяких там табличных и пересылки с порта на порт） или поздно победят, то второе наверное вечно😜

С чего вы это решили?

Да ну? scmRTOS не менят приоритеты задач на ходу, они там статически задаются на этапе линковки, и тем не менее, это ОС.

Я написал, что "Одновременно предоставляя все необходимые для этого сервисы".
Ваш троллинг не удался.

А Вы выложите краткое изложение с примерами, как именно Вы делаете, мы и подскажем.
У каждого свой подход, перенимать чужой опыт Вам будет сложно.
Например, я практически не иcпользую RTOS, в отличие от выступивших тут апологетов.
Конечные автоматы - наше всё

Это иерархия автоматов!

1.Разумеется не один и тот же.
2.Про "напрямую" это Вы сами придумали и неведомо что под этим подразумеваете.

Проблема в том, что Вы не реализовывали сколь нибудь сложных конечных автоматов и соответственно не сталкивались с тем, как из оптимально реализовывать, например, стеки протоколов в семиуровневой модели OSI как правило описываюбтся в терминах конечных автоматов и при этом на КАЖДОМ уровне это совершенно свой автомат и еще такая же стопка автоматов на встречной стороне. Причем отдельные уровни реализуются еще и на разном оборудовании разных производителей.