DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 22:36

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10
Автор Сообщение
СообщениеДобавлено: Четверг, 23 Август, 2018 00:48 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
Да хоть любой протокол, к примеру.

Протокол -- другое дело.
Если бы вы привели в пример "TCP стек", то, разумеется, на Д-схемах там делать нечего.
Вернее, может и можно что-то сделать, но целиковый TCP стек на Д-схемах это, скорее, из разряда "дичь".

PSV100 писал(а):
В рамках затронутой здесь SWITCH-технологии был хороший примерчик:
http://www.kit-e.ru/articles/circuit/2007_08_170.php

Это не ахти какой плохой пример.

И вот почему:

1) В этой статье единственным преимуществом SWITCH-подхода предъявляется то, что
SWITCH-статья писал(а):
Одно из них уже было приведено: при работе драйвера клавиатуры основная программа не испытывает существенных задержек, связанных с работой антидребезгового алгоритма.

Но это преимущество не имеет никакого отношения к SWITCH подходу. Вообще никакого.

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

2) В этой статье код на C предлагается писать вручную. Занавес. Это и есть код на switch-case, в котором легко ошибиться и который тяжело поддерживать. "key_state=3". О, да, эта строка говорит о многом.

3) На "рис. 3" приведена временная схема работы автомата. К ней вопрос: а что, если кнопка *всегда* дребезжит?
Как её должен расценивать автомат? Ну, это всё к слову о том, что от того, как нужно реагировать на дребезг существенно зависит алгоритм обработки.

Ну да ладно. Давайте возьмём и напишем алгоритм как он есть? Жалко что-ли?

Вот он. И этот код гораздо компактнее SWITCH-кода!

