DRAKON.SU

Уважаемый and007!

Просьба дать развернутый комментарий. Например, достоинства и недостатки. И,самое главное ВЫВОДЫ, к которым Вы пришли после того, как Вы написали Вашу 9-страничную программу на asm.

Геннадий Николаевич спасибо!
Действительно опечатка, вместо JJ надо J. В алгоритме вывода телеметрии есть логическая ошибка.
Идея была в том, чтобы получить максимальное быстродействие. Для этого вывод байтов должен идти параллельно с выполнением основной программы (т.е. в «фоновом режиме»).
В начале измерительного цикла указывается, какой байт из очереди надо вывести, а при вызове очередного прерывания (частота вызовов 19200 Гц) выводится очередной бит этого байта.
Есть ограничение – число команд, выполняемых в прерывании должно быть минимально, иначе не остается времени на выполнение основной программы, или даже они не успеют выполнится до запроса на очередное прерывание.

Логическая ошибка алгоритма в следующем. Если бы контроллер был сверхбыстродействующим (т.е. период выполнения измерительного цикла << периода вызова прерывания) то нарушилась бы очередность передаваемых байтов; если count_bit=0, то номер байта может увеличиться, прежде чем вызовется прерывание.
На практике измерительный цикл длится ~3000 мкс, а период прерывания ~50 мкс и ошибки не происходит.

Извините, ранее поторопился написать.
В схеме "Пересылка байта в UART" комментарий "По заданному номеру отсылаем байт на почту" скорее должно быть иконой "Действие".
В контекстном меню есть замена вида иконы.

Владимир Даниелович!
У меня нет достаточного опыта в программировании микроконтроллеров, не с чем сравнивать и мнение будет субъективно.

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

В итоге - Си быстро, но не надежно; ассемблер же долго, сложно и не факт, что надежно.
Получается противоречие между качеством результата и средствами его достижения.

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

Все это существенно упрощает написание и понимание кода и увеличивает его надежность.

PS ассемблерный листинг (черновик)

Здесь

Имхо, правило №6 порождает потенциальную опасность непонимания алгоритма.
Об этом уже говорил Геннадий Тышов


Ниже рисунок, показывающий в упрощённом виде алгоритм, изображённый на листах 4 и 5

(стрелки к алгоритму не относятся, просто показывают передачу управления)

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

Ошибку №1 Владимир Паронджанов предложил исправить следующим образом (на рисунке ниже выделено жёлтым цветом)



Появляется совершенно лишняя и ненаглядная для цикла FOR проверка.

А ведь Дракон-схема — это эргономичность, наглядность, понимание с первого взгляда.

Ошибка №2 (по крайней мере я это воспринимаю как ошибку) никак не устранена.

Ценность Дракон-схем (опять же, по крайней мере для меня) в том, что человек глядя на неё, практически без знания правил языка Дракон, может правильно понять алгоритм.

Обрамление цикла FOR веточным циклом, имхо, неестественно и путает восприятие.

Например, если ввести две новых иконы и разрешить использовать иконы Цикл FOR в качестве имени ветки и адреса то может получиться схема показанная на рисунке ниже.

Правила для цикла FOR, расположенного в разных ветвях силуэта:
1. Иконы «Адрес в цикле» и «Имя ветки в цикле» могут использоваться только внутри цикла FOR, размещённого на разных ветках силуэта.
2. Икона «Адрес» может передать управление только на начало цикла FOR и никогда во внутрь цикла, а также из цикла FOR наружу.
3. Иконы «Адрес в цикле» может передавать управление только внутри цикла FOR, включая начало цикла FOR.
4. При завершении цикла FOR управление естественным образом передаётся на следующую справа от цикла FOR ветку.
5. Икона "Начало цикла FOR" всегда располагается в шапке силуэта.

Слова «оператор» в скобках - это пробование на вкус других терминов : )

Опыт реализации в и.с. Drakon.

Отказался от реализации многоветочного цикла ДЛЯ, т.к. нарушается однородность схемы из-за разрыва цикла ДЛЯ и т.к. нарушается однозначность логики языка из-за ввода дополнительных условностей. В книгах В.Д. Паронджанова до 2010 года описание и возможность наличия многоветочного цикла ДЛЯ отсутствует.

Согласно принципа "Автомат Калашникова" координатора Info21 цикл For не должен существовать, его функции полностью обеспечиваются циклом While.

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

Отказом от многоветочного цикла Вы убиваете автоматную составляющую ДРАКОНа. Вы уже не можете использовать силуэт как конечный автомат.

