В настоящее время получили распространение различные жидкокристаллические дисплеи, которые отлично подключаются к контроллерам семейства STM32. В данной статье речь пойдет об одном из распространенных контроллеров STM32F103C8T6 и дисплее 7" на контроллере SSD1963. Оба в виде законченных узлов легко доступны на Aliexpress и относительно недорого стоят. Конечно, все рассмотренное ниже справедливо и для других дисплеев с параллельным интерфейсом и большинства контроллеров STM32.

Вот так выглядят соединяемые устройства:





В комплекте с дисплеем была распиновка выводов и код инициализации для 51-го контроллера с комментариями на языке изготовителя.

Коротко о подключении

Подключение дисплея заключается в подаче питания 3.3 и 5 вольт на нужные выводы и соединении информационных линий с контроллером. Управляющие сигналы D/C, WE, RST подключатся к свободным линиям ввода-вывода на процессоре. В нашем случае это D/C — PA1, WE — PA8, RST — PA2. Сигналы RD и CS можно не использовать, при этом на RD надо подать логическую единицу, т.е. подключить через резистор (в данном случае 4,7 КОм) на +3.3 В, а на CS — «0», т.е. подключить на землю.


Далее нужно подключить шину данных. У данного дисплея она предполагается 16-разрядная, но можно при инициализации выбрать 8-и и 9-и битные режимы работы. То есть нужно подключить как минимум линии дисплея DB0-DB7, как максимум еще и DB8-DB15. Для удобства программирования и минимизации команд преобразования данных лучше их завести на одну группу ввода-вывода. Если рассматривать вариант 16-разрядной шины данных, то выбирать на данном микроконтроллере не приходится — только PB0 — PB15.

Соединяем их соответственно с DB0-DB15 дисплея:


На гребенке дисплея остается много неподключенных контактов, пусть это вас не смущает. На нем присутствует слот SD карт памяти, сенсор экрана, даже есть разводка под микросхему EEPROM памяти, но сама она отсутствует. Эти устройства и занимают остальную часть разъема. Кстати, под 40-контактный разъем дисплея идеально подходит шлейф PATA жестких дисков компьютера.

Инициализация дисплея

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


В коде нет инициализации портов ввода-вывода и системного таймера, на основе которого реализуются миллисекундные задержки (delay_ms()).

После выполнения инициализации:

  tick_init(); // инициализация системного таймера
  lcd_port_init(); // инициализация портов ввода-вывода
  SSD1963_Init(); // инициализация дисплея

Мы видим «мусор» видеопамяти на дисплее:

Заливка дисплея

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


Как видно, код зависит от выбранной разрядности шины. Соответственно зависит и время, необходимое для выполнения передачи пикселя на дисплей. Для 16-разрядной шины пиксель передается за один цикл передачи по шине данных, для 9-разрядной — за два, для 8-разрядной — за 3. Откуда эти данные? Из документации на SSD1963.



В таблице можно найти расположение каждой составляющей цвета пикселя в зависимости от режима. В проекте используются режимы 8 бит, 9 бит и 16 бит (565 формат). Как видите, можно было также задействовать «чистый» формат 16 бит для более точного кодирования цвета, но он также требует трех циклов передачи данных по шине. Форматы 18 и 24 бит мы задействовать не можем по причине наличия только 16-битной шины на выходе дисплея.

Итак, с какой скоростью мы сможем заполнить дисплей на процессоре с тактовой частотой 72 МГц?

176 мс — 16-разрядная шина
374 мс — 9-разрядная шина
470 мс — 8-разрядная шина

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

Попробуем рассмотреть компромиссный вариант — 9 бит, как выигрывающий почти 0.1 с у 8-битного варианта за счет всего одного дополнительного порта ввода-вывода.

Оптимизация по скорости

Попробуем ускорить процесс заливки дисплея. Что если сократить количество логических операций внутри цикла?

// на входе 18-битный цвет RGB666
void SSD1963_WriteDataPix_9(uint32_t pixdata)
{
  uint32_t tmp = (LCD_DATA_PORT->ODR & 0xfe00);
  SET_LCD_RDS;
  LCD_DATA_PORT->ODR  = tmp | ((pixdata >>  9) & 0x01ff);
  RESET_LCD_WR;
  SET_LCD_WR;

  LCD_DATA_PORT->ODR  = tmp | (pixdata & 0x01ff);
  RESET_LCD_WR;
  SET_LCD_WR;
}

