DRAKON.SU

Где? Я вот не нашел или не очень понял. Владимир Даниэлович, а как-бы Вы изобразили данный режим исполнения с ожиданием по времени: "пропустить исполнение если не прошел заданный интервал"?

В драконе есть развитая система икон реального времени

цикл ЖДАТЬ с иконой ПЕРИОД
икона ПАУЗА
Икона СИНХРОНИЗАТОР
Икона ПУСК ТАЙМЕРА
Икона ПАРАЛЛЕЛЬНЫЙ ПРОЦЕСС

см. глава 13 Алгоритмы реального времени стр. 205-221 в книге "Учись..."
Желательно прочитать
http://drakon.su/_media/01._parondzhano ... oritmy.pdf

Наверное я плохо прочитал это место, но это те самые страницы, с которых и началось наше с Вами общение.

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

P.S.

В наших автоматах управления, этот макрос используется " в каждом первом случае", ибо он имитирует требуемую периодичность управляющих воздействий с учетом инерции управляемого механизма и практически он же используется как имитатор RTOS для псевдо-параллельных процессов .. прошло 8мсек? запускаем "задачу". И если его разворачивать как отдельные иконы, то вся наглядность ДРАКОН будет утеряна "безвозвратно".

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

К сожалению, эту грустную фразу я не смог понять.

Что имеется в виду?
Желательно показать рисунок, глядя на который, я смог бы воочию убедиться, что
Вы меня простите, но я сомневаюсь, что увижу такой печальный результат.

См. также сочетание двух икон ПУСК ТАЙМЕРА и СИНХРОНИЗАТОР на рис. 149 и 151.

Перерисовал макрос everyMillis();
Его реализация выглядит так:

Что позволяет использовать его так показывал выше (повтор):

Таких вызовов в конечном коде может быть много: управление моторами, запуск/прием расстояний с ультразвукового датчика, отрисовка текстов на дисплее, анализ цвета датчиков освещения, управление серводвигателями и т.д. Каждое из устройств имеет "свое" время исполнения команды и паузу перед следующей командой приходится выдерживать .. вот "всяко". Если все команды отдавать устройствам с ожиданием пауз, то никакой робот никуда просто не поедет. А так, пока одно устройство "занято", работают остальные.

В частности, программа нашего примера - это реальный цикл движения (только он) нашего простейшего робота по линии. Он может физически перемещаться со скоростью до 2 м/сек или .. 2 миллиметра в 1мсек! За 8мсек паузы он и так успевает пролететь 16мм. И даже при ширине линии в 4-5см .. он тупо её проскакивает, ибо не успевает затормозить и повернуть моторами. И так с "каждым устройством": чтобы серводвигатель повернулся на нужный угол .. требуется 2мсек на каждый градус поворота ..

Посмотрите насколько картинка стала больше по размеру и соответственно насколько меньше станет понятен алгоритм всего робота..

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

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

Владимир, вас трудно понять, так как вы говорите одновременно о многих РАЗНЫХ проблемах.

Проблема №1. Наглядность. Ваша картинка наглядна. Я не увидел никакой проблемы с наглядностью. Я не заметил никакого ухудшения наглядности. Так что проблема совсем не в ухудшении наглядности, а в чем-то ДРУГОМ.

Проблема №2. Имеется в виду принципиально НОВАЯ ФУНКЦИЯ? Или нет?

Вы говорите о необходимости ПАРАЛЛЕЛЬНОЙ работы нескольких устройств? Или нет?
Что это за устройства? Они входят в состав ОДНОГО робота? Или нет?

Мне не ясна постановка задачи. Мое первое (возможно, ошибочное)впечатление, что наглядность здесь ни при чем.

Вы использовали термин "наглядность" для обозначения совсем другой (очень важной, или даже грандиозной) проблемы.
Но какой именно проблемы? Я этого пока не понял.

=======================

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

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

Вы нарисуйте картинку (скриншот), пусть коряво и ненаглядно, чтобы можно было понять, в чем суть вашей проблемы. И что вы хотите изобразить на ДРАКОНе.

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

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

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

В целом, именно такой работы с таймерами в ДРАКОН как-бы и нет. Есть паузы, задержки, ожидания .. всё это блокирующие алгоритмы. Это пример неблокирующей паузы, действующей ровно на "свое устройство" (или их набор).

