Раньше уже была тема о КА - 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.

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

Что-нибудь да скушало бы, это точно. Вообще, стремлюсь пользоваться самыми самыми простыми и "шоколадными" сервисами Delay, Stop, Resume, Cooperate, а в прерываниях не использую сервисы как класс (расставлю флажки и потом подбираю их в цикле планировщика). Конечно, это минимум возможностей, и хоть ясно как сделать все это без RTOS, делать без нее категорически не хочется. Даже если удастся 100-200 байт "освободить".

Во-первых оптимизирующий компилятор заменяет switch на переход по таблице...

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




Сопрограмммы, увы, существенно отстают даже от SWITCH технологии им. А. А. Шалыто. Последняя, впрочем,
самодостаточна только для простых систем.

IAR AVR не так давно имел 3!!! модели работы со switch. Устанавливается ручками. Ведёт себя соотвественно - специально проверял.

Дело в том, что сопрограммы в представленном формате фактически только статические. Область видимости ограничивается сутью - локальные переменные статические. Область видимости - соответственно.

О так называемой "технологии им Шалыто" унал от создателя nesos - http://www.nilsenelektronikk.no/nenesos.html - о чём давал линк на первой странице обсуждения в 14-м посте.
А насчёт сопрограмм, то они, конечно, имеют свои недостатки. Вот господин Adam Dunkels сопрограммы ввернул в Protothreads и не постеснялся. Покажите, плз. внятный академический пример, в котором SWITCH сделан не на виртуальном языке, а на Си (но не nesos) и как его применить и чем же оно так разительно отличается. Хочу увидеть практический вариант SWITCH технологии явно отличающийся от статических сопрограмм. А то получается "армянин лучше, чем грузин"

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

Во-первых, хороший оптимизирующий компилятор это делает не всегда, а только
тогда, когда это выгодно....
Красиво расказываете....,
а нельзя ли какой нить примерчик в студию ?
то есть типа исследование того как разные компиляторы раскрывают switch..case по сравнению
с табличным вызовом... было бы очень интересно...

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





...не понимаю. Как правило этот механизм и есть простой и наглядный, при этом описывается в нескольких правилах.

Вот перевод упомянутой здесь статьи о конечных автоматах - Martin Gomez "Embedded State Machine Implementation".


Сообщение отредактировал sansnotfor - Mar 24 2011, 00:24

могу посоветовать вот это http://www.state-machine.com кооперативная и приоритетная реализация + графическая среда разработки. Мне нравится.

Во блин, не заметил что тема нафталином пропитана

Сообщение отредактировал kovz - Mar 28 2011, 13:17