// на входе 18-битный цвет RGB666
void SSD1963_ClearScreen_9(uint32_t color)
{
  unsigned int x,y;
  SSD1963_SetArea(0, TFT_WIDTH-1 , 0, TFT_HEIGHT-1);
  SSD1963_WriteCommand(0x002c);
  for(x=0;x<TFT_WIDTH;x++) {
    for(y= 0;y<TFT_HEIGHT;y++) {
      SSD1963_WriteDataPix_9(color);
    }
  }
}

Изменили кодировку цвета вместо 16-битной переменной в формате RGB565 используем 32-битную, задействовав только 18 из них в формате RGB666. Кроме того ввели временную переменную для хранения значения регистра LCD_DATA_PORT->ODR во время двух циклов вывода 9-битных данных на шину. Тут надо сделать оговорку, что это не всегда возможно, т.к. за время вывода состояние других портов группы GPIO B, настроенных на вывод, может быть изменено в это время в прерывании и программа будет работать неправильно. Однако в нашем случае таких проблем нет и мы проверяем чего мы достигли. Итак после первой оптимизации экран заполняется в 9-битном режиме за 298 мс. Если переменную не использовать, и работать с текущим состоянием порта, то прирост скорости тоже есть, хотя и не такой значительный — 335 мс:

void SSD1963_WriteDataPix_9(uint32_t pixdata)
{
  SET_LCD_RDS;
  LCD_DATA_PORT->ODR  = (LCD_DATA_PORT->ODR & 0xfe00) | ((pixdata >>  9) & 0x01ff);
  RESET_LCD_WR;
  SET_LCD_WR;

  LCD_DATA_PORT->ODR  = (LCD_DATA_PORT->ODR & 0xfe00) | (pixdata & 0x01ff);
  RESET_LCD_WR;
  SET_LCD_WR;
}

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

void SSD1963_WriteDataPix_9(uint32_t pixdata)
{
  SET_LCD_RDS;
  LCD_DATA_PORT->ODR  = pixdata >>  9;
  RESET_LCD_WR;
  SET_LCD_WR;

  LCD_DATA_PORT->ODR  = pixdata;
  RESET_LCD_WR;
  SET_LCD_WR;
}

Понятно, что в режиме ввода и в альтернативных функциях возможность использования сохранятся, они не зависят от регистра ODR.
Это даст еще некоторое ускорение, до 246 мс.


Двигаемся дальше.

Следующим этапом вынесем основной цикл перебора пикселов в функцию на уровень глубже и попробуем сделать программный вариант эмуляции работы канала DMA, прямого доступа к памяти. Для этого нам надо перенести линию управления WE дисплея в группу, где расположена шина данных, т.е. GPIO B. Пусть это будет PB9.

