Tag Archives: Трюки

Управление большим количеством светодиодов через Binary Angle Modulation

Вот приспичило вам сделать себе могучую светодиодную хреновину, чтобы моргала и переливалась. Да еще в RGB и плавненько так. Собрали вы это дело, поглядели на количество каналов которыми нужно рулить и призадумались…
 

▌А что не так с ШИМ?
Да все с ним хорошо, только аппаратных каналов обычно всего несколько штук. А программный ШИМ имеет ряд недостатков. Да, можно взять и на базе алгоритма управления кучей сервомашинок, используя всего один таймер собрать многоканальный ШИМ, но сколько у нас будет вызовов прерываний?
 


 

Каждый отдельный фронт потребует своего прерывания на смену уровня. А представьте, что у нас этих каналов будет не 4, а 40? Или 400? Да контроллер из прерываний вылезать не будет. Прерывания будут налезать друг на друга, порождая джиттер. Не говоря уже о том, что все эти каналы надо будет при любом изменении скважности заново сортировать по длительности. В общем, тупилово будет еще то.
 

▌Нас спасет BAM
Но решение есть. Зовется этот метод BAM. Суть его в том, что мы включаем нагрузку импульсами, поразрядно, с длительностью равной весу разряда.

 

В результате мы имеем высокую дискретность, но при этом у нас всего 7 прерываний на любое число каналов. Соответственно разрядам.

 

Интегрируется все аналогично обычному ШИМу. Но есть ряд нюансов:

  1. Частота плавает и на малых разрядах она повышается. Для светодиода или грелки это наплевать. А вот двигатель или еще какую нагрузку с реактивными элементами вроде обмоток или емкостей я бы таким сигналом питать не стал.
  2. При переходе с малых весов к одному большому наблюдается мерцание. Но с этим можно бороться, подробности ниже.
  3. Выдавать вес лучше с большего к меньшему, так меньше заметно влияние второго пункта.

 
(далее…)

Read More »

Мультиплексирование

Думаю, каждый сталкивался с нехваткой выводов у выбранного контроллера. Принципиальных путей решения данной проблемы ровно два: менять контроллер на более многоногий или менять схему, чтобы упихнуться в существующие ноги.
Например, классика жанра — кнопки. Когда их две-три, то проще всего повесить каждую на свою ногу, особенно если на этих ногах есть внешнее прерывание. Тогда и работать с ними одно удовольствие. А если кнопок больше десятка? Если идти по первому пути, то с кличем «больше ножек!» выбираем какой-нить TQFP64 и оккупирем два порта. У такого решения есть очевидный плюс — каждая кнопка анализируется независимо от других, поэтому возможны любые аккорды. Минусы тоже очевидны: много ног ушло почти в никуда.

Второй путь — преобразовать схему так, чтобы подсократить количество занимаемых ног. Тут простора для творчества побольше. Начиная от PC-style (отдельный контроллер, который занимается опросом клавиатуры и преобразует нажатие клавиш в удобоваримый последовательный код, хоть в 1-wire) и сдвиговых регистров (как на джойстиках Dendy) заканчивая клавиатурами на резистивных делителях, подключаемых к АЦП. Весь вопрос — в стоимости.

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

Первое, что сразу приходит в голову — поставить цепочку резисторов и кнопками коротить их на землю. Примерно так:

Посмотрим, как оно работает.
(далее…)

Read More »

Управление множеством сервомашинок

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

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

Возьмем, для начала, 8 сервомашинок. На каждую серву идет вот такой сигнал:

На каждую серву со своей ноги контроллера должна идти такая вот последовательность. Итого подобие ШИМ’a на 8 каналов. Как сгенерировать эту бодягу? Да проще простого. Принцип тут простой. Импульсы медленные — всего то 50Гц, меняются тоже нечасто — серва штука инерционная, поэтому даже сто раз в секунду ей не подергаешь. Так что времени на обработку у нас вагон и маленькая тележка.

Сами импульсы будут генерироваться одним таймером, в фоновом режиме. Принцип генерации прост: Все импульсы стартуют одновременно, выставляя свои уровни в 1.
Затем в таймер, в регистр сравнения, заносится время длительности первого импульса. По прерыванию сравнения происходит:

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

