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

Результаты положительные, но тут хотелось бы спросить совета профессионалов, каким путём дальше идти, стоит ли использовать кодогенераторы и прочее ПО и т. д.

Интересно было бы узнать, насколько часто микроконтроллерщики используют автоматный подход к проектированию программ. Какое ПО при этом используется (Visual State etc.), каковы результаты (увеличение скорости разработки, надёжности, улучшение взаимопонимания в коллективе разарботчиков).

Я использую следующий подход. main выполняется в виде последовательности проверок флагов готовности данных и вызовов соответствующих обработчиков. Т.е. main является не совсем автоматом, но позволяет разделить код на независимые части и таким образом постепенно наращивать проект.
Что касается автоматов при разборе данных или управлением состояниями системы, то конечно переменая с состояниями и по ветвям swith'а, это во многих случаях формализует построение и упрощает жизнь при проектировании сложных систем.
Построение при помощи всяких приложений считаю осмысленным только на начальном этапе и простеньких системах когда хочется посмотреть как примерно надо инициализировать систему и т.д.
Вот вроде и все.

Да, собственно, выбор-то невелик - или КА, или задачи под управлением операционной системы.
Есть лишнее ОЗУ - закладываем RTOS, нет - обходимся автоматами.

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

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

Другие программы явно есть, но конкретно пока сказать не могу.
а по поводу таймера - это не совсем верно. проблемы тут нет. Таймеры вообще могут не определять состояние системы, а лишь генерировать события - входные воздействия для автомата. а запущен, или не запущен таймер - это можно считать внешним фактором. причём управление включением/выключением/инициализацией таймера можно считать выходным воздействием автомата. В общем, пояснить можно только на примере, что я имею в виду.
Основная идея - не нужно выделять ВСЕ состояния на одной диаграмме. многие состояния с одинаковыми преходами можно объединять, другие состояния можно заменять вложенными автоматами (это целая теория) и т. п. Задача, как и обычно, производить проектирование сверху вниз, последовательно детализируя структуру. Любую сложную задачу иначе не решить.

для интересующихся могу дать интересную ссылку
softCraft

BRICK: Basic Reduced Integrated Cooperative Kernel
Software requirements:
• fit into 2048 bytes of internal SRAM including application tasks and their separate stacks.
• support up to 15 user defined tasks
• automatically switch between regular and power save mode
• switch context in less than 1024 MCU clocks
• very limited usage of inline assembly
The programming language of choice is object oriented C (“C—“) with very limited elements of inline assembly. The design is done for WinAVR compiler - open source software development tools for the Atmel AVR series of RISC microprocessors hosted on the Windows platform.
Hardware design requires external crystal oscillator for microcontroller itself and may require another external crystal oscillator 32768 Hz for system timer. The latter becomes a must if power saving mode is chosen. All other elements (RAM, ROM, EEPROM, system timer, ADC and etc) are already implemented on the ATMega 128/AT90CAN128.

Где бы исходники этой радости скачать? Гугл ничего вменяемого не выдал...

Использование кооперативных RTOS вполне возможно и целесообразно даже на таких кристаллах. См, например, jacos. Очень быстрая и компактная, но кооперативная RTOS (отработал свою задачу – дай поработать другим). Заметно упрощает написание многих навороченных алгоритмов с явно параллельными задачами.

У меня на базе jacos в ATmega8 работает вариометр (прибор для пилотов парапланов). В нем крутится около десятка задач (независимые строго периодические опросы датчиков давления, перегрузки, температуры, вычисление высоты и скорости ее изменения с использованием плавающей арифметики - почему бы и нет, если вполне хватает ресурсов и быстродействия, формирование тональных сигналов с плавно управляемой частотой и периодом их повторения в зависимости от измеренных параметров, сканирование кнопок, мониторинг питания, и т.п.). Все это, разумеется, можно писать и без RTOS (изначально так и было), но использование jacos позволило существенно упростить логику в системе, где критичны относительно точные (в пределах кванта времени RTOS) временнЫе взаимосвязи задач и уделить основное внимание собственно предмету. Даже моргание двухцветным светодиодом (зеленый-пауза-красный-пауза) – и то проще сделать отдельной задачей, что может выглядеть вот так (все переменные убраны для очевидности текста):



И в основном коде запуск задачи:



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

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

