Виртуальная машина и байт код
Автор DI HALT
Опубликовано 19 Фев 2010
Рубрики: Робототехника
Метки: Алгоритм, Программирование, Робот
Часто требуется делать большие последовательности сложных операций — например полетное задание для робота. Да, можно запихать все это дело в основную программу, но вдруг что то пойдет не так как надо и алгоритм надо будет переделать — придется переделывать всю программу.
Тут на помощь придет виртуальная машина. Суть в чем — в памяти контроллера, в основную программу, занесены основные процедуры управления устройством. Если это робот, то это могут быть такие простые команды как “вперед”, “назад”, “повернуть” и так далее.
Дальше мы увязываем это все в таблицу переходов, где у каждой команды будет номер-смещение.
Потом нам нужен обработчик скриптов, который бы брал откуда нибудь, нашу последовательность действий — скрипт и преобразовывал это в вызовы реальных кусков кода -микрооперации.
Обработчик скриптов может быть той же самой задачей диспетчера, запущенной фоном. А откуда он будет брать данные неважно. Их вполне можно засасывать по usart или тащить из EEPROM памяти. А можно загнать на IIC память и получится сменный картридж :)
Читать полностью
AVR. Учебный курс. Архитектура Программ. Часть 3.
Автор DI HALT
Опубликовано 31 Янв 2010
Рубрики: AVR. Учебный курс
Метки: RTOS, Алгоритм, Программирование
Приоритетный диспетчер.
Одной из проблем простого диспетчера является то, что все задачи имеют равный приоритет. С одной стороны, это просто и удобно. С другой — какое-либо важное событие можно прошляпить, пока там конвейер перещёлкает все задачи…
Проблему решает введение приоритетов.
В простейшем случае, можно ввести два приоритета — высокий и низкий. Разница между ними будет лишь в том с какой стороны очереди они будут засовываться на конвейер. Высокоприоритетные пихаются сразу в начало, низкоприоритетные с конца.
Разумеется, тут надо следить за тем, чтобы высокоприоритетные задачи не забивали конвейер, блокируя низкоприоритетные. Никакой защиты от этого нет, только думать головой.
Если нужна высокоуровневая система приоритетов, то можно очередь задач превратить в двумерный массив, где вторым этажом будет идти приоритет задачи. Правда при этом увеличиться время обработки конвейера — ведь надо будет сперва прочесать всю очередь в поисках наибольшего элемента. Но тут можно напридумывать кучу оптимизаций. Например, сортировать очередь при постановке задачи на конвейер, либо завести TOP list приоритетов, занося туда значения приоритетов. Тогда диспетчер, обрабатывая очередь, сразу будет искать нужный элемент, ориентируясь по TOP листу. Но вот так, на вскидку, я не берусь сказать какой из приемов будет эффективней/компактней/быстрей.
Читать полностью
AVR. Учебный Курс. Архитектура Программ Часть 2
Автор DI HALT
Опубликовано 20 Янв 2010
Рубрики: AVR. Учебный курс
Метки: RTOS, Алгоритм, Программирование
Диспетчер
Данная организация программы требует чуть большего количества кода чем флаговый автомат (Хотя это еще как посмотреть. С увеличением числа задач служебный код динамического диспетчра не увеличивается, а вот флаговый автомат разрастается за счет большего числа флагов и проверок этих флагов, плюс быстродейтсвие снижается, чего нет в диспетчере) , но зато лишена ряда недостатков.
Во первых тут очередь выполнения задач не жестко заданная, а динамическая, конвеерного типа. То есть у нас есть в памяти массив из указателей на задачи-функции. Диспетчер берет указатель и, если он не указывает на Idle, осуществлет переход по этому адресу. Предварительно удалив его из очереди и подкинув очередь.
Заброс указателей-задач в очередь осуществляется другими задачами и прерываниями, а также программными таймерами. Собственно, принцип передачи управления от задачи к задаче похож на флаговый автомат — работаем через посредника. Только у нас тут отстутствуют проверки флагов, а переход делается диспетчером. За счет этого увеличение числа задач не сказывается на увеличении размера управляющей структуры.
Благодаря такой системе управляющую структуру можно вынести в отдельную библиотеку, сварганить к ней конфиг и таскать за собой ее туда сюда. Очень удобно.
А теперь подробно распишу тот диспетчер который стоит в 90% моих проектов на Си.
Читать полностью
AVR. Учебный Курс. Архитектура Программ
Автор DI HALT
Опубликовано 14 Янв 2010
Рубрики: AVR. Учебный курс
Метки: Алгоритм, Микроконтроллер, Программатор
Все учебные курсы по микроконтроллерам которые я встречал (в том числе, к сожалению, и мой ассемблерный, но я надеюсь это постепенно поправить) страдают одной и той же проблемой.
В курсе бросаются строить дом не заложив фундамент. Только показав на примере как мигнуть светодиодом, сразу же кидаются в периферию. Начинают осваивать ШИМ-ы, таймеры, подключать дисплеи и всякие термодатчики.
С одной стороны это понятно — хочется действа и результата мгновенно. С другой — рано или поздно такой подход упрется в тот факт, что программа, надстраиваемая без четкой идеологии, просто обрушится под своей сложностью. Сделав невозможным дальнейшее развитие.
Итогом становится либо рождение жутких программных уродцев, либо миллионы вопросов на форуме вида “а как бы мне все сделать одновременно, а то частоты контроллера уже на все не хватает”.
Самое интересное, что правильной организации программы учат программистов в ВУЗах, но вот только к микроконтроллеру народ обычно идет не от программирования, а от железа. А, как показала практика обучения в ВУЗе, электронщиков толковому программингу практически не обучают :( Приходится все додумывать самостоятельно.
Итак, что такое структура программы. Это, прежде всего, ее скелет. То какими путями движется код. Как организованы переходы между задачами прошивки. То как распределяется процессорное время. Без краткого ликбеза по общим принципам построения прошивки дальше двигаться нет смысла.
Все ниже написанное это лишь продукт моих умозаключений, поэтому терминология может отличаться от общепринятой. Если это сильно кому то будет резать глаз — поправляйте в комментах.
Итак, я для себя выделяю следующие структуры, по порядку возростания сложности конструкции и количеству управляющего кода:
- Суперцикл
- Суперцикл+прерывания
- Флаговый автомат
- Диспетчер
- Приоритетный диспетчер
- Кооперативная RTOS
- Вытесняющая RTOS
А теперь подробно по каждому пункту: Читать полностью
AVR. Учебный Курс. Управляемый вектор прерывания
Автор DI HALT
Опубликовано 12 июня 2009
Рубрики: AVR. Учебный курс
Метки: Assembler, RTOS, Алгоритм, Трюки
Бывает такая ситуация, когда надо на один периферийный девайс повесить много разных задач, а он всего один и что то надо с этим делать.
Простой пример — таймер и его прерывание по переполнению.
Мы можем задавать выдержку и по прерыванию делать какие-нибудь операции. Но если в один момент времени мы хотим чтобы таймер по прерванию сделал одну операцию, а потом другую, третью. Да сколько угодно, в зависимости от состояния. А вектор один.
Или, например, 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) направление куда нам надо перенаправить наш вектор и воткнуть в обработчик прерывания индексный переход. И вуаля! Переход будет туда куда нужно, без всякого сравнения вариантов.
Читать полностью
М. Дамке “Операционные системы микроЭВМ”
Автор DI HALT
Опубликовано 04 мая 2009
Рубрики: Книги
Метки: RTOS, Алгоритм, Трюки
 |
