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

Исходные тексты программы терминала можно взять здесь: terminal.rar

Итак, в статье описана программа, реализующая функции видеокарты со следующими характеристиками:

Хоть видеокарта и способна отображать 15 цветов, но есть некоторые ограничения:

1. фон может быть только черным;
2. один символ может быть только одного цвета (не считая цвета фона).

Вот тестовая картинка, сгенерированная видеокартой (сама программа была написана еще в 2004 году, но функция демо-экрана была добавлена только что для демонстрации):

VGA-монитор управляется по 5 линиям: 2 цифровых (синхронизация горизонтальная и вертикальная) и 3 аналоговых (красный, зеленый, синий). Линии синхронизации служат для того, чтобы монитор знал, где начало кадра, какое разрешение и какова частота кадров. Аналоговые входы служат для задания цвета. Чем выше напряжение мы подаем на аналоговый вход, тем более яркий оттенок соответствующего цвета мы получим. Регулируя уровни напряжения на трех аналоговых линиях в различных комбинациях, можно получить различные оттенки цветов. Например, подав одинаковые уровни на входы управления красным и зеленым цветом (при нулевом синем) можно получить желтый цвет.

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

Для того чтобы человеческим глазом не было видно мерцания, частота обновления кадров выбирается не менее 60 Гц. Т.е. за секунду должно быть прорисовано 60 кадров. Каждый кадр в стандартном VGA-режиме состоит из 525 строк, из которых 480 являются информативными (содержащими информацию для вывода на экран), а остальные составляют передний и задний фронты синхронизации, а также нижний и верхний бордюр и не несут в себе информации о цвете. Каждая строка также логически разбита на несколько участков: передний и задний фронты синхронизации, левый и правый бордюры, видеоинформация для вывода на экран и гасящий синхроимпульс.

Нетрудно подсчитать, что время одной строки = 1с/60 кадров / 525 строк = 31.75 мкс

Ниже приведен рисунок, поясняющий порядок передачи информации на VGA-монитор:

Здесь все просто. Все, что нам нужно, - это генерировать импульсы отрицательной полярности длительностью 3.9 мкс с постоянным периодом в 31.75 мкс. Это будут импульсы горизонтальной синхронизации. Во время каждых 524-го и 525-го импульсов будем формировать отрицательный импульс вертикальной синхронизации. Очевидно, что для этой цели удобно воспользоваться прерыванием по таймеру.

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

Как мы будем формировать сигналы RGB? Вариантов несколько, но, учитывая специфику выводимой информации, т.е. цветной текст, состоящий из символов шириной по 8 пикселей, где каждый символ может быть прорисован только одним цветом, было принято решение организовать вывод следующим образом (есть еще одна причина, но о ней чуть ниже): одним выводом генерируем значение пикселя "зажжен"/"погашен", тремя выводами с открытым стоком модулируем пиксель для получения нужного цвета и одним выводом регулируем яркость. Схематически это можно изобразить так:

Когда на выходе Data уровень "0", вне зависимости от состояний остальных выходов все линии RGB будут в "0", что будет соответствовать черному цвету. Но когда на выходе Data уровень "1", то состояние линий RGB будет выбираться сигналами контроллера ~R, ~G и ~B. Если вывод установлен в "0" и соответствующий транзистор закрыт, то "1" с выхода Data будет проходить на управление цветом VGA. Если же вывод установлен в "1" и соответствующий транзистор открыт, то на соответствующей линии управления цветом будет "0". Таким образом, генерируя нули и единицы на выходе Data, мы можем каждой светящейся точке задавать цвет, устанавливая выводы ~R, ~G, ~B в нужное значение. Например, для получения точки голубого цвета нам нужно убрать красную составляющую, оставив синюю и зеленую. Т.е. устанавливаем выход ~R в "1", а ~G и ~B - в "0".

У нас есть еще один выход - ~Y. Это управление яркостью. Когда он установлен в "0", транзистор закрыт, и уровни напряжений на линиях VGA-R, VGA-G и VGA-B будут сформированы резистивным делителем, верхнее плечо которого - резистор в стоке транзисторов управления цветом, а нижнее плечо - входное сопротивление VGA = 75 Ом. Но когда выход ~Y устанавливается в "1", все три линии управления цветом прижимаются к земле через диоды, понижая тем самым напряжение на активных линиях до 0.35В (используются диоды 1N5819).

