[aiwa 0]

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

Нарисуйте логику включения/отключения нарисовать поименованными кружочками со стрелочками между ними.

Это можно сделать вне зависимости от сложности процесса.

Далее, имя кружочка - метка , стрелочка - небольшой кусок кода.

 

И процесс включения - это функция стрелочки:

void NextStepOn()

{

..........................................................

if(step == Кружок_1) goto Кружок_1;

.........................................................

if(step == Кружок_N) goto Кружок_N;

..........................................................

if(step == Кружок_ВсеВключено) return;

 

..............................................................

Кружок_1:

{

}

step = ......; //

return;

............................................................

Кружок_N:

{

// здесь код соответствующий стрелочке

}

step = Кружочек_K;

return;

...............................................................

}

 

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

то внести изменения в программу быстро и просто.

[Eddy_Em 1]

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

void NextStepOn(){
    stepfn[step]();
    if(++step == MAX_STEP) step = 0;
}

Изменено 9 января, 2017 пользователем Эдди

[aiwa 0]

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

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

 

[AlexandrY 3]

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

Я всегда говорил - все беды от чрезмерного увлечения машинами состояний.

Скажем те же двигатели.

У них проблема в поддержании безопасной траектории действий.

Каждое движение должно быть осуществлено при соблюдении тучи сопутствующих разрешений от разных механизмов.

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

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

 

С RTOS это все решается легче.

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

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

В результате задачи двигателя всегда короткие и девственно чисты от всяких проверок и перепроверок.

Если надо включить контроль еще чего-то в процессе управления двигателем, то не надо добавляь это в кучу веток,

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

[zltigo 1]

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

В результате задачи двигателя всегда короткие и девственно чисты от всяких проверок и перепроверок.

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

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

[AlexandrY 3]

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

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

 

Я же говорил если точнее о цепочке задач. Т.е. очередях задач. В MQX есть такая фишка.

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

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

[zltigo 1]

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

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

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

 

 

[Eddy_Em 1]

Скажем те же двигатели.

...

С RTOS это все решается легче.

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

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

[Ruslan1 17]

Ну вы граждане даете. О чем тема-то?

Кто не хочет пользоваться ОСРВ - не пользуйтесь.

Также удивляюсь с тех кто им доказывает что ОСРВ панацея. Ну не хотят они, не-хо-тят. Ну и не нужно.

Зачем эти взаимные наезды и упреки? Толерантнее нужно быть, толерантнее.... У каждого свой путь, а понимание множества возможностей приходит только с опытом и годами, советы со стороны тут мало кому помогут- для готовности слушать советы тоже нужен опыт :)

Никто никому ничего не докажет, а опять перессоритесь только. а зачем?

:beer:

[Tpeck 0]

У каждого свой путь, а понимание множества возможностей приходит только с опытом и годами, советы со стороны тут мало кому помогут- для готовности слушать советы тоже нужен опыт :)

Никто никому ничего не докажет, а опять перессоритесь только. а зачем? :beer:

+1

 

[AlexandrY 3]

И что здесь сложного?

Да у вас полный трэш.

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

От такого кода TC похоже и хочет избавиться.

И это у вас еще регулировка скорости и PID-ы не появились.

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

[Eddy_Em 1]

В случае изменения количества двигателей я просто напишу новую прошивку.

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

[AlexandrY 3]

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

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

 

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

 

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

 

Допустим вы делаете без RTOS в суперцикле.

Вы выполняете последовательно в цикле функции проверки действий пользователя и функции управления мотором. Все эти функции в себе содержат автоматы состояний.

Чтобы одни функции могли что-то передать другим вам надо объявить флаги.

В одних функциях эти флаги взводятся в других проверяются и сбрасываются.

Вот вам и сложность. У вас автоматы состояний, которые сами по себе не прозрачны, но еще в них появляются сторонние флаги.

Ваше внимание рассеивается, ваша оперативная память забивается. Вы не можете одновременно помнить более 7-и флагов.

И всё. Начинаете путаться и ошибаться.

 

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

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

 

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

[Eddy_Em 1]

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

Только ртось еще кучу ресурсов тратит на сохранение регистров при смене задач.

 

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

[zltigo 1]

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

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

 

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

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

Чтобы одни функции могли что-то передать другим вам надо объявить флаги.

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