Программный графический сопроцессор на STM32

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

Несмотря на наличие таких проектов как Nextion HMI и Gameduino, я решил сделать свое решение по ряду причин.
Gameduino хоть и казалась интересным решением (VGA выход и FPGA на борту), но невозможность достать вторую версию этой платы, вынудила приобрести ее первую ревизию. Это были боль и страдания:

• малопонятный протокол;
• малое количество примеров в сети;
• хранение графики в хосте (можно на SD карте, но тогда нужен FatFS, а он съедает куда больше, и смысл теряется);
• множество магических чисел, которые поймет только Гуру и.т.д.
• в целом этот проект скорее мертв, чем жив.

Несмотря на взрывную популярность Nextion сейчас, проект начал появляться до столь широкого распространения и вот другие причины отказа:

• мне не хотелось разбираться с nextion (начиная с IDE);
• опасность нарваться на не европейскую плату (хотя, это вроде лечится);
• доступны только заранее запрограммированные действия из IDE (поправьте, если не прав);
• нужно писать и для хоста и для дисплея;
• большой overhead в протоколе (что, правда, объяснимо).

И самое главное, в обоих случаях нет возможности дописать что-то свое.

Контроллер для sGPU

Не просто так написал ядро, достаточно сменить тип контроллера в проекте и изменить пару инклюдов и получаем sGPU с большим объемом памяти и контроллером FSMC
(дешевизна и распространённость mini версии, не дают покоя не использовать ее).

Экран

Интерфейс

• Поддержка почти любым контроллером;
• Легко реализовать;
• Обладает достаточной пропускной способностью;
• Обладает минимальным количеством используемых линий.

Выбор пал на UART. С выбором скорости было уже не так очевидно, так как далеко не все устройства могут поддерживать скорость обмена в 1МБод. Недолго думая просто сделал четыре возможных скорости: 9600, 57600, 115200 и 1М. Так же сделана возможность выбора скорости аппаратно, при помощи 3-х GPIO (соответствие GPIO и скоростей можно найти в STM32_GPU_GPIO_Pinout.txt), что дает 8 возможных значений.
Из них только 4 использовано, остальное в резерве (можно сделать хоть 1200 Бод).
Скорость выбирается по маске, посредством

switch(GPIOA->IDR & 0x07) // считываем состояние GPIO
  {
  case 0x01: {
    init_UART1(USART_BAUD_9600);
    print(T_BAUD_9600);
  } break;
  
  case 0x02: {
    init_UART1(USART_BAUD_57600);
    print(T_BAUD_57K);
  } break;
  
  case 0x03: {
    init_UART1(USART_BAUD_115200);
    print(T_BAUD_115K);
  } break;
  
  case 0x04: {
    init_UART1(USART_BAUD_1M);
    print(T_BAUD_1M);
  } break;
  /* 
  * params 0x05-0x07 and 0x00: reserved
  *
  */
  default: {
    init_UART1(USART_BAUD_57600);
    print(T_DAUD_DEFAULT);
  } break;
  }

Тайлы

Каждый тайл, это всего-навсего массив байт с индексами цветов в текущей палитре цветов.

Так выглядит тайл 8x8 (увеличен в 10 раз):

Подробнее описывать, что такое тайлы я точно не буду, понадеюсь на вашу способность найти информацию в сети, уж больно велик объем информации.
Так как тайлов могут быть сотни и тысячи, то они будут занимать безумные объемы ПЗУ.
Совершенно нелогично передавать их со стороны хоста (так сделано в Gameduino первой ревизии).
Выход был цеплять карту памяти по SPI, SDIO пока нет.
Самым тяжелым, оказалось, поднять FatFS. Так как все пишется при помощи SPL библиотеки, а не HAL и CubeMX и возможно потому, что плохо проверил подключение питания для SD карты (к питанию щепетильны жутко они), в какой-то момент все просто заработало.
В конечном счете, со стороны хоста достаточно отправить название файла и сколько тайлов загрузить в RAM sGPU.

Согласитесь, что команда размером в 5 байт (это минимальный размер для загрузки одного тайла на момент написания статьи) куда меньше чем громоздкая библиотека FatFS съедающая значительную часть как оперативной, так и постоянной памяти, что совершенно не заметно на контролере уровня stm32.

Поддерживаются следующие размеры тайлов:

• 8x8 — самые маленькие, используют всего 64 байта RAM;
• 16x16 — средний тип, используют уже в 4 раза больше RAM (256 байт);
• 32x32 — самые большие, снова в 4 раза больше и требуют в 4 раза больше RAM (1024 байта).

Последний тип тайлов доступен только для pro версии, так как всего 10 таких съедают половину памяти mini версии, что весьма очевидно — неприемлемо.
Так же упомяну, что воспользовался хитростью при выводе их на экран. Помимо использования DMA(есть буфер для одного преобразованного тайла в RGB565), я проверяю индекс каждого тайла, и если он совпадает с предыдущим, то преобразование пропускается, и старый тайл выводится по новым координатам. Не смотря на такую трату памяти, это имеет неоспоримое преимущество, когда подряд на экран выводятся одинаковые тайлы. Время на преобразование отсутствует, поэтому тайл выводится почти сразу.

Ложка дегтя – на видео сверху код для хоста использует С версию библиотеки (идентичного можно достигнуть только если использовать STM32 под Arduino).

Вот осциллограмма вывода тайлов:

Кусок побольше:

По ней можно заметить множество пустот во время выставления адресного окна. Эти пустоты по большей части переключение линии DC (выбор данных или команды, второй канал красная линия) и ожидание освобождения буфера SPI (ожидание передачи всех данных). С этим из-за особенностей дисплея почти ничего не сделаешь (только 9 бит режим или FSMC).