Таким образом, мы получаем 16 цветов: 8 обычных + 8 пониженной яркости. (На самом деле мы получаем 15 цветов, т.к. при данном подходе получаются два черных цвета.)

На практике транзисторы с открытым стоком мы можем реализовать на самом контроллере, установив защелку выходов в "0" и управляя регистром направления выводов (TRIS). Поэтому в устройстве для задания цвета будут присутствовать только диоды и резисторы.

Как видно из рисунка, поясняющего порядок синхронизации, видимая часть строки длится 25.17 мкс. Это означает, что, имея контроллер с производительностью 10 MIPS (на момент написания программы это была максимальная производительность для PIC18), т.е. со временем программного цикла = 100 нс, мы можем сформировать видимую область с максимальным разрешением 251 пиксель по горизонтали. Но тут можно возразить, что потребуется как минимум один такт на формирование данных и один такт на вывод, т.е. уже 200 нс. Но мы прибегнем к возможностям периферии, а именно - воспользуемся модулем USART, который сможет сгенерировать нам последовательность из 8-ми нулей и единиц длительностью по 100 нс каждый (для этого нужно будет запустить USART в синхронном режиме на максимальной скорости). Таким образом, нам понадобятся всего два такта для формирования 8 пикселей. И еще 6 тактов остаются на всякие дополнительные нужды: чтение таблицы знакогенератора и формирование цвета.

(Использование USART является второй причиной, по которой мы для формирования последовательности "зажженных"/"погашенных" пикселей используем один вывод контроллера).

Т.к. предполагается использовать шрифт шириной 8 пикселей, то и разрешение у нас будет кратным 8, т.е. максимально возможное - 248 точек (31 символ). Однако для простоты и удобства возьмем 30. Таким образом, разрешение видеоизображения по горизонтали будет 240 точек. Для вывода изображения нам нужно после генерации синхроимпульса выдержать паузу (левый бордюр), затем выполнить прорисовку текущей линии изображения, затем выдержать еще паузу (правый бордюр). Порядок обработки прерывания будет таким:

При такой организации у нас от каждой строки остается 3.9 мкс (39 инструкций, за вычетом 5-6 на вход/выход в прерывание и сброс бита прерывания) на обработку данных от SPI. Паузы здесь отмечены условно, т.е. на самом деле это время используется на сопутствующие вычисления (эмуляцию курсора, подсчет строк, формирование указателей).

В нашей программе применяется шрифт шириной 8 пикселей. Знакогенератор хранится во внутренней ROM контроллера и представляет собой массив, в котором на описание каждого символа выделяется 16 байт (по одному байту на каждую строку растра). Например, буква 'A' записана так:

И для вывода этого символа мы будем в течение прорисовки 16 линий через один и тот же промежуток времени после начала горизонтального синхроимпульса записывать в регистр TXREG все байты, описывающие этот символ: в первой и второй линиях байты 0х00, в третьей - 0x10, в четвертой - 0x38 и т.д. Тогда на экране это будет выглядеть так:

Здесь ts - момент начала строки, tc - момент старта символа.

Для вывода одной строки растра каждого символа у нас есть 8 тактов. За это время мы должны успеть выбрать текущий байт из массива знакогенератора для следующего символа и подготовить значение цвета для него. Ровно через 8 тактов после начала вывода предыдущего символа мы выводим следующий, еще через 8 - очередной и так выводятся все 30 символов.

Два слова о некоторых схемных решениях.

В первую очередь нужно обратить внимание на необязательную, но желательную микросхему 74AC245. Ее основная функция - разгрузить вывод RC7. Т.к. входы линий цвета VGA являются низкоомными (75 Ом), то ток, которым они управляются, получается сравнительно велик. Выводу RC7 приходится работать на низкоомную нагрузку сразу по трем линиям: управление красным, зеленым и синим. В принципе, эту микросхему можно и не ставить, а нагрузить все целиком на RC7, но при этом картинка на экране получится немного тусклой.