В общем, право на жизнь такие штуки имеют даже в контроллерах с 4-8 килобайтами памяти программ и 128 байтами RAM. И если говорить о предмете темы, то кооперативные OS, по моему мнению, ближе к автоматному подходу, чем операционки с вытесняющей многозадачностью.

имхо автомат конечных состояний и ртос это две различные веши и их сравнение не является корректным.

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

В этом плане реализации похожи по ресурсам как памяти, так и времени.

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

Я имел в виду только этот момент, а никак не сходство идеологий.

а как для случая роунд робин в котором переключение задачи не обьязательно управляется ею самой ?

Не совсем понял вопроса.

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

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

При всей кажущейся ограниченности кооперативного подхода на самом деле в очень большом числе случаев его более, чем достаточно. Достаточно гарантировать, что при наличии нескольких задач, чья очередь поработать подошла в данном кванте времени, их выполнение в сумме займет не более, чем длительность этого кванта времени. Тогда с точностью до него мы получим real-time OS. Если строгого real-time для каких-то задач не надо, то тогда можно слегка нарушить это правило, и тогда в среднем период исполнения все равно будет оставаться заданным. Если же нужен строгий real-time, то тогда нужно вытесняющую OS, и при этом время переключения контекста должно быть меньше ожидаемого времени реакции на событие.

Посмотрите NesOS - Finite State Machine Operating System - http://www.nilsenelektronikk.no/nenesos.html

Интересный гибрид. Как я понял из беглого просмотра описания, от просто кооперативной OS отличается еще тем, что внутри поддерживает также и состояние задачи, что позволяет простым switch реализовывать автомат внутри каждой задачи. Боюсь только, что для AVR издержки будут все же больше, чем при использовании вручную оптимизированной jacos + внутренние switch для тех же автоматов (где надо).

2 osnwt, в слючае роунд робин можно сделать так что для задач с одинакоым приоритетом выдача ресурсов опеределяется временем захвата ресурсов задачей и оно (время ) может быть равномерно распределено между задачами , хотя и ртос не является вытесняющей. То есть в этом случае мы не ждем завершения работы задачи а диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет). Хочу сказать что fsm машины не являются синонимом для кооперативки тоже. Для меня фсм видится как логический подход или метод для решения задачи с детерминированным количеством внутренних состояний в контексте самой этой задачи. По сути дела в каждой ртос сушествуют свои машины с конечным состоянием - допустим состояние какой либо задачи, но они не несут в себе этого названия (фсм).

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

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


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


Этого я и не утверждал. Это разные подходы. Я просто сказал, что nesos, судя по всему, представляет собой гибрид. А то, в каком смысле я противопоставлял fsm & кооперативные rtos - rtos-ам вытесняющим, я уже написал.

вот еще один какбы генератор WhatOS: http://www.sticlete.com/whatos/

название забавное: в переводе -- нафига тебе ос?

Еще один пример ОСРВ для МК и ДСП можно посмотреть здесь: scmRtos

Там есть варианты РТОС для msp430, avr и blackfin'а

Нет не про jacos



http://en.wikipedia.org/wiki/Round-robin_scheduling
http://www.geocities.com/michaelanburaj/RTOS_Theory.html

По первой ссылке читаю:


Раунд-робин планирование есть преемптивное.

По второй смотрю таблицу с kernels и вижу:



Иными словами, выходит так, что под сочетанием Non preemptive (кооперативной) RTOS и round-robin планирования понимается то, что задача обязана быть написана так, чтобы завершить свое исполнение в пределах своего временнОго слота и отдать управление другим задачам. А round-robin в данном случае - это циклический последовательный вызов задач на исполнение без учета их приоритетов, чтобы дать им поработать. При этом они по прежнему обязаны отдать управление в ограниченное временнЫм слотом время. Превышение времени выполнения (более, чем временнОй слот) - это уже нарушение требований RTOS. А большее или меньшее время выполнения в пределах этого слота никак не учитывается в кооперативных RTOS, потому говорить о гарантиях равного времени выполнения в такой системе просто нельзя.

Потому мне по прежнему не понятно, как из приведенных ссылок следует, что в кооперативной (non preemptive) RTOS реализуется round-robin планирование по времени так, что "диспетчер сам останавливает или запускает ее (вне зависимости быполнила ли задача свою работу или нет)". Ведь невозможность остановки выполнения задачи в non preemptive RTOS - это и есть само определение RTOS, как non preemptive.

