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

[Albert_V]

На мой взгляд, здесь изначально ошибка проектирования.
На проводах длиной 2 - 4 метра (как было сказано в посте от Ср авг 05, 2015 21:31:54) можно таких помех схватить (даже от мобильного телефона), что никакие экранированные провода не помогут. Даже с питанием индикатора могут быть проблемы, не говоря уже про чтение клавиатуры.
Тут, лучше всего, около индикатора с клавиатурой поставить отдельный контроллер, стабилизатор и т.д. (по сути, сделать терминал) и общаться с этим блоком по, к примеру, RS-485 или RS-422.
Но, как говорится, хозяин - барин.

[WiseLord]

Есть очень часто необходимость например включить курсор. аппаратно. Или его тоже эмулировать через буффер?

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

Буферизованный вывод очень быстр, но его задача - выввод информаци, и только. Остальная программа только пишет данные в буфер, ничего в принципе не зная о типе дисплея, никаких аппаратных его "фишек" не используя.

Так что либо большая скорость вывода + абстрагирование от типа дисплея за счёт небольшого перерасхода ОЗУ (на этот самый буфер) и прерывания таймер, либо привязка к конкретному дисплею с возможностью использования аппаратных его "фишек" и медленный вывод за счёт постоянных задержек. Кому что надо, тот то и выбирает.

[Alexeyslav]

в итоге уходит даже больше тактов процессора на вывод на дисплей. Да и зачем его перерисовывать 500 раз в секунду? ЖК вообще не способен так быстро реагировать, обычно на таких индикаторах информация статична и меняются только несколько знакомест. Может тогда проще организовать не постоянный вывод на дисплей, а просто очередь команд? Пусть в прерывании этот выводятся команды если есть очередь и ничего не делается когда буффер пуст. Вывод будет осуществляться со стороны программы не сложнее чем в массив, а тем временем получаем возможность использовать нативную функциональность дисплея и без лишних затрат энергии.
Вообще, такие дисплеи мало кто использует на полную мощность, некоторые только догадываются что в дисплеях есть аппаратная прокрутка строк...

[MOHCTEP]

Так, чтоб прокрутить, надо сначала загрузить эти строки в теневую память дисплея. А это не всегда удобно, например, если подразумевается тесное общение с пользователем (меню какие нибудь и т.п.) + затраты времени. А для статики (часы, календарь, погода... с автопрокруткой), да - хороший выход. Можно даже анимацию схимичить, по идее.

[amd9800]

Вот и я думал недельку назад что лучше кольцевой буфер команд или буфер дисплея.
Послушав вас пришел к идее что кольцевой буфер команд лучше.

Ну вот другая мысль - какой размер лучше тогда сделать?
Какие правила игры будут? Ведь данные с буфера будут передаваться через прерывание с учетом задержек.

А если мы буфер команд переполним? А будем его переполнять с другого прерывания.
Буфер же дисплея без проблем можем хоть 100 раз из прерывания писать.
Но если к командам дисплея добавить наши команды типа отправить строку, а дальше поместить в буфере адрес строки, тогда шансы переполнить буфер команд уменьшается.

[WiseLord]

Вот именно. Буфер команд мог бы быть решением, но проблема нормальной синхронизации вывода на дисплей с основным потоком программы практически нерешаема. Всегда есть шанс переполнения этого буфера. Либо придется опять же вносить задержки в код в случае заполнения буфера и также тупо ждать свободных ячеек в буфере. Потом, обычным массивом тут уже не обойтись, потребуется что-то вроде связного списка.

Аппаратные 128 байт памяти дисплея, из которых мы на экране видим только часть, слишком дорого обходятся. Возможность прокрутки по ним аппаратными командами убивает своей медлительностью.

А приведенный мною вариант минимально нагружает процессор, требуя минимального количества тактов на вывод и обеспечивает высокую скорость вывода. По поводы ненужности большой частоты обновления кадра - ну так никто не мешает выставить таймеру делитель не 8, а, например, 64, ещё сильнее разгрузив ядро процессора.

В общем, мое мнение - аппаратные возможности этих экранов есть смысл использовать только если управлять ими через ту же I2C шину (PCF8574), так как в этом случае именно шина, а не дисплей, будет самым медленным звеном.

[amd9800]

По поводы ненужности большой частоты обновления кадра - ну так никто не мешает выставить таймеру делитель не 8, а, например, 64, ещё сильнее разгрузив ядро процессора.