Во вторую очередь обратим внимание на RC-цепочку, стоящую на выходе RC7 (R4-C8). При отладке программы было обнаружено несоответствие поведения контроллера PIC18F252 (такое же несоответствие было установлено для PIC18F258, PIC18F452 и PIC18F458) с описанием в документации: там сказано, что импульсы USART, работающего в синхронном режиме на максимальной скорости, синхронизированы с тактом Q4. Однако на практике выяснилось, что они синхронизированы с тактом Q2. Для задания цвета каждому символу регистр цвета (TRISB) обновлялся одновременно с началом передачи по USART очередного байта. Проблема в том, что запись в регистр TRISB в этих контроллерах производится как раз по такту Q4. Т.е. запись в регистр управления цветом рассинхронизирована с началом передачи очередного байта по USART на Q4-Q2 = 50 нс (при тактовой частоте 40 МГц). На экране эта рассинхронизация проявляется в виде "заползания" цвета соседних символов друг на друга. Для того чтобы избавиться от этого эффекта, в схему и была внедрена RC-цепочка, задерживающая сигнал с выхода RC7 на 50 нс.

Примечание. Это несоответствие было обнаружено только на PIC18F252, PIC18F258, PIC18F452 и PIC18F458. Если будет использован контроллер более новой модификации (например, 2520), то RC-цепочку ставить не нужно.

Видеопамять содержит следующую информацию:

• массив символов, выводимых на экран (8 бит на символ);
• массив цветов для всех знакомест (4 бита на символ).

Экранное поле разбито на 900 знакомест (30 по вертикали и 30 по горизонтали). Таким образом, требуется 900 байт для хранения символов и 450 байт для хранения массива цветов. Учитывая требования по минимизации времени обработки данных в этих двух массивах, было решено организовать видеопамять в виде массива 3-х байтовых блоков:

где:

• x - 4 бита, задающие цвет символа XX;
• y - 4 бита, задающие цвет символа YY;
• XX - символ в четной позиции знакоместа;
• YY - символ в нечетной позиции знакоместа.

Эти трехбайтовые блоки хранятся в памяти последовательно в виде массива из 450 блоков. Такая организация памяти позволяет адресовать сразу два массива (массив символов и массив цветов) одним и тем же указателем FSR.

Для того чтобы не тратить дефицитное время на формирование FSR-регистров для указания на активный символ (для отображения или для записи), а также еще некоторых специальных регистров, программа организована таким образом, что за некоторыми регистрами закреплены определенные функции на протяжении всего времени выполнения программы:

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

• формирование указателей (и RAM и ROM);
• сохранение/восстановление SFR при входе/выходе в/из прерывания.

Знакогенератор организован в виде массива байтов для хранения информации о 256-ти символах по 16 байт на символ. Эти данные нам нужно разместить в определенном порядке, чтобы максимально сократить время выборки требуемого для вывода на экран байта с учетом того, что за один проход (за прорисовку одной строки растра) из всех 16-байт, описывающих конкретный символ, для каждого символа будет выбран только один байт, причем с одним и тем же индексом. Т.е., выводя строку номер 5, нам потребуются только 5-е байты из 16-ти, описывающих каждый символ. Поэтому массив знакогенератора организован не в виде массива 16-байтов блоков, каждый их которых описывает один символ, а в виде массива из 16-ти 256-байтовых блоков, каждый из которых содержит на каждый символ по одному байту, который будет выводиться при прорисовке текущей линии.

Такая организация позволит при прорисовке очередной строки растра один раз сформировать значение регистра TBLPTRH, который будет указывать на 256-байтный блок, и для каждого символа просто прописывать его значение в регистр TBLPTRL, получая тем самым адрес байта для вывода на экран. С учетом такого подхода у нас есть одно требование: таблица знакогенератора должна быть выровнена по границе 256 байт. В нашей программе знакогенератор будет храниться по адресу 0x1000.

(Символы с кодами с 0x80 по 0x98, выстроенные в 5 рядов по 5 символов, образуют графическое изображение логотипа Microchip.)

Терминал способен отображать мигающий курсор в текущей позиции. Это может оказаться полезным для более удобной организации ввода данных пользователем. Скорость мигания курсора определяется периодом таймера TMR0 (курсор мигает с частотой 2.5 Гц). Вывод курсора в программе организован следующим образом: при прорисовке той строки символов, которая содержит курсор, 2.5 раза в секунду символ, в позиции которого находится курсор, подменяется символом с кодом 0x00 (он представляет собой закрашенный символ), а после прорисовки строки - восстанавливается.

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