Автор: М. Дамке Название: Операционные системы микроЭВМ Издательство: Финансы и статистика
Старожил сайта и один из самых активных и толковых комментаторов, камрад SWG сделал замечательную вещь– отсканировал и пожал в DejaVu книгу по написанию операционных систем под микро-ЭВМ.
Я пока основательно не врубался, по диагонали пролистал — рулез! Особого грузилова нет, все в виде алгоритмов и концепций. Написано все простым и понятным языком. В частности все разобрано на примере Z80 и i8080 В общем, замечательная книга. Как говорил SWG где то в комментах: “Почитай эту книгу и изобретение велосипедов пойдет куда веселей” :) Надо будет закинуть в принтер бумаги побольше и напечатать этот труд.
AVR. Учебный курс. Операционная система. Таймерная служба
Автор DI HALT
Опубликовано 01 Апр 2009
Рубрики: AVR. Учебный курс
Метки: Assembler, AVR, RTOS, Алгоритм, Операционная система
Третья часть марлезонского балета описалова самопальной операционной системы для AVR.
Итак, у нас есть очередь задач и общая логика работы системы. Но одной очереди задач с диспетчером мало. Нужно распределять задачи по времени, задавать интервалы, запускать отложенные задачи. Всем этим будет заниматься служба таймеров.
В чем ее суть ее работы:
Время разбивается на интервалы, скажем, по 1мс. Такой выдержки хватает для большинства задач. Также у нас должна быть очередь программных таймеров, размещенных в ОЗУ. На каждый таймер отводится три байта:
Первый — идентификатор задачи. Два других — выдержка в миллисекундах.
Два байта позволяют организовать выдержку в 65.5 секунд. Конечно, можно сделать и больше, если отвести на временную выдержку три или даже четыре байта, но такие большие временные интервалы пригождаются редко, поэтому проще перехватиться через дополнительную переменную для конкретной задачи, а не нагружать таймерную службу обсчетом дополнительных байт.
Один из свободных аппаратных таймеров программируем на то, чтобы он генерировал прерывание каждые 0.001с
По прерыванию мы берем из очереди таймеров первый байт и сравниваем его с 0xFF, за 0xFF принято неактивное состояние. Если же там не 0xFF, то значит это идентификатор задачи, а таймер активен. Поэтому берем третий байт, декрементируем его, если он стал равен нулю декрементируем второй байт и если оба байта не стали равны нулю переходим к проверке следующего байта. В случае если время истекло, то идентификатор задачи пихается в очередь задач на исполнение. Читать полностью
Ревич “Практическое программирование Микроконтроллеров AVR на языке ассемблера”
Автор DI HALT
Опубликовано 13 Фев 2009
Рубрики: Книги
Метки: AVR, Алгоритм, Начинающим
 |
