Какие-то причины создали необходимость разобраться в данной теме. Все материалы, что встречались по пути напоминали большей частью свитки эльфов из любого фэнтези - всё мне казалось слишком сложным и привязанным к проекту, мне не встречалось ничего приличного из категории "в общих чертах", поэтому вооружившись интернетом и нейросетями сел я составлять свой "гайд" под свои предпочтения (ясная структура, последовательность (А НЕ РЕФЕРЕНСНАЯ БАЗА ПОД ФИЛЬМЫ ТАРАНТИНО), простота, свобода изложения и максимальность "общего").
Делюсь им, потому что не хочу, чтобы кому-то приходилось тратить сутки на простое понимание "В ЧЕМ ДЕЛО?".
ШАГ 0 - ПОДБОР ДИСПЛЕЯ
Вот этот шаг достоин новой темы для беседы, поэтому я принимаю парадигму -"выбор сделан".
ШАГ 1 - ОПРЕДЕЛИТЬ ТИП ВСТРОЕННОГО КОНТРОЛЛЕРА ДИСПЛЕЯ
ДЕЙСТВИЯ - просмотр datasheet, обзор платы (по разъемам и меткам), переписывание название, яндекс, анализ.
Каждый дисплей, как правило, снабжают встроенным контроллером (интегрированным в плату дисплея или выносным) - микросхемой, которая управляет его функционированием. Она является "мозгом" дисплея, который принимает сигналы от внешнего контроллера и преобразует их в сигналы, управляющие каждым пикселем или сегментом дисплея.
Точное определения типа контроллера позволяет правильно взаимодействовать с дисплеем - обеспечивать реализуемость процесса инициализации (включая подбор разрешения, режима работы, частоты обновления, регулировку контраста). Для управления отображением необходимо точно знать, какие команды поддерживает контроллер (вывод текста, вывод символа, установка пикселей, управление яркостью). Каждый контроллер поддерживает определённые разрешения, цветовые режимы, форматы данных и способы передачи информации.
Каждому контроллеру соответствует определенный протокол связи - набор правил по которым происходит обмен данными между устройствами ("договор" о том, как принимать и отправлять данные), внешний микроконтроллер обязан передавать данные на микроконтроллер дисплея согласно протоколу.
ШАГ 2 - ИЗУЧИТЬ DATASHEET ДИСПЛЕЯ
ДЕЙСТВИЯ - выяснение протоколов, команд, алгоритмов инициализации дисплея.
Основные протоколы используемые при работе с дисплеями:
- SPI (Serial peripheral interface) - быстрый протокол с синхронной передачей ("master/slave" обмен данными между внешним контроллером и контроллером дисплея через 4 провода: MOSI (master out slave in) - для передачи данных от контроллера к дисплею, MISO (master in slave out) - для передачи данных от дисплея к контроллеру, SCK (Serial Clock) - для синхронизации передачи данных, SS (Slave Select) - активизация конкретного периферийного устройства для обмена данными при подключении нескольких устройств.
- I²C (Integer-integrated cirquit) - более медленный протокол, использующий меньшее количество проводов в сравнении с SPI (переменный master/slave по 2 проводам для обмена данными - SDA (serial data line) для передачи данных и SCL (Serial clock line) - для тактового сигнала, синхронизирующего передачу данных), у каждого устройства на шине I²C имеется свой уникальный адрес, микроконтроллер отправляет данные конкретному устройству, указывая его адрес. Бытует мнение про сложную настройку при большом количестве устройств в линии.
ШАГ 3 - ПОДБОР ПЕРЕФЕРИИ
ДЕЙСТВИЯ - подбор компонентов для передачи изображения - внешний микроконтроллер, шину передачи, источник питания, дополнительные электронные компоненты.
Внешний контроллер выбирается, исходя из полученной информации о протоколах для контроллера дисплея и задач, которые должны им выполняться (показ текста, показ видео, показ картинок, задачи не связанные с дисплеем - контроль параметров систем, запуск проигрывания звука). Им могут быть устройства ARDUINO, Raspberry Pi, STM32 какие-то аналоги (а также - АРМ, ПК и проч.), всё зависит от ответов на вопросы: "сколько требуется пинов?", "какие будут задачи?", "какая требуется мощность передачи?" и "какие встроенные библиотеки привлекают нас, как моделлеров?".
Затем мы подбираем шинопровод, дополнительные компоненты (резисторы, конденсаторы и поехали...) исходя из особенностей связи двух контроллеров, которые нам уже известны и ПРИГОДНЫ ДРУГ ДЛЯ ДРУГА.
ШАГ 4/5 - ПОДКЛЮЧЕНИЕ ВЫБРАННЫХ УСТРОЙСТВ ДРУГ К ДРУГУ
ДЕЙСТВИЯ - подготовка аппаратных средств связи с рабочим ПК и IDE, сборка схем, их закрепление на корпусах/опорах (с или без этапа предварительного монтажа на макетной плате).
Как правило, все схемы есть, нужно лишь чекать документики с видеохостингами, а не играть в пасьянс.
ШАГ 5/4 - ПОДГОТОВКА СРЕДЫ РАЗРАБОТКИ, ПЕРВИЧНЫЙ НАКАТ ГОТОВЫХ ДРАЙВЕРОВ (ЕСЛИ ВОЗМОЖНО)
ДЕЙСТВИЯ - выбрать IDE, установить её на свой ПК, поставить на неё библиотеки, что необходимы и иногда поставить пак готовых драйверов.
IDE - все форумчане вроде бы, как правило, юзают что-то базовое (ну, т.е. созданное разработчиками аппаратной части их контроллеров). Для ARDUINO - Arduino IDE. Для Raspberry Pi - Thonny, бывает, что работу через терминал, используя библиотеки на Python (например, RPi.GPIO для работы с пинами), но (тут мое первичное мнение профана) так как Raspberry Pi является мини-пк, то с большинством дисплеев может быть достаточно установить дрова и просто подключиться, а потом накодить для себя любое linux-приложение, которое должно будет отображаться на дисплее (если дисплей современно-дефолтный, а не символьный и проч.). Для STM32 или других микроконтроллеров обычно используется STM32CubeIDE или другие специализированные среды для разработки на C (и говорят, что можно C++).
И судя по тому, что видел - порой можно настроить свой "воркфлоу" через Visual Studio или VS CODE, но надо определяться по конкретной ситуации - смотря какой controller, смотря какой software.
При использовании популярного дисплея с известным контроллером велик шанс наткнуться на готовые библиотеки. Это значительно упрощает работу с дисплеем, так как библиотеки уже содержат функции для инициализации и передачи данных. Как принято считать - "лучше в своих проектах использовать их, а не изобретать велосипед".
ШАГ 6 - НАСТРОЙКА ПРОТОКОЛА СВЯЗИ, ВКЛЮЧЕНИЕ И ИНИЦИАЛИЗАЦИЯ ДИСПЛЕЯ
ДЕЙСТВИЯ - указать пины и параметры, согласно выбранному протоколу и инструкциям к контроллеру дисплея, затем корректно запустить дисплей, согласно инструкциям.
Протокол связи настраивается согласно установленным библиотекам (или танцам с бубнами), как правило этот этап включает в себя точное указание пинов и каких-то первичных параметров. Если в datasheet дисплея нет последовательности инициализации, её можно поискать в датащит на контроллер, который встроен в дисплей.
При включении дисплея контроллер находится в неопределенном состоянии - информация о параметрах вывода информации (режим, яркость, контраст, состояние) отсутствует. Необходимо передать набор команд, который задаст основные параметры работы дисплея. Команды могут - включить дисплей, настраивать режим отображения (стандарт/инверсия, монохром/цвет, текст/графика), установить настройки отображения - разрешение, яркость, контраст.
Инициализация проводится по официальным инструкциям или особым предпочтениям опытных пользователей (гуру(профессионалов(не нас))).
ШАГ 7 - ТЕСТИРОВАНИЕ ПЕРЕДАЧИ ДАННЫХ
ДЕЙСТВИЯ - попробовать вывести на дисплей любую типовую графическую информацию, которую планируется на него выводить, проконтролировать правильность вывода.
ШАГ 8 - ПОДГОТОВКА ГРАФИЧЕСКОГО МАТЕРИАЛА ДЛЯ ВЫВОДА НА ДИСПЛЕЙ
ДЕЙСТВИЯ - разработка полного концепта отображаемого материала (графика + логика отображения), реализация используемого графического материала (шрифты, примитивы, изображения, анимации, видео, игры), реализация логики проекта (включая интеграцию других модулей), оптимизация производительности кода, оптимизация вывода данных, тестирование и отладка.
Первое действие - планирование того, что и как будет отображаться на дисплее. Нужно продумать структуру интерфейса, его элементы (меню, индикаторы, графики) и логику обновления данных. Важно учесть, как графические элементы будут взаимодействовать с пользователем и как часто они должны обновляться.
Второе - создание или адаптация графики, необходимой для проекта: шрифты для текста, примитивы (линии, прямоугольники, круги) для интерфейса, загрузка и настройка изображений, создание анимаций или видео, если они нужны. Здесь также настраивается разрешение и масштаб графики под параметры дисплея.
После предварительной готовности контента можно приступить к реализации проектной логики. Этот этап может включать в себя: обработку пользовательского ввода, работу с датчиками, обновление данных на дисплее в реальном времени и интеграцию других модулей (например, сенсоров, внешних устройств или интерфейсов связи).
Задача следующего этапа — убедиться в том, что код работает эффективно и не замедляет обновление дисплея. Можно оптимизировать алгоритмы обновления данных, буферизацию, и убедиться, что система работает стабильно при повышенной нагрузке. Особое внимание уделяется работе с большими объёмами данных или графикой.
Далее оптимизируется вывод данных - проверяется и дорабатывается сам процесс передачи данных на дисплей в целях минимизации задержки. Возможно, потребуется оптимизировать частоту обновления, частичное обновление экрана, корректировать параметры работы протоколов (SPI, I²C и т.д.) для лучшей скорости и эффективности.
На финальном этапе проводится всестороннее тестирование системы. Проверяется работа дисплея при различных условиях, стабильность обновления данных и корректность взаимодействия с другими модулями. В случае нахождения багов проводится отладка и исправление ошибок, чтобы система работала стабильно в реальных условиях.
ШАГ 9 - ТЕСТОВЫЙ ВЫВОД В РЕЛИЗ
ДЕЙСТВИЯ - запуск, мониторинг и настройка, создание документации, обратная связь, поддержка и обновление системы до релиза.
Ура, мы запустились! Но это ещё не тот самый повод возблагодарить всевышнего...
Даже после того, как система работает, полезно некоторое время понаблюдать за её поведением в реальных условиях. Это может выявить проблемы, которые не проявились на этапе тестирования: перегрев, нестабильность, сбои в длительной работе. Возможно столкнуться с необходимостью тонкой настройки, например - улучшения интерфейса под более приятный опыт пользователя.
Создание документации к проекту может быть полезно (а вообще - необходимо), особенно если в будущем планируются доработки или если систему будут использовать другие люди. Документация должна описывать, как устроена логика работы дисплея, какие настройки и параметры задействованы, а также - технические аспекты, связанные с подключением и конфигурацией.
Если система рассчитана на взаимодействие с пользователями-тестерами, может быть полезно получить обратную связь, чтобы понять, какие функции или элементы интерфейса можно улучшить. Это позволит сделать систему ещё более удобной и стабильной.
Возможны ситуации, когда будет нужно обновить прошивку или внести изменения в код (например, для добавления новых функций или улучшения производительности). Важно оставлять возможность для подобных изменений и своевременно реагировать на новые требования или проблемы.
ШАГ 10 - РЕЛИЗ
ДЕЙСТВИЯ - Дублируем пункт 9 в боевых условиях (меняя создание документации на доработку)
Вот тут уже мы говорим спасибо всем богам, чуть выдыхаем и даем себе возможность игнорировать неделю гневные тирады юзеров.
А далее уходим в бесконечные допил, обслуживание...
P.S.
- Энергопотребление - можно уделить внимание оптимизации энергопотребления системы, особенно если дисплей будет использоваться в мобильных или автономных устройствах. Это может включать управление яркостью дисплея, использование спящих режимов или сокращение частоты обновления.
- Управление ошибками и отказоустойчивость - можно реализовать системы проверки ошибок и диагностики. Например, что делать, если возникают проблемы с передачей данных между микроконтроллером и дисплеем, или если какие-то модули отказывают. Это обеспечит стабильность работы устройства в долгосрочной перспективе.
- Интерфейс взаимодействия с пользователем - если предполагается взаимодействие пользователя с дисплеем (например, через кнопки, сенсоры или другие элементы ввода), стоит заранее продумать и реализовать удобную логику пользовательского интерфейса.
- Тестирование на различных платформах - можно рассмотреть возможность тестирования на разных микроконтроллерах или даже симуляцию на ПК перед загрузкой кода на реальное устройство. Это позволит выявить платформо-зависимые ошибки.
- Физическая интеграция и корпус - если речь идёт о готовом устройстве, можно учесть физические размеры и интерфейсы дисплея при проектировании корпуса. Также важно продумать защиту экрана, особенно в условиях эксплуатации.
- Будущие обновления и масштабируемость - круто закладывать пространство и возможности заранее, использовать ООП, связь с управляющими серверами.
P.S.S.
Я начал вникать в эту тему день назад и соответственно - вообще не отвечаю за базар. Если что не так - у вас есть комментарии))
