[Lem 0]

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

 

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

 

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

[Laptop 0]

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

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

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

Вот вроде и все.

[vet 0]

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

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

[krdmitry 0]

А есть ли еще программы-кодогенераторы, кроме Visual State? Не обязательно под АВР, просто выдающие С-код?

Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).

Расписывание действий на выходах состояний тоже "отягощает" рисунок...

Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?

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

[Lem 0]

Выбор - понятно.

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

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

[Lem 0]

А есть ли еще программы-кодогенераторы, кроме Visual State? Не обязательно под АВР, просто выдающие С-код?

Есть еще вопрос с достаточно узкой "специализацией" КА-представления алгоритма. Например, ожидание таймера в одном из состояний приходится представлять как несколько состояний (инициализация, ожидание сигнала, останов таймера).

Расписывание действий на выходах состояний тоже "отягощает" рисунок...

Поэтому ИМХО нужно искать более "современные" и актуальные формы представления управляющих алгоритмов, похожие на КА, но обладающие расширенными возможностями. Есть ли такие?

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

 

 

Другие программы явно есть, но конкретно пока сказать не могу.

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

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

 

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

softCraft

[let's see 0]

..задачи под управлением операционной системы.

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

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.

[krdmitry 0]

..задачи под управлением операционной системы.

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

BRICK: Basic Reduced Integrated Cooperative Kernel

Software requirements:

 

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

[osnwt 0]

возможность применения RTOS на таком кристалле, как, например, atmega8, сомнительна

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

 

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

 

//
// Flashing LED
//
#if USE_LED_FLASHING

#define LED_FLASHING_PERIOD     5  // seconds

RTOS_TASK(FlashingLED,0)
{
    DDRC_Bit2 = DDRC_Bit3 = 1;

    while (1)
    {
        OS_DELAY_S(LED_FLASHING_PERIOD);
        PORTC_Bit2 = 1;
        OS_DELAY_mS(50);
        PORTC_Bit2 = 0;
        OS_DELAY_S(LED_FLASHING_PERIOD);
        PORTC_Bit3 = 1;
        OS_DELAY_mS(50);
        PORTC_Bit3 = 0;
    }
}

#endif // USE_LED_FLASHING

 

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

 

#if USE_LED_FLASHING
    RTOS_TASK_CREATE(FlashingLED);
#endif

 

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

 

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

 

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

Изменено 3 июля, 2006 пользователем osnwt

[_artem_ 0]

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

[osnwt 0]

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

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

 

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

 

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

 

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

[_artem_ 0]

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

В кооперативной RTOS мы попадаем в задачу, выполняем (также быстро) определенные действия и возвращаем управление диспетчеру задач.

 

 

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

[osnwt 0]

В кооперативной RTOS мы попадаем в задачу, выполняем (также быстро) определенные действия и возвращаем управление диспетчеру задач.

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

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

 

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

 

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

 

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

[sensor_ua 0]

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

[osnwt 0]

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

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