Если при подаче питания удерживать вход RA0 в "0", то программа войдет в режим демонстрации, в котором будет отображаться тестовая картинка (см. выше). Как только на RA0 появляется "1", экран очищается, и программа начинает работать в обычном режиме.

Наш терминал управляется внешним устройством по SPI по четырем линиям: notSS, SDI, SDO, SCK. При передачи на терминал (или при приеме от терминала) каждого байта линия notSS должна быть установлена в 0, а по завершении передачи (приема) байта - возвращена в единичное состояние. Данные (входные и выходные) синхронизируются по отрицательному фронту линии SCK. Ввиду того, что большую часть времени программа занята прорисовкой изображения, и из 31.5 мкс остается только около 2.5 мкс, т.е. 7.5% времени. Это накладывает некоторые ограничения на скорость обмена данными с терминалом. Программу удалось организовать так, что за 2.5 мкс будет успевать полностью обработаться один байт данных, т.е. за время прорисовки одной строки растра терминал может принять и полностью обработать один байт. Таким образом, частота следования байтов не может превышать частоты прорисовки строк растра, т.е. 1/31.5 мкс ~ 31.5 Кбайт/сек.

Для вывода символа на экран в текущей позиции курсора нужно просто передать терминалу по SPI его код от 0x10 до 0xFF. Байты с 0x00 до 0x0F зарезервированы для команд (см. команды управления). При этом:

1. в текущей позиции курсора будет выведен полученный символ;
2. этому символу будет установлен текущий цвет;
3. текущая позиция увеличивается на 1. Если она была в конце строки, то производится перевод на начало следующей. Если позиция находилась в конце экрана (нижний правый угол), то новая позиция курсора будет установлена в начало экрана (верхний левый угол).

Байты 0x00-0x0F зарезервированы для передачи терминалу управляющих команд (установка позиции курсора, текущего цвета, размера курсора и пр.)

Примечания:

1. Значения констант X_SIZE и Y_SIZE можно получить командами 0x0E и 0x0F, соответственно;
2. Чтение любого параметра из терминала производится в три этапа:
   1. на терминал отправляется команда (см. таблицу);
   2. выдерживается пауза не менее 32 мкс;
   3. производится чтение байта.
3. Эти команды добавлены для того, чтобы осталась возможность расширения возможностей программы терминала. Например, при переносе программы на более мощный контроллер (PIC24, PIC32, ATMEGA и т.д.) появится возможность увеличить разрешение и, следовательно, количество символов в строке. Или кто-нибудь решит переделать программу так, чтобы размер символа был не 8x16, а 8x8, увеличив тем самым количество текстовых строк.

Исходные тексты программы терминала можно взять здесь: terminal.rar

Для удобства разработки собственных приложений, управляющих терминалом, создан файл библиотеки. Он расположен в папке APPNOTE. Файл "vga_terminal.c" добавляется в проект, а файл "vga_terminal.h" включается во все файлы, из которых предполагается делать вызов функций терминала, директивой #include.

Ниже приведен список Си-фукций модуля vga_terminal.

Маленькая программа для PIC16F88, демонстрирующая использование библиотеки vga_terminal для управления терминалом: terminal_test.rar Для связи используется аппаратный SPI.

Программа выводит на экран следующую картинку:

Терминал с разрешением 51x30 символов - читатель Ковалев Игорь переделал терминал для работы на 16МГц (PIC18F46K20). За счет увеличения скорости он увеличил горизонтальное разрешение; символы визуально сузились, что сделало изображение более симпатичным

VGA-Терминал на PIC24 - 60х25 символов, 8 цветов, 2 размера шрифта, PS/2 клавиатура, USART. Схема, исходники, отличное описание (англ.)

http://www.micro-examples.com/public/microex-navig/doc/089-pic-pal-tv.html - PIC PAL Video Library - проект для PIC18F4620, написанный на mikorC

http://www.mikrocontroller.net/topic/53140 - текстовый терминал на ATmega8, 40x25, управление UART 19200 (вывод PAL)

http://neil.franklin.ch/Projects/SoftVGA/ - Еще один проект для atmega32.

http://mondo-technology.com/dcvideo.html - текстовый терминал на PIC16F819 с видео выходом. Разрешение 20x10 символов, управление: UART 9600