Не всё, что происходит от обезьяны, является человеком.

Меню навигации для мобильных

e-Paper :: включить и управлять, но как?

Автор Slabovik, 23 Сен., 2022, 14:19

« предыдущая - следующая »

Slabovik

Ещё до вируса у меня был прикуплен вот такой девайс

Front.jpg Back.jpg

Экранчик на e-ink, он же e-paper. Хочется научиться им управлять, естественно, с самого нижнего уровня. Когда он ко мне попал, я задачу осилить не смог из-за отсутствия документации на них. Однако сейчас, благодаря потолстевшему интернету, задача уже не выглядит безнадёжной. Предлагаю в этой темке собрать всё воедино и... вдруг получится :)

Как видно из надписи, это контора WaveShare (https://www.waveshare.com/). И да, там нашлась страничка с описанием (https://www.waveshare.com/wiki/2.9inch_e-Paper_Module_Manual#Overview) этого дисплейчика.
Из внешнего вида и описания становится понятно, что интерфейс реализован последовательный. Для небольших дисплеев вполне неплохо. Но для начала хорошо бы изучить схемку вот этой синей соединительной платки

296x128 e-paper schematic.pdf

Хороший файлик, удаляющий непонятки. Становится ясно, что большой чип посередине - это TXS0108E, а не то, что на чипе нарисовано. TXS0108E - двунаправленный преобразователь логических уровней. Весьма удобен тем, что реально двунаправленный - переключать ничего не надо, всё делается внутри чипа автоматически (прям колдунство какое-то). Т.е. модуль смело подключается к 5V питанию. 3.3 вольта, необходимые e-ink панельке, получаются из пятиногого линейного регулятора. Ну а преобразователь с индуктивностью, что справа - это пиание для внутренностей e-ink, причём на платке только силовые элементы, управляется он непосредственно с кристалла e-ink.

Полагаю, вот так можно отобразить этот экранчик, как компонент электрической схемы

Экран как компонент.png

Питаться же всё это может, благодаря распаянному преобразователю уровней, от любого напряжения в пределах 3.3~5 вольт, так что к той же ардуине подключить получится без проблем.

Остаётся вопрос: как этой штукой управлять?

Там же, на WaveShare, в самом низу странички (https://www.waveshare.com/wiki/2.9inch_e-Paper_Module_Manual#Resources) есть кое-какие материалы. В частности, даташит

296x128 e-paper v2 specification.pdf

в котором можно найти интересную таблицу с командами - на 20-й странице. Однако беглое прочтение пока даёт изрядное количество вопросов. В частности, в описании первой же команды почему-то первый байт данных сопровождён сигналом DC =1, а последующие - нет. Не расшифрованы аббревиатуры. Не показаны значения и зависимости от настроек управляющих напряжений (ох, из много там). Всё это надо искать где-то ещё. Тут надо понимать, что WaveShare - не производитель дисплея, он сделал только платку-адаптер. А описание - корявая копипаста откуда-то ещё. Для начала нужно разобраться, что вообще за контроллер установлен на дисплее и кто его производитель. Возможно, тогда найдётся и более подробная информация.
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.

Shaman

Интересно т.е. если судить по этой информации
↓ спойлер ↓
Выделение_063.png
[свернуть]
Пиксели управляются побайтово, 1-й байт пиксель с 1 по 8, 4736-й байт последняя группа пикселей. А как контроллер распознает порядковый номер байта Или всегда нужно полностью формировать матрицу? Тогда я не понимаю как сделать частичное обновление Единственное, что приходит в голову это в матрице менять биты и передавать её всю. Но тогда непонятно как экран может не поддерживать частичного обновления если оно чисто программное

Slabovik

#2
Насколько я понимаю даташит, если необходимо частичное обновление, можно поступать двумя способами.
Первый: использовать команды SetRAMX и SetRAMY для установки адресного счётчика. Это придётся делать столько раз за одно обновление, сколько строк необходимо обновить.
Второе: есть на мой взгляд более интересная команда "Set Ram X address Start/End position" и "Set Ram Y address Start/End position". Как написано, они задают "окно", в которое производится запись поступающих байт изображения. Поскольку согласно описания команды WriteRAM, все поступающие после получения контроллером этой команды байты интерпретируются как байты изображения (до тех пор, пока контроллер не получит какую-либо другую команду), а адресный счётчик после получения очередного байта автоинкрементируется по X, а по заполнении строки автоинкрементируется по Y, очень хочется полагать, что такое же поведение сохраняется при задании "окон" для записи. Отличие только в том, что автоинкрементация будет происходить только в рамках этого заданного окна.
Но разъяснения по работе команд практически отсутствуют, поэтому пока это только мои предположения.

зы: я, похоже, нашёл производителя чипов-контроллеров матриц. Это Solomon Systech: https://www.solomon-systech.com/
Копаясь в подворачивающихся даташитах наткнулся вначале на этот

SSD1606.pdf

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

Как оказалось, Соломон не раздаёт даташиты направо и налево: https://www.solomon-systech.com/product-category/bistable-display/
Понять можно - чипы буквально встраиваются (вклеиваются) в шлейфы и инфа по ним нужна реальным производителям. Но хотя бы зная названия, кое-что можно найти в хранилищах интернета. Вот, например, нашёлся сразу:

SSD1675.pdf

это для двуцветной матрицы 160x296...
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.

Slabovik

#3
Похоже, нашёл настоящее название моей матрицы. Под стикером продавца удалось прочитать стикер производителя (заклеивают, гады). Прочитал я CDEM029T94. Однако гугель такого названия не находит, зато быстро находит GDEM029T94. Ну что же, тот же самый китайский Good Display... И этот тип уже не производится. Думаю, не беда - чтение даташитов показало, что они весьма похожи, независимо от интерфейса. Зато там чётко написано название контроллера матрицы: SSD1680. Полагаю, хорошей практикой на УГО индикатора указывать и тип контроллера тоже - это поможет снимать непонятки.

SSD1680.pdf

Начинает проявляться желание хранить копию памяти индикатора где-то "рядом", желательно в ОЗУ (вообще, ОЗУ для хранения изображения - вещь очень удобная, но в ряде случаев есть конфликт за доступ к этой области памяти между ЦП, видеоконтроллером и контроллером ПДП впридачу). У МК же ОЗУ как правило очень маленькое. У индикатора чтение из его ОЗУ довольно корявое.

Реализовать можно двумя путями. Первый - взять контроллер "потолще". Как минимум с 8 кБ ОЗУ (очень скромно), но для реализации всех 4-х оттенков (или двух цветов) даже при таком разрешении необходимо (296/8)*128=4736 байт памяти на каждый слой, а здесь их два. Оптимально - 16 кБ, и это если ещё не заниматься обсчётом каких-нибудь картинок, подаваемых извне.

Второй вариант - прикрутить внешнюю микросхему ОЗУ. Минусы этого решения - надо много выводов + схема. Хотя, к 8051 прикрутится вообще без проблем (оно там изначально заточено для таких случаев), к некоторым Mega тоже можно также, только я сам не пробовал ещё. Z80/8080 - вопрос вообще не стоит, т.к. там памяти сколько захочешь - столько и будет.

Полагаю, надо сформировать хоть какое-то т.з., задающее направление, ибо имеющейся информации уже достаточно для следующего шага. Из возможных МК можно взять что-нибудь из этого: 8051/AtMega/Z8/STM8... STM32 пока не возьму, т.к. с asm там будет тяжеловато.

зы: но если ограничиться статической картинкой (картинками) или текстовой информацией, то такую картинку и шрифты очень даже можно ранить в памяти программ, которой достаточно много.
зызы: зафиксирую ссылку на преобразователь картинок для дисплеев https://github.com/abao66669999/Good-Display-Software

p.s. План действий:
Первое - соединить экран с МК. Проще всего интерфейс организовать программно (если что, смотреть и управлять легче), в случае успеха в следующих шагах, можно изменить на аппаратный (при этом аппаратный обязательно будет 4-проводным, а вот программный в силу гибкости можно завести и на 3 провода, т.е. избавиться от провода Data/Command).
Второе - научиться инициализировать экран и выводить на него статическую картинку.
Третье - научиться частичному обновлению экрана. Тут будет сложность с обновлением смежных пикселей, попадающих в один байт экранного ОЗУ. Придётся научиться чтению - модификации этих байт.
Четвёртое - нарисовать шрифты и научиться выводить текст шрифтами. При этом суть происходящего заключается в том, что шрифты - это маленькие картинки.

Пока наверное всё на данный момент. Просто дальше может (не обязательно, зависит от конкретики) понадобиться значительной величины ОЗУ.

ЗЫ: Для тех, кто не любит "много проводов", нашёл редко встречающуюся вещь - RAM со SPI интерфейсом. Объём 32кБ: 23K256.pdf.
Но 5 вольт питания она не умеет, что несколько ограничивает круг применения (универсальный преобразователь уровня наверное поможет).
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.

Slabovik

Не совсем понятно, что делать с выходом-входом DIN экрана. Он двунаправленный. Вариантов мне видится целых три. Самый простой - не использовать чтение из этого табло. В принципе, можно. Минусы - надо иметь копию RAM где-то локально, чтобы иметь возможность знать, что там записано для того, чтобы можно было производить битовые операции (рисовать спрайты, окна и т.п.)
Второй вариант - монтажно объединить выходы DI и DO проца (RXD, TXD). Минусы: образуется LoopBack и нужен арбитраж. Также нужно по-любому выключать DO, когда читаешь с DIN, иначе к.з. получается.
В случае же, если использовать чисто софтверное управление, то DI на проце можно не использовать. Использовать только DO - остаётся возможность хардверного вывода (используя COM-порт в режиме SPI), а для чтения переходить в софтверный режим, выключая порт, переводя ногу на чтение и формируя CLK программно же. там всё равно на чтение экран на порядок медленнее, чем на запись.
Третий вариант - городить хардверный арбитр ноги DIN, чтобы DIN и DO не устраивали к.з. Можно, но это лишний корпус.

зы: всё-таки последовательные интерфейсы в основном не удобные...
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.

Slabovik

Развёл под ЛУТ макетку-монстрика для опытов с экраном. На борту внешняя память, экран, питание, COM-порт в роли модема с преобразователем уровней в RS-232 на MAX232.

Макетка-для-экрана.png
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.

Slabovik

Стыдоба... Спаял ещё в январе...

Пробник.jpg Пробник-ботом.jpg

надо хоть что-то сделать наконец...
Общением на форуме подпитываю свою эгоистичную, склонную к самолюбованию сущность.