PS. Тема уже ушла в сторону...

RTOS большая и многогранная тема. Нет и не может быть универсальной на все случаи жизни, а отсюда и все многообразие таких систем. Я преподавал RTOS в Советском Союзе, сейчас делаю это в Америке. Мой опыт позволяет мне судить и делать выводы. Ваше дело, коллеги, соглашаться и разделять мою точку зрения или отвергать ее. Я, ни в коем случае, не претендую на истины в последней инстанции.
Итак. Длая начала надо опредилиться с приоритетами. Что мы имеем и чего стараемся достичь. Для мира AVR характерно ограничение по RAM. а это, в свою очередь серьезно ограничивает, нo не исключает использование preemtive RTOS. Еще интереснее дело обстоит со скоростью. Кооперативная переключает контекст гораздо быстрее - ей не надо сохранять все регистры, а только необходимые (определяется компилятором), кроме того, по системному таймеру нет необходимости переключать контекст активной задачи - переключения не произойдет! Заодно, кстати, и эконом ится стек для каждой задачи и, соответственно, RAM! Еще один аргумент в пользу коопреативности. При весьма ограниченных ресурсах AVR (да и подавляющего большинства других 8 -16 битных микроконтроллеров) разбиение на ос и апликации весьма условно. Проще сказать, что мы имеем scheduler (планировщик) и функции системы. Отсюда следует вывод: каждый проект есть не что иное как новая RTOS с одним и тем же планировщиком и разнообразным набором функций. Когда пишется функция ОС, прекарасно известно о том, что можно делать, а чего нет и какие ограничения необходимо соблюдать - аналогичные требования пред'являются дле задач в кооперативной RTOS. Какое совпадение!
Другой момент, требующий особого внимания - приоритеты задач в кооперативном мире. Если приоритеты постоянны, то низкоприоритетная задача может не получить управления никогда. Если же их менять, то как? Мой совет такой: используйте 2 приоритета: высший для планировщика и round robin для всего остального. В общем случае, работает надежно.
Из всего вышесказанного, в общем случае, кооперативная RTOS это то, что лучше подходит для систем с малым об'емом RAM.
Желаю успехов!

Вперве применил КА когда надо было сделать контроллер двух турникетов. Теперь только на них все и делаю. Сами свитчи тоже люблю. ифы применяю редко. Код получается понятным, скоростным и сатбильным. Мне кажется для встроенных приложений это оптиамльное решение. Хотя по сравнениию с осью сложнее по началу - надо мышление приучить.

Возможно полезным будет ресурс на тему http://softcraft.ru/auto.shtml Там есть даже варианты объектно-ориентированного подхода к автоматам (в том смысле, что тема живет и развивается)

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

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

Вообще-то, это далеко не всегда так. В принципе, для оператора switch должны генерироваться таблицы переходов. Правда, в IAR такого не делалось раньше, но, говорят, что в последних версиях это все-таки сделано.

Кстати творение этого кодоавтомата SDL у меня вот уже где. Что интересно - наш процессор вообше функшон пойнтер не поддерживает.) Хотя это в частном .

Дюмаю что rtti тоже его немало пользует. Оптимайзеры блин .
Visual state говорите? Бррр, вот куда автоматика нас завела. Еще немного и у меня к автоматам аллергия начнется.)

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

но предлагаю не путать теплое с мягким.

Хотел бы пару слов сказать в ответ исходному посту.

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

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

Сами по себе диаграммы состояний IVS (Iar Visual State) -- это часть стандарта UML, слегка модифицированные под нужды IVS (чего-то добавлено, даже кажется полезного). В итоге получаем проектирование жесткой системы. Наиболее вероятным кандидатом в качестве целевой платформы для генерируемой системы являются ПЛК. На это указывает многое. В частности, так любимый в ПЛК принцип "сначал читаем все входы - затем обновляем все выходы".

