ГП с трассировкой — устройство и принцип работы

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

Шейдерные процессоры выполняют арифметические операции, в то время как RT-ядра разработаны и оптимизированы именно для операций трассировки лучей.

Внутри RT-ядер находится два вычислительных движка. Первым начинает работу движок, занимающийся поиском пересечений лучей с объемами-коробками BVH.

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

Как и шейдерные процессоры, RT-ядра работают параллельно друг с другом. На современных видеокартах это позволяет обрабатывать несколько миллиардов лучей в секунду, а общий счет выполненных операций при этом достигает триллионов. Например, NVIDIA GeForce RTX 3090 родом из 2022 года выполняет за одну секунду до 36 триллионов операций. Тогда как самый мощный суперкомпьютер 2000 года, полагающийся на грубую вычислительную мощность центральных процессоров, за то же время осуществлял лишь 12,3 триллиона.

Чем отличается трассировка лучей

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

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

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

Это позволяет хорошо интерполировать непрямое освещение, не прибегая к огромному количеству вычислений. Данный способ является одним из методов трассировки, который используется системой освещения Lumen в графическом движке Unreal Engine 5. Второй вариант техники называется трассировкой лучей в экранном пространстве. Тут используется совершенно другой подход на основе трех составляющих: изображения, полученного с помощью традиционного рендеринга, карты глубины кадра и карты нормалей. Из отрендеренного изображения берется информация о цвете объектов. Карта глубины показывает, насколько далеко они находятся от камеры.

В свою очередь, карта нормалей сообщает, в какую сторону полигоны отражают свет.

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

Главная проблема подобного подхода в том, что он может использовать только отрендеренные кадры с экрана. То есть, когда деревья исчезнут из поля зрения игрока, пропадет и их отражение в озере. Такую технику трассировки лучей используют многие игры прошлых лет, в том числе — Cyberpunk 2077.

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

Что такое трассировка пути

Компьютерная графика, используемая в современном кинематографе, основана на одной из техник трассировки лучей — трассировке пути (Path Tracing). Этот алгоритм появился в далеком 1986 году, но из-за своей сложности лишь спустя 30 лет начал массово использоваться для создания графики в фильмах.

Чтобы понять, почему все это время трассировка пути оставалась неосуществимой, ознакомимся с основами построения подобной картинки. Сначала 3D-художники вручную моделируют форму объектов в сцене, а программное обеспечение для рендера разбивает их на мелкие треугольники — полигоны.

Затем на модели накладываются текстуры, которые симулируют материалы определенного цвета и типа — например, шероховатые, гладкие или стеклянные.

Готовые объекты и источники света: солнце, небо, фонари, размещаются в нужных положениях на 3D-сцене. После этого добавляется виртуальная камера и запускается процесс рендеринга — благодаря ему картинка в кадре визуализируется в виде привычного 2D-изображения.

С помощью трассировки пути имитируются отражения света от различных материалов. К примеру, попав на матовую красную черепицу крыши, часть света ей будет поглощена, а другая часть — отразится красным. Отраженный свет от каждого объекта попадает в виртуальную камеру, внося свой вклад в создание изображения.

Для образования каждой точки конечной картинки осуществляется несколько тысяч подобных расчетов. А для формирования одного кадра изображения с разрешением 4К их потребуется несколько миллиардов.

Именно из-за этого долгое время создание изображений с использованием трассировки пути было очень медленным процессом. Например, в 2016 году рендерингом фильмов «Зверополис» и «Моана» занималась ферма из тысяч серверов, которые производили вычисления в течении нескольких месяцев — и это всего для двух часов анимации.

Формирование изображения

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

Если показать на картинке траектории всех лучей, которые просчитываются для этой сцены, то она заполнится огромным количеством линий. Поэтому рассмотрим данный процесс на примере одной точки. Первый луч испускается из ее центра и попадает на полигон какого-либо объекта в кадре.

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

