Автоматный подход (SWITCH), Поделитесь опытом использования Опции

[Lem]

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

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

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

[Lem]

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

[osnwt]

возможность применения 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, по моему мнению, ближе к автоматному подходу, чем операционки с вытесняющей многозадачностью.

Сообщение отредактировал osnwt - Jul 3 2006, 09:20