(далее…)

Read More »

Обработка множества инкрементальных энкодеров одновременно

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

Обозначим текущее состояние энкодера как «y1» и «y2», а предыдущее, как «x1» и «x2». Всего 4 бита — 16 состояний. Условимся, что направление «Вперёд» у нас будет от первого датчика энкодера ко второму. Запишем все возможные состояния в таблицу.

Таблица 1.
№	y2	y1	x2	x1	Вперёд	Назад	Состояние
------------------------------------------------------------------
0	0	0	0	0	0	0	Стоп	
1	0	0	0	1	0	1	Назад
2	0	0	1	0	1	0	Вперёд
3	0	0	1	1	0	0	Не определено
4	0	1	0	0	1	0	Вперед
5	0	1	0	1	0	0	Стоп
6	0	1	1	0	0	1/0	Назад*	
7	0	1	1	1	0	1	Назад	
8	1	0	0	0	0	1	Назад	
9	1	0	0	1	1/0	0	Вперёд*	
A	1	0	1	0	0	0	Стоп	
B	1	0	1	1	1	0	Вперёд	
C	1	1	0	0	0	0	Не определено	
D	1	1	0	1	1	0	Вперёд	
E	1	1	1	0	0	1	Назад	
F	1	1	1	1	0	0	Стоп

* — строчки 6 и 9 в таблице в принципе означают перемещение назад и вперёд соответственно, в случае если оба датчика энкодера никогда не срабатывают одновременно. Такая ситуация теоретически может иметь место если энкодер это две оптопары и колесо с отверстиями, причем размер отверстия меньше расстояния между оптопарами. На практике это встречается редко, по этому будем иметь этот случай ввиду, но учитывать не будем.
(далее…)

Read More »

Пример виртуальной машины

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

Простой пример для чего это нужно — фрезерный станок с ЧПУ. И надо на нем выточить голову Сократа из цельного куска металла. Задача, на самом деле, не шибко сложная.

Но попробуйте написать прошивку, двигающую резцом, в виде классического конечного автомата — двигающую резцом в зависимости от условий или состояний. Да вы сдохнете раньше чем это сможете сделать.

Другое дело если разбить программу на элементарные операции, вроде «Резец вверх», «резец вниз», «шаг на n мм», а прошивке скормить последовательность этих микроопераций в виде байт-кода или текстового скрипта. Как все серьезно упрощается. Да и попутно можно нашинковать Платона с Гераклом, было бы желание, да образец для копирования.

Т.е. у нас появился свой язык устройства, полностью отвязанный от аппаратной реализации и оперирующий только органами устройства. И вот тут, главное, не впасть в высокоуровневую прелесть и не начать изобретать универсального интерпретируемого языка аля JAVA для микроконтроллеров. В условиях ограниченных ресурсов это полный бред.

Наоборот, этот язык нужно максимально упрощать за счет усложнения процедур машины, затачивая их строго под текущую задачу, а не делая нечто универсальное. Тогда можно выжать максимум из контроллера.

Ну, хватит воды, приведу пример того, что у меня получилось за вечерок курения в код. Код рабочий, но я там ничего не оптимизировал. Так, накидал чтоб работало, до ума доведете сами. Сделано все на базе ядра диспетчера. Я его уже описывал, поэтому работу его функций пояснять не буду
(далее…)

Read More »

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

Каждый кто пытался разбираться с конечными автоматами наверняка натыкался на всякие замудреные графы, какие то графики. Многие посчитав это слишком сложным плюнули и забили. А Зря!

С простейшим конечным автоматом каждый из нас сталкивался с самого детства — это механическая авторучка. Объект с единственной функцией «Нажатие кнопки», но в зависимости от очередности результат разный. Стержень то прячется, то вылазит.

Так и в нашем случае — конечный автомат это функция которая запоминает свое состояние и при следующем вызове делает свое черное дело исходя из прошлого опыта. Простой пример — мигалка (псевдокод):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
; Глобальные переменные
u08 Blink_State;
 
void Blink(void)
{
if (Blink_State == 1)
	{
	Led_On();
	Blink_State = 0;
	Return;
	}
if (Blink_State == 0)
	{
	Led_Off();
	Blink_State = 1;
	Return;
	}
}