В результате такого подхода формируется изображение с правильной перспективой.

Глобальное освещение

Мы рассмотрели, как цвет полигонов передается точкам виртуального кадра. Но для получения реалистичной сцены нужно просчитать глобальное освещение объектов — ведь яркость и оттенок цвета каждой точки зависит именно от него.

Для этой цели комбинируются два вида расчетов: прямого (Direct) и непрямого (Indirect) освещения. При первом виде вычислений просчитываются лучи непосредственно от источников освещения — солнца, неба и ламп. Они называются теневыми.

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

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

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

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

Не менее важно и то, что направление распространения вторичных лучей зависит от свойств материала объекта. Если он идеально гладкий, то угол падения луча будет равен углу его отражения — благодаря этому поверхность будет выглядеть зеркальной. А от шероховатого материала того же цвета лучи будут отражаться в случайные стороны — из-за этого он, как и положено, будет отображаться матовым.

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

Сложность трассировки пути зависит от количества источников света, количества лучей на точку и предельно допустимого числа их дополнительных отскоков. У сцены из первого примера с замком используется четыре источника света, тысяча лучей на точку и 12 отскоков. Чтобы визуализировать один ее кадр в 4К, нужно просчитать примерно 400 миллиардов лучей.

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

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

Иерархия ограничивающих объемов

Еще одна ключевая трудность при трассировке пути — узнать, на какой именно полигон луч из точки попадает первым, чтобы определить ее основной цвет. В случае, если полигонов десятки или сотни, можно воспользоваться вычислением траектории луча с помощью математических уравнений. Но в современных сценах их миллионы, поэтому этот способ потребует огромных вычислительных ресурсов. Чтобы упростить данный процесс, используется иерархия ограничивающих объемов (Bounding Volume Hierarchy, BVH). При таком подходе сцена разделяется на виртуальные объемы-коробки, в каждой из которых оказывается одинаковое количество полигонов.

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

Положение каждой коробки в пространстве выровнено строго по осям координат. Когда луч начинает свое путешествие из точки, его направление сравнивается с координатами первой пары больших коробок. Коробка, которую он не пересекает, исключается из расчетов — как и все более мелкие, на которые она поделена.

Затем направление луча сравнивается с координатами двух меньших коробок, на которые разделена исходная. И так до тех пор, пока луч не достигнет самой маленькой коробки.

В виду ограничения фотоматериалов

ПРОДОЛЖЕНИЕ СЛЕДУЕТ...

Будучи творческим человеком и техногиком, я обожаю при первой возможности апгрейдить своё оборудование. Время от времени я мониторю маркетплейсы в поисках чего-то новенького и в этот раз я наткнулся на настоящий мультитул для Embedded-разработчика — контроллер I2C/SPI/UART/JTAG в одной коробочке и всё это всего за 1.000 рублей... Конечно я не смог пройти мимо этой штучки и в рамках сегодняшней статьи хочу рассказать что оно из себя представляет и как с ним работать. Жду вас под катом!

❯ Что за устройство?

На самом деле такой формат статей для меня «в новинку», до этого я ни разу не делал обзоров на оборудование. Да и мой инструментарий слишком зауряден, чтобы делать ещё одну статью уровня «почему Quciko T12 лучше любой 900M станции» или «почему Вам не стоит покупать компрессорный люкей в 2025 году». Однако обзоров на сегодняшний гаджет я не нашёл, несмотря на его огромную пользу как для Embedded-разработчиков и инженеров, так и мастеров по ремонту смартфонов, планшетов и ноутбуков.

Во время подготовки статьи о том, как я написал BIOS для игровой консоли от Waveshare, в рекомендациях мне попадались другие товары от этого производителя — в том числе и сегодняшний гаджет. Меня сразу привлекла возможность переключения 3v3->5v логики и обширный набор поддерживаемых шин. В официальной вики были описаны следующие характеристики:

