Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1
Подождите немного. Документ загружается.
AVR. Учебный Курс. Архитектура Программ
Все учебные курсы по микроконтроллерам которые я встречал (в том числе,
к сожалению, и мой ассемблерный, но я надеюсь это постепенно поправить)
страдают одной и той же проблемой.
В курсе бросаются строить дом не заложив фундамент. Только показав на
примере как мигнуть светодиодом, сразу же кидаются в периферию.
Начинают осваивать ШИМ-ы, таймеры, подключать дисплеи и всякие
термодатчики.
С одной стороны это понятно — хочется действа и результата мгновенно. С
другой — рано или поздно такой подход упрется в тот факт, что программа,
надстраиваемая без четкой идеологии, просто обрушится под своей
сложностью. Сделав невозможным дальнейшее развитие.
Итогом становится либо рождение жутких программных уродцев, либо
миллионы вопросов на форуме вида “а как бы мне все сделать одновременно,
а то частоты контроллера уже на все не хватает”.
Самое интересное, что правильной организации программы учат
программистов в ВУЗах, но вот только к микроконтроллеру народ обычно
идет не от программирования, а от железа. А, как показала практика
обучения в ВУЗе, электронщиков толковому программингу практически не
обучают :( Приходится все додумывать самостоятельно.
Итак, что такое структура программы. Это, прежде всего, ее скелет. То
какими путями движется код. Как организованы переходы между задачами
прошивки. То как распределяется процессорное время. Без краткого ликбеза
по общим принципам построения прошивки дальше двигаться нет смысла.
Все ниже написанное это лишь продукт моих умозаключений, поэтому
терминология может отличаться от общепринятой. Если это сильно кому то
будет резать глаз — поправляйте в комментах.
Итак, я для себя выделяю следующие структуры, по порядку возростания
сложности конструкции и количеству управляющего кода:
•
Суперцикл
•
Суперцикл+прерывания
•
Флаговый автомат
•
Диспетчер
•
Приоритетный диспетчер
•
Кооперативная RTOS
•
Вытесняющая RTOS
А теперь подробно по каждому пункту:
Суперцикл
Самая простая организация программы. Отличается минимальным
количеством управляющего кода (код который не выполняет полезную
работу, а служит лишь для организации правильного порядка действий).
Идеально подходит для задач из серии “помигать диодом”.
Алгоритм прост как мычание (псевдо код):
1
2
3
4
5
6
7
8
9
10
11
void main(void);
{
while(1)
{
Led_ON();
Delay(1000);
Led_OFF();
u=KeyScan();
switch(u)
{
12
13
14
15
16
17
case 1: Action1();
case 2: Action2();
case 3: Action3();
}
}
}
И все примерно в таком духе. Т.е. тупое последовательное выполнение кода.
Задержка — прям там же, в общей куче. Опрос клавиатуры. Тут же. Внутри
суперцикла могут быть переходы и ветвления, но суть остается та же самая
— тупое движение по коду.
Достоинства очевидны сразу логичность и простота (поначалу, потом это ад).
Недостатки тоже вылазят сразу же — чем больше мы запихнем в наш код,
тем он будет более неповоротливым и тормозным.
Однако суперцикл поддается оптимизации. Например, в функцию Delay()
можно не тупо впустую щелкать тактами, а запихать туда опрос клавиатуры
и еще кучу полезного экшна.
В итоге, на суперцикле можно сделать сверх компактную, надежную, но при
этом совершенно монолитную программу. В нее будет нельзя ни добавить ни
отнять. А еще чтобы все учесть, написать и отладить надо быть гением.
Читали историю про Один байт? Вот это наверняка про нее или про
следующий вариант.
Обычно народ, наигравшись с суперциклом, раскуривает прерывания и
быстро переходит к варианту суперцикл+прерывания.
Суперцикл+прерывания
Чистый суперцикл используется крайне редко, потому как в любом
микроконтроллере куча периферии и у них есть такая удобная вещь как
прерывания (Хотя, я встречал на форуме microchip.ru высказывание что
прерывания снижают надежность программы и лучше избавляться от них по
возможности) .
Здесь ситуация становится несколько иной. За счет прерываний у нас
появляются параллельные процессы. Например, мы можем повесить опрос
клавиатуры и мигание лампочкой на прерывание по таймеру (псевдокод):
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
ISR(Timer1)
{
u=KeyScan();
}
ISR(Timer2)
{
if(LED_ON)
{
Led_OFF();
}
else
{
Led_ON();
}
}
void main(void);
{
Timer1_Delay=100; // Выдержка таймера1 100
Timer1=1<<ON; // Включить таймер1
Timer2_Delay=1000; // Выдержка таймера2 1000
Timer2=1<<ON; // Включить таймер2
SEI
(); // Разрешить прерывания
27
28
29
30
31
32
33
34
35
36
while(1)
{
switch(u)
{
case 1: Action1();
case 2: Action2();
case 3: Action3();
}
}
}
Уже лучше. Вроде как программа теперь крутится тремя независимыми
процессами. Нигде не тормозит и все в порядке. Да, до тех пор пока хватает
аппаратных ресурсов. У нас ведь что тут получается — на каждый процесс
по прерыванию. А таймеров то всего ничего и прерывания грузить тяжелыми
по времени процессами нельзя — они должны быть быстрыми.
И вот именно в этом месте сон разума начинает рождать чудовищ.
Появляются какие то дополнительные условия, проверки. На одно
прерывание вешается куча разных событий, проверка флажков, попытка все
это дело увязать… В результате конструкция превращается в макаронный
клубок из переходов, вызовов, условий… В котором что либо изменить или
понять невозможно. Не имея фундамента, конструкция рушится под своим
весом. Разрушая мозг своему создателю. Начинается анархия…
Что делать? А что делать когда возникает анархия? Правильно! Нужно какое
то единое правление — бюрократический аппарат. С теоретической точки
зрения от него толку как от козла молока — клавиатуры он не опрашивает,
ножками не дрыгает, данные не шлет. Только место занимает и процессорное
время жрет. Но без него как без рук.
Флаговый автомат
Первый управляющий механизм это классический флаговый автомат.
Реализаций его существует миллион, каждый придумывает свой собственный
вариант, но разницы между ними большой нет.
Итак, в суперциклах у нас задачи вызывались одна за другой. Либо в порядке
общей очереди, либо в виде прямого вызова. Очевидно, что эта цепь
получается неразрывной и если в ней есть затыки (например какой нибудь
DELAY), то встает вся цепь.
Флаговый автомат позволяет разорвать эту цепь.
Вот его простейший вариант.
Сначала мы определяем флаги. Обычно это битовое поле, где в одном байте
насовано несколько значащих битов. Каждый за что нибудь да отвечает.
Особые извращенцы под каждый флаг заюзывают по байту.
Пусть у нас будет байт flag, а в нем разные биты, выделяемые на нашем
псевдокоде точкой. Итак, выглядит примерно это так (псевдокод):
1
2
3
4
5
6
7
8
9
10
11
12
void main(void)
{
//Start Task
flag.ScanKey=1; //Запустить сканирование клавиатуры
flag.Led_On=1; // Запустить мигалку
while(1)
{
if(flag.keyscan==1)
{
u
=ScanKey();
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
switch(u)
{
case 1: flag.Action1=1; // Поставить задачу1 на
выполнение
case 2: flag.Action2=1; // Поставить задачу2 на
выполнение
case 3: flag.Action3=1; // Поставить задачу2 на
выполнение
}
}
if(flag.led_On==1) Led_ON(); // Если стоит флаг включения -
включить
if(flag.Led_Off==1) Led_OFF(); // Если стоит флаг
выключения - выключить
if(flag.Action1==1) Action1(); // Если надо выполнить задачу 1 -
выполнить
if(flag.Action2==1) Action2(); // Если надо выполнить задачу 2 -
выполнить
if(flag.Action3==1) Action3(); // Если надо выполнить задачу 3 -
выполнить
}
}
Задача может выглядеть примерно так (всевдокод):
1
2
3
void Action1(void)
{
flag.
Action1=0; // Задача выполнена. Сбросить флаг
4
5
6
7
DoSomeThing(); // Делаем что то полезное
if(Some_Event) flag.Action3=1; // Если какое то условие выполнено, то
поставим на выполнение
// Задачу 3
}
Как видишь, тут нет прямой передачи управления между блоками. Все
делается через флаги. Надо запустить задачу мы не передаем ей управление,
а ставим флаг ее запуска. И при следующей итерации главного цикла задача
будет выполнена, а флаг сброшен (или не сброшен, если задача запущена на
циклическое исполнение).
Наращивание функционала идет без особых усилий — мы просто добавляем
новые флаги и новые секции if(flag.****==1) { }
Только у нас лампочка должна была там мигать. Что делать с
разнокалиберными временными задержками? Ведь флаговый автомат эту
проблему так и не решил. Да, сам по себе флаговый автомат бесполезен. До
тех пор пока на арену не вылазит…
Программный таймер
Могучее средство работы с временными задержками. Позволяет с помощью
всего одного аппаратного таймера легко держать под контролем прорву
задержек разной длительности.
Для начала надо сконфигурировать системный таймер, чтобы он генерировал
нам системные тики. У меня за один тик принята 1мс. Поэтому я настраиваю
таймер таким образом, чтобы он мне каждую миллисекунду генерировал
прерывание. А вот в его прерывании мы и учиним беспредел.
Программный таймер обычно делается в виде массива структур (псевдокод):
1
volatile static struct // Глобальная
2
3
4
5
6
переменная
{
Number; // Номер флага в флаговом
байте
Time; // Выдержка в мс
}
SoftTimer[Max_Numbers_of_Timer]; // Очередь таймеров
А в прерывании по таймеру гоним примерно следующий код (псевдокод):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ISR(Timer1)
{
for(i=0;i!=Max_Numbers_of_Timer;i++) // Прочесываем очередь
таймеров
{
if(SoftTimer[i].Number == 255 ) continue; // Если нашли пустышку -
следующая итерация
if(SoftTimer[i].Time !=0)
// Если таймер не выщелкал,
то щелкаем еще раз.
{
SoftTimer[i].Time --;
// Уменьшаем число в ячейке если не
конец.
}
else
{
flags |= 1<<Number ;
// Дощелкали до нуля? Взводим флаг
в флаговом байте
SoftTimer[i].Number = 255; // А в ячейку пишем затычку
-- таймер пуст.
}
}
}
Видишь, все просто. Мы прочесываем массив структур таймеров,
поэлементно. Если в поле Number у нас 255, то очевидно что это пустой
таймер. Т.к. номер флага таким быть не может (в качестве номера флага
может быть только число с одним единичным битом). Такой таймерный слот
пропускается.
Если таймер не пуст, то мы проверяем поле Time на ноль. Если не ноль, то
уменьшаем и переходим к следующему элементу массива.
А коли таймер дощелкал, то мы устанавливаем взводим во флаговом
регистре бит лежащий в поле Number. И при следующем прогоне главного
цикла управляющая конструкция if(flag.***==1) Запустит нам нужную
задачу.
Число таймеров определяется исходя из числа одновременно отсчитываемых
временных интервалов. Мне обычно хватает десятка. Если сделать меньше -
может не хватит и получишь срыв таймерной очереди. Если сделать с
большим запасом, то очередь будет дольше обрабатываться в прерывании, а
это снижает точность отсчетов интервалов, да и вообще возникает лишний
затык.
Ставится таймер откуда угодно функцией SetTimer примерно такого вида
(псевдокод):
1
2
3
4
5
void SetTimer(NewNumber,NewTime)
{
InterruptDisable(); // Запрещаем прерывания. Помним
об атомарном доступе!