Генерируемая система хоть и представляет собой си-код, но на самом деле это табличный жесткозашитый автомат, т.е. руками сгенерированный код не отредактируешь даже при большом желании. Плохо это тем, что IVS нельзя использовать для кодогенерации отдельных разнообразных автоматов для нетипичных с точки зрения IVS задач. Так, например, IVS определяет понятие параллельных автоматов, но желание создать массив однотипных параллельных автоматов в количестве N штук не позволяет, т.е. необходимо как-то выкручиваться с copy-paste и не факт, что вам это удастся. По крайней мере для меня это стало одним из главных препятствий в использовании.

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

В общем, несмотря на красивый фасад и уйму потенциальных возможностей, для областей не связанных с ПЛК использование IVS, особенно на мелких контроллерах (типа АВР) представляется мне неоправданным.

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

Поэтому с точки зрения делать всю программу на одном жестком конечном автомате или на ОС -- я не стал бы выбирать первое (только если это задача по написанию ПО для открыванию лотка CDROM или миганию лампочек). Для реальных задач лучше использовать россыпь небольших квазипараллельно работающих конечных автоматов.

Сам я ОС до сих пор не пользовался, ибо по сути тщательно спроектированная система в виде набора параллельных автоматов -- это практически тоже самое, что и кооперативная ОС, только памяти жрет еще меньше и ты всегда имеешь полный контроль над процессом. Т.е. каждый раз я делаю примитивную кооперативную карусель, и мне хватает. Из набора сервисов: таймеры, фифо, реже семафоры. Это позволяет обеспечивать максимальную независимость работы разных задач, плюс регулировать насколько часто та или иная задача будет выполнять свою работу. Т.е. deadlock в таком виде невозможен, система работает предсказуемо. Что еще нужно для счастья?

И где ж я путаю и в чем?

4 слова: visual state, автоматика, автоматы, аллергия

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

Надеюсь мои слова не вызовят у Bас ассоциации о другом автомате - Калашникова?)

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

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

Ваши слова можно понимать как кому удобнее. Попробую немного прояснить ситуацию.

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

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

Причем под конкретный проект эта библиотечка может быть подточена, тонко подтюнингована.

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

Поэтому, тому кто владеет базовыми алгоритмами или интересуется ими, написать свои библиотеки несложно. Такие люди тратят свое время на единократное написание.

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

Я использую автоматное программирование на AVR, сразу предупреждаю что программирую на ассемблере. Для реализации автоматной структуры написал несколько макросов и простеньких подпрограммок(которые вызываются макросами). Макросы звучат типа так:

1. СТАРТОВАТЬ_АВТОМАТ_СРАЗУ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ
2. СТАРТОВАТЬ_АВТОМАТ_С_ЗАДЕРЖКОЙ ИМЯ_АВТОМАТА, ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ
3. ОСТАНОВИТЬ_АВТОМАТ ИМЯ_АВТОМАТА
4. ВЫПОЛНИТЬ_АВТОМАТ ИМЯ_АВТОМАТА
5. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_СРАЗУ ИМЯ_СОСТОЯНИЯ
6. ПЕРЕЙТИ_НА_ДРУГОЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ ИМЯ_СОСТОЯНИЯ, ВЕЛИЧИНА_ЗАДЕРЖКИ
7. ОСТАНОВИТЬСЯ
8. ПОВТОРИТЬ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

Макросами 1-4 пользуются в любом месте программы. Макросами 5-8 пользуются внутри состояния автомата.
С помощью этих макросов реализуется в общем любая автоматная структура (любое количество атоматов, любое количество состояний, вложенные автоматы с любой глубиной вложенности). Даже такие вещи как автомат состоящий из одного состояния Автоматы могут управлять друг другом. Все задержки отрабатываются каждым автоматом независимо с кратностью единого кванта времени. При этом нет холостых циклов.

Документированием в графике стараюсь не заниматься - уходит много времени, к тому же при изменении структуры надо документацию менять. Вместо этого стараюсь максимально комментирвать текст самой программы. Но если все-таки рисую графы (не алгоритмы) то делаю это в Visio.



Так и есть. Куча параллельных автоматов. Фактически многозадачность. Загружаем процессор равномерно - задачи "размазываются" по времени.

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

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

У вас какая-то смесь получается сервисов ОС (запустить/остановить) и КА (перейти в состояние).

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

В классическом КА нужно создать промежуточное состояние, если нужно выдержать паузу. А вообще непонятно зачем это может быть нужно.




Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

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