• Шины: 1x SPI с двумя чип-селектами (можно подключить до двух устройств на одну шину), 1x I2C, 1x JTAG (полноценный, с ресетом!) и 2x UART с дополнительными линиями CTS/RTS для совместимости с классическими COM-портами.

• Используемый контроллер: WCH CH347. Некоторым читателям чип может показаться знакомым по аналогии с классическим CH341A.

• Питание: 5В, 3.3В, потребление ~65мА на VBus. Есть самовосстанавливающийся предохранитель на «входе».

Я сразу смекнул, что смогу использовать гаджет как для восстановления программно-убитых устройств по типу КПК, так и для отладки своих собственных самоделок, благо набор шин к этому располагает. Устройство приехало ко мне примерно через месяц, в небольшом пакетике и брендовой коробочке, в которую входило само устройство, кабель USB Type-B (ну почему не Type-C?), Dupont-провода в IDC-коннекторе для всех шин, а также небольшой мануал. Нареканий к доставке кроме скорости не возникло.

Сам гаджет представляет из себя компактную металлическую коробочку с «ушками» для удобного крепления на столе или стене. Сверху расположена шпаргалка по распиновке и режимам работы CH347, а также светодиодные индикаторы для UART.

Разбирается гаджет очень просто: достаточно лишь открутить несколько винтов с обеих боковых пластин устройства и перед нами открывается вид на плату. Схемотехника здесь простейшая: самовосстанавливающийся предохранитель, линейный регулятор AMS1117, который питает контроллер и нагрузку на VCC (до ~600мА), сам CH347, а также набор ключей для согласования режимов работы. CH347 — это не просто ASIC, а вполне себе полноценный микроконтроллер, прошивку которого можно обновить, правда SDK для использования CH347 как МК производитель не предоставляет.

После подключения гаджет радостно зажег индикатор PWR, подтвердив свою работоспособность, а значит пришло время протестировать возможные варианты использования!

❯ UART

С UART всё просто и понятно: нам достаточно лишь выбрать желаемый режим работы (M0 — двухканальный UART, остальные режимы — UART + I2C/SPI или UART + JTAG) с помощью тумблера и подключить/припаять Dupont'ы к соответствующим пинам на плате. UART здесь достаточно быстрый: при двухканальном режиме работы, на UART0 можно добиться до 9Мб/с (мегабод), а на UART1 — до 7.5Мб/с.

В качестве теста я решил снять лог загрузки со своего проекта самодельной игровой консоли. Для работы с UART я привык использовать Putty: сначала я припаял RX/TX и массу, затем запустил Putty и выбрал COM-порт, соответствующий первому каналу, установил бодрейт в 115200 и включил консоль:

Всё работает! В целом, гаджет можно использовать и для прошивки более сложных устройств: например многие смартфоны и кнопочные телефоны всё ещё имеют альтернативный режим прошивки через UART, а ретро-телефоны Samsung и LG так вообще не имеют альтернатив — если нет специального JIG, то остаётся лишь вызванивать RX/TX с разъёма и подпаиваться напрямую к UART процессора!

❯ SPI/I2C

С SPI и I2C уже всё чуточку интереснее. Дело в том, что как вы уже могли понять — чип использует свой собственный проприетарный протокол для организации моста между программой на ПК и шиной данных. Для работы с этим протоколом производитель предоставляет уже готовую библиотеку для Windows начиная с 2000, так что возможно у чипа есть перспективы для оживления легаси пром. оборудования. Для Linux же есть альтернативные драйвера, которые пробрасывают CH347 как обычные spidev и i2c-dev устройства.

Для проверки коммуникации можно использовать специальную тестовую программу из SDK, которая позволяет отправлять произвольные данные и даже прошивать флэшки 25 'ой и EEPROM'ки 24'ой серии.

