Форум РадиоКот

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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