Дак это понятно, что сервисом лучше.
Вопрос был (и есть) в том, как это все лучше документировать/разрабатывать. Чтобы, так сказать, наглядно было.
Чтобы, помимо переходов из состояния в состояние, можно было на диаграмме отобразить "параллельные" процессы, действия при входе/ожидании/выходе из состояния и т.д. Вероятнее всего это будет что-то похожее на UML, только с _учетом_специфики_ембеддед_систем_.
SoftCraft посмотрел, внушаить. Однако, много теории и маловато практики.
Хотелось бы увидеть конкретный пример разработки от ТЗ до конечного кода с созданием документации хотя бы на уровне "опросить клаву 4х4 и вывести чего-то на ЖКИ" с использованием обсуждаемых здесь методов.

А это вы читали?http://www.softcraft.ru/auto/switch/umlswecl/umlswecl.pdf
Я скачал тот самый унимод и эклипс, но разбираться с ним, чувствую (с эклипсом) нужно не один день, а со временм совсем беда.
Если кто-нибудь имеет опыт общения с этим самым эклипсом, не поделитесь краткой инструкцией по установке этого самого юнимода, да и вообще, интересно про эклипс что-нибудь услышать от людей, реально его юзавших.

В общем правильно говоришь. Но эти промежуточные состояния - лишние. Пример автомата-светофора:

Состояния автомата:
R_STATE - горит красный 20 секунд
RY_STATE - горят красный и желтый 5 секунд
G_STATE - горит зеленый 20 секунд
GY_STATE - горит зеленый и желтый 5 секунд

Где-то в программе описаны временнЫе константы
RG_TIME = 20секунд
Y_TIME = 5секунд

Описания состояний:
R_STATE:
Включить красный, выключить желтый и зеленый.
NEXT_STATE_CDELAY RY_STATE,RG_TIME ;Перейти на состояние RY_STATE через 20сек
Возврат

RY_STATE:
Включить красный и желтый, выключить зеленый.
NEXT_STATE_CDELAY G_STATE,Y_TIME ;Перейти на состояние G_STATE через 5сек
Возврат

G_STATE:
Включить зеленый, выключить желтый и красный.
NEXT_STATE_CDELAY GY_STATE,RG_TIME ;Перейти на состояние GY_STATE через 20сек
Возврат

GY_STATE:
Включить зеленый и желтый, выключить красный.
NEXT_STATE_CDELAY R_STATE,Y_TIME ;Перейти на состояние R_STATE через 5сек
Возврат

Другой пример:

Автомат из одного состояния. Например, надо опрашивать датчик каждые 20мс, тогда единственное состояние выглядит так (граф из одного состояния с петлей):

SENSOR_STATE:
Опросить датчик
Обработать результат
REPEAT_STATE TIME20MS ;Повторить состояние через 20мс
Возврат

Здесь еще один макрос о котором я не упомянул - ПОВТОРИТЬ_ТО_ЖЕ_СОСТОЯНИЕ_С_ЗАДЕРЖКОЙ

Последний пример:

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


1. Определяю автоматы (в памяти данных)

ZASLONKA_AUTOMATON:
...

ALARM_AUTOMATON:
...

2. Инициализирую автоматы (в самом начале программы до разрешения прерывания)
Здесь автоматы инициализируются, но не работают - отдыхают пока (выполняют холостое СТОП_СОСТОЯНИЕ, состоящее из одного возврата)
STOP_AUTOMATON ZASLONKA_AUTOMATON
STOP_AUTOMATON ALARM_AUTOMATON


4. Где-то в программе включаем заслонку

START_AUTOMATON ZASLONKA_AUTOMATON,ONZASLONKA_STATE


4. Описываю состояния автоматов (подпрограммы)

ONZASLONKA_STATE:
Включить заслонку
START_AUTOMATON_CDELAY ALARM_AUTOMATON,ALARM_STATE,TIME2S ;Запустить аварийный автомат через 2сек
NEXT_STATE WAITZASLONKA_STATE ;Перейти на ожидание закрывания заслонки
Возврат

WAITZASLONKA_STATE:
Заслонка закрылась?
НЕТ - возврат (ждать дальше)
STOP_AUTOMATON ALARM_AUTOMATON ;ДА - остановить аварийный автомат
NEXT_STATE STOP_STATE ;Остановиться
Возврат