А можно отслеживать факт изменения буфера обмена.
Если буфер изменен мы его синхронизируем с реальным дисплеем, иначе ничего не делаем.
Таким образом по шине будет передаваться информация только когда мы меняем содержимое буфера.

[Alexeyslav]

т.е. изменили 1 символ и прийдется передать все 32. замечательный алгоритм.

Можно просто ввести признак ожидания освобождения буффера, и как-то вывести его наружу - на свободный пин или на дисплей, в процессе отладки программы мы будем знать надо ли увеличить размер буффера. Впрочем, при нормальной работе он не будет больше чем количество символов отображаемое на индикаторе + запас на несколько команд.
Ситуации когда один вывод накладывается на другой надо уже исключать на программном уровне, ибо смысла так быстро менять данные на дисплее нет никакого.

[amd9800]

т.е. изменили 1 символ и прийдется передать все 32. замечательный алгоритм.

Ну это лучше чем передавать по 100 раз в секунду все 32 символа.
Да и потом редко когда меняется одна буква на дисплее. Очень часто терпит изменение либо вся картинка либо значительная часть.

Ну если так не устраивает есть второй вариант. Создать 2 буфера.
1 Буфер базовый
2 Буфер произведенных измен

Если символ во втором буфере отличается от символа в первом тогда она запишется и во втором и отправится на дисплей.
Но эта операция опять не супер. Дело в том что мы должны перевести курсор по нужным координатам и записать символ.
Перевести курсор это примерно 3 команды на дисплей. Итого 4 с символом.
А если нам надо перевести курсор в 4-х местах и написать по 4 символа то это (3+4)*4=28 примерно те же самые 32 символа.
А если мы полностью обновим буфер то сколько проверок делать чтоб не перемещать курсор а писать дальше, это сколько проверок надо делать Если Если...
Алгоритм должен быть простой без кучи ветвлений.

вывод накладывается на другой надо уже исключать на программном уровне, ибо смысла так быстро менять данные на дисплее нет никакого.

Ну во первых надо подумать какие команды мы будем помещать в буфере.
И какого размера будет один элемент буфера? int(2 byte) или char(1byte)
как из буфера будем отличать команды от символов.

Например в моем случае на дисплей через регистр 595 передаются только 6 бит поскольку дисплей 4 бит режиме.
1 вариант в кольцевом буфере помещать именно 6 бит данных - конечно в одном байте - 2 бита будем терять.
Но тогда на отправку 1 символа нам потребуется 2 байта в кольцевом буфере. То есть 32 символа это уже 64 байта.

2 вариант помещать в буфере наши команды типа:
очистить дисплей
передвинуть курсор на такую позицию
вывести символ на дисплей
вывести н символов
и так далее

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

теперь предположим такой вариант - в буфере мы забили уже 10 команд в очереди, а 11 команда предполагает инициализацию дисплея. Какой смысл исполнять предыдущие если через долю секунды дисплей обнулится.
Значит будут команды которые будут аннулировать все предыдущие поскольку они уже не имеют смысла.

кольцевой буфер будет иметь курсор и метку.
Курсор хранит позицию исполняемой команды в данный момент. Метка хранит информацию до какой позиции есть команды на исполнение.
Если курсор сравнялся с меткой больше команды не исполняются.
Каждый буфер имеет свой курсор и метку их даже можно расположить как первую и вторую переменную в массиве.

я предлагаю чтоб каждый высказал свое мнение для каждой методики и какая методика будет лучшей ту и выберем.

[WiseLord]

Лучшей будет та методика, которая 1) работает вообще, 2) работает быстро, 3) не использует пустые задержки или циклы ожидания готовности, 4) проста в реализации, расходуя минимум flash-памяти.

Многим почему-то не нравится, что при буферизованном выводе данные обновляются слишком часто. Я же в этом не вижу ничего плохого, тем более, что это ничего не стоит в плане потребления ресурсов МК. Между прерываниями при делителе 8 получается 8х256=4к тактов процессора (120 обновлений экрана в секунду), из которых пусть штук 40 тратится на отправку команды в дисплей. Остальные 99% времени МК занят полезными вычислениями. А если взять делитель таймера не 8, а 64, то КПД вывода станет вообще 99.8%, при 15 обновлениях экрана в секунду.

Единственное неудобство - необходимость при генерации пользовательских символов отключать прерывания, либо встраивать эту генерацию в то же прерывание добавив ещё 64 байта в буфер.

