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

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

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

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

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

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

Итак, начну разматывать с самого верха. Есть у нас программа:

• FWD
• DLY,T(1000)
• STP
• DLY,T(1000)
• BCK
• DLY,T(2000)
• STP
• OFF

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

• FWD - ехать вперед.
• DLY - задержка, в скобочках время в мс
• STP - стоп
• BCK - назад
• OFF - выключение.

Простенькая такая программка истинного партийца — шаг вперед, два шага назад. =)))

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#define OFF 0
#define BCK 1
#define FWD 2
#define DLY 3
#define STP 4
#define T(X) ((X)& 0xFF),((X)>>8)
 
static u08 VM_PGM[]=
 
{
FWD,            //0
DLY,T(1000),    //1,2,3
STP,            //4
DLY,T(1000),    //5,6,7
BCK,            //8
DLY,T(2000),    //9,10,11
STP,            //12
OFF             //13
};

Тут все просто. Вначале через дефайны мы каждой мнемонике нашего ассемблера присваиваем номер команды (это важно!). А потом забиваем их в стандартный массив во флеше. Массив занял у нас 13 байт. Обрати внимание на то, что команды переменной длины. Т.е. есть простые - однобайтные, а есть двубайтные, например, задержка. Там байт на команду и два байта на выдержку.

Каждой команде присвоена своя процедура, содержимое процедур не важно особо, они для примера. Тут у меня “вперед” это зажигание одного светодиода на Pinboard, а “назад” другого. Команды эти лежат в файле VM.c, а хидеры в VM.h :

1
2
3
4
5
6
7
8

void VM_Back(void)
{
LED_PORT  ^=1<<LED3; 		// Зажигаем диод
VM_PC[0]++;			// Выбор следующей задачи VM
 
SetTask(VM);			// Вброс диспетчера виртуальной 
				// машины на конвейер диспетчера RTOS
}

Как видишь, тут мы что то делаем, а потом увеличиваем счетчик виртуальной машины. Заставляя выбирать ее следующую команду из нашей надпрограммы. Дальше обработчик виртуальной машины закидывается на конвейер ядра RTOS. Впрочем тут нет разницы каким образом организована главная логика программы. Это может быть и конечный автомат или же флаговый автомат. Остальные подзадачи аналогичны.

1
2
3
4
5
6
7

void VM_Stop(void)
{
LED_PORT  ^=1<<LED3;
VM_PC[0]++;
 
SetTask(VM);
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void VM_Delay(void)
{
u16 delay;				// Двубайтная переменная
u08 *OneByte;				// Указатель на один байт
 
OneByte = (u08 *)&delay;		// Берем адрес переменной
 
*OneByte = VM_PGM[++VM_PC[0]];	// По байтикам собираем слово
OneByte++;
*OneByte = VM_PGM[++VM_PC[0]];
 
VM_PC[0]++;				// Прощелкиваем счетчиком надпрограммы
 
SetTimerTask(VM,delay);		// Запуск задачи VM через диспетчер таймеров.
}

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

1
2
3
4

void VM_OFF(void)
{
InitVM();
}

Тут просто идет переинициализация VM

Сами обработчики операторов надпрограммы уложены в таблицу переходов, которая размещена во флеше.

1
2
3
4
5
6
7
8
9

//VM Task Table 
static TPTR VM_FUNC[] PROGMEM =
   {
   &VM_OFF,		//0
   &VM_Back,		//1
   &VM_Forward,      	//2
   &VM_Delay,		//3
   &VM_Stop		//4
   };

И вот тут важная деталь! Расположение адресов в таблице переходов ТОЧНО соответствует коду операции. Т.е. по нашей надпрограммной системе команд у команды OFF код 0, и ее адрес находится в нулевой ячейке массива VM_FUNC[].

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

1
2
3
4

void VM(void)    // Виртуальная машина
{
SetTask((void*)pgm_read_word_near(VM_FUNC+VM_PGM[VM_PC[0]]));
}

То есть тут только вызов SetTask. Куда мы считываем ему адрес из памяти программ, из массива VM_FUNC, по смещению из массива VM_PGM, а само смещение берем из массива VM_PC. Вот такая вот Кащеева смерть (Кащей, кстати, знаю что читаешь — заходи бухать. Давно тебя не видел).

А что за массив VM_PC? А это программный счетчик нашей виртуальной машины. Переменная в нем дает значение смещения по массиву с надпрограммой. Для выборки следующей выполняемой команды надпрограммы. Т.е. исходя из значения в VM_PC мы берем значение следующей команды. Поэтому то мы в каждой задаче и увеличивали его значение на 1, а если шли данные, то на 1+величину этих данных (в нашем случае на 1+2). Заботу о программном счетчике приходится решать нам, в обработчиках операторов надпрограммы. А как ты хотел? Реальный процессор работает точно также :)))) А мы сделали процессор в процессоре.

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

Остается один только вопрос, а нафига VM_PC массив? Ведь хватит и одного байта. Хватит, ага, но кто сказал, что у нас может выполняться только одна надпрограмма? ;))))

Почему бы не запустить несколько параллельных процессов, каждая со своим VM_PC?

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

Запускается же виртуальная машина просто:

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

1
2
3
4
5
6
7
8
9

void InitVM(void)
{
u08 i;
 
for(i=0;i!=10;i++)
   {
   VM_PC[i]=0;
   }
}

А дальше запускаем ее как обычную задачу из под диспетчера:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

int main(void)
{
InitAll();		// Инициализируем периферию
InitRTOS();		// Инициализируем ядро
InitVM();
RunRTOS();		// Старт ядра.
 
// Запуск фоновых задач.
SetTask(VM);
 
while(1)		// Главный цикл диспетчера
{
wdt_reset();		// Сброс собачьего таймера
TaskManager();		// Вызов диспетчера
}
 
return 0;
}

Ну и, напоследок, как обычно, собранный проект для WinAVR+AVRStudio с этим примером

WM-GCC-RTOS.ZIP

З.Ы.
На сайт теперь прикручена кодопомойка с подсветкой синтаксиса. Цветами я еще поиграюсь, но уже работает. Теперь не будет проблемы с публикацией длинных кусков кода в комментарии. Достаточно разместить ее в кодопомойке, а в коммент вставить ссылку. Ссылка на кодопомойку встроена теперь в поле ответа на коммент (открывается в новом окне).

Кодопомойка

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

З.З.Ы.
В Карте Сообщества был добит зверский баг из-за которого многие точки теряли координаты и топились в Атлантическом Океане, где то в районе Африки. Глюк мы подчистили, а также зачистили базу с битыми точками. Битых точек было вагон, поэтому если кто ставил свои отметки — проверьте их наличие, возможно их уже там нет. Надо переставить. Ну и народу там понадобавлялось порядочно. Сама же карта теперь торчит в виде баннера в виде… хм, карты.

З.З.З.Ы.
У меня тут, ВНЕЗАПНО, родственники, ТЫСЯЧИ ИХ! Плюс еще дела мелкие, но по тому же сценарию. Так что не теряйте. Я не забил, просто очень занят :(

Главное его не красить в зеленый цвет, а то монтировками загасят.

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

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

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;
	}
}

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

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

Приведу другой, более сложный пример. Генерацию сигнала сложной формы.

Пусть у нас есть сигнал:

Цифрами указана задержка, в каких нибудь величинах. Это не суть важно.

Обычно народ не парится и лепит его по быдлокодерски, через delay:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Set_Pin();	// Вывод в 1
Delay(10);	// Задержка 10
 
Clr_Pin();	// Вывод в 0
Delay(100);	// Задержка в 100
 
Set_Pin();
Delay(1);
 
Clr_Pin();
Delay(5);
 
Set_Pin();
Delay(2);
 
Clr_Pin();
Delay(3);
 
Set_Pin;
Delay(4);
 
Clr_Pin();

Это дает минимальный код, но затыкает работу контроллера на весь период посылки. А если слать надо постоянно? Да еще дофига всего попутно делать? Экран обновлять, данные обрабатывать, в память писать…
В таком случае у нас рулит RTOS, где на Delay происходит передача управления диспетчеру. Но если ОС нету? Вот тут то и идет в ход конечный автомат.

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

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
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
61
62
63

Timer_Overflow_Interrupt(void)
{
switch(TMR_State)			// Обработчик прерывания по переполнению
	{
	case 0:	
		{ 
		Clr_Pin();		// Вывод в 0
		TCNT = 255-100; 	// Задержка в 100 (до переполнения)
		TMR_State = 1; 		// Следующая стадия 1
		Break;			// Выход
		}
 
	case 1:	
		{ 
		Set_Pin();
		TCNT = 255-1; 
		TMR_State = 2; 
		Break;
		}
 
	case 2:	
		{ 
		Clr_Pin();
		TCNT = 255-5; 
		TMR_State = 3; 
		Break;
		}
 
	case 3:	
		{ 
		Set_Pin();
		TCNT = 255-2; 
		TMR_State = 4; 
		Break;
		}
 
	case 4:	
		{ 
		Clr_Pin();
		TCNT = 255-3; 
		TMR_State = 5; 
		Break;
		}
 
	case 5:	
		{ 
		Set_Pin();
		TCNT = 255-4; 
		TMR_State = 6; 
		Break;
		}
 
	case 6:
		{ 
		Clr_Pin();
		Timer_OFF(); 		// Выключаем таймер. Работа окончена
		TMR_State = 0; 		// Обнуляем состояние
		Break;			
		}
 
	default: 	break;		
	}
}

А запускается эта байда простым пинком:

1
2
3
4
5
6

Set_Pin();
TCNT=255-10;		// Грузим таймер на выдержку 10 тиков
TMR_State = 0;		// Устанавливаем начальное положение
Timer_ON();		// Поехали!
 
... // После чего можно заниматься чем угодно.

Когда автомат отработает - сама себя выключит. Можно еще какоенить событие сгенерировать, дабы основная программа поняла, что все уже готово. Хотя основная программа спокойно может палить переменную состояния автомата и все оттуда узнать сама.

Конечный автомат можно зациклить — скажем на стадии 6 сделать перенаправление на стадию 0, то получим генератор сигнала сложной формы. Причем он будет занимать минимум процессорного времени.

Если мы, например, захотим сделать десяток ШИМ сигналов? То что нам мешает повесить их на ОДИН таймер, главное отсортировать все скважности по возростанию, причем сортировать их вместе с ногами которыми нужно дрыгать. А потом прогнать по прерыванию таймера конечный автомат, да так чтобы он по стадиям передергивал ножки. Правда при изменении скважности любого из этих софтверных ШИМ каналов придется делать повторную сортировку всего массива. Разумеется больших скоростей мы на этом не получим. Таймер не может щелкать так быстро, да и математики там хватит. Но для многих задач, например, одновременное управление десятком сервомашинок этого более чем достаточно.

А если в том же прерывании таймера сделать выбор следующей стадии исходя не из тупой последовательности, а, скажем, на основе обрабатываемого байта, то мы получим программно-аппаратный генератор, к примеру, 1-Wire кода. Достаточно анализировать входной буфер и если там 1 - перебрасывать автомат в состояние соответствующее отработки генерации сигнала 1, а если 0, то в состояние генерящее выдержку нуля.

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

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

Особенно автоматный метод доставляет тем, что готовые автоматы вписываются как родные в ЛЮБУЮ почти архитектуру. У меня они и во флаговых автоматах работают на ура, и из диспетчера RTOS я их гоняю как родные. Красота!

Итак, несколько слов об устройстве. Ниже приведена 3d моделька девайсины.

В основе робота сервомашинки Futaba S3003 - самые простые и дешевые, что удалось раздобыть на нашей кафедре (кафедра ТМ и М ЮЗГУ(КурскГТУ)). О том, что такое сервомашинка и как она работает у Вас есть отдельная статья на данном сайте, поэтому останавливаться на этом я не буду.

Конструктив
Всего в конструкции 8 сервомашинок, управляющихся от одной 16ой атмеги. Соединенные металлическими уголками

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

Под мою задачу возникла необходимость уменьшения скорости поворота серв (при максимальной скорости поворота, т.к. робот делался на коленках, он переворачивался). Сделано это было так: посылалось не начальное и конечное значение на привод, а задавалось несколько промежуточных положений + количество импульсов на отработку одного положения. Таким образом, можно получить самые разные скорости и характеристики поворота от очень плавного и медленного до очень корявого. Для дополнительного трения с нижней стороны модулей были добавлены резиновые контактные площадки из обычных ластиков)).

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

И вот, что из всего этого получилось

При отладке проги внчале я делал симуляцию в протеусе. Надо сказать, что при правильной настройке модели сервы в протеусе, он симулирует ее очень правдиво. Вот симуляция в протеусе

А вот как это все в движении:

Когда переделал схемку под 8ую мегу и сделал красивую шкурку получилось очень даже мило внешне :)

Вопросы можете задавать в комментариях.

Это очередной робоконструктор — механическая рука с пятью степенями свободы. Velleman Robotic Arm KSR10
Штука довольно редко встречающася, т.к. на Ebay я нашел всего одного продавца и в exUSSR эта редиска слать не желает. Встречается в нескольких буржуйских магазинах и вроде бы была в ЧиД, но оттуда была выкуплена нами :) Цена вопроса от 60…100 баксов.

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

Итак, это механика и только механика. Тут нет никакой электронной начинки. Вообще. Т.е. пять движков и простейшая тумблерная система управления вперед-назад.

Работает от батареек и имеет пульт с пятью рычажками.

По каждой степени свободы манипулятор вращается через редуктор с весьма большим передаточным числом. На глазок - не меньше чем 1:300. Редуктор червячно-цилиндрический, многоступенчатый. С трещеткой ограничителя момента.

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

А теперь подробней о содержимом. В большой красочной коробке лежат несколько литников с деталями редукторов.

Пакетики с винтами и шестернями

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

Под дружное веселье нашей компании, я снял небольшую видяшку о том как Андрей этой клешней пытался захватить за хвост нашу пивную закусь. В ходе пятиминутного грозного елозения клешней под дружные “Ать! Ыть! Ну же!” ему таки удалось, ага:

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

Очень нехватает одной степени свободы — поворот клешни вокруг своей оси. Это затрудняет возможность схватить что-либо. А так сделано все приятно и смотрится как готовый узел для развлекухи и добавить электронное управление и микроконтроллер было бы несложно, но существует тут одна большая проблема — отсутствие какой-либо обратной связи по положению. Т.е. манипулятор полностью слеп. Мы не можем определить ни его текущее положение, ни насколько он переместился под нашим воздействием. А значит управлять им в автоматическом режиме будет весьма сложно. Впрочем, на глазок, полости редуктора при наличии прямых рук позволяют запихать туда хотя бы оптический датчик на базе диска с прорезями. Или прикрутить хотя бы переменный резистор к валу — он является несущим и не вращается, а по диаметру соразмерен с валом резистора RS09. Так что сколхозить можно и выглядеть будет не сильно страшно. Тем более, что углы вращения составляют не более 300 градусов по самой подвижной оси.

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

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

З.Ы.
Плюс там была куча разных шасси причем некоторые от раритетных советских игрушек, а еще мне задарили убойную ОЗУ на магнитных доменах (радиационностойкую). Попробую ее раскачать и заюзать по приезду.
Следующая наша тусовка в Евпатории планируется в районе 25 числа.

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

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

DI HALT
Надумал тут замутить еще одну рубрику - Автоэлектроника

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

Пока выложу пробным камнем статью Владимира Крылова о работе инжекторных движков, дабы было общее впечатление о их работе.

Часть первая, обзорная. Общий принцип работы бензинового двигателя внутреннего сгорания

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

• Железки (ШПГ, КШМ, ГРМ)
• Система питания
• Система зажигания

Железки
Если в школе(и/или вузе) тебе было глубоко положить на термодинамику, циклы Карно и Отто, тепловые процессы и иже с ними, если капот ты открывал только с целью долить масла или другой жижи – просто набери в Википедии «поршневой двигатель». Там есть анимированные картинки, которые дадут общее представление о кинематике ДВС. Сразу оговоримся, мы будем говорить о четырехтактном бензиновом моторе -– двухтактники это архаично и неэкологично, а дизель – это гораздо сложнее для неспециалиста. Итак, железки – они в сборе выполняют функции:

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

-преобразование возвратно-поступательного движения поршня во вращательное - шатун, коленчатый вал. Тут тоже все сугубо железно.

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

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

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

Итак, что же нам нужно, чтобы запустить систему, которая так весело крутится на Википедии? Достаточно немного – раскрутить железки электромотором от аккумулятора, подать на впуск ПРАВИЛЬНУЮ горючую смесь, и в ПРАВИЛЬНЫЙ момент её, сжатую, поджечь. Поехали? Просто? Вроде бы да, да закавыка в том, что ПРАВИЛЬНЫЕ состав смеси и момент искрообразования для каждой комбинации «обороты-нагрузка-тепература-положение педали газа-еще куча параметров» - величины совершенно разные. А сильно отклоняться от ПРАВИЛЬНЫХ нельзя: тут тебе и мощность, и экономичность с экологичностью логарифмически быстро ухудшаются.

Вот где простор для современной вычислительной техники! Однако, когда компьютеры были большими, рулила аналоговая техника. Применительно к авто они назывались «карбюратор» и «контактная система зажигания». Я сравниваю эти два автоархаизма с арифмометром «Феликс» - железно, надежно при качественном изготовлении, но уж очень медленно, инерционно, и поэтому неточно.

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

Углубляться в прошлое и рассказывать про карбюраторы и контактное зажигание не буду – любопытный сам найдет, а мы представим что их никогда и не было, забудем как страшный сон, и перейдем к более современным Электронным Системам Управления Двигателем – для своих просто ЭСУД или для буржуев Engine Management System.

Все гениальное просто – механическая часть систем питания и зажигания современных ДВС, оборудованных ЭСУД, действительно проста. Как мы договорились выше, нам нужно дать мотору правильную смесь и в нужный момент поджечь.

Для этого мы засовываем в бензобак топливный насос который, в отличие от своего карбюраторного собрата, способен давать некислое давление (на моём Опеле до 6 очков, как-то мерял), и врезаем в топливопровод регулятор давления. Эта фигня жутко похожа на стабилизатор LM78xx – она пропускает нужные мотору 2-3 атмосферы в топливную рейку, а остальное отправляет обратно в бак.
Топливная рейка(она же рампа), чтоб ты знал – это такая трубка из нержавейки квадратная в сечении обычно, по одной из граней которой прорезаны отверстия под форсунки. Собственно форсунка – это маленький электромагнитный клапан с распылителем. Подали напругу - Соленоид втягивает подпружиненную иглу, которая выходит из своего конического седла, и открывает форсунку. А она, как ты помнишь вставлена одним концом в рейку, в которой, как ты надеюсь тоже не забыл, строго определенное давление. Соответственно из крошечных отверстий распылителя форсунки изрыгается факел тончайше распыленного топлива. И самое интересное –- не абы сколько этого топлива, а до микрограмма определенное. Давление-то постоянное, и расход топлива через форсунку за единицу времени мы знаем… Какой вывод? Замечательный –- этой темой могут рулить твои и мои любимые электронные «жучки»

Т.е. подавая на форсунку импульсы определенной ширины мы получаем впрыснутую дозу топлива, строго пропорциональную ширине поданного импульса. Таким образом мы с тобой познакомились с первым исполнительным устройством системы управления двигателем.
Но, как известно, чтобы получить что-то на выходе, надо иметь что-то и на входе. В самом деле-впрыснуть топлива мы теперь можем сколько захотим, а вот сколько надо захотеть? Тут самое время сделать еще одно физическое-лирическое отступление: о составе горючей смеси. Как ты уже понял, оная состоит из воздуха и топлива(в нашем случае бензина), причем топливо подразумевается в испаренном состоянии. Фишка здесь в том, что наибольшая теплота сгорания развивается при сжигании смеси с определенным составом – на одну массовую долю топлива надо 14.7 массовых долей воздуха.
При отклонениях туда-сюда в 10 процентов тоже горит, но не всегда оптимально, при дальнейших отклонениях начинает переставать воспламеняться. Выходит, для того, чтобы впрыснуть сколько надо топлива, надо знать сколько мы засосали воздуха. Карбюратор не знал, он оперировал непосредственно законом Бернулли, за что был списан на задворки истории, а вот нам непременно надо. Для этого познакомимся с первым датчиком – массового расхода воздуха (ДМРВ). Раньше для замера массы входящего воздуха во впускном канале устанавливалась подпружиненная заслонка, ось которой была связана с потенциометрическим датчиком. Недостатки долго объяснять не надо – много механики, инерционная тяжелая заслонка, стирающееся покрытие дорожки потенциометра(ужас любого электронщика и аудиофила) – в общем у меня на машине такой, но ей уже 18 лет.

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

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

Подали на первичку 12 вольт постоянки – накопили энергию. Потом разрываем первичную цепь – великая и ужасная электромагнитная индукция наводит на вторичке требуемое высокое напряжение. Оно пробивает воздушный зазор на свече – и смесь нужной консистенции, которую мы с тобой засосали в цилиндр и сжали на первом «туда-сюда» рабочего цикла, благополучно воспламеняется.

Тут лирическое отступление. Я как человек, вкуривший-таки (хоть и в достаточно зрелом возрастеJ) в термодинамику, не люблю, когда говорят, что смесь в цилиндре «взрывается». Взрываться – слишком общее слово, взрывы могут происходить с участием не только процесса горения, но всяких там цепных ядерных реакций, термоядерных синтезов, гидроударов т.п. И лексика слова «взрыв» - оно однокоренное слову «рвать». И действительно – то, что взывается, обычно имеет оболочку, которая и рвется, у нас же в ее роли стенки цилиндров, которые остаются целыми и невредимыми. Так что я и книжки предпочитаем говорить, что смесь сгорает. И это действительно так – сгорая, нагревает теплотой сгорания газы, которые при сгорании образуются (а там безвредные CO2 и H2O, а также ужасные CO, CH, Nox, с которыми нужно бороться).

Газы, как им положено, при этом расширяются и давят на поршень, который на втором «чих-пых» рабочего цикла отдает механическую энергию вращающейся системе (там еще есть на одном конце коленвала круглая фигня, похожая на блин от штанги с зубчатым венцом по краю – маховик – он запасает энергию на рабочем ходу и отдает на прочих ходях поршня – получаем плавный ход).
Ну и напоследок еще одним ходом вверх при открытом выпускном клапане поршень выбрасывает газы наружу (в современных авто через специальный очиститель), загрязняя нашу многострадальную атмосферу. Цикл повторяется раз за разом, и оно крутится!
Но крутится пока только у нас в уме – поджечь-то мы подожгли, а вот в нужный ли момент? Фишка в том, что время сгорания определенной порции смеси – величина условно постоянная, а вот при разных оборотах мотора время цикла, разумеется, меняется. А еще, в идеальном случае сила давления на поршень должна появляться в момент, когда он пройдет свою верхнюю точку и только-только начнет движение вниз. Но если мы подадим искру в этот самый момент – пока смесь будет разгораться, пока начнет отдавать свое тепло газам – поршень уже уйдет чуть вниз, а когда дойдет до низа, у нас еще вовсю будет гореть смесь, которая уже должна быть отработанными газами.
Короче часть энергии – просто на ветер, а еще температура выпускного тракта поднимается, и еще есть негативные последствия. Стало быть, поджигать надо чуть раньше. Вот мы и подобрались к еще одной важнейшей количественной мере теории ДВС – углу опережения зажигания. Это угол по коленвалу между его положением в верхней мертвой точке и положением в момент подачи искры. Чем выше обороты, тем раньше надо поджечь, чтобы успело разгореться, тем больше соответственно угол. Выходит, нам с тобой надо знать положение коленвала в каждый момент времени.
И тут снова приходит на помощь наша любимая электроника. Вешаем на коленвал диск с зубчиками по краям, неподвижно у края диска закрепляем датчик (может быть датчиком Холла, индуктивным, да хоть оптическим). В простом случае хватает 60 зубчиков. При вращении коленвала датчик будет вырабатывать электрический сигнал (прямоугольный, синус, зависит от типа датчика). И самая главная хитрость – в одном или нескольких местах по окружности нашего диска убираем один зуб – теперь мы можем засечь КОНКРЕТНОЕ положение коленвала а дальше отсчитывать угол по импульсам датчика. Теперь мы поджигаем смесь не когда попало, а с нужным углом опережения. Больше оборотов – раньше генерим искру, меньше – позже. А что же происходит, когда давишь на газ? Элементарно – даешь мотору больше воздуха.
Мы не зря пошли плясать именно от воздуха – цепочка начинается с него. Больше воздуха измерили – больше впрыснули топлива – больше энергии выделилось – обороты увеличились(либо при тех же оборотах работаем на бОльшую нагрузку). Для регулирования потока воздуха поставим на его пути канал круглого сечения (называется дроссельный патрубок)и перекроем его круглым диском, надетым на ось, совпадающую с линией его диаметра так, что на этой оси он может поворачиваться. Поворачивая диск на оси регулируем поток воздуха – вуаля! Называется этот диск дроссельной заслонкой, управляется механически от педали газа, либо электронно (датчик на педали, исполнительный шаговик с датчиком положения на заслонке).
Вот так, в первом приближении оно все и работает. Знакомиться плотнее с системой управления, датчиками и исполнительными устройствами будем далее. Ждите новых материалов, задавайте вопросы, буду стараться отвечать.

Паять я люблю, а ещё больше я люблю делать подарки людям, а что может быть лучше действительно полезного подарка?
Но, поскольку с PIC-ами я не дружу, то пульт я переделал под маленькую tiny2313, благо их везде навалом, и они весьма недорогие. Плюс, хотелось поставить рекорд скорости по сборке устройства.

Братство Кольца
Немного теории, найденной на просторах интернета:
для фотоаппаратов марки Canon собирается пульт RC-1 (RC-5 это такой же пульт, только без “моментального спуска”)

-Несущая частота 33 кГц:
-команда “Спуск”: посылка 480 мкс, пауза 7324 мкс, посылка 480 мкс
-команда “Спуск с 2 сек. задержкой”: посылка 480 мкс, пауза 5371 мкс, посылка 480 мкс

Важно!
Не у всех фотоаппаратов Canon есть ИК приёмник (обычно расположен на ручке, под спусковой кнопкой). Смотрите инструкцию к своему фотоаппарату!

Nikon выбрал себе алгоритм похитрее, но всё равно мы и его скопируем:

-Несущая частота 40 кГц:
-команда “Спуск”: посылка 2250 мкс, пауза 27600 мкс, посылка 650 мкс, пауза 1375 мкс, посылка 575 мкс, пауза 3350 мкс, посылка 650 мкс. Потом пауза в 63 мс (милли- не микро-!!!) и повтор всей последовательности еще один раз

Интернет-народ утверждает, что лучше всего выбирать светодиоды с длиной волны 940 нм, я поверил им на слово.
Самые дешевые светодиоды оказались SFH415-U, на 1.3-1.5 вольта и 100 мА, поэтому была выбрана таблеточная трёхвольтовая батарейка и последовательное соединение светодиодов.
Для тактирования тини2313 я, естественно, использовал внутренний RC осциллятор на 1 Мгц.

Для экономии батарейки питание на микроконтроллер подается только при нажатии на кнопку спуска, после чего пульт отрабатывает посылку и отправляется в sleep (на случай если в сумке что-нибудь надавит на кнопку, батарейка не сдохла до съемки).

Две твердыни
Ну что же, время составить схемку и написать программку.

Схемка для Никона:

не отличается чем-либо особым. Конденсатор С2 выбран танталовым потому, что у него оооочень маленький ток утечки, поэтому батарейке ничего не должно грозить (кстати, этот пульт используется уже в течении года).

Схемка для Кэнона:

Тут уже повеселее. Я решил выбрать переключатель на три позиции, тем самым у меня появилось три “режима”:

• Выключен, чтобы при случайном нажатии на кнопку не садить батарейку.
• Спуск с 2сек задержкой - чтобы при фотографировании себя успеть убрать пульт из кадра.
• Немедленный спуск - отлично использовать для фотоохоты. Или фотографирования ночных пейзажей. Или для режима Bulb.

Естественно, при желании можно выкинуть переключатель, и использовать просто две кнопки, например так:

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

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

Программа написана на С (для ускорения времени разработки и простоты вычисления задержек)
Код для Никона:

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
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

#include <avr/io.h>
#include <avr/sleep.h>
#include <util/delay.h>
 
#define led_port PORTD
#define led_ddr DDRD
#define led_pin (1<<6);
 
#define nop() asm("nop")
//Посылка двух импульсов, количество нопов выверено в симуляторе
#define two_pulses {led_port |= led_pin; nop(); nop(); nop(); nop(); nop(); nop(); nop(); nop();
nop(); nop(); nop(); led_port &= ~led_pin; nop(); nop(); nop(); nop(); nop(); nop(); nop(); 
nop(); nop(); nop(); led_port |= led_pin; nop(); nop(); nop(); nop(); nop(); nop(); nop(); nop();
nop(); nop(); nop(); led_port &= ~led_pin; nop(); nop(); nop(); nop(); nop(); nop(); } //50 us
 
//Весь алгоритм передачи команды, ничего сверхъестественного
void program (void)
{
	unsigned char i;
	for (i = 0; i < (2250/50); i++)
		two_pulses;
	_delay_ms(27.6);
	for (i = 0; i < (650/50); i++)
		two_pulses;
	_delay_ms(1.35);
	for (i = 0; i < (600/50); i++)
		two_pulses;
	_delay_ms(3.35);
	for (i = 0; i < (650/50); i++)
		two_pulses;
 
	_delay_ms(63);
 
	for (i = 0; i < (2250/50); i++)
		two_pulses;
	_delay_ms(27.6);
	for (i = 0; i < (650/50); i++)
		two_pulses;
	_delay_ms(1.35);
	for (i = 0; i < (600/50); i++)
		two_pulses;
	_delay_ms(3.35);
	for (i = 0; i < (650/50); i++)
		two_pulses;
}
 
int main (void)
{
	MCUCR |= (1<<SM0); //PowerDown
	ACSR |= (1<<ACD); //AnaComp Disable
	led_ddr |= led_pin;
	_delay_ms(8);
	program();
	sleep_enable();
	sleep_cpu();	//Усыпляем до следующего включения питания	
}

А это для Кэнона:

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
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

#include <avr/io.h>
#include <avr/sleep.h>
#include <util/delay.h>
 
//Leds port:
#define led_port PORTD
#define led_ddr DDRD
#define led_pin 6
#define led_one (1<<led_pin)
#define led_all (1<<led_pin)
 
//Delay 2 sec
#define pin_delay (1<<0) //PortB pin0 //for delay
#define all_button_pins pin_delay
 
#define nop() asm("nop")
 
//Функция, которая отправляет одну посылку
void Post (char bits_to_set)
{
	unsigned char i;
	for (i = 0; i < 16; i++)
	{
		led_port |= bits_to_set;
		nop(); 
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
 
		led_port &= ~bits_to_set;
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop();
		nop(); //Количество нопов высчитано в симуляторе
	}
 
}
 
//Немедленный спуск
void Shutter (char led)
{
	Post(led);
	_delay_ms(7.324);
	Post(led);
}
 
//Спуск с двух секундной задержкой
void Shutter2 (char led)
{
	Post(led);
	_delay_ms(5.371);
	Post(led);
}
 
int main (void)
{
	PORTB |= all_button_pins; //PullUp
	led_ddr |= led_all; // DDR out
	MCUCR |= (1<<SM0); //PowerDown
	ACSR |= (1<<ACD); //AnaComp Disable
	for(;;)
	{
		_delay_ms(8); //Debounce
		if (PINB&pin_delay)//Проверяем состоние пина
		{
			Shutter2(led_one);
		}
		else
		{
			Shutter(led_one);
		}
 
		sleep_enable();
		sleep_cpu(); //Усыпляем до следующего включения питания
	}	
}

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

Возращение государя
Конечно же, самое интересное — это корпус.

Для Никона, с его единственной кнопкой, подошел вот такой:

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

А вот для Кэнона корпус я делал недавно, поэтому парочка фоток есть :)

Рассыпуха деталек для будущего пульта:

С платой замарачиваться не стал, тем более корпус всего-то 50х30х20 мм, поэтому микрушку и всякие транзюки понапаял на макетку, дрелью да напильником сделал необходимые отверстия, переключатель посадил на клей, распаял паутинку проводов:

Корпус оказался ооочень маленький, так что влезло всё впритык. Прижав коленкой закрутил винтики, и вот что получилось:

