caxapa.ru :: А по мне - так наоборот. КА идеален для множества последовательных переходов. Выношу в КА всю подобную логику работы.

Nikolay_Po (24.04.2025 08:03, просмотров: 159) ответил AlexBi на ИМХО, state machine хорошо смотрится когда между состояниями много не последовательных переходов. Но если есть множество последовательных действий типа включили, подождали, выключили или много циклов, тогда КА смотрится как на корове седло.

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

Мысли: КА достаточно там, где производительности процессора достаточно для всех задач. В таком случае, ОСРВ не нужна - функции системы выполнит набор конечных автоматов и аппаратные источники прерываний с различными приоритетами.

Если же желательно выполнять важные задачи чем чаще, тем лучше и, поэтому, нагрузка на ЦП будет достигать 100%, то требуется планировщик. И ОСРВ.

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

Ответить

- простите, а что в вашем понимании в этом контексте "быстро и надёжно"? - Vit(24.04.2025 09:06)
  - Из практики. Задача программисту: "Добавь эту функцию". Nikolay_Po(132 знак., 24.04.2025 09:13)
    - я, извините, не понял, где надёжно? но ещё предполагал, что вы о добавлении задач в рантайме. - Vit(24.04.2025 09:59)
      - Нет, я про бизнес. Что руководителю достаточно поставить задачу и она будет предсказуемо выполнена. В случае ОСРВ. И не так предсказуемо, не так надёжно выполнена в случае КА. - Nikolay_Po(24.04.2025 15:48)
        
        Думаю, что это лёгкий мухлёж. Существует масса подходов, позволяющих писать модульно, гибко и управляемо. Под ОСРВ обычно понимают ОС с вытесняющей многозадачностью, но вот сама вытесняющая многозадачность не является основным фактором гарантированной работоспособности добавляемых участков кода (ведь необязательно новый код это отдельные задачи?) и неразваливаемости всего остального. Да, многозадачность является определённой реализацией модульности. Да, на уровне Vit(2178 знак., 26.04.2025 11:39)
        
        Поддерживал софт огрооооомной промустановки, есно, написанной как КА. Я даже не знаю сколько там было автоматов, наверно не меньше 100500. Понадобилось добавить функционал, добавил, понадобилось изменить, изменил. ЧЯДНТ? - IBAH(24.04.2025 19:12)
        
        Квалификация у вас не та. Слишком высокая. А нужно, чтобы студент справился. ОСРВ снижает порог входа в сложные системы. Это и не плохо, и не хорошо. - Nikolay_Po(24.04.2025 21:47)
        
        Дело не в квалификации, а в организации ПО. Вообще, топлю за языки МЭК, на них нельзя написать кривой КА. На С/С++ при автоматном программировании концепция должна быть такая же. - IBAH(24.04.2025 22:16)
        
        Лично я не представляю себе, как сделать КА на языке МЭК. А вот коллега, который не может внедрить фичу, потому, что иначе у него "всё развалится" - как раз умеет. Но, блин, внести доработку в его проект - это боль. И время, и непредсказуемость результата. И да, писать КА на Си/Си++ он умеет и делает это. Nikolay_Po(140 знак., 25.04.2025 10:18)
        
        Для КА на МЭК наиболее адекватный вариант специализированный язык - SFC. Либо часто встречается расширение языка LD - "стадии", т.е. участки программы, которые можно активировать и деактивировать. - AlexG(25.04.2025 14:45)
        
        Ещё была возможность писать КА в программе S7-GRAPH. Я пользовался для программирования конвеерных линий лет 20 назад, было очень наглядно и работало надёжно. Бoмж(1914 знак., 25.04.2025 17:05, ссылка, ссылка)
        
        Спасибо. - Nikolay_Po(25.04.2025 18:28)
        
        Раз в неделю пишу. Но на FBD именно КА не очень нужен, благодаря тому что всегда вычисляются все ветки программы (что несовсем правда, просто внешне выглядит так). Cкpипaч(153 знак., 25.04.2025 10:39)
        
        Если у вас студенты справляются, то у меня один вопрос: где таких студентов взять? Eddy_Em(703 знак., 24.04.2025 22:08)
        
        Практически дословно, всё это было сказанно в 1995-м году на одной из пьянок одним стареньким профессором другу академику! 8) - Cкpипaч(24.04.2025 22:11)
        
        Другими словами, если студенты херовые, значит, препод херовый. Нужно работать с тем, что есть. Зажечь человека своей вовлечённостью, своим примером и своей поддержкой. Другое дело, что студенту может оказаться это не нужно - тогда надо искать, собирать тех, кому нужно. В этом тоже работа преподавателя. - Nikolay_Po(25.04.2025 10:20)
        
        Соваглобусье! Говорят, только 10% людей способны овладеть научными методами мышления, даже на уровне средней школы. Остальные принимают решения исходя из своего, а чаще чужого опыта тех самых 90% людей. Задача педагогики не научить обезьяну ездить на велосипеде, а вырастить человека, не дать ему стать обезьяной. И это нужно начинать делать с зачатия. - IBAH(25.04.2025 11:57)
        
        У педагогики 2 немного противоречащие друг другу задачи. С одной стороны, вырастить работников, которые адекватно заполнят рабочие места, для чего нужно дать им необходимые навыки. С другой стороны, не переучить, чтобы они не начали ставить под сомнение существующий общественный порядок. - SciFi(25.04.2025 12:03)
        
        Так отож! Педагогика 2.0! - IBAH(25.04.2025 12:24)
        
        Это не только "другими словами", но и "мысль совершенно другая", не имеющая к моей ни малейшего отношения. - Cкpипaч(25.04.2025 10:29)
        
        До меня не донеслась, увы. - Nikolay_Po(25.04.2025 10:29)
        
        Учителям всегда кажется что ученики бестолковые. Абберация зрения. Кроме того, они забывают что потому и достигли успеха сами, в своё время, шли в числе первых в новую область знания. Туда где небыло учителей. - Cкpипaч(25.04.2025 10:34 - 10:45)
        
        Мне нравятся цитаты двухтысячелетней давности о никчёмности молодого поколения. Не знаю, насколько достоверные, но я легко готов поверить, что старые пердуны во все века глупы одинаково :-) - SciFi(25.04.2025 10:37)
        
        ...немного под другим углом: вот было поколение изобретения транзисторов - их условыне учителя, перед ними, были поколением ламповой техники, а ученики - поколением цифровой схемотехники. Попытка "передать знания молодым" вполне естественно упиралась в отсутствие интереса к устаревшим знаниям. Потому и оценки нелестные. Строго в соответствии к освоению того чему хотели научить (а не того, что в это время только зарождалось). - Cкpипaч(25.04.2025 10:46)
        
        2-4к лет назад "новых знаний" не было. Новое знание за поколение, это середина 19 века и позжэ. А в наше время есть люди, которые застали ланпы и щас небрежно тычут в Ютуп на 5-гиговых процах. - mse homjak(25.04.2025 11:09)
        
        Недавно где-то прочел. Удивительное время, одновременно живут люди еще не заставшие "отправить факс" и уже не заставшие "отправить факс". - LightElf(25.04.2025 12:32)
        
        Жванецкий вайб. - SciFi(25.04.2025 12:35)
    - Оно отчасти правда. Но если есть данные что проц условно 50% времени лежит в sleep, то у обоих проблем нет. Cкpипaч(470 знак., 24.04.2025 09:37)
      - Даже если проц нагружен на 100%, это не значит что он не может сделать что-то ещё. Может, просто некоторые функции начнут исполняться медленнее. В концепции РТОС это проще пареной репы - самая низкоприоритетная задача будет получать меньше процессорного времени. В нормальном дизайне ничего не поломается, но может увеличиться время некоторых действий. Думаю это вполне можно считать эффектом "накинуть 10% от себя". - =AlexD=(25.04.2025 10:37)
        
        Я - пробовал. Обычно где-то в неожиданном месте начинает глючить. Cкpипaч(12 знак., 25.04.2025 10:48)
        
        Охотно верю. Слишком много кода в прерываниях - это вообще загон себя в критичные условия. - =AlexD=(25.04.2025 10:54)
        
        Мы о RTOS говорили. Нет? О том что там "все просто немного замедлится". На практике будет совершенно иначе, полезут странные "артефакты". Cкpипaч(25 знак., 25.04.2025 10:57)
        
        То что вы пишете относится к дизайну, а не к ртос. Очереди событий, счётные семафоры и инверсия приоритетов как правило позволяют избегать множества проблем. - =AlexD=(25.04.2025 14:01)
        
        ...оставшихся проблем (после устранения "множества") обычно хватает на пожизненное трудоустройства пары ~~говно~~кодеров. У меня несколько примеров, когда перенос разумного кол-ва кода (90%) из RTOS в корпоративку, существенно поправляло дела в уже почти списанных проектах. - Cкpипaч(25.04.2025 14:13)
        
        Есть подозрение, что в ходе переноса, линейный код на циклах был переписан на шаги конечного автомата, в ходе чего просто выловили блох. КА это вообще наилучшее архитектурное решение в программировании. Для большинства применений в любом окружении. - =AlexD=(25.04.2025 14:25)
        
        Вообще-то там и так код небыл особо линейным, алгоритмы управления плохо "линеаризируются". Достоверно, было "отстрелено" 99,0% сигналов, семафоров и прочих объектов синхронизации. Склоняюсь к предположению что ключом к победе было именно это. - Cкpипaч(25.04.2025 14:37)
        
        "из RTOS в корпоративку" - возможно стоит понимать как "из вытесняющей RTOS в кооперативную RTOS"? - mr-x(25.04.2025 14:18)
        
        Да. Именно так. Прошу прощения за жаргон. Cкpипaч(548 знак., 25.04.2025 14:38)

Средства и методы разработки