Easyelectronics.ru

Ну если Delphi 3.0 или Borland Builder 6.0 то есть и вполне законные честно купленные :) так что с точки зрения лицензионной чистоты кода все будет хорошо.



Ничего не могу сказать по этому поводу - не умею ни то и другое. Разве что только Wine или ReactOS.




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

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

Пойдем дальше деклараций? Глядишь Тышова наши неуклюжие попытки подтолкнут поднять удобство интерфейса на новый уровень, мы ж только рады будем?

Мне кажется оптимальным вариантом опенсорсного движка мог бы быть Питон+PyQt

Доброго времени суток.

Сразу хочу поблагодарить Сергея Ефанова. Замечательные ролики, заинтересовали сразу же. :) А вопрос у меня вот какой, никак не могу разобраться как оформить прерывание (AVR Studio 5.0). Что-то показалось логичным создать примитив отдельный и в гноме его указать. Так-то все в коде вставляется верно, вот только выйти нормально не получается. Для примера вот картинка:



В заголовке код:



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



Так-то алгоритм выполняется верно, но как для прерывания так беда совсем... Буду благодарен если подскажете, что же я не так делаю.

Доброго!



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

Я пробовал делать силуэт с отдельной веткой выхода, но результат тот же самый.

Икона "Конец" чаще всего в коде располагается в середине процедуры, функции. В П тексте иконы должен находиться выход из процедура, для функции с возвратом результата, пишется оператор Возврат или Exit или Return или что нибудь подобное.

Это я сразу понял, только там суть не в "в иконе "Конец" я не знаю что писать", а в том что мне "Вроде как ничего не нужно" :) Спасибо за ответы.

В иконе "Конец" напишите goto end_interrupt;
В программном приложении схемы перед закрывающей фигурной скобкой напишите end_interrupt:;

Сергей, спасибо. Я прекрасно понял суть, так на выходе будет создана метка, на которую икона "Конец" в любом случае перенаправит. Но никак не могу привыкнуть к куче прыжков. Ужас просто. :)))

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

Ну вы блин даёте...
А нельзя написать просто:
// типа конец
?

Вроде был уже вопрос, но повторюсь, т.к. в свое время не дошел до этого момента.
Во многих иконах есть поля "приложение А" и Б.
Опытным путем установлено, что в кодогенерации они не участвуют.
Тогда для чего?
Ещё заметил, что слева от икон можно ставить галочки.
Зачем?

Посмотрите внимательнее, я и писал коментарий:



Только какая разница, если он присваивает иконе "Конец" метку. А она находится в середине.

ИС Дракон является средой языка Дракон для общего и широкого применения.

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

Галочки у икон, называются метками. Назначение их также на ваш выбор. Для программиста есть пункт меню "Программирование / Трассировка икон с метками", вы по время отладочного прогона можете получить протокол последовательности выполнения отмеченных икон.

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

Немного не в тему: посмотрел дизасм в студии, оператор return как и положено для прерываний как RETI а для функций RET. То бишь я могу в иконе "Конец" все же просто написать return;? Просто я совсем недавно разбираюсь с правильным Си для AVR. И в общем случае обработка выглядит как:



Допрыгали до конца и ушли обратно. Не будет ошибкой самому указать где именно выходить?

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

А вообще, размещать икону "конец" в середине кода - оригинально-с.

P.S.

Рановато для такого пафоса, пока что оно только на поделку тянет. Алсо, где вы тут "интегрированную среду" увидели? Сделайте менеджер проекта и систему сборки и отладки прежде чем это называть "ИС". Сейчас это не более чем редактор.

А вы, что не слышали о возможности выхода из середины процедуры?

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

Редактор с кодогенератором - маловато, чтобы называться ИС.

Имеете полное право.
И можно даже не в конце, а хоть в самом начале.
Например:
if(something) // а не зря ли мы сюда вошли?
return;
// продолжаем дальше, если все нормально

goto это пусть...
Но вот как по мне, идеологически неверно преобразовывать "переключатель" в if-else-goto.
Почему?
Очень просто. Паронджанов в своей книге декларирует абсолютную тождественность графического и текстового описания алгоритма.
То есть, полученный из дракон-схемы текст должен однозначно преобразовываться обратно в исходную схему.
В случае switch-case это легко реализуемо. if-else преобразуется в лесенку развилок, что исказит исходную картинку.
Да и оптимизируется switch местами гораздо лучше, превращаясь в таблицу переходов.

Также, лично я бы преобразовывал ветки в do{}while(0), пусть даже с goto между ними. Это улучшает структуру текста и облегчает дальнейшую работу именно с текстом. И самое главное, что теоретически никаких препятствий для этого не вижу.
Начало ветки сопроводить текстом "do{", а конец - "}while(0)", ничего больше не меняя.

Для ARM например тактика if-else может иметь больше успеха учитывая его префиксные условные команды, да и кое где еще существует команда "пропуска если". Даже если сильно захотеть - оптимизатор может так координально всю структуру изменить что мама родная не узнает схемы переходов в итоге.

Так вот суть в том, что в общем случае компилятор сам может преобразовать switch() в if-else, если это будет оптимальнее, а вот обратно вряд ли.
Представим ситуацию парсинга какого-нибудь протокола и выбор одного из 100 последовательных вариантов.
Один переход по вычисленному смещению значительно быстрее и компактнее, чем последовательный перебор 100 условий.
Опять же, в случае switch() даже перебор условий может быть оптимизирован в симметричное дерево, значительно сократив количество развилок.

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