Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1

Подождите немного. Документ загружается.

Вызваю процедуру записи в EEPROM — во как, сразу же сожралось куча

времени на выполнение. А записалось всего 6 байт. Обратите внимание на

масштаб времени. Насколько запись в EEPROM дольше выполнения

обычного кода.

Но одними иголками сыт не будешь. Не прикольно. Как бы задачки эти

выделить. Чтобы можно было понять кто есть кто. Решение элементарное —

выделить для отладочных целей не один бит, а поболее. У меня тут в запасе

нашлось целых 8 ног. Соответственно я сразу же по заходу в задачу вывел в

порт ее номер, а из порта загнал в R-2R ЦАП. Картина стала наглядней —

теперь высота иголки у всех задач стала разной.

Чем меньше номер, тем меньше напряжение с ЦАП. Мало того, если задачи

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

иголки, а лесенки.

Вот что мы видим. Иголки номер 1 - это сканирование клавиатуры. Те что

повыше, номер 2 — это пинг, отсыл одного байта по UART, а вот средние —

отправка пачек данных через тот же UART.

Вообще применение осциллографа это могучее средство для реалтаймовой

отладки. Не обязательно таким замудреным способом как у меня. Это я

больше для прикола и наглядности всякие АЦП вешаю. Достаточно же

просто бит выводить и смотреть на осциллографе. Еще можно добавлять

программные ловушки. Например, переполнилась критическая переменная

— выдали бит. А чтобы не ловить на экране осциллографа этих тараканов,

проще этот бит завести на какую-либо следящую систему, да хоть на триггер.

Взвел следилку и гоняй свою отлаживаемую программу в хвост и в гриву,

нагружай пока не позеленеет от натуги. А если где то что то сорвет, то

выскочит твой бит, триггер его запомнит и там хоть сирену включай —

ахтунг! Error!!!

Для большей наглядности решил я записать видяшку с происходящим. Там я

нагружаю микроконтроллер и показываю как меняется диаграмма загрузки.

На некоторых кадрах есть сильная засветка — эт мой светлый лик, заметил

уже когда залил на комп, а переснимать мне было влом. Да, думаю, и так все

самое интересное видно. Также не смотрите на то, что диаграммы иногда

плывут по оси Y — я забыл переключить осцилл на постоянное напряжение.

Однобитные иголки

Нагрузили еще немного. Шлю по UART, видно как растет нагрузка на

конвеер

Применили R-2R ЦАП.

AVR. Учебный Курс. Управляемый вектор прерывания

Бывает такая ситуация, когда надо на один периферийный девайс повесить

много разных задач, а он всего один и что то надо с этим делать.

Простой пример — таймер и его прерывание по переполнению.

Мы можем задавать выдержку и по прерыванию делать какие-нибудь

операции. Но если в один момент времени мы хотим чтобы таймер по

прерванию сделал одну операцию, а потом другую, третью. Да сколько

угодно, в зависимости от состояния. А вектор один.

Или, например, USART. Нам запросто может потребоваться, чтобы в

зависимости от режима на прерывание по приходу байта выполнялся разный

код. В одном режиме - выдача приветствия, в другом посыл матом в баню. В

третьем удар в голову. А вектор один.

Конечно, можно добавить в обработчик прерывания switch-case конструкцию

и по выбору режима перейти на нужный участок кода, но это довольно

громоздко, а самое главное — время перехода будет разное, в зависимости от

того в каком порядке будет идти опрос-сравнение switch-case структуры.

То есть в свитче вида:

switch(x)

{

1: Действие 1

2: Действие 2

3: Действие 3

4: Действие 4

}

Будет последовательное сравнение х вначале с 1, потом с 2, потом с 3 и так

до перебора всех вариантов. А в таком случае реакция на Действие 1 будет

быстрей чем реакция на Действие 4. Особо важно это при расчете точных

временных интервалов на таймере.

Но есть простое решение этой проблемы — индексный переход. Достаточно