Давайте же попробуем написать что-нибудь полезное! Например, подключим к гаджету 1.8-дюймовый дисплей и что-нибудь на него выведем.

С разводкой дисплея проблем не возникает: SDO к MOSI, SCK к CLK, VCC к VCC и BL (питание подсветки), однако для управления DBI-дисплеями необходимы ещё две дополнительные линии: D/C (линия, определяющая как интерпретировать байт на входе), а также RESET для аппаратного сброса контроллера. И с этим проблем тоже не возникает: у контроллера есть как минимум четыре свободных GPIO, два из которых мы с вами и будем использовать для управления линиями дисплея — GPIO6 (CTS на UART1) и GPIO7 (RTS на UART).

Далее я начал изучать PDF-ку с документацией сомнительного качества и писать код инициализации. Начинается всё с получения контекста устройства с помощью функции CH347OpenDevice, которая принимает в себя индекс нужного контроллера в системе и возвращает непонятный идентификатор (вероятно WinUSB?). Интересно то, что в остальном API используется не идентификатор, а как раз тот самый индекс, который в большинстве случаев будет 0. Далее мы получаем информацию об устройстве и сверяем режим работы, если он отличается от нужного — выбрасываем исключение:

Далее настраиваем SPI-контроллер. На выбор есть все три существующих режима, настройки полярности и возможность вручную дергать один из двух доступных ChipSelect'ов, а также тайминги. Частота работы определяется предустановленным набором делителей — 60МГц, 30МГц, 15МГц и т.п. Не забываем настроить таймаут каждой USB-транзакции:

И инициализируем дисплей. Здесь есть важный момент: функция CH347GPIO_Set устанавливает состояние всего GPIO-контроллера в чипе и поэтому принимает в себя три битовые маски с конфигурацией каждого пина. Функции GPIO стандартные — вход/выход, плюс обработка прерываний с помощью специального callback'а:

CH347GPIO_Set(deviceIndex, 1 << config.IOReset, 1 << config.IOReset, 0);
this_thread::sleep_for(16ms); /* HW reset */
CH347GPIO_Set(deviceIndex, 1 << config.IOReset, 1 << config.IOReset, 1 << config.IOReset);

/* Software initialization */
SendCommand(EMIPICommandList::cmdSWRESET, 0, 0, 16);
SendCommand(EMIPICommandList::cmdSLPOUT, 0, 0, 0);

/* Framerate and refresh */
uint8_t frameRateControlRegister[] = { 0x01, 0x2C, 0x2D };
SendCommand(EMIPICommandList::cmdFRMCTL1, frameRateControlRegister, sizeof(frameRateControlRegister), 0);
SendCommand(EMIPICommandList::cmdFRMCTL2, frameRateControlRegister, sizeof(frameRateControlRegister), 0);
SendCommand(EMIPICommandList::cmdFRMCTL3, frameRateControlRegister, sizeof(frameRateControlRegister), 0);
SendCommand(EMIPICommandList::cmdFRMCTL4, frameRateControlRegister, sizeof(frameRateControlRegister), 0);

/* Power control */
uint8_t powerControlRegister1[] = { 0xA2, 0x02, 0x84 };
SendCommand(EMIPICommandList::cmdPWCTL1, powerControlRegister1, sizeof(powerControlRegister1), 0);

uint8_t powerControlRegister2 = 0xC5;
SendCommand(EMIPICommandList::cmdPWCTL2, &powerControlRegister2, sizeof(powerControlRegister2), 0);

uint8_t powerControlRegister3[] = { 0x0A, 0x00 };
SendCommand(EMIPICommandList::cmdPWCTL3, powerControlRegister3, sizeof(powerControlRegister3), 0);

uint8_t powerControlRegister4[] = { 0x8A, 0x2A };
SendCommand(EMIPICommandList::cmdPWCTL4, powerControlRegister4, sizeof(powerControlRegister4), 0);