Код:
WHILE TRUE LOOP
  (* Ждём нажатия клавиши *)
  WHILE key_code=0 LOOP
    ПАУЗА;
  END_WHILE;

  _key_code := key_code; (* запоминаем что было нажато *)

  ПАУЗА debounce;

  IF key_code <> _key_code THEN
    (* после антидребезга нажата другая -- ну его нафиг, начинаем сначала *)
    CONTINUE;
  END_IF;

  SEND_MESSAGE(оба-на-клавиша-нажата);

  (* Вот здесь по задаче нужно сделать задержку длительностью first_delay,
      но при отпускании клавиши нужно начать сначала.
      Можно сохранить текущее время и сверять его, но в МЭК61131 есть готовые блоки.
      В данном случае, достаточно TOF: http://plc24.ru/tajmery-v-codesys/ *)
  delayTOF(IN := FALSE); (* сбрасываем таймер *)
  REPEAT
    ПАУЗА;
    delayTOF(IN := key_code=_key_code, PT := first_delay);
  UNTIL delayTOF.Q
  END_REPEAT;

  IF key_code <> _key_code THEN (* технически, этот IF можно поместить и внутрь предыдущего WHILE, но не суть *)
    (* Если клавиша поменялась -- всё по новой *)
    CONTINUE;
  END_IF;

  (* А теперь нужно шарашить импульсы и интервалом auto_repeat *)
  WHILE key_code=_key_code LOOP
    (* Здесь, кстати, в исходной постановке задачи непонятно что должно быть, если first_delay меньше auto_repeat *)
    SEND_MESSAGE(оба-на-клавиша-нажата);

    (* Тут можно было бы сделать и TOF (или вообще BLINK), но сделаем вариант в лоб *)
    следующий_повтор := TIME() + auto_repeat;
    WHILE key_code=_key_code AND TIME()<следующий повтор THEN
      ПАУЗА;
    END_WHILE;
  END_WHILE;

END_WHILE;


Разумеется, такое гораздо проще и понятнее, чем исходный вариант на switch-case.
Тут некая многословность из-за всяких END_WHILE, но оно несильно портит картину.

Но, повторюсь, по сути, это 1-в-1 повторение "хвалёного SWITCH-кода" с той поправкой, что вместо "case 2: ... key_state=3" используется одна строка "ПАУЗА;"
Вот и вся разница. Но читать код на паузах гораздо проще (понятно что в каком порядке выполняется) и писать его гораздо проще (можно не бояться накосячить в индексах).

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


PSV100 писал(а):
Рисовать Д-схему на "паузах" в таких случаях у меня нет желания (да и в целом Д-схему).

Мой вариант на ST наверняка можно 1-в-1 переложить на Д-схемы и там тоже всё нормально будет.
В целом, оно будет более-менее похоже и на "рис. 2".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Сентябрь, 2018 16:37 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
А вдруг там compare&swap?
Без проблем можно читать-обновлять глобальные переменные даже когда процессы выполняются параллельно.

Кстати, если "там" есть внутри иконы "вопрос" (согласно исходному примеру), то тогда нарушается "нормализация", свойственная визуальным средствам моделирования с "метафорами" (собственно то, часто нормализация есть ключевая характеристика на фоне текстовых языков моделей): "вопрос" является управляющей конструкцией без "побочных эффектов". Действия с эффектами задаются в контексте иной определенной метафоры (к примеру, как "ввод/вывод" пусть над "lock-free"-структурами, "transactional memory" или прочие операции спекулятивного доступа, если необходимо).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Сентябрь, 2018 16:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Цитата:
Одно из них уже было приведено: при работе драйвера клавиатуры основная программа не испытывает существенных задержек, связанных с работой антидребезгового алгоритма.

Но это преимущество не имеет никакого отношения к SWITCH подходу. Вообще никакого.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Сентябрь, 2018 16:47 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Да, всё так. Лишняя проверка. И? Какие-то проблемы с этим?
После "7. запустить насос" можно было бы добавить паузу со словами "а всё равно делать на текущем такте нам больше нечего, можно вернуть управление". Но это больше религиозный вопрос, т.к. без этой "лишней" паузы видно, что мы уходим на ожидание.
PSV100 писал(а):
При сценарии выше даже в этом примерчике приглядность в виде применения лишь одной конструкции "цикл-ждать" для актов ожидания возникает за счёт лишних операций (которые в общем случае могут быть не простыми), которыми, по-видимому, якобы можно пренебречь

Здесь можно пренебречь.
Но, если нужна пауза ДО проверки условия, то можно воткнуть эту паузу прямо перед условием (ну как сделали вы, чем породили бурю моих комментариев).
Да, где-то пауза "по ходу" может быть вполне обоснована. Но в обсуждаемой задаче пауза будет лишь мешать.

Может быть в рамках частных задачек и частных же методов их решения такие рассуждения допустимы (игнорирование мол лишних операций, мешающих обходиться лишь паттерном "цикл-ждать" (и так ведь примерно видно) и пр.), но в контексте общей методологии "автоматного программирования" (в контексте методов универсального моделирования для разработки "на потоке") таковы принципы применимы лишь для "жизнеритмов" (согласно текущим результатам Паронджанова):
viewtopic.php?p=101872#p101872
Вложение:
img117.png
img117.png [ 25.98 КБ | Просмотров: 4808 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Сентябрь, 2018 16:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Мой вариант на ST наверняка можно 1-в-1 переложить на Д-схемы и там тоже всё нормально будет.
В целом, оно будет более-менее похоже и на "рис. 2".

Код на ST есть "жизнеритм" по отношению к "рис. 2" -- пропущены необходимые "паузы". В оригинале переходы в начальное состояние ("ожидание нажатия клавиши") не являются "мгновенными" (во всяком случае такова исходная постановка задачи). В ST-варианте (и в потенциальной Д-схеме) нужны "паузы" перед операторами "CONTINUE" и в конце основного WHILE-цикла.
Владимир Ситников писал(а):
В общем, простая пауза гораздо более топорный инструмент, который, тем не менее, позволяет строить адекватные алгоритмы, которые поймёт полный профан.

Однако, с "топором" в таком виде нет шансов конкурировать с компактизацией в тех же графах переходов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Сентябрь, 2018 18:51 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
Код на ST есть "жизнеритм" по отношению к "рис. 2" -- пропущены необходимые "паузы".

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

Но мой ST код он полностью рабочий и дополнительных пауз не требует.

PSV100 писал(а):
В ST-варианте (и в потенциальной Д-схеме) нужны "паузы" перед операторами "CONTINUE" и в конце основного WHILE-цикла.

Зачем? Вот зачем туда втыкать паузы?


PSV100 писал(а):
Однако, с "топором" в таком виде нет шансов конкурировать с компактизацией в тех же графах переходов.

Я написал код в лоб и он оказался проще и понятнее, чем C код в предлагаемой статье.
Очевидно, что в предлагаемой статье смысла нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Сентябрь, 2018 19:20 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
PSV100 писал(а):
В ST-варианте (и в потенциальной Д-схеме) нужны "паузы" перед операторами "CONTINUE" и в конце основного WHILE-цикла

Зачем? Вот зачем туда втыкать паузы?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Сентябрь, 2018 19:26 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Ситников писал(а):
Я написал код в лоб и он оказался проще и понятнее, чем C код в предлагаемой статье.
Очевидно, что в предлагаемой статье смысла нет.

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

В Дракон-е "напряжёнка" с выделением блоков кода/моделей и отображением "исключительных ситуаций". Фактически, способ один -- задействовать икону "длительность группы действий" аля:
https://forum.drakon.su/viewtopic.php?f=172&t=5370#p91440

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 7


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB