Работа с ЖКИ на контроллере HD44780 и его аналогах

HHIMERA

Неправильно!!! Читайте даташит...

Реклама

Леонид Иванович

Реклама

HHIMERA

Да, да... развивайте мысль дальше... где практическое применение этому чуду???

WiseLord

olegleon писал(а):Enable cycle time = 500ns min,
как бы максимумом не ограничено, но повторюсь, хочу по максимуму оптимизировать.

Большого смысла нет.
Всё равно, следующую команду дисплей сразу же принять может. Флаг готовности устанавливается (исходя из моего опыта) где-то через 7..8 мкс. На некоторых дисплеях и 10мкс не хватало.
Поэтому, не важно, 500нс у вас будет, 100нс, или 1мкс - всё равно вся команда будет выполняться на порядок дольше. Так что степень этой оптимизации - с гулькин нос.
А вообще у меня реально в жизни дисплею и 4 nop-ов хватает (тыц). Плюс у функций вроде _delay_us() - аргумент типа double, что не слишком хорошо для тех же AVR.

HHIMERA писал(а):практическое применение этому чуду???

Кстати, как раз и аргумент

Код по ссылке выше отлично работает на 16МГц.

Реклама

Леонид Иванович

HHIMERA писал(а):развивайте мысль дальше

Что тут развивать? Сказанное про сигнал ENABLE - правильно. Если гнаться за максимальной скоростью работы с ЖКИ, то именно с таким темпом нужно дергать ENABLE, сначала в цикле записи/чтения, затем в циклах чтения BUSY. Но особого смысла в этом нет, так как общая скорость в основном будет определяться временем выполнения команд контроллером.

Реклама

olegleon

Леонид Иванович писал(а):есть ли смысл гнаться за предельной скоростью?

Смысл есть, хочу научиться решать полностью возникшую ситуацию, а не находить выход типа "сделал лишь бы работало, некогда оптимизировать"
Никуда не спешу, хочу научиться делать хорошо, правильно и оптимально.

Реклама

ARV · Сообщение **ARV** » Чт май 08, 2014 15:08:42

WiseLord писал(а):Плюс у функций вроде _delay_us() - аргумент типа double, что не слишком хорошо для тех же AVR.

очень даже хорошо для AVR. _delay_us(.5) очень даже нормально отработает 500 нс, если тактовая соответствующая.

Gudd-Head

Кстати, да. Смысл шпарить на мегагерце, если все команды выполняются 38 мкс (SPLC780D)?

HHIMERA

olegleon писал(а): хочу научиться делать хорошо, правильно и оптимально.

В данном случае оптимально не получится... как и нет никакого смысла в "500nS"...
В случае с STM8L/STM32 можно заюзать ДМА... Тогда во время загрузки дисплея можно заниматься своими делами... нет потерь на ожиданиях и задержках... Но даже в этом случае нет смысла доводить ситуацию до "прикрутил другой дисплей, а он почему-то не работает"...

Alexeyslav

Шмышл есть иногда чтобы не задерживать программу когда общение с индикатором идет не аппаратно. и в 4-х битном режиме надо выталкивать по две порции данных на одну команду. Максимально быстро вытолкнули данные в индикатор а потом можно что-то сделать перед тем как дождаться готовности индикатора к приёму следующей команды.

HHIMERA

Alexeyslav писал(а):Шмышл есть иногда чтобы не задерживать программу когда общение с индикатором идет не аппаратно. и в 4-х битном режиме надо выталкивать по две порции данных на одну команду.

500nS это 8 циклов МК для 16МГц... в вышеприведённом исходнике я не вижу функции залержки на 500nS... даже в случае с 4-х битным режимом...

olegleon

ARV писал(а):если тактовая соответствующая.

а как указать компилятору какая тактовая, чтобы он правильно все с таймингами считал?

ARV · Сообщение **ARV** » Чт май 08, 2014 16:55:11

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

olegleon

ARV писал(а):delay_us(.5)

к сожалению не все компиляторы поддерживают не целые числа. Так что актуальным остается вопрос о задержке в 500ns.
все что предложили, заполнить nop-ами, еще варианты есть ?
Если нет, то как автоматизировать нужное количество нопов под соответствующую частоту ?

Леонид Иванович

В IAR есть intrinsic функция __delay_cycles(), которая сама выбирает нужное количество nop-ов, а для длинных задержек использует цикл + nop-ы. Наносекундная задержка будет выглядеть так: __delay_cycles(DELAY_NS * F_CLK_MHZ / 1000)

ARV · Сообщение **ARV** » Чт май 08, 2014 22:05:22

аналогичные функции (точнее, макросы) имеются и в WinAVR

WiseLord

HHIMERA писал(а): в вышеприведённом исходнике я не вижу функции залержки на 500nS... даже в случае с 4-х битным режимом...

А там и не нужны 500ns. У дисплея на строб 230 в даташите - это 4 "nop"-а. А после строба до 500 добивать смысла нет - эти 4-5 инструкций всё равно потратятся на тот же вызов функции строба.

olegleon

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

sartam

Послушайте, причём тут длительность импульса? В даташите сказано что запись/чтение данных происходит по заднему фронту сигнала.

HHIMERA

olegleon писал(а): к примеру STM32, то алгоритм нужен более точный. Ответ в тайминг графике, и правильное решение, кстати, нашел товарисч DiHALT и хорошо это описал

Не нужно сгущать краски...

В случае с STM8L/STM32 можно заюзать ДМА... Тогда во время загрузки дисплея можно заниматься своими делами... нет потерь на ожиданиях и задержках...

В данном случае о таймингах заботится таймер...