mRTOS-кооперативная операционная система, порт CodeVision, порт WinAvr, mRTOS-кооперативная операционная система для AVR Опции

[LVII]

Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени для малых и средних контроллеров AVR, правда никто не запрещает использовать ее для всех типов контроллеров. Существует два порта - под CodeVision и WinAVR.
Сразу же хочу оговориться, что понятие реального времени в случае кооперативных систем достаточно условно - это описано в статье на сайте и документации к ОС.
Используя эту систему начинаю разработку с проектирования ПО - используя упрощенную нотацию UML в бесплатном редакторе DIA.
Разрабатывать проекты получается быстрее, существенно легче стало обеспечивать модификацию, сопровождение и отладку программного обеспечения. Понятнее и прозрачнее стали тексты программ.

Адрес сайта - http://movilavn.narod.ru/

Зайти в раздел "Статьи", выбрать статью - "mRTOS - кооперативная операционная система для микроконтроллеров".
Для загрузки доступны сама ОС, документация и примеры использования.

Сообщение отредактировал LVII - Oct 30 2009, 11:58

[LVII]

ОС была намеренно минимизирована. Чтобы уместилась даже на малые AVR типа 2313. Поэтому средства межпроцессорного взаимодействия такие, как сообщения, очереди, mailbox отсутствуют. В документации есть упоминание о том, как используя event организовать все это самостоятельно.

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление. Это кооперативная операционная система - это + код вносят некоторые возможности RTOS.

Приоритеты. Кооперативная операционная система это сама ОС + прикладной код. Только тогда она может в какой мере заменить preemtive систему. Мой подход к проектированию таков - предположим есть 4 задачи. Есть период времени T приблизительно определенный суммой приоритетов процессов. Одна (первая) главная, вторая за период T может сгенирить 3 события, третья 2, четвертая 1. Назначаем приоритеты 1-ой 200, 2-ой 150, 3-ей 100, 4-ой 50. За время T каждой равномерно будет передано управление исходя из приоритетов. Приведенная схема проектирования упрощена. Но даже так работает!

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

Сообщение отредактировал LVII - Nov 2 2009, 11:37

[ReAl]

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление.

О чём я и говорю - управление передаётся только синхронно на верхнем уровне функций процессов, поэтому кроме точки возврата ничего не надо сохранять, статусный регистр в том числе.

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

Я прошу конкретный пример, а не "есть возможность".

А теперь смотрим код:

Код

// Макрос - контекст текущей задачи                  
#define CPU_STATE (tasks[current_task].cpu_state)
// Макрос - переключатель задач
#define DISPATCH dispatch_task(CPU_STATE);
...
// Номер текущей задачи
extern char current_task;
// Массив структур TCB
extern struct TCB tasks[MAXTASKS];

Перед вызовом dispatch_task(switch_buf cpu_state) надо вычислить адрес начала массива cpu_state типа switch_buf.

Код

tasks[current_task].cpu_state

для чего в регистры будет загружено значение переменной current_task, умножено на sizeof(struct TCB) и сложено с адресом начала массива tasks и смещением offsetof(struct TCB, cpu_state).
Таким образом, при входе в dispatch_task в регистре SREG всегда будут флаги, оставшиеся от этих вычислений, а не мифическое "состояние процесса". Я думал, что после критического замечания "по сути", которое Вы просили, Вы сможете сами критически глянуть на свой код.
Ещё понятно было бы, если бы dispatch_task() не принимал аргументов (какая разница - всё равно макрос берёт их из тех же глобальных параметров, кстати, это тоже несколько уменьшило бы код), тогда действительно в SREG был бы результат последних операций процесса перед вызовом диспетчера. Ну и как это применать? Так, чтоли?

Код

    c = a + b;
    DISPATCH;
    if( SREG & (1<<SREG_Z) ) {
         // c присвоен 0 перед вызовом диспетчера
    }

Накладные расходы на это ничтожны

Байт на задачу, при 4 задачах - больше 3% ОЗУ упомянутой tiny2313