Розробляючи пристрій на основі ARM, який повинен відображати просту графіку на кольоровому РК-дисплеї, як слід найкраще займатися розробкою речей для швидкого оновлення, бажано, не прив'язуючись до конкретного постачальника ARM чи LCD? У моєму теперішньому проекті використовується чорно-білий дисплей, який можна блискавично рухати через порт SPI на PIC (перемальовуючи складний дисплей за 1/60 секунди). Здається, звичайні кольорові РК-дисплеї мають порт SPI, але навіть заповнення РК-дисплея 160x120 суцільним кольором займе 30 мс, а 320x240 потребує 120 мс (найкращий 10МГц).
Якби можна було пощадити шпильки контролера, паралельний режим міг би бути кращим, але я не знаю жодного сімейного способу підключення паралельного інтерфейсу, не вимагаючи трьох окремих інструкцій щодо зберігання пам’яті для кожного пікселя (один для встановлення даних, один встановити високий вихідний сигнал та один - низький. Деякі мікросхеми ARM мають інтерфейси шини пам’яті, але вони часто хочуть робити такі речі, як мультиплексна адреса та дані, або призначати багато штифтів для виведення невідповідних бітів адреси (РК-дисплею знадобиться лише один біт адреси).
Дивлячись на ILI9320 від ILITEK або HD66789 від Renesas, одним із підходів, який видається цікавим, буде використання CPLD для перетворення SPI в паралельні дані та включення режиму, який виводить піксель на біт. Переглядаючи аркуш даних Renesas, можливо, можна отримати піксель на біт запису з мінімальним обладнанням (не потрібен CPLD), змусивши всі біти даних паралельного порту відстежувати штифти даних послідовних даних, використовуючи серійний режим для всього, крім пікселя пише, і використовуючи функції порівняння / маскування, щоб або всі нульові пікселі були прозорими, і всі пікселі встановлювали вибрані біти в GRAM, або всі пікселі були прозорими, а пікселі з усіма нулями очищали вибрані біти. Розділ "Особливості" в інформаційному аркуші IKITEK дозволяє припустити, що він має подібний функціонал, але карта реєстру не відповідає "
Якщо припустити, що в основному в коді будуть відображатися тексти та графіки суцільного кольору, ідеальним підходом може бути використання CPLD для інтерфейсу SPI-порта ARM до паралельного порту дисплея, а також дозволити завантаження CPLD кольорами переднього плану / фону. Це було б особливо приємно, якби у вас були засоби для написання «прозорих» пікселів. Враховуючи шрифт як двоколірну растрову карту, можна просто завантажити дані шрифту безпосередньо у порт SPI; це дозволило б відображати дані шрифту зі швидкістю один піксель кожні два такти ARM. З іншого боку, CPLD, достатній для вирішення такого завдання контролю дисплея, коштуватиме приблизно 2 долари.
Який найкращий спосіб з'єднати ARM з кольоровим РК-дисплеєм, якщо мета полягає в основному в тому, щоб показати суцільний кольоровий текст або просту (наприклад, 16-кольорну або 64-кольорову) графіку?
Редагувати
Я зробив багато проектів з РК-дисплеєм, з багатьма типами РК-дисплеїв, включаючи РК-дисплеї в символьному режимі, спеціальні мультиплексовані 3: 1 сегменти на основі власного методу приводу, чорно-білі графічні РК-дисплеї із вбудованими контролерами та чорно- -білі РК-дисплеї, для яких я створив власний контролер на основі CPLD для взаємодії з DMA мікроконтролера загального призначення (що забезпечує навіть рівневий рівень сірого в чотири рівні). Я пишаюся тим, що роблю дисплеї на блискавці. Один з графічних контролерів був трохи собакою, якій потрібно було близько 1/10 секунди для повного оновлення екрана, навіть коли пишуть постійні дані, але більшість моїх дисплеїв можуть відображати навіть досить складне зображення менше ніж на 1/50 секунди.
Багато проектів, які я роблю, працюють від акумулятора, тому поточний розіграш є проблемою. Контролер дисплея на основі DMA я добре працював, але це було для лінійного проекту. Я вважаю, що єдиний спосіб отримати розумний малюнок струму від графічного РК-дисплея - це використовувати контролер, який поєднує буфер дисплея та драйвери стовпців. Надсилання великої кількості дисплея між мікросхемами кожного кадру витратить багато енергії навіть на один біт на піксель; на кольоровому дисплеї з шістнадцятьма бітами на піксель було б набагато гірше.
Я лише почав переглядати дані кольорових РК-таблиць; на багатьох дисплеях, здається, використовується контролер, подібний до ILITEK ILI9320, хоча всі аркуші даних, які я знайшов для контролерів на основі цієї загальної конструкції, були позначені "попередніми". Деякі, як ІЛІТЕК, стверджують, що мають функції маскування та прозорості, але не перераховують жодних регістрів для них; Я не знаю, чи мають справжні мікросхеми такі особливості, але "попередні" аркуші даних нехтували їх включенням, чи вони пропустили функції, але забули згадати про них. Якщо на практиці всі такі мікросхеми мають функції прозорості, було б доцільно розробити їх; якщо ні, ні.
Я б очікував, що для більшості проектів типовий екран складається з довільно розміщеного тексту з помірною кількістю довільних шрифтів довільного розміру. Шрифти, швидше за все, зберігатимуться як дані про біт на піксель. Використовуючи Cortex-M3, якби я хотів записати дисплей з паралельними даними, "внутрішній цикл" коду для запису двох пікселів, ймовірно, закінчився б чимось на зразок:
rol r0, r0, # 2; Отримайте один біт у С, інший у N itcs strhcs r1, [r3, # DATA_OFS]; Запишіть дані strhcc r2, [r3, # DATA_OFS]; Запишіть дані strb r4, [r3, # CLOCK_SET_OFS]; Встановити високий годинник strb r4, [r3, # CLOCK_CLR_OFS]; Встановіть годинник низьким itmi strhmi r1, [r3, # DATA_OFS]; Запишіть дані strhpl r2, [r3, # DATA_OFS]; Запишіть дані strb r4, [r3, # CLOCK_SET_OFS]; Встановити високий годинник strb r4, [r3, # CLOCK_CLR_OFS]; Встановіть годинник низьким
Не зовсім найшвидша річ у світі. Усунення запису до встановлених / чітких інструкцій годин допоможе. Я думаю, що немає жодного приємного незалежного від архітектури способу усунення обох записів годинника, але може бути досить поширений спосіб, який би дозволив усунути один (наприклад, багато чіпів можуть мати лічильник / ШІМ, який можна зробити для імпульсу виходу коротко у відповідь на одну операцію зберігання пам'яті).
Використання порту SPI та додавання апаратури для тактовання одного пікселя на біт значно пришвидшить доступ до дисплея. Якщо використовувати дисплей без маскування та прозорості, CPLD повинен був би включити лічильник адрес, і для кожного пікселя або годинник, слово піксельних даних, або інша команда набору адрес для позиції наступного пікселя (для чого знадобиться лічильник ). На противагу цьому, якби дисплей маскував та прозорів, все, що мені потрібно було б зробити це, щоб CPLD підтримував режим, коли після того, як він набрався в 16 біт, кожен додатковий біт передавав би слово з даних на дисплей із LSB відстеження контакту SDI (можливо, навіть не знадобиться використовувати CPLD - лише кілька звичайних логічних мікросхем). Я б встановив колір прозорості таким, щоб він був кольором, який я хочу написати, але з перевернутим LSB.
Я не хочу придумувати гарний дизайн, який спирається на маскування та прозорість, а потім виявляю, що лише на дисплеях з такими функціями є тривалість 30-тижневого часу. З іншого боку, якщо подібні дисплеї можуть бути і залишаються широко доступними у багатьох постачальників, я не хочу дозволити паранойї щодо доступності спонукати мене використовувати менший дизайн.