uint8_t powerControlRegister5[] = { 0x8A, 0xEE };
SendCommand(EMIPICommandList::cmdPWCTL5, powerControlRegister5, sizeof(powerControlRegister5), 0);

uint8_t powerControlVCOMRegister = 0x0E;
SendCommand(EMIPICommandList::cmdPWCTL6, &powerControlVCOMRegister, sizeof(powerControlVCOMRegister), 0);

/* Addressing */
uint8_t madCtlMode = 0xC8;
SendCommand(EMIPICommandList::cmdMADCTL, &madCtlMode, sizeof(madCtlMode), 0);

uint8_t rasetRegister[] = { 0x0, 0x0, 0x0, 0x7f };
uint8_t casetRegister[] = { 0x0, 0x0, 0x0, 0x9f };
SendCommand(EMIPICommandList::cmdRASET, casetRegister, sizeof(rasetRegister), 0);
SendCommand(EMIPICommandList::cmdCASET, rasetRegister, sizeof(casetRegister), 0);

uint8_t colorMode = 0x05; /* RGB565 */
SendCommand(EMIPICommandList::cmdCOLMOD, &colorMode, sizeof(colorMode), 0);
SendCommand(EMIPICommandList::cmdDISPON, nullptr, 0, 0);

...

void CDisplay::SendCommand(EMIPICommandList command, uint8_t* data, size_t length, uint32_t delay)
{
uint8_t cmd = (uint8_t)command;

/* Send command */
GPIOSet(deviceIndex, config.IODataCommand, 0);
CH347SPI_Write(deviceIndex, 0, sizeof(cmd), sizeof(cmd), &cmd);

/* Send arguments (if any) */
if (data && length)
{
GPIOSet(deviceIndex, config.IODataCommand, 1);
CH347SPI_Write(deviceIndex, 0, length, length, data);
}

this_thread::sleep_for(chrono::milliseconds(delay));
}

Теперь можно запустить программу и посмотреть на результат. Если вы увидели шум (или мусор) на экране — значит вы всё делаете правильно и контроллер успешно проинициализирован.

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

Теперь можно что-нибудь вывести. Подготавливаем изображение, преобразовав в 16-битный массив пикселей, переводим контроллер в режим записи в VRAM, отправляем изображение:

void CDisplay::CopyFrameBuffer(uint8_t* pixels)
{
uint8_t cmd = (uint8_t)EMIPICommandList::cmdRAMWR;

/* Send command */
GPIOSet(deviceIndex, config.IODataCommand, 0);
CH347SPI_Write(deviceIndex, 0, sizeof(cmd), sizeof(cmd), &cmd);

GPIOSet(deviceIndex, config.IODataCommand, 1);

uint32_t frameBufferSize = config.Width * config.Height * 2;
uint32_t offset = 0;

CH347SPI_Write(deviceIndex, 0, frameBufferSize, 2, pixels);
}

И пишем небольшую демо-программу:

int main(int argc, char** argv)
{
CDisplayConfiguration config = {
ChipSelectIndex, ResetGPIOIndex, DataCommandGPIOIndex, 128, 160
};
CDisplay display(config);
display.CopyFrameBuffer(beach);


return 0;
}

Результат — на дисплее появляется картинка!

Потенциальных применений у такого гаджета много: можно сделать красивые анимированные часы, мониторинг датчиков, показ уведомлений или дублировать окно с основного ПК. А ведь когда-то ради такого покупали LPT-провода, дисплеи от Сименсов и вручную превращали параллельную шину в последовательную...

❯ Заключение

Вот такой интересный гаджет выпустила компания Waveshare — и, что радует, по очень приятной цене! Ссылку по понятным причинам прилагать не буду, но при желании вы сможете его найти на всех трёх крупных маркетплейсах. Кроме того, можно купить Breakout-плату с тем же самым чипом за ~500 рублей, но там не будет таких удобных переключателей и Dupont'ов.