Создание тайлов

Создать тайл не так сложно, достаточно сделать следующее:

• В GIMP готовое изображение привести к индексированному режиму;
• экспортировать как raw data (стандартный R,G,B);
• переименовать файл по маске 8.3 (8 символов максимум на имя файла и 3 на расширение, это ограничение текущих настроек FatFS), я обычно использую расширение *.tle (sGPU сам подставляет расширение, так что хосту не придется его передавать);
• поместить файл *.tle на SD карту в корень;
• — ???;
• — PROFIT!!!

Не совсем, так как нужно создать само изображение тайла или набора тайлов (tileset). Среди множества инструментов для pixel art мною был выбран PixelEdit
(снова понадеюсь на вашу способность найти информацию в сети).
Сделав там изображение его достаточно экспортировать как *.png и скормить GIMP (как описано выше).

Спрайты

Количество спрайтов для mini — 56, тогда как для pro версии немногим больше — 63.
Их количество для версий mini и pro вычислялось по-разному. Так для mini это сумма половины максимального количества тайлов каждого типа, тогда как для pro это сумма четвертей 63 спрайта хватит всем.

Спрайты могут состоять из любого, но одинакового типа тайлов, т.е. нельзя сделать спрайт из тайлов 8x8 и 16x16 одновременно, но, можно два спрайта из тайлов 8x8 и 16x16. Каждый спрайт состоит из четырех тайлов (максимум) спрайта 64x64 хватит всем, для всего остального есть вывод *.bmp.
Возможны следующие комбинации размеров:

• 1x1;
• 1x2;
• 2x1;
• 2x2,

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

typedef struct {
 uint16_t posX; // __ координаты где выводить на экран
 uint16_t posY; // /
 uint8_t type; // размер и тип спрайта ( 1x1, 1x2… 8x8, 16x16…)
 uint8_t visible;// должен выводится на экран или нет
 uint8_t tle[4]; // индексы используемых тайлов
} sprite_t;

Тайловый фон

В памяти содержится массив из 1200 байт (40x30 тайлов) с индексами тайлов только размером 8x8 (в будущем может быть будет возможность выбора).
Тайловая карта хранится в RAM и грузится с SD карты (расширение *.map).
На текущий момент инструменты, которые позволили бы создавать файл карты, отсутствуют.

Пример тайлового фона можно увидеть во время подачи питания.

Эти 18 тайлов размером 8x8 пикселей (увеличены в 10 раз):

Позволяют сделать такое (увеличено в 2 раза):

Теперь самое неприятное. Спрайты и тайловый фон используют одни и те же тайлы 8x8. Это означает, что для фона и спрайтов необходимо использовать разные тайлы (да, которых не так много на mini версии).

Распределение памяти

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

• 80 тайлов 8х8, как самый используемый ресурс;
• 10 тайлов 16х16, к сожалению их мало, так как это все, что осталось от свободной памяти.

Не стоит забывать про более крупный контроллер, в котором 64 кб RAM, для него распределение уже будет следующим:

• 160 тайлов 8х8, снова как самый используемый ресурс;
• 80 тайлов 16х16, на этот раз их уже куда больше;
• 10 тайлов 32x32, их снова мало, но на этот раз стоит учитывать их размер.

До сих пор сомневаюсь в правильности распределения (динамика совсем не выход).
Остальное можно найти в файле «RAMmath.txt».

Цветовая палитра

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

76 цветов:

Буду премного благодарен, если кто сможет найти или сделать более адекватную палитру на 256 цветов (с одним цветом для будущего альфа канала).

Если нужно будет использовать другую палитру, ее можно загрузить с SD карты.
В RAM sGPU есть целых 512 байт под это (256 цветов по два байта на цвет, прямо как в GameBoy Advance, но только в RGB565).
Экспортировать палитру из GIMP очень просто, достаточно экспортировать любое индексированное изображение (как raw data), и GIMP рядом с файлом изображения создаст еще один с расширением *.pal. Его и нужно поместить на SD карту (не забыв про размер имени до 8 символов).

Протокол

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

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

Сторона хоста

Не смотря на большой входной буфер для команд sGPU, все равно есть риск его переполнения. Поэтому есть два варианта защиты (по факту 1):

• Программный ответ хосту. Медленный, но широко поддерживаемый вариант (можно использовать хоть USB <-->UART и всего 3 линии для обмена);
• Аппаратный ответ хосту. Значительно быстрее, так как используется GPIO, и хосту достаточно следить за состоянием этого пина и меньше шансов, что буфер будет переполнен.

Есть две версии библиотек под Arduino.
Версия библиотеки, полностью заточенная под Arduino (на C++), конечно хоть и обладает безумным количеством преимуществ, но у нее есть один огромный и побочный недостаток — она ну очень толстая и медленная (см. раздел тайлов). Иными словами пустой скетч,

#include <STMsGPU.h>
STMsGPU gpu;

void setup() {}
void loop() {}

съедает 1634 байт ROM и 217 байт RAM, и это без метода синхронизации с sGPU! Более того, если использовать STM32, то эти цифры будут уже в 10 (как минимум) раз выше – 16732 байта ROM и 3960 байт RAM!
Поэтому есть версия на С. К сожалению, пока заточенная под atmega328p (и ей подобным) и лишенная почти всех достоинств Arduino. Эти недостатки компенсируются как увеличенной скоростью работы, так и значительно меньшим размером: 922 байт ROM и 46 байт RAM (можно сделать и меньше конечно) только уже с синхронизацией.
Самое главное если вы использовали библиотеку для экранов ili9341 от Adafruit, то не придется переписывать почти ничего! Имеется почти полная совместимость со всеми методами.

Недостатки

Исходники

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

Автор: Bismuth208

Источник