[Tran 0]

Раньше уже была тема о КА - http://electronix.ru/forum/index.php?showt...&hl=Ts+controls

, там постили редактор/кодогенератор TS Control, я попробовал с этой прогой работать, мне понравилось

[tag 0]

Вроде, в нашем родном ГОСТе предусматриваются только алгоритмы ("схема программы")...

 

 

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

[bialix 0]

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

 

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

 

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

 

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

[sensor_ua 0]

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, изящное решение. Беру на вооружение

[uuC 0]

Причём, речь идёт конкретно о семействе AVR, как можно было бы догодаться, то есть, экономия железа - на первом или почти на первом месте (естественно, применяется С, но возможность применения RTOS на таком кристалле, как, например, atmega8, сомнительна).

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

 

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

[osnwt 0]

Для mega8 накладные расходы составили около 450байт flash. На мой взгляд - сущие пустяки

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

[uuC 0]

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

 

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

[fk0 0]

Вызов фунцкий по таблице указателей где переменную для switch используют как индекс к таблице работает быстрее конструкции switch.

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

 

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

 

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

 

 

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, изящное решение. Беру на вооружение

 

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

самодостаточна только для простых систем.

[sensor_ua 0]

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

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

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

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

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

самодостаточна только для простых систем.

О так называемой "технологии им Шалыто" унал от создателя nesos - http://www.nilsenelektronikk.no/nenesos.html - о чём давал линк на первой странице обсуждения в 14-м посте.

А насчёт сопрограмм, то они, конечно, имеют свои недостатки. Вот господин Adam Dunkels сопрограммы ввернул в Protothreads и не постеснялся. Покажите, плз. внятный академический пример, в котором SWITCH сделан не на виртуальном языке, а на Си (но не nesos) и как его применить и чем же оно так разительно отличается. Хочу увидеть практический вариант SWITCH технологии явно отличающийся от статических сопрограмм. А то получается "армянин лучше, чем грузин" ;)

[DogPawlowa 0]

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

Я то думал, что суть switch - обеспечить нужную логику работы :)

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

Что же касается RTOS... При значительно отличающихся приоритетах задач мне лично хочется иметь механизм управления ресурсами простым и наглядным.

[singlskv 0]

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

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

тогда, когда это выгодно....

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

Красиво расказываете....,

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

то есть типа исследование того как разные компиляторы раскрывают switch..case по сравнению

с табличным вызовом... было бы очень интересно...

[tag 0]

Да, собственно, выбор-то невелик - или КА, или задачи под управлением операционной системы.

Есть лишнее ОЗУ - закладываем RTOS, нет - обходимся автоматами.

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

 

 

Что же касается RTOS... При значительно отличающихся приоритетах задач мне лично хочется иметь механизм управления ресурсами простым и наглядным.

 

 

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

[sansnotfor 0]

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

 

Изменено 24 марта, 2011 пользователем sansnotfor

[kovz 0]

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

 

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

Изменено 28 марта, 2011 пользователем kovz