перед тем как мы начнем ожидать прерывание предварительно загрузить в

переменные (а можно и сразу в индексный регистр Z) направление куда нам

надо перенаправить наш вектор и воткнуть в обработчик прерывания

индексный переход. И вуаля! Переход будет туда куда нужно, без всякого

сравнения вариантов.

В памяти создаем переменные под плавающий вектор:

Timer0_Vect_L: .

byte

1 ; Два байта адреса, старший и младший

Timer0_Vect_H: .byte 1

Подготовка к ожиданию прерывания проста, мы берем и загружаем в нашу

переменную нужным адресом

CLI

; Критическая часть. Прерывания

OFF

LDI R16,low(Timer_01) ; Берем адрес и сохраняем

STS Timer0_Vect_L,R16 ; его в ячейку памяти.

LDI R16,High(Timer_01) ; Аналогично, но уже со старшим

вектором

STS Timer0_Vect_H,R16

SEI ; Прерывания ON

Все, можно запускать таймер и ждать нашего прерывания. С другими

случаями аналогично.

А обработчик получается вида:

;=============================

; Вход в прерывание по переполнению от Timer0

;=============================

TIMER_0: PUSH ZL ; сохраняем индексный регистр в стек

PUSH ZH ; т.к. мы его используем

PUSH R2 ; сохраняем R2, т.к. мы его тоже портим

IN R2,SREG ; Извлекем и сохраняем флаговый

регистр

PUSH R2 ; Если не сделать это, то 100% получим

глюки

LDS ZL,Timer0_Vect_L ; загружаем адрес

нового вектора

LDS ZH,Timer0_Vect_H ; оба байта.

CLR R2 ; Очищаем R2

OR R2,ZL ; Проверяем вектор на ноль. Иначе

схватим аналог

OR R2,ZH ; reset'a. Проверка идет через операцию

BREQ Exit_Tm0 ; с накоплением результата в R2

; так мы не портим содержимое Z и нам

не придется

; загружать его снова

IJMP ; Уходим по новому вектору

; Выход из прерывания.

Exit_Tm0

: POP R2 ; Достаем и восстанавливаем регистр

флагов

OUT SREG,R2

POP

R2 ; восстанавливаем R2

POP ZH ; Восстанавливаем Z

POP ZL

RETI

; Дополнительный вектор 1

Timer_01: NOP ; Это наши новые вектора

NOP ; тут мы можем творить что угодно

NOP ; желательно недолго - в прерывании же

NOP ; как никак. Если используем какие другие

NOP ; регистры, то их тоже в стеке

сохраняем

RJMP Exit_Tm0 ; Это переход на выход из прерывания

; специально сделал через RJMP чтобы

; Дополнительный вектор 2 ; сэкономить десяток байт на коде

возврата :)))

Timer_02: NOP

NOP

RJMP Exit_Tm0

; Дополнительный вектор 3

Timer_03: NOP

NOP

RJMP Exit_Tm0

Реализация для RTOS

Но что делать если у нас программа построена так, что весь код вращается по

цепочкам задач через диспетчер RTOS? Просчитать в уме как эти цепочки

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

попытаться завладеть таймером (конечно не самовольно, с нашей подачи, мы

же программу пишем, но отследить по времени как все будет сложно).

В современных больших осях на этот случай есть механизм Mutual exclusion

— mutex. Т.е. это своего рода флаг занятости. Если какой нибудь процесс

общается, например, с UART то другой процесс туда байт сунуть не смеет и

покорно ждет пока первый процесс освободит UART, о чем просемафорит

флажок.

В моей RTOS механизмов взаимоисключений нет, но их можно реализовать.

По крайней мере сделать некоторое минимальное подобие. Полноценную

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

удержания размера ядра на уровне 500-800 байт.

Проще всего зарезервировать в памяти еще один байт — переменную

занятости. И когда один процесс захватывает ресурс, то в эту переменную он

записывает время когда ориентировочно он его освободит. Время идет в