void SSD1963_WriteDataPix_9(uint32_t pixdata, uint32_t n){
  static uint32_t dp[4];
  uint8_t i;
  SET_LCD_RDS;
  RESET_LCD_WR;
  dp[0] = (pixdata >>  9) & 0x01ff;
  dp[1] = ((pixdata >>  9) & 0x01ff) | 0x0200;
  dp[2] = pixdata & 0x01ff;
  dp[3] = (pixdata & 0x01ff) | 0x0200;
  for (;n;n--){
      for (i=0;i<4;i++) {
          LCD_DATA_PORT->ODR = dp[i];
      }
  }
 
void SSD1963_ClearScreen_9(uint32_t color)
{
  SSD1963_SetArea(0, TFT_WIDTH-1 , 0, TFT_HEIGHT-1);
  SSD1963_WriteCommand(0x002c);
  SSD1963_WriteDataPix_9(color, TFT_HEIGHT*TFT_WIDTH);
}

Как видно из кода, мы последовательно записываем 4 варианта данных в группу портов B, где кроме 9-битной шины данных расположен также сигнал WE. Операция " | 0x0200" — это как раз выставление этого сигнала. Такой код дает великолепный прирост до 85 мс, а если заменить определение массива «static uint32_t dp[4]» на «static uint16_t dp[4]», то и до 75 мс. Для проверки был замерен вариант с включением режима DMA и такой же передачей содержимого 4-х ячеек в порт ввода-вывода. Результат всего лишь 230 мс. Почему DMA медленнее? Все просто, в программном режиме компилятор оптимизирует код и все 4 значения размещаются в регистрах процессора, а не в памяти, а выборка из памяти, которая выполняется контроллером DMA, идет значительно медленнее, чем работа с регистрами.
Скомпилированный основной цикл выглядит так:

08000265: ldr r3, [pc, #24] ; (0x8000280 <SSD1963_WriteDataPix_9+84>)
08000267: str r6, [r3, #12]
08000269: str r5, [r3, #12]
0800026b: str r4, [r3, #12]
0800026d: str r1, [r3, #12]
0800026f: subs r2, #1
08000271: bne.n 0x8000266 <SSD1963_WriteDataPix_9+58>

В этом варианте, а также в варианте с каналом DMA остается ограничение на использование портов PB10-PB15. Однако на них можно вывести сигналы дисплея RST и D/C и учесть их в цикле, тогда ограничений будем меньше.

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

Дело в том, что в некоторых применениях дисплея не нужен весь набор цветов (в RGB656 — 65536 цветов). Например, в области АСУТП, где требуется отображать состояние производственного объекта, либо какое-то текстовое применение, отображение сообщений. Если это предположение верно, и нам не требуется отображать полноцветные фото- и видеоматериалы, то попробуем продолжить оптимизацию.
Рассмотрим палитру, где у каждого цвета равны первая и вторая часть данных, передаваемых по шине в дисплей. Т.е. из 18 бит модели RGB666, первые 9 бит равны вторым 9. Это дает нам 2^9=512 цветов. Возможно кому-то покажется недостаточно, но для построения графиков или отображения алфавитно-цифровой информации вполне может хватить. Назовем их условно «симметричные цвета».


Что нам дает использование только этих цветов? Да то что для заполнения области нам не надо менять состояние шины данных в процессе заливки. Достаточно переключать состояние сигнала WE и считать сколько раз мы это сделали. Более того, можно инвертировать WE сколько угодно долго, главное не меньше чем нужно для заполнения области. Нетрудно посчитать, что раз на один пиксел нам требуется передать два блока данных по шине, то требуется 2 подтверждения сигналом WE. Соответственно на весь экран надо (Ширина_экрана*Длина_экрана*2) импульсов, или 800*480*2=768000.

Как проще генерировать импульсы. Конечно! Можно использовать таймер. TIM1 в данном контроллере более быстрый, чем таймеры TIM2-TIM4, т.к. находится на более скоростной шине тактирования APB2. Исследования показали, что включив таймер в режиме ШИМ генератора с минимальным делителем можно получить время заполнения 32 мс! Понятно что сигнал WE надо снимать с выхода таймера, например PA8 (TIM1_CH1).

Можно еще увеличить скорость заполнения? Оказалось да, просто подав сигнал SYSCLK с выхода RCC_MCO на вход WE LCD. Это максимальная доступная частота на процессоре, 72 МГц. Время заполнения дисплея симметричным цветом составляет 10.7 мс.
Отсчитывается время таймером, после чего по прерыванию сигнал снимается, а порт переключается в режим вывода.


Таймер отсчитывает время с точностью 1/72 мкс для количества точек, меньшего 32000 и с точностью 1 мкс для большего количества точек. Это связано с разрядностью счетчика таймера. Учитывая, что требуется какое-то время на обработку прерывания при выключении таймера, сигнал на выходе MCO снимается немного позднее, чем требуется, с небольшим запасом. Экспериментально установлено что это около 10-11 тактов частоты процессора. Таким образом, можно сказать что есть порог использования данной методики, при котором она остается быстрее, несмотря на накладные расходы на инициализацию таймера и RCC_MCO и отключение. Квадрат 2х2 пиксела вероятно выгоднее программно заполнять по циклу.

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

Буду рад замечаниям и дополнениям.