К сожалению, теста JTAG в статье не будет. У меня пока нет готовых к работе необычных гаджетов, где можно было бы протестировать OpenOCD... однако мой HTC Dream всё ещё ждёт свою прошивку модема!

А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.

Если вам понравилась статья...

И у вас появилось желание что-то мне задонатить (например прикольный гаджет) - пишите мне в телегу или в комментариях :) Без вашей помощи статьи бы не выходили! А ещё у меня есть Boosty.

Подготовлено при поддержке @Timeweb.Cloud

В данной статье я хочу Вам рассказать про датчик HEDR(от компании avago technologies) - это двухканальный инкрементальный оптический датчик, предназначен для измерения пройденного пути, линейной скорости, угловой скорости и направлении вращения вала.
С помощью данного датчика будет реализован энкодер на базе микроконтроллера STM32, который будет производить вычисление пройденного пути.

В данной статье будет рассмотрено:

• Принцип работы датчика HEDR-5420-ES214;

• Схема подключения к микроконтроллеру STM32;

• Программная реализация (расчет пройденного пути и вывод информации на дисплей).

Технические характеристики датчика HEDR-5420-ES214

Документация на датчик

• Напряжение питания [ 4.5 - 5.5В ];

• Тип выхода [ квадратурный ];

• Диаметр вала [ 5 мм ];

• Разрешение [ 200 отсчетов на оборот ];

• Рабочая температура [ от -10°C до +85°C ].

Принцип работы датчика HEDR-5420-ES214

Устройство состоит из трех основных компонентов:

• Источник света (светодиод, формирующий поток света);

• Оптическая система (линза, обеспечивает фокусировку и отражение света);

• Фотодетектор.

Линза фокусирует излучаемый свет на кодовое колесо (диск с чередующимися отражающими и неотражающими участками), при вращении диска, отраженный свет проходит обратно через оптическую систему и попадает на фотодиоды, таким образом на их поверхности формируется чередующийся рисунок света и тени, соответствующий узору кодового диска.

Эти изменения интенсивности света преобразуются в внутренние сигналы А и В, которые проходят через компараторы в составе обработки сигналов, на выходе формируются два цифровых прямоугольных сигнала - канал А и В, находящиеся в квадратурной фазе на 90°, что позволяет микроконтроллеру определять направление вращения вала, к примеру:

• если канал А опережает канал B - вращение происходит в одну сторону;

• если канал B опережает канал А - вращение происходит в противоположную сторону.

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

Схема подключения к микроконтроллеру STM32

В данной схеме используются преобразователь напряжения DA1 (+12V +5V) и стабилизатор напряжения DA2, дисплей подключается к выводам МК 21_SCL_I2C2 и 22_SDA_I2C2, датчик HEDR подключается к выводам МК 29_CH.A и 30_CH.B, данные сигналы сначала проходят через делители, R17-R18-[CH.A] и R15-R16-[CH.B], так как датчик работает от +5V, сигналы соответственно тоже у него +5V, я всегда стараюсь дополнительно защитить МК, после делителя амплитуда сигналов снизится до +3.3V, копипастить информацию по описанию узлов преобразователя, стабилизатора, узла обвязки напряжения питания и резонатора для МК не особо хочется, поэтому кому интересно можно почитать статью [Модуль обработки и коммутации данных, с внешними управляющими устройствами по RS-485 на STM32]
Настройка микроконтроллера STM32F030CCTx в CubeIDE

Настройка RCC и SYS (в RCC выбираю Crystal/Ceramic Resonator, так как у меня внешний кварц на 8 МГц)

Настройка дисплея

Взаимодействие дисплея с МК будет через I2C2

Настройка выводов узла подключения датчика HEDR

• TIM1_CH1 (к данному выводу будет подключаться сигнал CH.A);

• TIM1_CH2 (к данному выводу будет подключаться сигнал CH.B).

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