Автор: Юрий Ревич Название: Практическое программирование Микроконтроллеров AVR на языке ассемблера Издательство: Bhv
Отличная книга. Из серии настольных. Автор очень доступно, подробно, без занудства и заумностей рассказывает как использовать все то богатство, что разработчики из Atmel напихали в свой контроллер, причем книжка свежая, а значит контроллеры там уже из современных. Разобраны все периферийные устройства, а также на конкретных практических примерах наглядно показано, как воспроизводить звуки через ШИМ, как писать и читать на MMC флешки, как пользоваться компараторами, АЦП, SPI, TWI. Есть целый раздел посвященный математике на микроконтроллерах. Сложение, деление, умножение целых и дробных чисел. Как со знаком, так и без. В сочетании с даташитом или книгой Евстифеева дает практически полную информацию для работы с AVR. Также есть глава посвященная связи МК с компом. Есть пример проги на Delphi для работы с COM портом. В общем, настоятельно рекомендую скачать, а можно и в бумаге заиметь, не помешает.
Работа с АЦП. Программные средства повышения точности
Автор DI HALT
Опубликовано 29 Янв 2009
Рубрики: AVR. Учебный курс
Метки: Assembler, AVR, Алгоритм, Аналог, АЦП
Вообще, сграбив сигнал в цифровую форму мы мы можем извращаться с ним как угодно. Методик цифровых фильтраций существует масса и все они основаны на сборе избыточной информации с последующим выделением сигнала. Я приведу для примера лишь один простейший способ - усреднение.
Суть усреднения в том, что у нас есть статичный (считаем, что за время измерения сигнал не меняется) сигнал к которому подмешан шум. Шум возникает изза работы транзисторов, из-за колебания опорного напряжения, помех, наведенных на сигнальные линии. Да от чего только он не возникает. Особенность шума в том что он, как правило, хаотичен. Так что во время нашего замера может меняться как в меньшую так и в большую сторону. Тут то мы его и прижучим.
Берем и снимаем не одно измерение, а сразу кучу. А потом берем по ним среднее арифметическое. Так как полезный сигнал у нас константен, то его составляющая такой и останется, как ее не усредняй, а вот шум изрядно приглушит. И чем больше выборок мы сделаем, тем сильней задавит шумовую составляющую. Западло этого метода очевидно - резко снижается скорость обработки. Так как вместо одной выборки нам приходится делать серию и объявлять ее как одну, но это неизбежное зло.
В качестве демонстрации метода я приведу пример усреднения. Программка простая, хватает 64 выборки, усредняет их и отправляет по UART. Сразу отмечу тот факт, что для эффективного подавления шума нужно чтобы частота выборок была ниже частоты всяких паразитных колебаний (вроде 50Гц наводок от сети) раза в два три, иначе у нас эти колебания благополучно пролезут как полезный сигнал. А еще число выборок нужно брать кратным двойке, чтобы можно было делить простым сдвигом. Впрочем, смотрите на код, там будет более понятно. Весь код я выкладывать не буду, только главный файл. Все инициализации АЦП и UART, а также ряд служебных процедурок я оставлю за кадром. Если интересно, то вы всегда можете скачать проект и посмотреть сами. Сбор числа у меня идет в прерывании от АЦП, а деление в прерывании по передаче. Так минимизируется число действий выполняемых процом. Хотя растягивание прерываний это не есть гуд. Но городить флаговую операционную систему мне тут впадлу, впрочем, дойдет и до нее время. Читать полностью
AVR. Учебный курс. Подключение к AVR LCD дисплея HD44780
Автор DI HALT
Опубликовано 23 Сен 2008
Рубрики: AVR. Учебный курс
Метки: HD44780, LCD, Алгоритм, Программирование
 |