Хотя подобный алгоритм всё же больше подходит для графических символов, давая максимально возможную скорость вывода.

[Alexeyslav]

120 обновлений экрана в секунду, при том что кристаллы инертные и реагируют по 100мс на переключение - это просто зря тратить ресурсы. Да и зачем гонять на дисплей постоянно данные если он должен показывать одно и то же в течение нескольких часов, даже в ситуации когда контроллер можно безболезненно загнать в спячку.

[ARV]

вставлю свои 5 копеек.

имхо, алгоритм работы должен наиболее полно соответствовать решаемой задаче в первую очередь, а уже потом подгоняться под особенности аппаратуры. никакой необходимости в промежуточном буфере, выводимом на ЖКИ по таймеру, нет, если вы не планируете делать какую-то мультипликацию или что-то подобное:

логика и здравый смысл подсказывают, что обновлять ЖКИ необходимо только в момент, когда изменяется состояние девайса, отображаемое на ЖКИ. например, для часов - 1 раз в секунду (или 2 раза в секунду, если используется мигающее двоеточие), для системы меню - только после нажатия кнопки пользователем и т.д.

заниматься обновлением дисплея, выводя одно и то же - это свидетельствует о нерациональном алгоритме, даже если не стоит ничего по затратам. тем более что на самом деле стоит - таймер достаточно дефицитный ресурс AVR.

в очередной раз повторю то, что уже 100500 раз говорил в темах о кнопках, usart и еще других: необходимость в асинхронном вводе-выводе (для AVR это означает использование прерываний) сильно (ОЧЕНЬ СИЛЬНО) преувеличивается. почти любой любительский проект на AVR может быть сделан строго синхронным в плане пользовательского интерфейса, т.е. в основном цикле тупо ожидание события и только потом реакция на него.

например, я еще ни разу не встречал любительских проектов, в которых на самом деле был бы необходим кольцевой буфер приема и передачи по usart. и тем не менее встречал очень много проектов, где этот подход был реализован. никаких плюсов он не давал, использовался просто "потому что". детальный анализ проекта иной раз свидетельствовал, что из-за этого буфера наоборот, могли возникать проблемы. в то время, как чуть ли не 99% консольных программ даже компьютеров используют функции scanf и printf - полностью синхронные функции! и это не мешает всему работать, как часы.

так и тут - привнесение лишнего, ничего не прибавляющего в качестве, но несущее дополнительные расходы периферии, - разве это хорошо?! тем более что этот подход еще и лишает возможности использовать аппаратные функции ЖКИ по отображению курсора.

[amd9800]

...

Уважаемый, вы наверное не поняли о чем речь, поэтому получилось данное мнение.
Дело в том что функции вывода на дисплей и в особенности через регистры 595 требуют определенные задержки.
А это надо учитывать когда разрабатываешь программу и особенно когда применяешь "функции вывода на экран" в прерываниях. Для этого должны быть некие функции которые в RAM вставляют нужную информацию в определенном организованном порядке (будь RAM буфер дисплея или Кольцевой буфер команд). А дальше уже где нибудь в основном цикле программы в свободное время эти данные выводятся на реальный дисплей.

Теперь обычный программист имеет функции на руках которые он может вставлять куда хочет не задумываясь о задержках.
А дальше специальная функция обработчик которая добавляется в основной цикл берет на себя всю работу.

Я согласен что можно написать программу с нуля которая будет оптимизированнее и код будет меньше места во флэш занимать и ram меньше использовать, ну это трудоемкий процесс.

А так готовые функции - неприхотливые к временным интервалам.
Создал проект сконцентрировался на основную цель проекта.
Подключил библиотеку и спокойно использовал функции по выводу текста на экран ни о чем не задумываясь.
В итоге за короткий период получаешь достаточно стабильную программу без глюков, но использует ресурсы немного больше.
Зато сколько сэкономленного времени - сколько новых проектов которые просто бы не сделали при других обстоятельств.

Я же почему привязался к передачи по 3 проводам.
Все очень просто - изготовил себе модулей в виде LCD дисплеев с приемом данных по 3 пинам.
Дальше написал библиотеки.
И дальше нужно сделать устройство?
Так я не мучаюсь разводить 10 или 14 дорожек от МК к LCD - да еще думать какие ноги мне нужны
А так 3 и все. А нужен дисплей не на плате девайса а на расстояние 1метр - да пожалуйста вывел вывод на 3 пина + (2 питание если надо) и дело в сделано.