Encoder Mode TI1 and TI2 данный параметр указывает, что используется оба канала датчика (A и B), это дает разрешение X4 - т.е. счетчик будет увеличиваться на 4 шага за один полный оборот.

Описание режимов

TI1 - подсчет ведется по фронту одного канала А, направление определяется по уровню В, разрешение 1.8 градусов;

TI2 - аналогично логике TI1, но базируется на канале В;

TI1 and TI2 - подсчет ведется на каждом фронте обоих каналов (А+, А-, В+, В-), направление определяется автоматически, т.е. количеством импульсов на оборот 200, я получаю 800 шагов на оборот, разрешение будет 0.45 градусов.

Input Filter - включает цифровую фильтрацию входного сигнала, помогает убрать дребезг и шум, значения от 0 до 15, чем выше значение, тем надежнее фильтрация, но будет повышаться задержка.

Polarity (Rising Edge) - счетчик реагирует на восходящие фронты сигнала.

Настройка Clock

Программная реализация ведомого устройства

Ссылка на скачивание исходного кода [ https://t.me/ChipCraft В закрепленном сообщении [ #исскуствомк_исходный_код — Исходный код для Encoder_HEDR_5420_STM32F030CCTx].

Модуль process_Encoder

Данный модуль реализует считывание сигналов с инкрементального датчика HEDR и вычисляет:

• Количество импульсов на оборот;

• Пройденную дистанцию;

• Отображение данных на дисплее.

#define ENCODER_MODE_X4 4

Данный параметр отражает режим подсчета импульсов, привожу формулу

Этот режим обеспечивает максимальную точность - 0.45 на один шаг.

#define WHEEL_DIAMETR_M 0.230f // 230 мм
#define WHEEL_RADIUS_M (WHEEL_DIAMETR_M / 2.0f)

Здесь я задаю геометрические размеры колеса, на валу которого установлен датчик%

Диаметр колеса 230 мм (0.230м);

Радиус вычисляется так:

#define STEPS_PER_REV (ENCODER_PPR * ENCODER_MODE_X4)

Максимальное количество шагов за один оборот

#define CIRCUMFERENCE_M (2.0f *M_PI * WHEEL_RADIUS_M)

Длина окружности колеса - это путь, который проходит колесо за один оборот

т.е. при моем радиусе 0.115, получится за один полный оборот 0.72 м.

Функция display_init() - инициализация дисплея

• Инициализируется драйвер дисплея;

• Выполняется заливка экрана черным цветом;

• На дисплее на 2 секунды отображается стартовый экран с надписью ''ChipCraft";

• После задержки экран очищается для дальнейшей работы.

библиотеку для работы с дисплеем я взял с [https://github.com/afiskon/stm32-ssd1306/tree/master]

Функция display_update()

Отвечает за визуализацию информации на дисплее:

• Экран предварительно очищается с помощью ssd1306_Fill(Black);

• В верхней части по центру отображается надпись «Encoder»;

• Ниже последовательно выводятся:

  • количество импульсов;

  • дистанция;

• Буфер графики передается на дисплей вызовом ssd1306_UpdateScreen()

Функция encoder_Handler()

Логика работы:

• считывание текущего значения таймера;

• определение разницы (delta) между текущим и предыдущим значениями;

• накопление общего счетчика enocoder_position;

• вызов функций для вычисления дистанции и обновление дисплея.

Функция get_distance_m() - вычисление пройденной дистанции

Переводит количество импульсов датчика в физическую длину пути в (метрах).

process_Encoder.c

Модуль proj_main() - главный метод

• Выполняется инициализация дисплея;

• Запуск таймера;

• Запуск функции encoder_Handler().

proj_main.c

Если статья показалась Вам интересной, буду рад выпустить для Вас еще множество статей исследований по всевозможным видам устройств, так что, если не хотите их пропустить — буду благодарен за подписку на мой ТГ-канал.