ALARM_STATE:
STOP_AUTOMATON ZASLONKA_AUTOMATON ;Остановить автомат закрывания заслонки
Выполнить действия при аварии
NEXT_STATE STOP_STATE ;Остановиться
Возврат

В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.
Но это не есть плохо! Это очень логично. Пример из реальной жизни:
Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.

По поводу в каком состоянии находится автомат во время задержки - он находится в неком промежуточном состоянии, в котором считает время через свой собственный таймер.


В общем-то так все и есть. Макрос (он же сервис) "перейти с задержкой" запускает таймер. Затем скрытое состояние считает этот таймер и при окончании счета запускается состояние, заданное тем же "перейти с задержкой".

Насчет ув.Шалыто - все у него хорошо, но слишком уж строго-формально.

Может кому пригодится
********************************************************************************
***
=== Abstract State Machines: A Method for High-Level System Design and Analysis ===
********************************************************************************
***
Egon Boerger, Robert Staerk, "Abstract State Machines: A Method for High-Level System Design and Analysis"
Springer | ISBN 3540007024 | 2003 Year | PDF | 2 Mb | 438 Pages

Качать: (2 Мбайт)
http://rapidshare.de/files/8717800/EBorger.rar.html
Пароль:
www.AvaxHome.ru

The systems engineering method proposed in this book, which is based on Abstract State Machines (ASMs), guides the development of software and embedded hardware-software systems seamlessly from requirements capture to actual implementation and documentation. The method bridges the gap between the human understanding and formulation of real-world problems and the deployment of their algorithmic solutions by code-executing machines. Within a single conceptual framework it covers design, verification by reasoning techniques, and validation by simulation and testing. ASMs improve current industrial practice by using accurate high-level modeling and by linking the descriptions at the successive stages of system development in an organic and efficiently maintainable chain of rigorous and coherent system models at stepwise-refined abstraction levels. In several industrial projects the ASM method has proven its superiority compared to the popular UML methodology when designing complex parallel or dynamic systems. This book combines the features of a textbook and a handbook: the reader will find detailed explanations, proofs, and exercises as well as numerous examples and real-world case studies. Researchers will find here the most comprehensive description of ASMs available today and professionals will use it as a "modeling handbook for the working software engineer." As a textbook it supports self-study or it can form the basis of a lecture course. The book is complemented by a CD containing the whole book text, additional course material, solutions to exercises, and additional examples. Even more information can be found on the related website maintained by the authors: http://www.di.unipi.it/AsmBook/

Источник информации:
http://www.avaxhome.ru/ebooks/abstract_state_machines.html
///////////////////////////////////////////////////////////////////////////////

Как я уже написал IAR Visual State использует диаграммы UML, точнее его подмножество, которое отвечает за конечные автоматы. О какой собственно embedded специфике вы говорите? Где она должна присутствовать на диаграммах? Что-то вы путаете, диаграммы они и в африке диаграммы.

Судя по всему, вам таки надо внимательно поизучать IAR Visual State, оценочная версия позволяет проектировать систему из 20 состояний -- этого с головой хватит чтобы понять что это за зверь. Как раз Visual State исповедует принцип сквозного проектирования, который вам нужен (от ТЗ до конечного кода).

[quote name='Crystaly' date='Jul 10 2006, 09:13' post='132519']
[quote name='bialix' post='131998' date='Jul 7 2006, 17:04']
У вас какая-то смесь получается сервисов ОС (запустить/остановить) и КА (перейти в состояние).

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

В классическом КА нужно создать промежуточное состояние, если нужно выдержать паузу. А вообще непонятно зачем это может быть нужно.[/quote]
В общем правильно говоришь. Но эти промежуточные состояния - лишние. Пример автомата-светофора:
[/quote]

Каждый кулик хвалит свое болото -- народная мудрость. Тебе удобнее решать задачу так как ты привык и считаешь правильным. В то же время приведенное решение в некоторых вещах противоречит принципам КА.

Вобщем хочешь строить свою теорию -- строй. Только это уже будет не классические КА.

В классике: действия производятся при переходе из состояния в состояние. Все состояния выделяются явно.

[quote]В приведенном примере два автомата управляют друг другом. То есть автоматы не независимы, не изолированы.
Но это не есть плохо! Это очень логично. Пример из реальной жизни:
Я ложусь спать - завожу будильник. Если сам не проснулся - будильник будит меня. Если я сам проснулся - выключаю будильник, чтобы никого больше не разбудил.[/i]
[/quote]

