Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1
Подождите немного. Документ загружается.
59
60
61
62
_delay_ms(1000);
LED_PORT=1<<LED1;
_delay_ms(1000);
}
}
Если грузануть его в Pinboard, предварительно подключив USART к FT232 и
законнектиться терминалкой, то будет мигать наш LED4, а в терминалку от-
стреляются байты ASCII кодов нашей строки. В это же время будет
неторопливо тикать наш цикл с мигалкой.
Ну и, как всегда, пример кода в архиве.
Виртуальная машина и байт код
Часто требуется делать большие последовательности сложных операций —
например полетное задание для робота. Да, можно запихать все это дело в
основную программу, но вдруг что-то пойдет не так как надо и алгоритм
надо будет переделать — придется переделывать всю программу.
Тут на помощь придет виртуальная машина. Суть в чем — в памяти
контроллера, в основную программу, занесены основные процедуры
управления устройством. Если это робот, то это могут быть такие простые
команды как “вперед”, “назад”, “повернуть” и так далее.
Дальше мы увязываем это все в таблицу переходов, где у каждой команды
будет номер-смещение.
Потом нам нужен обработчик скриптов, который бы брал откуда нибудь,
нашу последовательность действий — скрипт и преобразовывал это в вызовы
реальных кусков кода -микрооперации.
Обработчик скриптов может быть той же самой задачей диспетчера,
запущенной фоном. А откуда он будет брать данные неважно. Их вполне
можно засасывать по usart или тащить из EEPROM памяти. А можно загнать
на IIC память и получится сменный картридж :)
В простейшем случае, обработчик скрипта хватает байт-код из источника и
сразу же заправляет его на конвейер, где микрооперация выполняется также
как и обычная задача. А чтобы очередь диспетчера не переполнялась можно
сделать так, чтобы новая партия байт-кода бралась только тогда, когда
прожуется первая. Для этого достаточно, чтобы обработчик скрипта
запускался по завершении каждой микрооперации.
В более продвинутой системе в байткоде могут быть и переменные. Тогда
обработчик скрипта должен анализировать код, хотя бы по свитчу.
Например, есть у нас такая система команд:
•
0х00 выключить периферию
•
0х01 включить периферию
•
0х02,0хZZ поднять манипулятор на ZZ попугаев.
•
0×03,0xYY повернуть манипулятор на YY слонят.
•
0×04 открыть зажим
•
0х05 закрыть зажим
Тогда алгоритм хватания и переноса в нулевую позицию ящика стоящего на
высоте в 10, под углом 15. Будет в источнике кода (ЕЕПРОМ или вообще что
угодно) будет выглядеть примерно таким образом:
1
01, 02,10, 03,15, 04, 02,-10, 05, 02,10, 03,-15, 02,-10, 04, 00
Всего 17 байт на довольно сложное действие. Обрабатывать его можно будет
примерно таким способом.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
script_loader(void)
{
Byte_op=current_chain[i] // Берем код команды
switch(Byte_op)
{
case 0x02: // Если у ней есть аргументы
case 0x03: // То в зависимости от типа команды делаем переход
{
SetTask(Byte_op); // Сразу грузим команду на конвейер
i++; // Берем аргумент
Param_REG = current_chain[i]; // Грузим его в регистр
аргументов
} // Откуда задаче будет его
удобно взять
break;
default: // Если команда не имеет аргументов
{
SetTask(Byte_op) // Просто бросаем ее на конвейер.
Param_REG = 0; // А регистровый параметр
зануляем
} // Хотя это и не обязательно
}
i++;
// Переводим указатель на следующую команду
}
Сейчас операнды байт-кода выполняются последовательно. НО! Никто не
мешает сделать доп аргумент разрешающий выполнять их и одновременно
(кооперативно, разумеется, но никто не мешает побить ту же микрооперацию
на подзадачи которые можно перемешать в конвейере).
И тогда, например, команды подъема и поворота могут быть указаны
следующим образом:
•
0х00 выключить периферию
•
0х01 включить периферию
•
0х02,0хZZ,0хMM поднять манипулятор на ZZ попугаев. Поставить MM
код многозадачности
•
0×03,0xYY,0хMM повернуть манипулятор на YY слонят. Поставить
MM код многозадачности
•
0×04 открыть зажим
•
0х05 закрыть зажим
Что такое код многозадачности? Ну это я только что, экспромтом, придумал.
Некий флаговый байт в памяти содержащий код, который показывает, что
текущая задача может допускать параллельное выполнение других задач, а
также свой собственный код.
При этом, управление обработчику скриптов отдается сразу же (если MM не
нулевой) и следующая задача, забрасываемая в конвейер, проверит код
многозадачности и если он не конфликтует с ней (понятно, что повернуть
одновременно на разные углы нельзя или есть ограничения механического
плана) — пихается на конвейер в нагрузку к первой.
Конечно, тут еще надо проверять кучу разных условий, думать как хранить
коды многозадачности операций и вообще все несколько сложней, чем
кажется на первый взгляд. Но общая концепция, думаю, ясна. А детали уже
вылезут по ходу реализации.
Вот таким нехитрым образом, увязав диспетчер с обработчиком скриптов мы
получаем действующую виртуальную машину, со своим языком, своим байт
кодом. Получаем полностью отвязанные от железа алгоритмы устройств.
А поскольку байт код может быть где угодно, хоть в ОЗУ, то это открывает
нам широчайший простор для создания полиморфических и
самообучающихся алгоритмов =).
Предлагаю коллективным разумом на форуме сгенерировать ROBO-API на
подобном байткоде. По крайней мере сформулировать список команд,
синтаксис инструкций. А тут, в комментах, обсуждения самого подхода.
P.S. Диспетчер, рассмотренный в прошлых статьях Архитектуры Программ
курса AVR для этих целей не очень годится, т.к. конвейер там основан на
указателях, а не на таблице переходов (хотя никто не мешает сделать там и
таблицу переходов, прям в задаче скрипт лоадера). А вот, диспетчер из цикла
статей по ассемблерной RTOS, вполне на эту роль пойдет. Ну и кто-то его на
Си портировал уже.
Пример виртуальной машины
Как то раз я описывал концепцию создания языка программирования для
устройства. Который бы позволил запихать сложнейший алгоритм или
последовательность действий в виде компактного скрипта.
Простой пример для чего это нужно — фрезерный станок с ЧПУ. И надо на
нем выточить голову Сократа из цельного куска металла. Задача, на самом
деле, не шибко сложная.
Но попробуйте написать прошивку, двигающую резцом, в виде
классического конечного автомата — двигающую резцом в зависимости от
условий или состояний. Да вы сдохнете раньше чем это сможете сделать.
Другое дело если разбить программу на элементарные операции, вроде
“Резец вверх”, “резец вниз”, “шаг на 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
void VM_Delay(void)
{
u16 delay; // Двубайтная переменная
u08 *OneByte; // Указатель на один байт
OneByte = (u08 *)&delay; // Берем адрес переменной
*OneByte = VM_PGM[++VM_PC[0]]; // По байтикам собираем слово
OneByte++;
*OneByte = VM_PGM[++VM_PC[0]];
12
13
14
15
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?