Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LPC2468, как прикрутить графический ЖКИ
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > ARM, 32bit
haker_fox
Здравствуйте, уважаемые коллеги!
В LPC2468 нет графического контроллера. Однако, очень хочется попробовать подключить к нему LCD TM12864 (128x64 точки). Монохромный. Интерфейс ЖКИ параллельный (8 бит данных, выбор кристалла и строб записи + еще пара сигналов). Контроллер ЖКИ HD61202.
В выводе данных на дисплей особых-то проблем нет. Да и те аппаратные - согласование 3,3 с 5 В. А вот строб формировать программно на ARM как-то не камильфо.
Вопрос: возможно ли для этого дела использовать модуль EMC, если на плате уже запаяна ОЗУ 512 Кб? И вообще, можно ли мучать контроллер памяти такими задачами? Может быть есть другие варианты, которых я не замечаю? Внешний контроллер абсолютно исключается. Проще отказаться от идеи, либо заменить дисплей на двухстрочный на основе HD44780, задействовать на него лишнюю AVR и довольствоваться малым)))
З.Ы. Графики не будет. По сути текстовый режим.

Благодарен заранее!
maksimp
Строб формировать программно никаких проблем. Испытано на AVR, на ARM тоже всё должно быть нормально.
haker_fox
QUOTE (maksimp @ Nov 15 2011, 13:54) *
Строб формировать программно никаких проблем. Испытано на AVR, на ARM тоже всё должно быть нормально.

Конечно сформировать строб не проблема. Но учитывая его длительность (наносекунды, микросекунды) - другим задачам времени может не хватить. Т.е. на процессор будет нагрузка. Т.к. не один байт на дисплей выводится...(
esaulenka
Предлагаю посчитать, прежде чем городить "лишние AVR".
Максимальная частота шины - 1 МГц. Сколько байт в секунду планируется выводить? У меня подозрение, что большая часть затрат будет не в формировании строба, а в растеризации буковок.
toweroff
Цитата(haker_fox @ Nov 15 2011, 11:59) *
Конечно сформировать строб не проблема. Но учитывая его длительность (наносекунды, микросекунды) - другим задачам времени может не хватить. Т.е. на процессор будет нагрузка. Т.к. не один байт на дисплей выводится...(

а если таймером флаг выставлять?
450нс - маловато времени

а почему аппаратный EMC не пользовать?
у LPC2468 четыре банка, на одном висит RAM, на втором - индикатор
В силу специфики выставляем R/W, D/I и совершаем просто обращение к банку, в качестве E будет выступать /CSx контроллера
haker_fox
QUOTE (esaulenka @ Nov 15 2011, 17:12) *
Предлагаю посчитать, прежде чем городить "лишние AVR".
Максимальная частота шины - 1 МГц. Сколько байт в секунду планируется выводить? У меня подозрение, что большая часть затрат будет не в формировании строба, а в растеризации буковок.

Допустим, что мы будем обновлять весь дисплей (1024 байта) раз в 1 сек.

QUOTE (toweroff @ Nov 15 2011, 17:12) *
а почему аппаратный EMC не пользовать?
у LPC2468 четыре банка, на одном висит RAM, на втором - индикатор
В силу специфики выставляем R/W, D/I и совершаем просто обращение к банку, в качестве E будет выступать /CSx контроллера

Ну вот похоже, что его и буду присматривать к задаче.
esaulenka
Цитата(haker_fox @ Nov 15 2011, 13:56) *
Допустим, что мы будем обновлять весь дисплей (1024 байта) раз в 1 сек.

В теории получается, что займёт это 1/1000 процессорного времени.

На практике, конечно, всё гораздо хуже. Но неужели жалко пары процентов?
maksimp
Ещё вариант: выводить данные по DMA в порт общего назначения. По 64 байта за раз - одна строка на одной половине индикатора (половины раздельно управляются). DMA работает по таймеру - по каждому окончанию счёта выводится следующий байт (если DMA LPC2468 поддерживает такой режим работы, в STM32 так можно).
Синхросигнал - от того же таймера от выхода ШИМ. Если ШИМ не удобен - то ещё один канал DMA выводит синхросигнал через порт общего назначения, из буфера где записано 0, 1, 0, 1, 0, 1, ..., всего 128 байт, по таймеру который считатет в 2 раза быстрее первого. Если работать только от одного таймера, то буфер данных нужно скопировать в другой буфер, записав каждый байт данных 2 раза подряд, так что тоже будет 128 байт.

Цитата(toweroff @ Nov 15 2011, 13:12) *
а почему аппаратный EMC не пользовать?
у LPC2468 четыре банка, на одном висит RAM, на втором - индикатор
В силу специфики выставляем R/W, D/I и совершаем просто обращение к банку, в качестве E будет выступать /CSx контроллера

Шина данных на все банки вероятно общая. Поэтому пока идёт отведённое на обмен с индикатором время, и он неспеша берёт данные с шины, пользоваться этой RAM нельзя.
haker_fox
QUOTE (maksimp @ Nov 16 2011, 10:53) *
Ещё вариант: выводить данные по DMA в порт общего назначения.

Вот, про DMA тоже думал. Он может работать с памятью и с некоторой периферией, но не портами общего назначения (GPIO). Если к портам можно обращаться как к ОЗУ, то вполне все будет работать. А держать два байта данных (в которых записан строб) это даже проще для меня.
Уважаемый, maksimp, спасибо за идею!!! Будем думать)
haker_fox
Похоже в системе намечается сопроцессор на базе AVR для реализации таких задач, как опрос шин 1-Wire, организации гальванически развязанного АЦП. AVR можно подключить к ARM через SPI, который достаточно легко развязать оптронами. В качестве сопроцессора можно поставить ATmega64 (есть запас в наличии). У нее 4 кБ ОЗУ. На три видеобуфера хватит в пределе (оставшиеся 1024 кБ под переменные). Заодно решается вопрос преобразования уровней 3.3 В в 5 В. Можно видеостраницы формировать в ARM'e у которого ОЗУ "немеряно" и по SPI загонять в буфер меги. Затем та обновляет дисплей.
Сильно бредовая идея? От AVR, похоже, отказаться не удастся, тк нужно опрашивать датчики DS18B20, чашку ключа iButton и охранные датчки через АЦП. ARM "погибнет" на реализации 1-Wire. Да и АЦП нужно отвязать гальванически, т.к. в длинных охранных шлейфах всякое может произойти...

Вариант с DMA отпадает согласно табличке "GPDMA accessible memory"( DMA может обращаться только к "набортному" и "забортному" ОЗУ.
maksimp
Цитата(haker_fox @ Nov 17 2011, 06:11) *
Похоже в системе намечается сопроцессор на базе AVR
...
поставить ATmega64 ... У нее 4 кБ ОЗУ. На три видеобуфера хватит в пределе (оставшиеся 1024 кБ под переменные).

Зачем AVR? Поставьте ещё один ARM. Жизнь прощь будет. Памяти больше. С атрибутом PROGMEM не нужно возиться.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.