Где вы видете отказ от многоветочного цикла? Ведь сказано:
Во всей литературе В.Д. Пароджанова нет связи между силуэтом и конечным автоматом. Илья, каким образом сложилось у вас такое мнение. Смотрите и.с. Drakon, там как раз для программирования используется модель конечного автомата.

У Владимира Даниеловича есть иллюстрация связи между силуэтом и КА. На одном рисунке. Силуэт с веточными циклами - и ниже соответствующий КА. Сейчас точно не укажу страницу.

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

Упоминания конечных автоматов в и.с. Дракон (версия ноября 2010) не нашёл, хотя помню, что Вы про них говорили.
(кстати, могу порадовать - под Линуксом и.с. Дракон запустилась нормально)

Уважаемый Эдуард Ильченко!

Я допустил ошибку. Правило 6 следует отменить.
Вы абсолютно правы, это правило
не помогает, а запутывает дело.

Илья, смотрите справку, раздел "Программирование, синтез программного обеспечения в интегрированной среде DRAKON".


Да есть рис135, 136, но по тексту упоминание 1 раз в примечании к другим вопросам (структурный, лианный, адресный блок).

Что-то я не пойму.
Состояние - это ветка. Переход в другое состояние - это оператор "Адрес" в конце ветки.

У Вас - шампур и ещё какой-то непонятный способ перехода на него. Или то же самое, только другими словами?

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

Документация, вынужден огорчить, под Линуксом не открывается. Так что обратиться к ней не могу.

Нельзя вообще разносить цикл ДЛЯ на разные ветки - это передача управления, минуя петлю силуэта. Если нужен многоветочный цикл с параметром - приводить к циклу ДО, как показано в книге (с. 136).

Найдите способ работать с *.CHM файлами.

Илья Евгеньевич прав. Про конечный автомат говорится в двух местах:

1. На стр. 260.
См. Примечание внизу страницы:


2. На стр. 262, рис. 137.
Подрисуночная подпись:


Первым сказал, что "силуэт -- это конечный автомат", -- Леонид Эйсымонт из Института прикладной математики им. акад. Келдыша.

http://forum.oberoncore.ru/viewtopic.php?p=55582#p55582
Поправляюсь:
В Драконе многоветочный цикл органично реализуется в последней ветке цикла блоком "Развилка" с заземленной лианой правого выхода.

Эдуард Ильченко пишет:


Спасибо за предложение (которое после). Оно требует тщательного обдумывания.

Вы вообще отказались от использования цикла FOR, разнося его на разные ветки силуэта, или допускаете использование в каком-то другом варианте?

Без вложений других циклов - да. Если в этой же ветке закачивается не один цикл - визуализация несколько усложняется.

Считаю нужным использовать цикл FOR. В том числе разнося его на разные ветки силуэта.

Во избежание недоразумений изложу свою позицию подробно.

Красным написано то, что следует удалить.

6. Правило. Если цикл ДЛЯ занимает две или более веток, то цикл ДЛЯ
должен быть обрамлен веточным циклом.

6.1. Икона "Начало цикла ДЛЯ" размещается сразу под иконой
"имя ветки", обозначающей начало веточного цикла.
6.2. Икона "Конец цикла ДЛЯ" размещается перед иконой "адрес"
обозначающей конец веточного цикла.
6.3. В иконе "имя ветки",обозначающей начало веточного цикла, в данном
случае написано ДИАЛОГ.НАЧАЛО,
6.4. В иконе "адрес",обозначающей конец веточного цикла, в данном
случае написано ДИАЛОГ.КОНЕЦ,

7. Пояснение. Цикл ДЛЯ может быть длинным. Он может не поместиться
в одну ветку (и даже в две ветки). В этом случае иконы "Начало цикла
ДЛЯ" и "Конец цикла ДЛЯ" могут оказаться в разных ветках
(см. пункты 6.1 и 6.2).

Красный текст заменяется на следующий:

6. Правило. Цикл ДЛЯ может быть длинным. Он может не поместиться
в одной ветке (и даже в двух ветках). В этом случае иконы "Начало цикла
ДЛЯ" и "Конец цикла ДЛЯ" могут оказаться в разных ветках.

:6.1. Рекомендация. Если цикл ДЛЯ размещается в двух или более ветках,
рекомендуется икону "Начало цикла ДЛЯ" размещать сразу под иконой "имя ветки".
(чтобы ее можно было легко отыскать взглядом).