Вызывая эту функцию подряд мы заставим диодик менять свое состояние при каждом вызове.
(далее…)

Read More »

М. Дамке «Операционные системы микроЭВМ»

Автор:		М. Дамке
Название: 	Операционные системы микроЭВМ
Издательство: 	Финансы и статистика

Старожил сайта и один из самых активных и толковых комментаторов, камрад SWG сделал замечательную вещь— отсканировал и пожал в DejaVu книгу по написанию операционных систем под микро-ЭВМ.

Я пока основательно не врубался, по диагонали пролистал — рулез! Особого грузилова нет, все в виде алгоритмов и концепций. Написано все простым и понятным языком. В частности все разобрано на примере Z80 и i8080 В общем, замечательная книга. Как говорил SWG где то в комментах: «Почитай эту книгу и изобретение велосипедов пойдет куда веселей» :)

Read More »

Это сладкое слово ХАЛЯВА!

Не раз и не два в комментах и в постах я упоминал, что у меня полно всяких радиодеталей, причем редких, дорогих и не продающихся в наших лабазах даже под заказ. Пора бы поделиться с читателями сокровенным — где я надыбал столько ништяковых радиодеталей. Которые даже под заказ днем с огнем не сыщешь даже в столице, не говоря уже про такие медвежьи углы как Челябинск. А мне они достались нахаляву. И дело тут не в особой карме или везении, а всего лишь ловкость рук и немного мошенничества :)

Итак, каждый уважающий себя производитель комплектующих просто жаждет найти и привлечь крупного оптовика, который будет у него скупать их кремниевых тараканов сотнями тысяч штук. Но для этого оптовика нужно привлечь, показать его разработчикам продукт, дать пощупать его мягкое жирное мясо. Поэтому они, практически все, шлют бесплатные образцы. В количестве нескольких штук. Мало того, зачастую они согласны даже оплачивать растаможку и дорогущую экспресс доставку. Чем я нагло и с кайфом пользуюсь. (далее…)

Read More »

AVR. Учебный курс. Делаем АЦП из Аналогового компаратора

Так сложилось, что основной МК с которым я работаю постоянно и на котором делаю подавляющее большинство задач это ATTiny2313 — он популярен, а, главное, это самый дешевый контроллер из всей линейки AVR с числом ног более 8. Я их брал числом около трех сотен за 18, чтоль, рублей штучка. Но вот западло — у него нет АЦП. Совсем нет. А тут он понадобился — нужно замерить сигнал с датчика. Засада. Не переходить же из-за такой фигни на более фаршированную ATTiny26 — она и стоит дороже и фиг где купишь у нас, да и что тогда делать с той прорвой ATTiny2313 что уже закуплена? Пораскинул мозгами…

А почему бы не сварганить АЦП последовательного сравнения? Конечно, быстродействие и точность будет не фонтан, зато, не меняя тип МК и всего с двумя копеечными деталями дополнительного обвеса, я получу полноценный, хоть и тормозной, 8ми разрядный АЦП, вполне удовлетворяющий моим скромным запросам! (далее…)

Read More »

AVR. Учебный Курс. Виртуальные порты

Глядя на то, как раскиданы порой ножки портов по корпусу контроллеров, у меня возникают большое подозрение, что разводчик кристалла дунул что то сильно забористое. Когда вперемешку идут выводы разных портов, да еще почти в рандомном порядке… Когда к этим портам вешаем что-либо разнобойное, то пофигу. А если надо подцепиться на прямую линейку шины данных, вроде того же LCD дисплея? Вот тут и начинается круголяние дорожек по плате. А если плата фаршированная донельзя? Тут приходится вводить перемычки, дополнительные слои и извращаться как только можно. Короче, та еще проблема.

Я решаю ее виртуальными портами. То есть завожу в системе переменную каждому биту которой привязываю какую-либо ножку. Поскольку все выводы независимы я могу компоновать виртуальный порт в любом порядке и из любых линий. Чертовски удобно. Впрочем, за удобство приходится платить — обработка такого порта требует несколько десятков команд. Но когда кристалл не забит под завязку, то можно позволить себе немного пошиковать во имя удобства.

Итак. Подключаем куда-нибудь в область процедур блок кода виртуального порта. (далее…)

Read More »

Переменный резистор

Переменный резистор
Переменный резистор
Ограничение крайних значений
Ограничение крайних значений
Повышение точности
Повышение точности
Вроде бы простая деталька, чего тут может быть сложного? Ан нет! Есть в использовании этой штуки пара хитростей. Конструктивно переменный резистор устроен также как и нарисован на схеме — полоска из материала с сопротивлением, к краям припаяны контакты, но есть еще подвижный третий вывод, который может принимать любое положение на этой полоске, деля сопротивление на части. Может служить как перестариваемым делителем напряжения (потенциометром) так и переменным резистором — если нужно просто менять сопротивление.

Хитрость конструктивная:
Допустим, нам надо сделать переменное сопротивление. Выводов нам надо два, а у девайса их три. Вроде бы напрашивается очевидная вещь — не использовать один крайний вывод, а пользоваться только средним и вторым крайним. Плохая идея! Почему? Да просто в момент движения по полоске подвижный контакт может подпрыгивать, подрагивать и всячески терять контакт с поверхностью. При этом сопротивление нашего переменного резистора становится под бесконечность, вызывая помехи при настройке, искрение и выгорание графитовой дорожки резистора, вывод настраимого девайса из допустимого режима настройки, что может быть фатально.
Решение? Соединить крайний вывод с средним. В этом случае, худшее что ждет девайс — кратковременное появление максимального сопротивления, но не обрыв.

Борьба с предельными значениями.
Если переменным резистором регулируется ток, например питание светодиода, то при выведении в крайнее положение мы можем вывести сопротивление в ноль, а это по сути дела отстутствие резистора — светодиод обуглится и сгорит. Так что нужно вводить дополнительный резистор, задающий минимально допустимое сопротивление. Причем тут есть два решения — очевидное и красивое :) Очевидное понятно в своей простоте, а красивое замечательно тем, что у нас не меняется максимально возможное сопротивление, при невозможности вывести движок на ноль. При крайне верхнем положении движка сопротивление будет равно (R1*R2)/(R1+R2) — минимальное сопротивление. А в крайне нижнем будет равно R1 — тому которое мы и рассчитали, и не надо делать поправку на добавочный резистор. Красиво же! :)

Если надо воткнуть ограничение по обеим сторонам, то просто вставляем по постоянному резистору сверху и снизу. Просто и эффективно. Заодно можно и получить увеличение точности, по принципу приведенному ниже.

Повышение точности.
Порой бывает нужно регулировать сопротивление на много кОм, но регулировать совсем чуть чуть — на доли процента. Чтобы не ловить отверткой эти микроградусы поворта движка на большом резисторе, то ставят два переменника. Один на большое сопротивление, а второй на маленькое, равное величине предполагаемой регулировки. В итоге мы имеем две крутилки — одна «Грубо» вторая «Точно» Большой выставляем примерное значение, а потом мелкой добиваем его до кондиции.

Read More »

AVR. Учебный Курс. Отладка программ. Часть 4

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

Осциллограф
Очень часто хочется в динамике поглядеть как работает программа. Особенно если ее структура сложней чем просто суперцикл. Если там конечные автоматы на прерываниях или разделение задач на флаговом автомате/очередном диспетчере, то аналитическое тупление в код и прогоны в отладчике мало что дадут — наслоение прерываний, процессов в очереди, стадии и взаимодействие разных конечных автоматов взорвут мозг кому угодно. А если еще программа не написана с нуля, а собрана из кучи чужих исходников, да даже если из своих, но древних и уже забытых.
 

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

Для примера возьму ту программу, что идет в доке к демоплате Pinboard. Там стоит мой диспетчер очереди, а также немного автоматики на прерываниях. Плюс старая библиотека для HD44780
 

В принципе все с виду работает пучком и никаких косяков. Но одолели меня сомнения, так ли это? Если двигатель вращается, то это еще не значит, что он работает хорошо и без ошибок. Так и у нас, надо проверить, все ли в порядке. Слушать мы будем осциллографом «механику» тиканья службы таймера. Почему его? Ну так вокруг него вся логика программы построена.
 