Пусть управляют, если так нравится. Больше головной боли и всего-то...

[quote]
По поводу в каком состоянии находится автомат во время задержки - он находится в неком промежуточном состоянии, в котором считает время через свой собственный таймер.
[/quote]

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

[quote name='bialix' post='131998' date='Jul 7 2006, 17:04']
Неправильно, ты дядя Федор бутерброд ешь... (с) кот матроскин

Запуск и останов таймера -- это должно делаться на уровне сервисов, т.е. КА не обязан заниматься такими вещами. КА должен послать сигнал сервису таймера "начни отсчет". Потом дождаться сигнала "таймаут истек". Достаточно одного состояния. Если нужно досрочно остановить, посыдаем сигнал "остановить таймер".
[/quote]
В общем-то так все и есть. Макрос (он же сервис) "перейти с задержкой" запускает таймер. Затем скрытое состояние считает этот таймер и при окончании счета запускается состояние, заданное тем же "перейти с задержкой".

Насчет ув.Шалыто - все у него хорошо, но слишком уж строго-формально.
[/quote]

Без комментариев.

Перепишем алгоритм светофора в терминах классической теории КА.

Итак, явно выделим состояния:

1) Начальное
2) Горит красный
3) Горит красный+желтый
4) Горит зеленый
5) Горит зеленый и желтый

Действия производим во время перехода из состояния в состояние:

* при переходе в состояние 2 из любого другого: включить красный, выключить желтый, зеленый; запустить таймер на 20 секунд
* при переходе в состояние 3: включить красный, желтый, выключить зеленый; запустить таймер на 5 секунд
* при переходе в состояние 4: включить зеленый, выключить красный, желтый; запустить таймер на 20 секунд
* при переходе в состояние 5: выключить красный, включить желтый, зеленый; запустить таймер на 5 секунд

Начинается все с начального состояния (1) в котором все лампы выключены. По сигналу начать работу (это может быть просто запуск автомата) сразу же производим переход в состояние 2.

В состоянии 2 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 3.

В состоянии 3 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 4.

В состоянии 4 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 5.

В состоянии 5 ожидаем сигнал от таймера. Когда сигнал получен -- переходим в состояние 2.

Кольцо замкнулось.

Раньше уже была тема о КА - http://electronix.ru/forum/index.php?showt...&hl=Ts+controls
, там постили редактор/кодогенератор TS Control, я попробовал с этой прогой работать, мне понравилось

...да, но в ГОСТе никто не отменял рисунков в описании программы. Я обычно при разработке разрисовываю алгоритм в виде КА, а кодирую как набор функций одного типа (каждая функция выполняет один переход КА и в указателе сохраняет адрес функции следующего перехода), затем в main-е вызываю их через указатель на функцию. Как мне кажется это удобней чем постоянно анализировать переменную состояния

По поводу диаграмм конечных автоматов в нотации UML.

Рекомендую книгу: Хассан Гома "UML проектирование систем реального времени, распределенных и параллельных приложений", изд-во ДМК, Москва 2002.

Где-то в сети эта книга гуляет в электронном виде, у меня вариант в виде мертвого дерева, поэтому не подскажу. Поищите на известных сайтах.

Эта книга хороша для начального ознакомления с UML нотацией для диаграмм конечных автоматов и подходит в качестве дополнительного источника при изучении Iar Visual State.

Cегодня такая вот прелесть попалась - 4 макроса для реализации механизма простых сопрограмм

http://www.codepost.org/view/101

#define cr_start() static int __s = 0; switch (__s) { case 0:
#define cr_returnv { __s = __LINE__; return; case __LINE__: ; }
#define cr_return(x) { __s = __LINE__; return x; case __LINE__: ; }
#define cr_end() } __s = 0;

IMHO, изящное решение. Беру на вооружение

На счет mega8 и RTOS не соглашусь. Успешно использовал RTOS (jacOS) и для mega8 и для более слабых контроллеров (PIC18F1320, PIC16F628A и даже PIC12F683). Для mega8 накладные расходы составили около 450байт flash. На мой взгляд - сущие пустяки, тем более что осталось не задействовано еще 2K flash.