Можно использовать икону "синхронизатор" (что я и сделал), если разрешить в нем такое описание как было на первых картинках: "каждые 8мсек". Слово "каждые" - тут ключевое. Оно означает что исполнение должно происходить по истечению 8мсек от предыдущего исполнения этой (и только этой!) иконы.

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

Не, перерисовывать код робота-паука на 8-и серводвигателях с узв. датчиком расстояний и режимами обхода препятствий, подтанцовками .. увы, я не в силах. Хотя в основном исполнительном цикле нет практически ничего кроме десятка таких вот "каждые Nмсек" стоящих подряд друг за другом..

Я лучше выложу то, что отрисовал: смешанные вычисления среднего "столбик" + "строчка". Да, проверил. Постепенный рост закраски внутренностей с ростом уровня вложения проигрывает этому варианту: чередование четной и нечетной закрасок.

Зайца надо есть по частям. Потому что целиком он в рот не лезет.

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

2. Обозримость. То же самое. Эту проблему мы тоже успешно решим методом последовательных приближений.
Сперва надо создать и увидеть алгоритм. После этого можно его подправить и улучшить, чтобы всем понравилось.

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

Arhat109, вы упустили важное: период цикла ТП. Насколько жёсткая эта система.
Если цикл микросекундный (что нереально), то такой подход (действие раз в 8 мс) годится.
Если же цикл 5 мс, а действие надо выполнять каждые 8 мс - мы будем иметь принципиальную проблему.
Собственно, и при цикле 1 мс могут быть всякие нехорошие штуки. Всё опять же зависит от того, откуда берётся время в вашей функции.

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

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

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

Алексей, а можете привести пример из MatCad? Никогда с ним не работал, ибо не математик (физик).

По примеру. Микроконтроллер работает на частоте 16Мгц и имеет 1.3 команды за 1 такт в среднем. Чтение цифрового датчика = 1 команда, ну вот и оцените "частоту управляющего цикла" .. да, даже аналоговый датчик линии оцифровывается в самом худшем случае за 15 кГц, но и его можно "запинать" до мегагерца (тут не требуется точность в 10 бит)... 8 миллисекунд - это "очень долго" для микроконтроллера. И это всего 16Мгц тактовой. (на очереди, в планах освоение 180Мгц в виде STM32F429 )
Дополню ..
Управление мотором (установка скорости) - тоже 1 команда на самом деле. Микроконтроллер имеет встроенное железо в виде аппаратных драйверов "много чего" и управление таким железом - практически везде это или обработчик соответствующего прерывания и учет результатов в виде чтения переменных из ОЗУ или вот такие одно-командные управлятели .. При среднем цикле ТП длительностью в 8мсек (у меня этим заведует watchdog таймер) через такие синхронизаторы "каждый интервал" можно вполне нормально управлять до сотни устройств (ATmega2560 - до 86 управляющих выходов). Средняя длительность управления в таких синхронизаторах от 2.5 до 20мксек. По крайней мере на нашем опыте.

Я не нашел в ДРАКОН способов неблокирующих задержек или callback функций для иконы "Пауза" .. что-то типа Yield() из Ардуино. То есть, если мы указали паузу в алгоритме, то .. что в это время будет исполнять "Исполнитель"? Сушить сухари в недрах ОС? А если нет ОС?

Не, не могу
Смотрел лет двадцать назад - там был интерактивный визуальный конструктор формул, вполне удобный, в отличие от жутчайшего мастера в Excel (который, кстати, появился позже).

Так вы без ОС, что ли, совсем? Аж завидую!
В универсальных промышленных контроллерах цикл 10 мс - редкость, обычно 100-1000 мс вообще (правда, часто с отдельными быстродействующими контурами регулирования)
Накладные расходы, знаете ли
У нас - от 1 до 5 мс - слишком объёмистую логику раскатывают релейщики

Как сделаете исполняющую систему, так и будет. Но если следовать формальному алгоритму, то да, тупо ждать (как бы нас другие действия не волнуют - хоть цикл ожидания ставь, если нет ОС).

Никаких проблем нет. Придумайте любые (НОВЫЕ) иконы и обозначения, которые вам нужны для счастья.