И не надо сидеть и мурыжить проект месяцами отлавливать глюки - где что не так сделал.
Модульная система - это большой плюс.

[ARV]

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

вы намерены выводить из обработчика прерываний, я верно вас понял? если верно, то это полностью порочный подход. да, можно извратиться и реализовать его, но... см. принцип бритвы Оккама.

какие бы ни были функции вывода на ЖКИ, вам всегда будет важно только одно: не сделать задержки МЕНЬШЕ, чем необходимо. т.е. если задержка будет больше, то ничего страшного не произойдет. это означает, что вывод через 595-е регистры можно делать в основном цикле, точнее, функцией, вызываемой откуда угодно (но не из прерывания, разумеется). а по прерываниям делать что-то реально безотлагательное - и пусть прерывания замедляют функцию вывода через регистры - это никак не повредит.

т.е. выбрав кривой путь вывода из прерывания, вы вынуждены идти по нему, все более и более перемешивая плохое и хорошее в своей программе.

[MOHCTEP]

#define CONCAT(x,y) x ## y

Отменная вещь! Не знал.

[FireProoF]

Всем привет. Помогите разобраться в подключении hd44780 1602 к STM32F103C8T6
Подключил D4-7, E и RS к 5В толерантных выходам МК.
Если подключить контраст V0 к земле, то только нижняя строка заполняется белыми прямоугольниками. Уже через 1КОм к 5В пустой экран.
Смущает еще то, что в используемой библиотеке при инициализции порты конфигурируются как Open-Drain.
// инициализация выводов дисплея
void lcd44780_init_pins(void)
{
RCC_APB2PeriphClockCmd(lcd44780_RCC, ENABLE);
lcd44780_GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
lcd44780_GPIO_InitStructure.GPIO_Pin = lcd44780_pin_E | lcd44780_pin_RS | lcd44780_pins_data;
lcd44780_GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_OD;
GPIO_Init(lcd44780_port, &lcd44780_GPIO_InitStructure);
}
Получается нужна подтяжка?
Можно ли как-нибудь без неё обойтись?

[WiseLord]

Либо библиотека кривая и нерабочая, либо предполагает, что МК может с этих выводов и читать, а не только писать - "отпускает" открытый сток в единицу и читает что там на шине реальное устройство (тот же дисплей в режиме чтения) выдаёт.

[FireProoF]

Заменил Open-Drain на Push-Pull. Теперь при ресете МК пропадают и снова появляются квадраты в нижней строке. Говорят, что это режим самодиагностики. Пытаюсь на него писать - бестолку. Библиотека рабочая, судя по отзывам.

Спойлер

Чую, что дело в функции задержки. Хоть библиотека написана под мой stm32f10x, не нравится она мне:)

Код: Выделить всё

void lcd44780_delay(unsigned int p)
{
   unsigned long i;
   for(i=0;i<(p*10);i++){}
}

У автора МК 24Мгц, у меня 72Мгц. Домножил p еще на 3 - реультат 0. Проверил, а не работает ли он на 8 Мгц; поставил p*3 - тоже.

[amd9800]

У автора МК 24Мгц, у меня 72Мгц.

выставь свой МК в 24Мгц или ниже и проверь.

[amd9800]

На мой взгляд, здесь изначально ошибка проектирования.
На проводах длиной 2 - 4 метра (как было сказано в посте от Ср авг 05, 2015 21:31:54) можно таких помех схватить (даже от мобильного телефона), что никакие экранированные провода не помогут. Даже с питанием индикатора могут быть проблемы, не говоря уже про чтение клавиатуры.

уже отладил почти все библиотеки включая библиотеку клавиатуры с обработкой прерываний нажатий кнопок. А также определения кнопок зажатых более 3 сек. Нарисовал менюшки - короче все готово для тестов.

Скажу честно, с помехами вы меня напугали и я решил все проверить.

Сделал тесты с кабелем 110см + еще один 25см который подключается через коннектор как удлинитель итого 135см
Кабель не экранированный - сделан из шлейфов для подключения флопика к материнки.

Результаты - все прекрасно работает.

Далее взял два мобильных телефона поставил рядом с кабелем с одной и другой стороны.
С первого телефона позвонил на второй - компьютерные колонки шипят аж ужас, а у меня все прекрасно клавиатура работает, менюшки крутятся никаких глюков не было обнаружено.