(далее…)

Read More »

AVR. Учебный Курс. Отладка программ. Часть 3

Метод 3. USART (Работа с последовательными интерфейсами)
Пожалуй самым популярным отладочным интерфейсом является все же USART. Во-первых, он поддерживается аппаратно почти всеми микроконтроллерами. Во-вторых, он прост в использовании и требует всего один/два сигнальных провода, а в третьих, для связи с компом не надо городить никаких специфичных девайсов. В худшем случае UART-USB или UART-RS232 конвертер на FT232RL или MAX232.
 

Пользоваться им проще простого — в любой момент, когда нам это захочется, мы берем и отправляем нужный байт по этому интерфейсу. При этом достаточно заранее его настроить — стандартная инициализация UART:
 

1
2
3
4
5
6
7
8
9
10
11
12
; Usart INIT
		.equ 	XTAL = 8000000 	
		.equ 	baudrate = 9600  
		.equ 	bauddivider = XTAL/(16*baudrate)-1
 
uart_init:	LDI 	R16, low(bauddivider)
		OUT 	UBRRL,R16
		LDI 	R16, high(bauddivider)
		OUT 	UBRRH,R16
 
		LDI 	R16,0
		OUT 	UCSRA, R16

 

1
2
3
; Прерывания запрещены, прием-передача разрешен.
	LDI 	R16, (1< <RXEN)|(1<<TXEN)|(0<<RXCIE)|(0<<TXCIE)|(0<<UDRIE)
	OUT 	UCSRB, R16

 

Маркеры
Всегда полезно знать где наша программа шляется в данный момент. Конечно, можно зажигать светодиодики, как в прошлом методе. Но когда точек много, то выводов не напасешься на эту затею. Или затрахаешься перекомпилировать. Проще всего натыкать в код маркеров, наступая на которые наш МК будет отрыгивать в терминал свое местоположение. Терминальный клиент будет писать лог и ничего не проморгаешь.
 
(далее…)

Read More »

AVR. Учебный Курс. Отладка программ. Часть 1

У каждого случалась такая ситуация — программа вроде бы написана, даже компилится, но не работает. Почему не работает? Дак все же просто — в ней есть лажа!
 

Процесс избавления программ от лажи называется, соответственно, отлаживанием. И часто этот процесс длится куда дольше разработки, особенно в хитрых случаях, с привлечением внешней периферии.
 

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

Метод 0. Тупление в код (Аналитический)
К моему великому удивлению, данный метод является наиболее популярным в народе и, а у начинающих порой единственным.
Видимо сказывается засилье всяких высокоуровневых языков вроде ПОХАПЭ или Си, где такое вполне может и проканать. Там да, можно пофтыкать несколько минут в исходник, глядишь да найдешь где накосячил.
 

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

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

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

Хотя я, в свое время, изучал ассемблер вообще без компа — не было его у меня. Тетрадка в клеточку, команды i8008 в столбик. А потом и Z80 с его божественным ассемблером. И опять без отладчиков, аналитически. Ляпота! Но вот когда я сел за ассемблер 80С51, в первую же очередь я нашел нормальную IDE с эмуляцией — Keil uVision. А эра х86 прошла под знаменем Borland Turbo Debugger и TASM. Когда моя первая 128 байтная интруха полыхнула по экрану пиксельным пламенем клеточного автомата… да ощущения были еще те. Где то ее сорцы валяются, надо поискать.

 

В написании может быть, но вот в отладке нифига подобного. Так как нечего тут думать. Ассемблер это как лопата — берешь и копаешь, а не думаешь как там поршни и трансмиссия в экскаваторе крутится.
 

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

Под каждый стиль написания кода свои инструменты отладки. Поэтому переходим к другому методу. (далее…)

Read More »

Извращенский ШИМ из UART

Пока писал статью про UART пришла в голову одна извращенная идея — на базе UART же можно организовать самый натуральный низкодискретный ШИМ!

Достаточно только сделать где-нибудь в памяти переменную, куда мы будем совать число с заданной скважностью нулей и единиц, а по прерыванию опустошения буфера это число снова пихать в регистр UDRE. Таким образом, генерация ШИМ будет самопроизвольной, без лишних телодвижений. Правда можно получить всего 10 разных значений ШИМ, но зато нахаляву!!!

Для тех кто не понял как, приведу числа которые надо будет непрерывно слать через UART:
два дополнительных значения мы получим за счет старт и стоп битов.

00000000 — 1/10
00000001 — 2/10
00000011 — 3/10
00000111 — 4/10
00001111 — 5/10
00011111 — 6/10
00111111 — 7/10
01111111 — 8/10
11111111 — 9/10

Да и частоты там можно получить нефиговые!
Красота!=)))))

Read More »

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

Вот ты читаешь сейчас это и думаешь — память, регистры, стек и прочее это хорошо. Но ведь это не пощупать, не увидеть. Разве что в симуляторе, но я и на дельфи с тем же условием могу накодить. Где мясо!!!
 
В других курсах там, чуть ли не с первых строк, делают что то существенное — диодиком мигают и говорят, что это наш Hello World. А тут? Гыде???
 

Да-да-да, я тебя понимаю. Более того, наверняка ты уже сбегал к конкурентам и помигал у них диодиком ;)))) Ничего, простительно.
 

Я просто не хотел на этом же мигании дидодиков и остановиться, а для прогресса нужно четкое понимание основ и принципов — мощная теоретическая база. Но вот пришла очередь практики.
 

О портах было рассказано, шаблон программы у вас уже есть, так что сразу и начнем.
 
(далее…)

Read More »

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

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

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

Или, например, USART. Нам запросто может потребоваться, чтобы в зависимости от режима на прерывание по приходу байта выполнялся разный код. В одном режиме — выдача приветствия, в другом посыл матом в баню. В третьем удар в голову. А вектор один.

Конечно, можно добавить в обработчик прерывания switch-case конструкцию и по выбору режима перейти на нужный участок кода, но это довольно громоздко, а самое главное — время перехода будет разное, в зависимости от того в каком порядке будет идти опрос-сравнение switch-case структуры.

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

1
2
3
4
5
6
7
switch(x)
	{
	1: Действие 1
	2: Действие 2
	3: Действие 3
	4: Действие 4
	}

Будет последовательное сравнение х вначале с 1, потом с 2, потом с 3 и так до перебора всех вариантов. А в таком случае реакция на Действие 1 будет быстрей чем реакция на Действие 4. Особо важно это при расчете точных временных интервалов на таймере.

Но есть простое решение этой проблемы — индексный переход. Достаточно перед тем как мы начнем ожидать прерывание предварительно загрузить в переменные (а можно и сразу в индексный регистр Z) направление куда нам надо перенаправить наш вектор и воткнуть в обработчик прерывания индексный переход. И вуаля! Переход будет туда куда нужно, без всякого сравнения вариантов.
(далее…)

Read More »

AVR. Учебный Курс. Оценка загрузки контроллера.

Как оценить загруженность микроконтроллера? С памятью все понятно — размеры занимаемого кода и оперативной памяти показывает компилятор, а что делать с процессорным временем? Конечно, в линейной программе можно взять и посчитать время выполнения каждой процедуры и станет ясно успеет микроконтроллер выполнить все на него повешанное или слажает в каком-нибудь критичном месте.
Куда сложней оценивать время в кооперативной операционной системе реального времени. Тут задачка получается нетривиальной — у нас куча процессов скачут через диспетчер. В ходе программирования задачи навешиваешь одну за другой, как бусинки на нить — каждый процесс обработки чего либо составляет подобную цепочку, а всего их может быть просто тьма. Ядро же у контроллера всего одно, а значит выполнять можно всего одну задачу за раз и если у нас в диспетчере скопится много критичных ко времени процессов (вообще их лучше развешивать на прерывания, но бывает и прерываний на всех не напасешься), то возможно либо переполнение очереди диспетчера, либо превышение времени ожидания, что тоже не праздник.
Самое западло в том, что умозрительно отлаживать такие вещи довольно сложно. Единственный вариант — рисовать временные диаграммы запуска каждой задачи и смотреть где у нас узкие места. Еще можно попробовать в AVR Studio поставить Break Point на переполнение диспетчера, но студия не сэмулирует всю ту прорву периферии, а в пошаговой отладке этого не увидеть — да и момент надо подобрать так, чтобы все навалилось.