?!? Ардуино - ваще-то проект для "начинающих" знакомиться с микроконтроллерами и, "управляющее воздействие" это примерно 40 команд, в основном из-за дурацкой идеи пронумеровать все ноги контроллера цифирками .. нормальные спецы работают в ATmel Studio и адресуют ноги по их прямому адресу с "управляющим воздействием" = 1 команда. Я просто сделал себе набор макросов, которые выглядят как у Ардуино, но работают как в студии .. Упражение "Blink без Delay()" одно из первых куда отправляют "начинающего ардуинщика". А ОС - да нет никакой .. есть "попытки" и "псевдо ОС", но это так - "баловство" ибо не требуется. Даже у Atmega2560 всего .. 8 килобайт родного ОЗУ, какое уж "ОС"! Но, правда надо сказать что задействовать все 8 килобайт за почти 2 года издевательств - мне так и не удалось ни разу. В лучшем случае было 4кб. А сложные алгоритмы типа "картографирование комнаты роботом" (запомнить все места, где я могу просочиться) оно сразу в ОЗУ не влезло ..

Пауза у нас так и сделана - тупым циклом ожидания, что и приводит к работе через такой вот макрос как единственно верному способу использовать МК "пока оно тупит". Датчики температуры, так те вообще отдают замер через 750мсек ..

Есть такой вот подход: в главном цикле запускаем самое медленное устройство, а в callback паузы - все остальное и часто тоже с синхронизатором "каждые..", типа такого:


В данном примере, самое медленное устройство управления - LCD-дисплей. Оно тут выводит каждый символ по 5мсек. Всего имеет 2 строки по 16 символов.
После вывода символа проверяем выход за границу буфера данных и повторяем вывод. Делаем паузу вывода на 5мсек, и пока она идет - вызываем главный алгоритм.
Главный алгоритм смотрит чего ему надо делать, то и запускает. Каждые 300мсек он переставляет буфер вывода на новые данные.
2*16*5 = 160мсек -- время обновления инфы на дисплее. 450 мсек - пауза на "посмотреть" глазом. Мерцает, но вполне терпимо.

... и? Насколько будет наглядным ДРАКОН-схема для алгоритма brain() тут? Все в сплошных иконах вопрос и каждая к своему "таймеру" .. что и не интересно ни разу. То бишь "визуальный мусор".

Владимир Даниэлович! Это конечно здорово получить от автора языка индульгенцию на его изменение. Но, не хотелось бы превратить язык в то, что Вы потом откажетесь называть "потомком ДРАКОН"

Atmega2560 и есть "универсальный микроконтроллер". Читал где-то что даже бывает в "военном исполнении" и "космическом". Кстати на Atmega128A (примерно 1/2 от большой меги) есть российский аналог и в космическом исполнении у Миландра кажется, вот не помню..

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

Да, и ещё: идея разделения языков (ГРАФИТ-ФЛОКС) и работы через "базу устройств" тут проходит как нельзя лучше: для Ардуино и таких микроконтроллеров существует огромная куча "стандартных" периферийных устройств, а если учесть, что ноги микроконтроллера имеют привязку к его внутренним управляющим драйверам (таймеры, ШИМ, АЦП, драйвера шин типа I2C, UART, SPI, X-bus), то и тем более.

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

Не совсем так.

1. Вы изобретаете, вводите новые иконы и показываете примеры, что получилось.

2. Я пытаюсь свести Ваши примеры к стандартному набору икон, чтобы ничего не менять. В рамках здорового консерватизма.

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

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

===========================

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

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

Вот последний пример. Уважаемый Степан Митькин предпринял очередную попытку внести изменения в язык, желая расширить набор икон и добавив в алфавит языка еще одну (маленькую) икону.
viewtopic.php?f=62&t=5946

Многие его поддержали, кроме LKom. Это нормальный процесс проверки и развития языка.
Я тоже в оппозиции. Я попросил Степана объяснить, зачем это нужно. Но он пока не ответил.

Arhat109, промышленный контроллер - это не микроконтроллер (микропроцессор с портами в/в). Это большое устройство, со своей ОС и системой программирования, с самодиагностикой и поддержкой кучи стандартных протоколов, с аналоговыми и дискретными устройствами сопряжения с объектами и т.д. и т.п.
На всё это нужны накладные расходы.
А так бы с отдельным "чёрным ящичком"-то работать - милое дело!

Алексей, могу только посочуствовать.

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

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

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

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

Момент второй: callback исполнение во время пауз .. могу предложить вариант, аналогичный парам икон "Ввод" и "Вывод": Разрешить указывать "заднюю" икону для иконы "Пауза", которая будет исполнена во время ожидания.

Ваше мнение?