| Сегодня разменял четверть века! |
Для начала оговорюсь сразу, что речь тут пойдет о LCD индикаторах на контроллере HD44780, который стал промышленным стандартом де-факто на рынке цифро-буквенных дисплеев. Продается везде где только можно, стоит недорого (8х2 мне обошелся порядка 150 рублей), а также под него написана куча кода. Я же, как обычно, решил изобрести велосипед и сварганить свою собственную тру-библиотеку для работы с этим типом индикаторов. Разумеется на ассемблере, а на чем же еще? ;)
AVR. Учебный курс. Процедура сканирования клавиатуры
Автор DI HALT
Опубликовано 21 Сен 2008
Рубрики: AVR. Учебный курс
Метки: Assembler, AVR, Алгоритм, Клавиатура, Программирование
Матричная клавиатура
Автор DI HALT
Опубликовано 08 Сен 2008
Рубрики: Начинающим
Метки: Алгоритм, Клавиатура, Начинающим, Программирование, Схемотехника
Клавиатурная матрица.
Я ее нарисовал тебе на первой картинке. Как видишь, там есть строки и столбцы. Кружочками обозначены кнопки. Включены они так, что при нажатии кнопка замыкает строку на столбец.
Считывающий порт включается в режиме Pull-up входа, то есть вход с подтягивающими резисторами. Если контроллер это не поддерживает, то эти резисторы надо повесить снаружи.
Сканирующий порт работает в режиме выхода, он подключен к столбцам. Столбцы должны быть подтянуты резисторами к питанию. Впрочем, если используется полноценный Push-Pull то подтяжка не нужна - выход сам поднимет ногу на нужный уровень.
Рубрики
Облако тегов плагина WP Cumulus требует для просмотра или выше.