Результатом доволен и я, и те кому достался пультик. А на написание этой статьи ушло примерно столько же времени, сколько на изготовление одного пультика :)

Проект в AVR Studio

Если у вас какой-либо другой фотоаппарат, то то в статье от sappa есть алгоритмы и для них. Дерзайте, творческих (в пайке и в фотографии) успехов вам!

Bonus:
Ну и вот вам, бонусом, идея для корпуса кухонных часов. Со стратегическим запасом гречки на черный день.

Пользоваться им проще простого — в любой момент, когда нам это захочется, мы берем и отправляем нужный байт по этому интерфейсу. При этом достаточно заранее его настроить — стандартная инициализация 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

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

Для отправки надо записать наше маркерное число в регистр UDR, пусть это будет код буквы “А”.

1
2

	LDI	R16,'A'
	OUT	UDR,R16

Я даже проверку на занятость UDR не делаю. Для одиночного байта, если у нас отправки по UART нет и участок не зациклен, этого вполне достаточно — регистр будет свободен. Разумеется в реальной программе такого делать не следует, но для отладочной затычки вполне сойдет.

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

1
2
3
4

	LDI	R16,'A'
	SBIS 	UCSRA,UDRE		; Пропуск если нет флага готовности
	RJMP	PC-1 			; ждем готовности - флага UDRE
 	OUT	UDR, R16		; шлем байт

Можно в макрос это запихать:

1
2
3
4
5
6
7
8

	.MACRO	DEB_SEND
	PUSH	R16
	LDI	R16,@0
	SBIS	UCSRA,UDRE
	RJMP	PC-1
	OUT	UDR,R16
	POP	R16
	.ENDM

Заодно R16 в стеке спрячем, так что макрос можно юзать где угодно, словно команду:

1

	DEB_SEND 'A'

Но это затормозит выполнение программы, могут полететь тайминги. Так что если у вас есть какие то участки жестко зависимые от времени (скажем тайминги протокола 1-wire), то данная затычка даст сбой.

Выводить можно любую инфу. Например содержание нужных регистров, содержание переменных, ячеек памяти, состояния битов регистров периферии. Что хотим поглядеть — то и тащим. Надо только загрузить это в UDR. А поскольку там могут быть произвольные значения, то глядеть их лучше через терминалку способную показывать в хексах. Например, моя любимая Terminal v1.9b.

Также полезно выбрасывать в терминал маркеры прохождения кода. Чтобы оценить правильность переходов и логики работы.

Еще настоятельно рекомендую заиметь спец литеру отправляемую в терминал сразу же после инициализации USART, еще до перехода к основной программе. У меня это обычно буква “R”. От “Reset”. Это позволяет поймать момент перезагрузки контроллера.

Например, глючила у меня программа. Все работало нормально, но при попытке принять байт все начинало странно глючить. Все облазил, код весь до дыр проглядел. По коду все должно работать… Наконец воткнул в код OUTI UDR,’R’ еще до вхождения в main. Опаньки — а контроллер то сбрасывается!

А почему контроллер может сбрасываться? Сбой по питанию я исключил сразу — не было там ничего такого, что бы могло дергаться. RESET был подтянут через 10кОм и особо тоже не вихлялся. Что еще?

Срыв стека, если произошел переход за конец кода, тоже похож на сброс — программа уходит за конец памяти и возвращается к нулевому адресу. Прошарил в отладчике и этот момент — нет срыва. Но может срыв не сразу, а спустя несколько итераций? Поставил .ORG на предпоследний адрес флеша и прописал туда маркер — не вылазит, значит срыва стека нет.
Да и код был прост как мычание, нечему там глючить. Накидал отладочных маркеров по коду, засылающих байты в строго определенном порядке — в терминалке высветилась фраза “УБЕЙ СИБЯ АПСТОЛ” — значит прога работает четко по алгоритму.

Заглянул под панельку… Вот в чем засада — медная ворсинка от провода МГТФ попала между RXD и RST (На меге8 они совсем рядом) и при приходе байта в порт дрыганья на RXD сбрасывали контроллер. Соблюдайте чистоту на рабочем месте! Не допетри я тогда поставить на перезагрузку маркер, так я бы до утра ковырялся с кодом. А так я резко сузил круг возможных косяков и ушло не более десяти минут на отлов этого бага.

Управление кодом, добыча произвольных данных
Но не едиными маркерами сыт боец USART’овой отладки.

Мы же можем не только слать, но и принимать! А принятое обрабатывать! Так что нам мешает делать полноценные брейкпоинты?

Скажем, такие:

1
2
3
4
5

	PUSH	R16
	SBIS	UCSRA,RXC
	RJMP	PC-1
	IN	R16,UDR		; Читаем UDR, чтобы сбросить RXC флаг
	POP	R16

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

В сочетании с маркерами дает еще и информацию о том, где мы встали. Но можно же и большее заиметь!

Что нам мешает сделать небольшой обработчик команд? Скажем, если мы послали R - выдаст значение нужного регистра, если М - ячейки памяти, I - байта из IO, а G - пойдет дальше:

Пример макроса может быть таким:

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
32
33
34
35
36
37
38
39

	.MACRO	DEB_CMD
	PUSH	R16		; Сохраняем регистр и флаги в стек
	IN	R16,SREG
	PUSH	R16
 
	SBIS	UCSRA,RXC
	RJMP	PC-1
	IN	R16,UDR		; Читаем UDR, чтобы сбросить RXC флаг
 
				; Определяем что там пришло
	CPI	R16,'R'
	BREQ	PC+0x07		; BREQ REGISTER
 
	CPI	R16,'M'
	BREQ	PC+0x07		; BREQ	MEMORY
 
	CPI	R16,'I'
	BREQ	PC+0x09 	; BREQ	IO
 
	CPI	R16,'G'
	BREQ	PC+0x0A		; BREQ GONEXT
 
 
	OUT	UDR,@0		; REGISTER - отправляем в UDR значение регистра
	RJMP	PC+0x0008	; Проверка на пустоту UDR тут скорей всего не нужна.
				; Т.к. пока впечатаешь ручкам в терминалку байт, наверняка 
				; все что хотело уйти уже уйдет и UDR опустошится.
 
	LDS	R16,@1		; MEMORY - шлем значение из памяти
	OUT	UDR,R16
	RJMP	PC+0x0004
 
	IN	R16,@2		; IO - шлем значение из порта ввода-вывода.
	OUT	UDR,R16
 
	POP	R16		; GONEXT - достаем все сохраненное из стека и идем дальше
	OUT	SREG,R16
	POP	R16
	.ENDM

