caxapa.ru :: Не только. Прототредсы - вполне приемлемый ответ на вопрос: "как из автомата вызвать автомат".

Скрипач, пророк (30.07.2013 13:38, просмотров: 753) ответил Vit на Шалыто это "автоматное программирование" - технология, использующая конечные автоматы в первую очередь для документирования программ - читай для получения процентовок. "Прототрид'сы" и вариации на тему позволяют писать квазилинейный код без

Не только. Прототредсы - вполне приемлемый ответ на вопрос: "как из автомата вызвать автомат".

... но не любой ценой.

Ответить

- Приемлемый ответ в виде "вложенного автомата" есть у Шалыто. А у прототредов есть проблема -- как ожидать более одного события одновременно. - fk0(30.07.2013 16:08)
  - Нет в прототредах такой проблемы Скрипач(101 знак., 30.07.2013 19:35 - 19:43)
    - Жечь напалмом за такой говнокод! CPU load over 9000%. Не для батарейного питания точно. И не для автомобильной тематики вообще, к слову. И чем больше CPU, тем больше такой говнокод сожрёт в амперах. Да и реактивность системы в целом ни к чёрту, fk0(43 знак., 30.07.2013 22:40)
      - оглянитесь вокруг. Пока вы экономите милливатты, мега- и тераватты спокойно тратят впустую. Да и распад на солнце и в р/а элементах не остановить. - zeleny(31.07.2013 20:13)
        
        Думаете, нужно жахнуть? :-) - SciFi(31.07.2013 20:25, youtube)
      - Не все, а только те, что могут поступить СЕЙЧАС. Впрочем, согласен. Для батарейки нужно выворачивать автоматы на изнанку и тогда прототредс идут лесом. Скрипач(154 знак., 30.07.2013 23:01)
        
        не нужго ничего выворачивать. В основном цикле ложимся спать. По приходу любого прерывания - просыпание и проворачивание всех задач. - zeleny(31.07.2013 22:14)
        
        +1. После отработки всея ложимся спать только в одном спецзаточенном месте. После прерывания рулим дальше. Да еще в зависимости от того, что прервало. А вообще, приходится тщательно продумывать взаимодействие с внешним миром. Это дает гораздо Гудвин(56 знак., 31.07.2013 22:56)
        
        Посмотрел на число постов, взгрустнулось... Это дает гораздо лучшие результаты, чем теоретические терки этой темы Ан нееет, проблески человеческого разума ещё не угасли! :-D - Николай Коровин(15.03.2015 20:02)
        
        Вот и поспорьте с fk0. - Скрипач(31.07.2013 22:34)
        
        не соглашайся. нормально прототридсы с батарейками дружат. для батарейки нужно крутиться вокруг менеджера питания, а не пытаться засыпать где-попало - как пёс лапку задирает. - Vit(31.07.2013 15:40)
        
        Признаюсь честно, я батареечных приборов не делал. Максимум - с резервированием питания. Но писать "чисто событийно" пробовал. Не понравилось. Скрипач(314 знак., 31.07.2013 16:30)
        
        Вот и отличненько. Удалось значит понять суть: императивный стиль программирования повсеместно вдалбливаемый в (не)окрепший мозг -- суть есть тонкая диверсия. Невозможно писать программы в императивном стиле. Особенно, управляющие программы. fk0(2184 знак., 31.07.2013 16:47)
        
        "Далее, полезли глюки неопределенных состояний"... и это главная беда. Скрипач(750 знак., 31.07.2013 17:03)
        
        Что за глюки "неопределенных состояний"? Может определить эти состояния и глюки пропадут? Apтём(334 знак., 31.07.2013 17:19)
        
        "Наизнанку - это как?" Гусары молчать! :) Скрипач(334 знак., 31.07.2013 17:30 - 17:40)
        
        Лучше Miro Samek-а читать - Vit(31.07.2013 22:18, ссылка)
        
        А можно ссылку, чё читать? А то по вашей ссылке яркие краски, бубенчики и крайне мало текста :( - Скрипач(31.07.2013 22:26)
        
        Переводы некоторых статей там--> - Vit(31.07.2013 22:40, ссылка)
        
        гуглится Vit(31.07.2013 22:34, ссылка, ссылка)
        
        ОС для событийного программирования? Проектирование "событийного" автомата радикально менее формализовано, чем проектирование "автомата состояний". И потому более опасно в плане редко возникающих ошибок, примеры которых я привел ранее. - Скрипач(31.07.2013 23:14 - 23:31)
        
        автомат без явного описания состояний это прототридсы. всё Вам опасно и редко возникающе:) - Vit(01.08.2013 00:15)
        
        А у вас в программе все ошибки - синтаксические, да? :) Скрипач(164 знак., 01.08.2013 00:24)
        
        fk0 в том, что без событийной системы строить мелкожручее, ИМХО, прав. Запускать же адресно автомат (с неформализованным, например, описанием) по событию, которое он ожидает, т.е. описано явно, у Вас почему-то оказывается сложным. Vit(1490 знак., 01.08.2013 10:06)
        
        Не так. Модель конечного автомата: Скрипач(294 знак., 01.08.2013 14:16 - 14:22)
        
        Возражение не принимается. Работа жесткой логики и программы чуток отличаются. Расставьте всего-лишь 2 входа на разные порты МК и автомат "сам,, в любой момент времени, полностью определить состояние ВСЕХ своих входных сигналов" тупо НЕ СМОЖЕТ и Vit(74 знак., 01.08.2013 16:55)
        
        Упускается один момент. Мы же не с логикой работаем, чтобы входные сигналы одновременно считывать. Пусть пины разбросаны хоть по десятку портов. Скрипач уже написал, сам так делаю. Собираем состояние портов в промежуточном массиве, я иногда делаю mazur(507 знак., 02.08.2013 12:48)
        
        Тут я могу возразить. Представьте себе автомат в виде черного ящика, и вы просто не сможете определить как Bill(317 знак., 01.08.2013 18:57)
        
        Возражайте. По задержкам и гонкам определяется. И расскажите, как примете 16 входов гарантированно одновременно, до того, как состояние на пине любого входа изменится, на AVR, а потом будем обобщать дальше. - Vit(01.08.2013 21:36)
        
        Одновременно - понятие растяжимое. Тут все зависит от конкретных условий, а не от Bill(29 знак., 02.08.2013 07:23)
        
        К сожалению нет. Ловить просто уровни это один гипертрофированный случай. По пинам обычно ловятся изменения. Бывает, что их порядок/количество не очень важны, но это опять же редкость. Т.к. для автомата входной сигнал это не пин, а его состояние в Vit(999 знак., 02.08.2013 08:39, ссылка)
        
        Все правильно, именно это я и имел в виду. Любой синхронный автомат (а именно о них и идет речь) работает Bill(1710 знак., 02.08.2013 10:41)
        
        C чего вдруг речь о синхронных автоматах? - Vit(02.08.2013 12:10, ссылка, ссылка)
        
        Вы еще раз внимательно перечитайте ваше сообщение -> - Bill(02.08.2013 12:22, ссылка)
        
        Вы бы внимательней перечитали сами. Лучше начиная с --> или с начала топика - Vit(02.08.2013 21:04, ссылка)
        
        Цитата: Скрипач(767 знак., 02.08.2013 08:55)
        
        Вам это ненадо. У Вас есть "классическая" теория для Нобелевки. Забил. А насчет моих программ - да, я не люблю Кургиняна и Ваших проблем не имею. - Vit(02.08.2013 09:34)
        
        Аргументов не понял, а против основной мысли возражаю. Скрипач(132 знак., 01.08.2013 16:59)
        
        у Вас момент растягивается как хошь - Vit(01.08.2013 17:15)
        
        Да. И неслабо упрощает прикладное программирование. - Скрипач(01.08.2013 17:22)
        
        я о "кручу-верчу-запутать хочу" - Vit(01.08.2013 21:37)
        
        Пох, забей :) - Скрипач(01.08.2013 23:05)
        
        Входами автомата могут быть: собсно дискретные входы, события, таймеры. Что приоритетнее выбирается по условиям задачи. Никакой гонки сигналов тут нет. У нас есть аварийные входы, они идут в первую очередь, очень важные события тоже в первую mazur(643 знак., 01.08.2013 15:43)
        
        Например, событие пришло ДО переключения автомата в состояние ожидания этого события. - Скрипач(01.08.2013 15:54)
        
        Значит, оно произошло ДО. Оно ведь и на пол-часа раньше ДО произойти могло. Что в этом такого? - fk0(01.08.2013 16:11)
        
        Мы его пропустили и ждем следующего. Что может проскочить мимо внимания, когда проектируешь алгоритм. - Скрипач(01.08.2013 16:48)
        
        Я уже вообще не понимаю о чём речь. Что значит "пропустили"? Утверждения мол "автоматы не работают" -- очевидно, что абсурдны. У вас какое-то недопонимание, и я даже не понимаю чего именно. - fk0(01.08.2013 17:33)
        
        Вы рискуете войти в рекурсию непонимания :-) - Shura(01.08.2013 17:36)
        
        Выход из рекурсии - оператор: "Та пох. Забей" :) - Скрипач(01.08.2013 18:40 - 18:48)
        
        Вы где-то что-то упускаете. Скажите, как вы реализуете событийную систему. У вас обработка событий в одном месте? У меня нет таких проблем. У меня есть автоматы. В начале автомата, в зависимости от назначения, опрос входов, дискретных или mazur(665 знак., 01.08.2013 16:06)
        
        Для этого предполагатся, что все события могут возникать строго последовательно, и никакой гонки уже быть не может. Порядок возникновения событий во времени придётся сохранить. И вообще не понятно, что мешает автомату самостоятельно проверить fk0(106 знак., 01.08.2013 14:50)
        
        "Приказом по предприятию запретить отказы и выход из строя оборудования КИПиА" :))) Это к попыткам принять в размышлениях возможность влиять на поток событий. - Скрипач(01.08.2013 15:34)
        
        Можно предположить, что все события не одновременны, а разделены минимальным квантом времени, большим нуля (планковское время, например). Тогда не возникает неоднозначности, если события обрабатываются строго последовательно, в порядке их fk0(281 знак., 01.08.2013 16:09)
        
        Лучше разделить их символом табуляции. - Скрипач(01.08.2013 17:04)
        
        События и входные сигналы это вообще разные сущности. Бывают события, которые вообще невозможно зарегистрировать опросом. А есть входные сигналы, которые не инициируют сами по себе изменение состояния автомата, но могут влиять на переходные =AlexD=(45 знак., 01.08.2013 14:57)
        
        Подразумевалось, что (изменение) входных сигналов вызывают события. - fk0(01.08.2013 16:10)
        
        это узкий частный случай - =AlexD=(01.08.2013 21:00)
        
        +1 - Vit(01.08.2013 16:32)
        
        Не у Скрипача: "по Шатыло" и "не по Шатыло". Можно делать сколь угодно сложно-комбинированные системы, нельзя скомбинировать только наличие методики и ее отсутствие :) - Скрипач(01.08.2013 15:36 - 15:38)
        
        Методика Шалыто вполне полная. А вот у вас как раз отсутствие методики. Когда не только программы пишутся программистом по наитию, но точно также выдумывается из головы алгоритм управления, зачастую противоречивый и не полный. Автоматы нужны в fk0(273 знак., 01.08.2013 16:14)
        
        Не смущает. Скрипач(250 знак., 01.08.2013 16:53)
        
        У Шалыто оно уже event driven -- автомат получает события как аргумент функции. И менять ничего-то не нужно. Если речь про то, что при вычислении условий перехода вызываются какие-либо функции (`x') и проверяют входы, например, то ничто не мешат fk0(680 знак., 01.08.2013 17:42)
        
        То, что "вы" называете "event driven" нечто полностью этому противоположное. Цитата: "факт события использовать только для запуска автомата, в котором уже игнорировать событие и проанализировать входы напрямую". Скрипач(238 знак., 01.08.2013 18:39)
        
        Пример события из ОС: поступили данные в сокет (проявляется в WaitForMultipleEvents() или в select()). Но какие данные -- не узнаешь, пока не прочитаешь. Также и здесь. И таки да, у всех всё работает, кроме Скрипача, который несёт какую-то чушь fk0(697 знак., 01.08.2013 22:28, ссылка)
        
        И где это я говорю об "одновременности"? Если сами с собой разговариваете, то хотябы на меня не ссылайтесь, бля. - Скрипач(01.08.2013 23:02)
        
        перечитывая классиков:) забил:) - Vit(02.08.2013 00:16, ссылка)
        
        По ссылке даже слово "одновременно" нету. Скрипач(490 знак., 02.08.2013 08:38)
        
        Событие может наступить "не тогда, когда ждали", что под этим подразумевали? Вы сейчас хоть на это конкретные примеры приведите. Хотя нет, скорее интересует как вы реализуете обработку входных сигналов, чем бы они не были. Пример кода в студию, mazur(71 знак., 02.08.2013 13:10)
        
        Сахар лежит в баночке из-под кофе, на которой написано "соль"(С) - Vit(02.08.2013 08:42)
        
        в кононичЬной:) Vit(153 знак., 01.08.2013 21:50)
        
        я предлагал читать - Vit(01.08.2013 00:10)
        
        Practical UML? Качаю. У меня сейчас и-нет "походный". Медленно. - Скрипач(01.08.2013 00:29)
        
        там её приаттачил - Vit(01.08.2013 10:10, ссылка)
        
        Я видел. Начал просматривать, но Скрипач(76 знак., 01.08.2013 14:24)
        
        перевожу: "RTOS рулез" - Mahagam(31.07.2013 16:50)
        
        На мой взгляд RTOS нужна только для вытесняющей многозадачности в изолированных процессах. Потоки вообще не нужны. Вместо них нужен механизм событийно-ориентированного программирования (в виде C-библиотеки, например), вроде того, что делает fk0(30 знак., 31.07.2013 16:55)
        
        тут походу RTOS - синоним вытесняющей многозадачности. Mahagam(346 знак., 31.07.2013 16:59)
        
        Роскошно живете, товарищ! :) - Гудвин(31.07.2013 22:26)
        
        как ни странно, при кооперативке та же фигня:) - Vit(31.07.2013 22:19)
      - Религиозный фанатик детектед! Ну да, фсе процы фсегда на батарейках, а если нет - сжечь! И про реактивность - тоже лажа: в огромном множестве задач такой подход отлично работает. - SciFi(30.07.2013 22:46)
        
        Он успешно работает в маленьких проектах и без особых требований к потреблению. - fk0(30.07.2013 22:55)
        
        Я бы сказал что как раз на БОЛЬШИХ системах такой подход работает лучше, чем событийно-ориентированное программирование. Скрипач(125 знак., 30.07.2013 23:15)
        
        В больших системах множество независимых параллельных процессов. С разными требованиями к времени отклика. И эта тупая проверка условий в каждом цикле сжирает слишком много cpu, чтобы время отклика стало неприемлимо большим, даже если все условия fk0(64 знак., 31.07.2013 00:50)
        
        есть ресурс. вычислительная мощность. такой цикл автоматически перераспределяет этот ресурс. подразумевается что евентс по прерываниям обрабатываются. больше нагрузка на обработчиках - меньше работает основной цикл. в основной цикл можно заложить Белый Жрец(220 знак., 31.07.2013 16:36)
        
        Эта "тупая проверка" сжигает так мало, что с экономии на переключении контекстов вытесняющей ОС, инфраструктуры "запуска-остановки задач" и "отправки сообщений" еще и остается :) - Скрипач(31.07.2013 00:57)
        
        fk0 уже упоминал, что у него сотни потоков. Если при этом нужно батарейку экономить и где-то что-то успевать, то таки да, задачка. - SciFi(31.07.2013 08:22)
        
        Ну на БОЛЬШИХ !Ё! БАТАРЕЕЧНЫХ он точно не работает ;о) - Скрипач(30.07.2013 23:11)
        
        Скрипач, рано сдаёшься! Как там проект, который просыпается раз в год? Добавить 100000 строк кода, и он станет большим и батареечным! :-) - SciFi(30.07.2013 23:14, ссылка)
        
        :) Проблема в другом: пытаясь экономить можно запросто поддаться самообману и вместо событийной системы получить сразу две: 1) сканирующую-и-генерирующую события 2) событийную. Скрипач(159 знак., 30.07.2013 23:21)
        
        Коих (этих проектов) сильно больше половины, я бы сказал. Такшта не надо излишне драматизировать. - SciFi(30.07.2013 23:00)
  - Ткните пальцем на "вложенный автомат у Шатыло", не дайте помереть необразованным. - Скрипач(30.07.2013 19:38)
    - по первой ссылке - книга, в которой есть разбор по вложенным автоматам. по второй - работа, на которую авторы книги ссылаются, как на первичное определение вложенного автомата. - Д.ARMоед(31.07.2013 00:17 - 00:52, ссылка, ссылка)
      - Отлично! Я, в принципе, ожидал 100% совпадения, но оно таки 100% совпадение :) - Скрипач(31.07.2013 00:51)
    - На softcraft.ru есть статьи, из наиболее старых, где в целом описывается технология. Там упоминается. - fk0(30.07.2013 22:42)
  - PT_WAIT_UNTIL(&pt, event_a() && event_b()); - SciFi(30.07.2013 17:14)
    - && должно вычисляться каждый раз. Проблема protothreads -- отсутствие "планировщика" понимающего, что если произошёл event_a, то нужно запустить поток такой-то. См. ответ Скрипачу. Я не прав таки. В protothreads множествнное ожидание не проблема. fk0(222 знак., 30.07.2013 22:44)

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