Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1
Подождите немного. Документ загружается.
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
//System Timer Config
#define Prescale 64
#define TimerDivider (F_CPU/Prescaler/1000) // 1 mS
inline void RunRTOS (void)
{
TCCR2 = 1<<WGM21|4<<CS20; // Freq = CK/64 - Установить режим и
предделитель
// Автосброс после достижения регистра
сравнения
TCNT2 = 0; // Установить начальное значение счётчиков
OCR2 = LO(TimerDivider); // Установить значение в регистр сравнения
TIMSK = 0<<TOIE0|1<<OCIE2; // Разрешаем прерывание - запуск диспетчера
sei();
}
Главный файл, собственно файл проекта, выглядит так:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#include <HAL.h>
#include <EERTOS.h>
//RTOS Interrupt
ISR(RTOS_ISR)
{
TimerService();
}
// Прототипы задач =========================
void Task1 (void);
void Task2 (void);
void Task3 (void);
//=====================================
// Область задач
// Задачки простые, диодиком помигать. Одна зажигает, другая гасит.
// Зацикливаются они вызовом через диспетчер.
void Task1 (void)
{
SetTimerTask(Task2,100); //Запускаем вторую задачу
LED_PORT ^=1<<LED1; // Зажигаем диодик
}
void Task2 (void)
{
SetTimerTask(Task1,100); // Запускаем первую задачу
LED_PORT &= ~(1<<LED1); // Гасим диод.
}
// Результатом стал цикл из двух задач. Одна запускает другую по таймеру.
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// первая зажигает диод, вторая гасит. В результате он мигает.
// А чтобы добавить, например, сканирование клавы мы добавляем еще одну задачу
void KeyScan()
{
SetTimerTask(KeyScan,50); // И зацикливаем ее через диспетчер саму на себя
Scan(); // Делаем полезную вещь.
}
int main(void)
{
InitAll(); // Инициализируем периферию
InitRTOS(); // Инициализируем ядро
RunRTOS(); // Старт ядра.
// Запуск фоновых задач. Для того чтобы задача завертелась кто то должен
// Запустить ее вручную хотя бы раз. Делаем это перед главным циклом.
SetTask(Task1);
SetTask(KeyScan);
while(1) // Главный цикл диспетчера
{
wdt_reset(); // Сброс собачьего таймера
TaskManager(); // Вызов диспетчера
}
return 0;
}
Прикладываю проект с уже поднятым диспетчером на базе ATMega16.
Там все раскидано по файликам.
1
2
3
4
5
6
7
8
9
10
11
12
13
GCC_RTOS.c Это главный файл проекта.
EERTOS.c Файл с ядром диспетчером.
EERTOS.h Заголовочный файл ядра
EERTOSHAL.h Файлы аппаратной абстракции и конфигурации ядра.
EERTOSHAL.с Там я описал работу с прерывания для AVR Файл с
функциями
аппаратной абстрацкии ядра. Запуск диспетчера.
HAL.c Аппартная абстракция проекта. По возможности стараюсь сделать
так, чтобы все
HAL.h аппаратно зависимые фишки были описаны в отдельном файле.
В главном проекте только основной алгоритм.
Не зависящий от типа контроллера.
Разгорелась целая дискуссия по поводу оптимальности как подхода в целом,
так и конкретных реализаций. Есть много здравых мыслей. Я, в свою
очередь, не претендую на оптимальность своего решения (порой бывает
избыточной такая конструкция), но получилось достаточно удобно и когда
надо быстро скреативить прошивку, да так чтобы отлаживать не пришлось
почти, то эта конвеерная молотилка как нельзя кстати приходится. Плюс тут
очень многое поддается оптимизации. Можно сделать очередь на указателях
в виде кольцевого буфера, можно оптимизировать таймер. Например, сделав
его статичным.
В ассемлерных программах у меня тоже используется похожая структура.
Правда переход идет не по реальным адресам, а по индексам в таблице
переходов. Впрочем, в ранних постах я эту систему подробно описывал, и
все последующие примеры кода были уже на ней.
Файл с примером кода на диспетчере
AVR. Учебный курс. Архитектура Программ. Часть 3
Приоритетный диспетчер.
Одной из проблем простого диспетчера является то, что все задачи имеют
равный приоритет. С одной стороны, это просто и удобно. С другой — какое-
либо важное событие можно прошляпить, пока там конвейер перещёлкает
все задачи…
Проблему решает введение приоритетов.
В простейшем случае, можно ввести два приоритета — высокий и низкий.
Разница между ними будет лишь в том с какой стороны очереди они будут
засовываться на конвейер. Высокоприоритетные пихаются сразу в начало,
низкоприоритетные с конца.
Разумеется, тут надо следить за тем, чтобы высокоприоритетные задачи не
забивали конвейер, блокируя низкоприоритетные. Никакой защиты от этого
нет, только думать головой.
Если нужна высокоуровневая система приоритетов, то можно очередь задач
превратить в двумерный массив, где вторым этажом будет идти приоритет
задачи. Правда при этом увеличиться время обработки конвейера — ведь
надо будет сперва прочесать всю очередь в поисках наибольшего элемента.
Но тут можно напридумывать кучу оптимизаций. Например, сортировать
очередь при постановке задачи на конвейер, либо завести TOP list
приоритетов, занося туда значения приоритетов. Тогда диспетчер,
обрабатывая очередь, сразу будет искать нужный элемент, ориентируясь по
TOP листу. Но вот так, на вскидку, я не берусь сказать какой из приемов
будет эффективней/компактней/быстрей.
Кооперативная RTOS
На самом деле, называть RTOS такую систему нельзя. Она не является чисто
реалтаймовой. Но название устоялось.
Это еще более сложная структура разделения кода. Отличается тем, что
теперь у нас задания это не цепочки процедурок объединенных
конвейером/флаг-автоматом, а полноценные законченные задачи.
Вот, например, программа мигания двумя светодиодами с разной частотой,
на диспетчере (здесь и далее псевдокод), только функциональная часть:
1
2
3
4
5
6
7
8
9
10
Led1_OFF(void)
{
SetTimerTask(Led1_ON,1000);
led1_off();
}
Led1_On(void)
{
SetTimerTask(Led1_OFF,1000);
led1_on();
11
12
13
14
15
16
17
18
19
20
21
22
23
}
Led2_OFF(void)
{
SetTimerTask(Led2_ON,1000);
led2_off();
}
Led2_On(void)
{
SetTimerTask(Led2_OFF,1000);
led2_on();
}
Как видишь, у нас тут нет функционально законченных блоков. Все наши
задачи представляют собой набор простейших действий залинкованных в
цепочки друг на друга. Либо напрямую, либо через таймер. В очень больших
программах, даже при такой абстракции запутаться уже несложно.
На кооперативной RTOS все будет выглядеть куда прозрачней:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Blink1_Task(void)
{
while(1)
{
Led1_on();
Dispatch(delay,1000);
led1_off();
Dispatch(delay,1000);
}
}
Blink2_Task(void)
{
while(1)
{
Led2_on();
Dispatch(delay,1000);
led2_off();
Dispatch(delay,1000);
}
}
Как видишь, программа двух действий разбилась на две независимые части.
Мигание диодом 1 и мигание диодом 2.
Вырви из кода один блок, замени Dispatch(delay,1000) на delay_ms(1000); и
задачу можно заливать без какой либо организации прям в контроллер и она
будет работать как простейшая программа!
Т.е. теперь у нас уже получаются полноценные программы внутри основной
программы. А что же такое
1
Dispatch(delay,1000);
А это команда API ядра RTOS. В нашем псеводокоде, допустим, ей мы
приказываем передать управление диспетчеру (чтобы он занялся другими
задачами) и вернуться сюда же когда таймерная служба натикает нам 1000мс.
Таким образом появляется многозадачность. Т.е. все неиспользуемое
процессорное время (задержки) мы отдаем диспетчеру, который распределит
его между другими задачами.
Таким образом, у нас получается что задача может быть активной — получит
управление сразу же как это будет доступно, ожидающей чего-либо,
например, того же таймера и неактивной — просто висящей в памяти
программ. Сюда же могут быть добавлены приоритеты, а также чайный клуб
с шахматами и поэтессами.
Задача может ожидать события от чего угодно — таймера,установки/сброса
бита, сообщения от другой задачи. Также она может посылать события
другим задачам.
Подробней расписывать не буду, о работе корпоративной RTOS очень
хорошо расписано в Salvo RTOS User Manual (перевод Андрея Шлеенкова).
А несколько позже, наверное, дам подробный раскур какой-нибудь
кооперативной RTOS (пока еще даже не решил какой. Salvo, SCM или AVRX
- сам еще ни одну из них толком не щупал).
Вытесняющая RTOS
Все не относящееся к вытесняющим ОС назвать полноценной операционной
системой реального времени нельзя. Дело в том, что понятие реального
времени означает, что чтобы ни случилось — время обработки и создание
реакции на критического событие не превысит заданного порога.
Т.е. если заявлено что при ядерной ялярме стержни в реактор упадут в
течении 50мс, то должно быть так.
Сам понимаешь, что ни диспетчер, ни кооперативная ОС этого гарантировать
не могут. Если ты где-то не передашь управление диспетчеру (ну ошибся,
бывает) и у тебя проц зациклиться в одной задаче, то повиснет вся система.
Реальное время тут гарантируется только мозгами разработчика, четко
понимающего что он творит.
Этого недостатка лишена вытесняющая RTOS. Она является по настоящему
реалтаймовой.
И задачи там могут быть вида:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Blink1_Task(void)
{
while(1)
{
Led1_on();
delay_ms(1000);
led1_off();
delay_ms(1000);
}
}
Blink2_Task(void)
{
while(1)
{
Led2_on();
delay_ms(1000);
led2_off();
delay_ms
(1000);
}
}
22
23
24
25
26
27
28
Да хоть
DumbLoop(void)
{
m1: goto m1
}
Тут это не важно. Диспетчер тут обладает полномочиями прерывать
выполнение любой задачи когда угодно, между двумя любыми командами
процессора — делается это посредством прерывания на котором сидит
диспетчер. В результате, каждая задача выполняется рывками, кусочками
заданного интервала. Скажем, по 10мс на задачу. В этом случае, даже если
одна будет наглухо висеть, то вся система не повиснет, т.к. диспетчер будет у
ней забирать управление и делать более важные вещи. Круто, да?
Но за крутизну приходится платить. Т.к. у нас происходит отбирание
управления у одной задачи и передача другой, то надо сохранять состояние
остановленной задачи. И одним сохранением регистров (как это было в
прерывании) тут не обойдешься. Ведь у каждой задачи будет еще и
собственный стек, и локальные переменные и регистры.
В результате, на каждую задачу выделяется свое адресное пространство с
запасом и не дай боже одной задаче потереть контекст другой — все рухнет
как карточный домик.
На восьмиразрядных микроконтроллерах вытесняющие RTOS существуют
(правда название не вспомню, но видел), однако худо бедно этот монстр
может запуститься разве что на ATmega128. Да и то большая часть ресурсов,
в первую очередь оперативная память, МК будет занята проворачиванием
диспетчера, так что кооперативки тут предпочтительней. А вот на ARM
ситуация с этим делом уже намного лучше.
AVR. Учебный Курс. Архитектура Программ. Часть 4
Вытесняющий диспетчер
Давным-давно, когда я учился в школе, мне не давал покоя вопрос. Как
работают параллельные операционки? Как тот же самый Windows
умудряется переключать процессы, не терять регистры (да, я тогда уже
начинал учить асму), как он определяет момент переключения, почему все
это работает? Виртуальная память, проверка на ошибочный код - никто
ничего этого не объяснял. Все твердили про какие-то там объекты, классы, и
говорили очень виртуально. А мне мясо, мясо давай!
Но вот прошло время, и я начал писать программы под МК. Тут я получил
полную свободу действий и абсолютную прозрачность кода. И почти сразу я
стал писать свою операционку. Не для того, чтобы что-то запускать на ней, а
лишь для того, чтобы по ходу понять и сообразить, как же все это устроено.
И эта статья как раз о том, что я узнал.
Отмазки
Сея программа не более чем учебный пример. Т.к. не тестировалась в
серьезных условиях. Не использовалась в каких либо проектах, а гонялась
только на эмуляторе. Смысл ее не дать готовое решение, а показать принцип
и механизм работы диспетчера операционной системы с принудительным
переключением задач. Да и AVR это не та платформа на которой имеет
смысл городить вытесняющие диспетчеры.
Немного теории
Думаю не секрет, что любая многозадачная операционка работает на
прерываниях таймера. Даже на x86 архитектуре без него никуда.
При срабатывании прерывания процессор идет на обработчик, а там
прописано примерно так:
•
1) Сохранение регистров.
o
1.1) Сохранение виртуальной памяти - в файл подкачки или еще
куда-нибудь.
•
2) Сохранение текущего адреса.
•
3) Загрузка регистров след. процесса.
o
3.1) Загрузка виртуальной памяти.
•
4) Загрузка адреса возврата.
•
5) Переход по этому адресу.
По сути - не так уж и много работы, если исключить пункты X.Y. Всего и
делов - сохранить, загрузить и вернуться. Вот именно это я и реализовал -
простейшее ядро операционки, БЕЗ проверок и т.д.
Структура моей операционки
Каждый процесс имеет собственную память - 64 байта (число взял от балды,
просто чтобы красивое было): 35 байт - место для сохранения регистров и SP,
остальные 29 - под стек.
Да, кстати: переключение процессов дополнительно нагружает стек на 3
байта. Поэтому больше 26ти байт лучше не использовать, или же выделять
CLI/SEI.
В памяти находится очередь процессов — она начинается с нуля (нулевой,
ущербный процесс), и заканчивается FF. Почему FF? А просто так удобнее
отлаживать: проще найти очередь в памяти в эмуляторе. Это единственная
причина, поэтому можно его убрать. С нулевым процессом нельзя проводить
никакие махинации - никаких пауз и таймеров к нему не использовать, иначе
это приведет к апокалипсису. Наверное. Не пробовал.
Каждому процессу соответствует свой таймер. Это двухбайтные числа,
лежащие в массиве, устанавливаются при помощи “API” функции
SetTimer.Используется, чтобы временно убрать процесс из очереди.