Как видишь, макрос массово использует относительные переходы (иначе при вставке двух макросов метки будут дублироваться). Так что модифицировать его нужно очень осторожно. Высчитывая команды. Но есть спрособ проще - написать его вначале с обычными метками, скомпилить, запустить отладку, потом открыть дизассемблер (view->disassembler) и поглядеть там смещения.

Используется просто — вставляешь в код такую штуку:

1

	DEB_CMD R15,0x0000,PORTD

И при попадании в это место МК остановится и будет ждать приказа. По команде G - пойдет дальше. По команде R - даст содержание регистра R15, по команде M - содержание ячейки ОЗУ с адресом 0х0000, а по команде I - значение из порта PORTD. Порты, регистры, ячейки памяти вписываешь те которые хочешь посмотреть. Если нужно что то одно, то пишешь в ненужные поля любые подходящие значения. Ну или делаешь узкоспециализированные макросы под память, регистр и порт ВВ.

Можно еще прерывания запретить, чтобы стопор был полный, но не забывай, что всякие таймеры продолжают тикать самостоятельно вне зависимость от того работает МК или зациклен в ожидании команды. А еще, если включен WATCHDOG, то он может и за задницу укусить. Поэтому в макрос можно и команду WDR добавить, в цикл ожидания байта.

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

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

Оставляю это на самостоятельное изучение :)

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

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

Перебирая разные системы, наткнулся на MicroMenu:

Попробуем разобрать ее на части и прикрутить к системе.

Структура данных:
Меню организовано в виде четырехсвязного списка. Каждый элемент меню (пункт меню) ссылается на предыдущего и последующего элемента, также ссылается на своего родителя (пункт меню предыдущего уровня) и потомка (пункт подменю). Если это первый пункт, то предыдущего элемента у него нет, соответствующая ссылка пустая.

Изобразим это на рисунке:

Для чего такая избыточность? По сути, с текущим пунктом меню можно сделать четыре вещи:

• Перейти вверх или вниз (предыдущий или следующий пункт)
• Вернуться в родительское меню (если есть)
• Выбрать текущий пункт. При этом мы или переходим в подменю (ели оно есть), или выполняется команда, прикрепленная к этому пункту меню.

При наличии джойстика (или четырех кнопок «крестом») эти действия как раз вешаются на свою кнопку.

Соответственно, все эти действия отражают четыре указателя. В оригинальной системе указатель на потомка обозван SIBLING, но я считаю это идеологически неверным. Sibling – это родственник того же уровня. Брат или сестра. Но никак не потомок. Поэтому мы будем использовать идеологически выверенное CHILD.

Итак, описание структуры пункта меню:

1
2
3
4
5
6
7
8

typedef struct PROGMEM{
	void       *Next;
	void       *Previous;
	void       *Parent;
	void       *Child;
	uint8_t     Select;
	const char  Text[];
} menuItem;

Добавлен байт Select – это код команды, привязанный к текущему пункту. Если у данного пункта есть подменю, код нулевой. Также есть поле Text. Капитан Очевидность подсказывает, что это, собственно, текст пункта меню. По расходам памяти — на каждый пункт меню расходуется 9 байт плюс длина текстовой части. И это все — кладется во флеш.

Самое полезное, почерпнутое у MicroMenu – набор дефайнов для быстрого и удобного определения меню.

1
2
3
4
5
6

#define MAKE_MENU(Name, Next, Previous, Parent, Child, Select, Text) \
	extern menuItem Next;     \
	extern menuItem Previous; \
	extern menuItem Parent;   \
	extern menuItem Child;  \
	menuItem Name = {(void*)&Next, (void*)&Previous, (void*)&Parent, (void*)&Child, (uint8_t)Select, { Text }}

В чем пафос такой конструкции? Для того, чтобы определить текущий элемент, нам надо указать ссылку на следующий, еще не известный компилятору. Поэтому этот дефайн создает заведомо избыточное количество описаний extern. Это означает, что такой идентификатор будет где-то описан, не обязательно в этом же файле. В качестве бонуса это позволит растащить меню по нескольким файлам, если вдруг возникнет такое неудовлетворенное желание.

Теперь самое интересное: описание структуры меню, как на рисунке.

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
32
33
34
35

// для начала — пустой элемент. Который NULL на рисунке
#define NULL_ENTRY Null_Menu
menuItem	Null_Menu = {(void*)0, (void*)0, (void*)0, (void*)0, 0, {0x00}};
 
enum {
    MENU_CANCEL=1,
    MENU_RESET,
    MENU_MODE1,
    MENU_MODE2,
    MENU_MODE3,
    MENU_SENS1,
    MENU_SENS2,
};
 
//                 NEXT,      PREVIOUS     PARENT,     CHILD
MAKE_MENU(m_s1i1,  m_s1i2,    NULL_ENTRY,  NULL_ENTRY, m_s2i1,       0, "Запуск");
MAKE_MENU(m_s1i2,  m_s1i3,    m_s1i1,      NULL_ENTRY, m_s3i1,       0, "Настройка");
MAKE_MENU(m_s1i3,  NULL_ENTRY,m_s1i2,      NULL_ENTRY, NULL_ENTRY,   MENU_RESET, "Сброс");
 
// подменю Запуск
MAKE_MENU(m_s2i1,  m_s2i2,    NULL_ENTRY,  m_s1i1,     NULL_ENTRY,   MENU_MODE1, "Режим 1");
MAKE_MENU(m_s2i2,  m_s2i3,    m_s2i1,      m_s1i1,     NULL_ENTRY,   MENU_MODE2, "Режим 2");
MAKE_MENU(m_s2i3,  NULL_ENTRY,m_s2i2,      m_s1i1,     NULL_ENTRY,   MENU_MODE3, "Режим 3");
 
// подменю Настройка
MAKE_MENU(m_s3i1,  m_s3i2,    NULL_ENTRY,  m_s1i2,     m_s4i1,       0, "Давление");
MAKE_MENU(m_s3i2,  NULL_ENTRY,m_s3i1,      m_s1i2,     m_s5i1,       0, "Время");
 
// подменю Давление
MAKE_MENU(m_s4i1,  m_s4i2,    NULL_ENTRY,  m_s3i1,     NULL_ENTRY,   MENU_SENS1, "Датчик 1");
MAKE_MENU(m_s4i2,  NULL_ENTRY,m_s4i1,      m_s3i1,     NULL_ENTRY,   MENU_SENS2, "Датчик 2");
 
// подменю Время
MAKE_MENU(m_s5i1,  m_s5i2,    NULL_ENTRY,  m_s3i2,     NULL_ENTRY,   MENU_WARM, "Разогрев");
MAKE_MENU(m_s5i2,  NULL_ENTRY,m_s5i1,      m_s3i2,     NULL_ENTRY,   MENU_PROCESS, "Процесс");