тиках системного таймера которое у меня 1ms.

Если какой либо другой процесс попытается обратиться к этому же

аппаратному ресурсу, то он вначале посмотрит на состояние его занятости,

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

период — загрузит сам себя в очередь по таймеру. Там снова проверит и так

далее. Это простейший вариант.

Проблема тут в том, что если на один вектор много желающих будет, то

процессы так и будут бегать вокруг да около, словно бухая молодежь вокруг

единственного сортира на площади в период праздничных гуляний. У кого

нибудь да мочевой пузырь не выдержит — запорет алгоритм. А у кого тут

фиг угадаешь, т.к. промоделировать это будет сложновато.

Решение проблемы — добавление еще одной очередной цепочки, на этот раз

уже на доступ к ресурсу. Чтобы он не простаивал вообще. Т.е. один

выскочил, тут же второй, третий и так далее пока все процессы не справят

свою нужду в какой нибудь там USART.

Недостаток очевиден — еще одна очередь это дополнительная память,

дополнительный код, дополнительное время. Можно, конечно, извратиться и

на очередь к вектору натравить код диспетчера основной цепи. Но тут надо

все внимательно отлаживать, ведь вызываться он будет по прерыванию! Да и

громоздко, требуется лишь тогда, когда у нас много желающих.

Второе решение — выкинуть переменную времени занятости, оставив только

флаг “Занято!”. А процесс который пытается обратиться не убегает покурить,

а отскакивает на пару шагов назад — на конец очереди задач и сразу же

ломится обратно. Народ вокруг сортира не вокруг бегает, а толкется локтями

у входа по принципу кто первый пролезет.

Недостаток другой — большая нагрузка на главный конвеер, куча запросов

на постановку в очередь так недолго распухнуть на всю оперативку и

повстречаться со стеком, а это черевато глобальным апокалипсисом.

Разумеется таймер тут приведен для примера, большую часть задач можно

решить системным таймером RTOS, но если нужна вдруг меньшая

дискретность или высокая скорость реакции на событие (а не пока главный

конвеер дотащит задачу до исполнения), то механизм управляемых

прерываний, ИМХО, то что доктор прописал.

AVR. Учебный курс. Устройство и работа портов ввода-вывода

С внешним миром микроконтроллер общается через порты ввода вывода.

Схема порта ввода вывода указана в даташите:

Но новичку там разобраться довольно сложно. Поэтому я ее несколько

упростил:

Итак, что же представляет собой один вывод микроконтроллера. Вначале на

входе стоит небольшая защита из диодов, она призвана защитить ввод

микроконтроллера от превышения напряжения. Если напряжение будет выше

питания, то верхний диод откроется и это напряжение будет стравлено на

шину питания, где с ним будет уже бороться источник питания и его

фильтры. Если на ввод попадет отрицательное (ниже нулевого уровня)

напряжение, то оно будет нейтрализовано через нижний диод и погасится на

землю. Впрочем, диоды там хилые и защита эта помогает только от

микроскопических импульсов от помех. Если же ты по ошибке вкачаешь в

ножку микроконтроллера вольт 6-7 при 5 вольтах питания, то никакой диод

его не спасет.

Конденсатор, нарисованный пунктиром, это паразитная емкость вывода.

Хоть она и крошечная, но присутствует. Обычно ее не учитывают, но она

есть. Не забивай голову, просто знай это, как нибудь я тебе даже покажу как

её можно применить ;)

Дальше идут ключи управления. Это я их нарисовал рубильниками, на самом

деле там стоят полевые транзисторы, но особой сути это не меняет. А

рубильники наглядней.

Каждый рубильник подчинен логическому условию которое я подписал на

рисунке. Когда условие выполняется — ключ замыкается. PIN, PORT, DDR

это регистры конфигурации порта.

Есть в каждом контроллере AVR (в PIC есть тоже подобные регистры,

только звать их по другому).

Например, смотри в даташите на цоколевку микросхемы: