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

WiseLord

#define RW_READ PORTD|=1<<1
#define RW_WRITE PORTD=PORTD&0xFD;

#define RS_DATA PORTD|=1<<0
#define RS_COMAND PORTD=PORTD&0xFE;
#define DATA_BUS PORTD

Почему бы не пользовать вместо этого чем-то более красивым:

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

#define LCD_PORT  PORTD
#define E         (1<<2)
#define RW        (1<<1)
#define RS        (1<<0)
#define DATA      (0xF0)

Примеры использования:

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

LCD_PORT |= RW;                   // установили бит RW в 1
LCD_PORT |= E;                    // установили бит E в 1
LCD_PORT &= ~E;                   // сбросили бит E в 0
LCD_PORT &= ~DATA;                // очистили 4 бита данных
LCD_PORT |= (data & 0xF0);        // отправили старшие 4 байта данных в порт
LCD_PORT &= ~DATA;                // очистили 4 бита данных
LCD_PORT |= ((data << 4) & 0xF0); // отправили младшие 4 байта данных в порт

Реклама

ROMan2947

WiseLord писал(а):

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

#define RW_READ PORTD|=1<<1
#define RW_WRITE PORTD=PORTD&0xFD;

#define RS_DATA PORTD|=1<<0
#define RS_COMAND PORTD=PORTD&0xFE;
#define DATA_BUS PORTD

Почему бы не пользовать вместо этого чем-то более красивым:

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

#define LCD_PORT  PORTD
#define E         (1<<2)
#define RW        (1<<1)
#define RS        (1<<0)
#define DATA      (0xF0)

Примеры использования:

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

LCD_PORT |= RW;                   // установили бит RW в 1
LCD_PORT |= E;                    // установили бит E в 1
LCD_PORT &= ~E;                   // сбросили бит E в 0
LCD_PORT &= ~DATA;                // очистили 4 бита данных
LCD_PORT |= (data & 0xF0);        // отправили старшие 4 байта данных в порт
LCD_PORT &= ~DATA;                // очистили 4 бита данных
LCD_PORT |= ((data << 4) & 0xF0); // отправили младшие 4 байта данных в порт

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

за примеры несомненно спасибо!!!я их разберу и обязательно применю!

Реклама

Мурато Мяуконни

ARV писал(а):это скользкий путь - надеяться на задержки, правильный подход заключается в считывании статуса контроллера дисплея - битик там такой есть.

Никогда не использовал чтение дисплея и ножку RW. И ничо - работает не хуже, без вопросов. Зато без лишней мороки и ожидания этого битика

MOHCTEP

ROMan2947 писал(а):исправленная функция write_Command

Неисправна. 1 Опять какие-то странные манипуляции с регистром направления DDRD.
2 Опять байт ВСЕГДА!! отправляете дважды - по половинке. Причем, второй раз отправляете всегда нули.
Я у себя "распределил" отправку на пару функций. Когда нужно однократно отправить что-то "в лоб", то примерно так:

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

void send_byte(char val){
	LCD_DT_PORT&=~data_mask;//Чистка шины
	LCD_DT_PORT|=(val&data_mask);//Если пины LCD и порта одинаковы
	//strobe
	LCD_CMD_PORT|=(1<<LCD_E);
	_delay_us(40);
	LCD_CMD_PORT&=~(1<<LCD_E);
	_delay_us(40);
}

А отправка байта с разбитием на тетрады, если необходимо, этак вот:

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

void send_nibbles(char val){
	send_byte(val);
	if(LCD_BUS==4){send_byte(val<<4);}
}

Реклама

Albert_V

Мурато Мяуконни писал(а):Никогда не использовал чтение дисплея и ножку RW. И ничо - работает не хуже...

Свяжетесь с серийным производством - поймёте, что проще и дешевле читать бит занятости.
Я уже это давно прошёл и ни один раз говорил об этом в этой теме.

Реклама

Мурато Мяуконни

Albert_V писал(а):Свяжетесь с серийным производством - .

Ой да вы что, а я то и не знал

я, знаете ли, в это самое, как его, серийное, да, дисплеи 1602 не ставлю, понимаете ли. только тфт и не ниже 480х272.
Но не в этом дело. Дело в том, что не шибко то выгодно с точки зрения кода - ожидать готовность дисплея, проверяя бит занятости. А ведь есть еще и аппаратный вывод в такой дисплей, где код не принимает участие в формировании задержек и дерганий ногами.

Реклама

ARV · Сообщение **ARV** » Пн янв 16, 2017 06:51:45

Мурато Мяуконни писал(а):Дело в том, что не шибко то выгодно с точки зрения кода - ожидать готовность дисплея, проверяя бит занятости

тупой цикл ничегонеделания гораздо эффективнее с точки зрения кода - верно?

Добавлено after 1 minute 34 seconds:

Мурато Мяуконни писал(а): ведь есть еще и аппаратный вывод в такой дисплей, где код не принимает участие в формировании задержек и дерганий ногами

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

Мурато Мяуконни

И с чего вы вдруг думаете, что тупой цикл ничегонеделания? С чего это вдруг такие категоричные, но такие пространные фразочки?
Про таймеры ничего не слышали?

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

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

scorpi_0n

ARV писал(а):
Мурато Мяуконни писал(а): ведь есть еще и аппаратный вывод в такой дисплей, где код не принимает участие в формировании задержек и дерганий ногами
если его проектировал не горе-специалист, то аппаратный интерфейс будет использовать аппаратные возможности контроллера дисплея для максимальной производительности. но можно и по-вашему.

Шутите? А что будем принимать за максимальную производительность, минимальное время вывода на дисплей или затраченное на вывод время МК? Разницу во времени в несколько процентов при выводе на дисплей уж точно не заметить, ибо он изначально тормозной. А вот разница по времени занятости МК стремящаяся к 100% между софтовым выводом и аппаратным настолько очевидна, что не увидеть её просто невозможно.

trengtor

Мурато Мяуконни писал(а):Для дисплея 1602 максимальная производительность ну нафик не нужна. даже при вдвое больших интервалах передачи производительность ничуть не страдает. Производительность ограничена скоростью реакции пикселей, а она невысока

Спорно. Достаточно взять совместимый VFD или OLED.

scorpi_0n писал(а):
ARV писал(а): Разницу во времени в несколько процентов при выводе на дисплей уж точно не заметить, ибо он изначально тормозной.

Отчасти ошибочное мнение. Если вывод на дисплей идет во временной сетке диспетчера, то уменьшение времени обмена МК-дисплей может быть важным.

scorpi_0n

trengtor писал(а): Отчасти ошибочное мнение. Если вывод на дисплей идет во временной сетке диспетчера, то уменьшение времени обмена МК-дисплей может быть важным.

Неужели? При хардварном выводе на дисплей время занятости МК стремится к нулю. Нет там привычного "обмена МК-дисплей", там этим занимается периферия МК практически без участия ядра.

trengtor

scorpi_0n писал(а):
trengtor писал(а): Отчасти ошибочное мнение. Если вывод на дисплей идет во временной сетке диспетчера, то уменьшение времени обмена МК-дисплей может быть важным.
Неужели? При хардварном выводе на дисплей время занятости МК стремится к нулю. Нет там привычного "обмена МК-дисплей", там этим занимается периферия МК практически без участия ядра.

Ну так и говорите по-русски, что речь идёт о дисплейном сопроцессоре или об ARM.

Мурато Мяуконни

Да какой там дисплейный сопроцессор. Да ну, обычный универсальный микроконтроллер в том же самом корпусе физически.

Даже если олед 1602 - все равно не критично совершенно. 32 байта переслать за время не больше 40 мс это фигня чистой воды. Скорость 800 байт/с. Интервал передачи в 3 раза больше необходимого по даташиту

ARV · Сообщение **ARV** » Пн янв 16, 2017 11:10:48

Мурато Мяуконни писал(а):Да какой там дисплейный сопроцессор. Да ну, обычный универсальный микроконтроллер в том же самом корпусе физически.

и этот МК у вас работает с тупыми задержками - и это хорошо, так? я-то думал, вы на ПЛИСине делаете дисплейный модуль, уж думал - во спец! а оказалось...

горе-специалист

trengtor

Мурато Мяуконни писал(а):Да какой там дисплейный сопроцессор. Да ну, обычный универсальный микроконтроллер в том же самом корпусе физически.

Даже если олед 1602 - все равно не критично совершенно. 32 байта переслать за время не больше 40 мс это фигня чистой воды. Скорость 800 байт/с. Интервал передачи в 3 раза больше необходимого по даташиту

Да ну, откуда там 416 мкс на знакоместо по DS? У меня цикл вывода из 6 закомест (3+3 в соседних строках) уложился в 500 мкс на 4-битном без R/W. Китайский совместимый дисплей за $2 и встроенные функции-дилеи компилятора. Можно еще поджать, если отрабатывать задержки более точно.

Мурато Мяуконни

ARV писал(а):уж думал - во спец! а оказалось... горе-специалист

Это вы про себя так? Самокритично.
Нет никакого смысла ставить отдельный сопроцессор на такой простой дисплей.

scorpi_0n

ARV писал(а):
Мурато Мяуконни писал(а):Да какой там дисплейный сопроцессор. Да ну, обычный универсальный микроконтроллер в том же самом корпусе физически.
и этот МК у вас работает с тупыми задержками - и это хорошо, так? я-то думал, вы на ПЛИСине делаете дисплейный модуль, уж думал - во спец! а оказалось... горе-специалист

Нет, это не плисина, это копеечный СТМ32 и этот МК не юзает тупые задержки, ему это просто ни к чему. К нему можно прицепить, при необходимости, несколько HD44780 дисплеев и все они будут работать параллельно и без участия ядра. Из необходимых действий - заполнить/изменить буфер и тыркнуть таймер. Всё! Дальше периферия сама будет всё разруливать, а ядро может спокойно заниматься своими делами.

Мурато Мяуконни

trengtor писал(а): У меня цикл вывода из 6 закомест (3+3 в соседних строках) уложился в 500 .

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

trengtor

Мурато Мяуконни писал(а):
trengtor писал(а): У меня цикл вывода из 6 закомест (3+3 в соседних строках) уложился в 500 .
А я вот, когда в последний раз ставил алфавитно-цифровые 1602, я вообще не парился скоростями.

Мне понадобилось «упаковать» вывод на LCD в сетку диспетчера, причем так, чтобы при выводе оставалось свободное время такта для еще пары задач. Так что случаи разные бывают.

scorpi_0n

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