Готово!

Естественно, пункты меню можно описывать и вперемешку, в порядке обхода дерева. Типа такого:

1
2
3
4
5
6

MAKE_MENU(m_s1i1,  m_s1i2,    NULL_ENTRY,  NULL_ENTRY, m_s2i1,       0, "Запуск");
    // подменю Запуск
    MAKE_MENU(m_s2i1,  m_s2i2,    NULL_ENTRY,  m_s1i1,     NULL_ENTRY,   MENU_MODE1, "Режим 1");
    MAKE_MENU(m_s2i2,  m_s2i3,    m_s2i1,      m_s1i1,     NULL_ENTRY,   MENU_MODE2, "Режим 2");
    MAKE_MENU(m_s2i3,  NULL_ENTRY,m_s2i2,      m_s1i1,     NULL_ENTRY,   MENU_MODE3, "Режим 3");
MAKE_MENU(m_s1i2,  m_s1i3,    m_s1i1,      NULL_ENTRY, m_s3i1,       0, "Настройка");

Можно даже пойти дальше — строить меню в какой-нибудь визуальной среде, а потом автоматически генерировать такой список. Но это на потом.

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

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

Дальше. Как ходить по меню. Автор предлагает несколько дефайнов. Я их сохранил, хотя можно и без них обойтись.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#define PREVIOUS   ((menuItem*)pgm_read_word(&selectedMenuItem->Previous))
#define NEXT       ((menuItem*)pgm_read_word(&selectedMenuItem->Next))
#define PARENT     ((menuItem*)pgm_read_word(&selectedMenuItem->Parent))
#define CHILD      ((menuItem*)pgm_read_word(&selectedMenuItem->Child))
#define SELECT	    (pgm_read_byte(&selectedMenuItem->Select))
 
menuItem* selectedMenuItem; // текущий пункт меню
 
void menuChange(menuItem* NewMenu)
{
	if ((void*)NewMenu == (void*)&NULL_ENTRY)
	  return;
 
	selectedMenuItem = NewMenu;
}

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

1

menuChange(PREVIOUS);

Далее, процедура реакции на нажатие клавиш (в качестве параметра передается код нажатой клавиши):

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
32
33
34
35
36
37
38

uint8_t keyMenu(msg_par par) {
	switch (par) {
	case 0: {
		return 1;
	}
	case KEY_UP: {
		menuChange(PREVIOUS);
		break;
	}
	case KEY_DOWN: {
		menuChange(NEXT);
		break;
	}
	case KEY_RIGHT:
		;
	case KEY_OK:
		{ // выбор пункта
			uint8_t sel;
			sel = SELECT;
			if (sel != 0) {
				sendMessage(MSG_MENU_SELECT, sel);
 
				killHandler(MSG_KEY_PRESS, &keyMenu);
				killHandler(MSG_DISP_REFRESH, &dispMenu);
 
				return (1);
			} else {
				menuChange(CHILD);
			}
			break;
		}
	case KEY_LEFT: { // отмена выбора (возврат)
		menuChange(PARENT);
	}
	}
	dispMenu(0);
	return (1);
}

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

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
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

char* menuText(int8_t menuShift)
{
	int8_t i;
	menuItem* tempMenu;
 
	if ((void*)selectedMenuItem == (void*)&NULL_ENTRY)
	  return strNULL;
 
	i = menuShift;
	tempMenu = selectedMenuItem;
	if (i>0) {
		while( i!=0 ) {
			if ((void*)tempMenu != (void*)&NULL_ENTRY) {
				tempMenu = (menuItem*)pgm_read_word(&tempMenu->Next);
			}
			i--;
		}
	} else {
		while( i!=0 ) {
			if ((void*)tempMenu != (void*)&NULL_ENTRY) {
				tempMenu = (menuItem*)pgm_read_word(&tempMenu->Previous);
			}
			i++;
		}
	}
 
	if ((void*)tempMenu == (void*)&NULL_ENTRY) {
		return strNULL;
	} else {
		return ((char *)tempMenu->Text);
	}
}
 
unsigned char dispMenu(msg_par par) {
	char buf[25];
 
	LCD_clear();
 
	sprintf_P(buf, PSTR(">%-20S"), menuText(0));
	LCD_putsXY(2, 28, buf);
 
	sprintf_P(buf, PSTR("%-20S"), menuText(-2));
	LCD_putsXY(2, 8, buf);
 
	sprintf_P(buf, PSTR("%-20S"), menuText(-1));
	LCD_putsXY(5, 17, buf);
 
 
	sprintf_P(buf, PSTR("%-20S"), menuText(1));
	LCD_putsXY(5, 39, buf);
 
	sprintf_P(buf, PSTR("%-20S"), menuText(2));
	LCD_putsXY(2, 48, buf);
 
	LCD_drawLine(0, 26, 127, 26, 1);
	LCD_drawLine(0, 34, 127, 34, 1);
 
	return (1);
}

И последний штрих — инициализация меню:

1
2
3
4
5
6
7

void startMenu(void) {
	selectedMenuItem = (menuItem*)&m_l1i1;
 
	dispMenu(0);
	setHandler(MSG_KEY_PRESS, &keyMenu);
	setHandler(MSG_DISP_REFRESH, &dispMenu);
}

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

Краткое описание того, что делает процедура setHandler - она привязывает обработчик к событию. В данном случае, при возникновении события MSG_KEY_PRESS вызовется функция keyMenu для обработки этого события.

Для демонстрации системы меню, описанной в предыдущем посте, собрал модель в протеусе. На базе двухстрочного LCD-индикатора, контроллераatmega32 и пяти кнопок (влево-вправо-вверх-вниз и выбор). В своих схемах использую джойстики от мобилок, они тоже пятипозиционные. Также воткнул три светодиода, чтобы хоть как-то реагировать на выбор пунктов меню.

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

Обработка меню:

• при выборе пунктов Start/Mode 1, Start/Mode 2, Start/Mode 3 загорается соответствующий светодиод
• при выборе пункта Reset - все светодиоды гаснут
• после выбора любого конечного пункта, возвращаемся обратно в корень меню.

Некоторые модификации, связанные с моделированием:

• заменил весь текст на английский, потому что в оригинале модель экранчика не поддерживает русский язык. Да, я знаю, про замену dll, но не у всех она есть, а для просмотра - пойдет.
• моя боевая библиотека работы с LCD почему-то отказалась работать с моделью. Поэтому взял какую-то первую попавшуюся из древнего проекта.
• отключил автоповтор кнопок (на модели неудобно работать), но он есть

Ну и, надеюсь, мне простят подключение светодиодов без балластного резистора? ;)

Файлы к статье

• Исходники
• Файлы для Proteus