В один момент мне пришла в голову одна идея — а почему бы не заставить рисовать временные диаграммы работы задач сам контроллер? Это же просто! Берем и в диспетчере, перед вызовом задачи выставляем бит порта в 1. А когда диспетчер задач опустошается полностью, то есть выполняется переход на Idle — сбрасываем бит в 0. В результате, у нас на выходе будет подобие ШИМ. Если постоянно крутится Idle — будут нули перманентно. Если же проц в поте лица гонит через себя непрерывно код, то будут высокий уровнь сплошняком. А если все прерывисто — что то ШИМообразное. Причем чем больше загрузка процессора тем выше заполнение. Можно поставить интегрирующую RC цепочку и получим аналоговый сигнал. Хоть на стрелочный индикатор заводи :). Сказано — сделано.
(далее…)

Read More »

AVR. Учебный курс. Операционная система. Пример.

Отлично, с теорией работы ОС ознакомил. Устанавливать научил, осталось научить использовать весь этот конвеерно таймерный шухер. Чем я сейчас и займусь. Сразу берем быка за рога и формулируем учебно-боевую программу.
Тестовое задание:
Пусть у нас будет ATMega8, с несколькими кнопками. АЦП и подключеним к компу через UART. На меге будет три светодиода.

  • Девайс должен при включении начинать мигать зеленым диодом, мол работаю.
  • При этом раз в секунду сканировать показания АЦП и если показания ниже порога — Моргать красным диодом.
  • По сигналу с UARТ с целью защиты от ошибок сделать по байту ‘R’ установку флага готовности, а потом, в течении 10ms если не придет байт ‘A’ сбросить флаг готовности и игнорировать все входящие байты кроме ‘R’. Если ‘A’ придет в течении 10мс после ‘R’, то отправить в UART ответ и зажечь белый диод на 1 секунду.

Вот так вот, не сильно сложно. Но мне просто лень делать что либо сложней, а для тестовой задачи сгодится. (далее…)

Read More »

AVR. Учебный курс. Скелет программы

При написании прошивки надо очень внимательно подходить к процессу организации архитектуры будущей программы. Программа должна быть быстрой, не допускать задержек главного цикла и легко расширяться. Оптимально использовать аппаратные ресурсы и стараться выжать максимум возможного из имеющихся ресурсов.

Вообще, архитектура программ это отдельная тема и ближе к концу курса, в его Сишной части я подробней рассказываю о разных типах организации прошивки. Можешь забежать вперед и поглядеть, что да как.

В ассемблерной же части, я расскажу о одном из самых простых вариантов — флаговом автомате, а позже, когда ты уже будешь вовсю ориентироваться в моем коде, дам пример на основе конвейерного диспетчера, с подробным описанием его работы.

Суперцикл
Все программы на микроконтроллерах обычно зацикленные. Т.е. у нас есть какой то главный цикл, который вращается непрерывно.

Структура же программы при этом следующая:

  • Макросы и макроопредения
  • Сегмент ОЗУ
  • Точка входа — ORG 0000
  • Таблица векторов — и вектора, ведущие в секцию обработчиков прерываний
  • Обработчики прерываний — тела обработчиков, возврат отсюда только по RETI
  • Инициализация памяти — а вот уже отсюда начинается активная часть программы
  • Инициализация стека
  • Инициализация внутренней периферии — программирование и запуск в работу всяких таймеров, интерфейсов, выставление портов ввода-вывода в нужные уровни. Разрешение прерываний.
  • Инициализация внешней периферии — инициализация дисплеев, внешней памяти, разных аппаратных примочек, что подключены к микроконтроллеру извне.
  • Запуск фоновых процессов — процессы работающие непрерывно, вне зависимости от условий. Такие как сканирование клавиатуры, обновление экрана и так далее.
  • Главный цикл — тут уже идет вся управляющая логика программы.
  • Сегмент ЕЕПРОМ

(далее…)

Read More »