Комментарии 12
Я бы в sendStr() сделал передачу номера строки (row 0..3) и номера стартового символа (poz 0..19). А в коде уже пересчитывать start_address = row*20 + poz. Так избавимся от громоздкого switch и от нерациональных пробелов для смещения текста, как тут
sendStr(" HELLO, HABR", 1);
DDRAM имеет непривычную адресацию (вроде-бы — для упрощения разводки проводников на стекле). Простым "row*20 + poz" не отделаться.
Можно организовать буфер в ОЗУ и печатать туда как заблагорассудится. А дисплей обновлять из буфера, либо через фиксированные интервалы времени, либо по факту изменения буфера.
Хотелось бы ещё узнать как автор будет проблему кириллицы решать.
Хотелось бы ещё узнать как автор будет проблему кириллицы решать.
Для кириллицы есть такие дисплеи с кириллическим знакогенератором. Но если его нет, то во всех таких дисплеях есть память под пользовательские 8 символов, которые можно нарисовать как хочешь. Можно попробовать динамически рисовать кириллицу в эту память а потом выводить оттуда на экран. На сколько это будет быстро работать вопрос…
Судя по таблице, адреса строк идут не по порядку и не монотонно. Т.е. вычислять адрес по линейной формуле не выйдет.
Это решается 4 строками кода:
И вызов функции будет как-то так:
Так расчет в функции вывода будет даже проще, т.к. теперь не надо будет делать умножение для вычисления строки, просто прибавить к адресу Lineх позицию начала вывода текста.
#define Line1 0x00
#define Line2 0x40
#define Line3 0x15
#define Line4 0x54И вызов функции будет как-то так:
sendStr("HELLO, HABR!", Line1, 5);Так расчет в функции вывода будет даже проще, т.к. теперь не надо будет делать умножение для вычисления строки, просто прибавить к адресу Lineх позицию начала вывода текста.
Думаю так «в лоб» решить задачу не получится. Потому, что адресация первой строки продолжается на третью, а второй на четвертую. Скорее всего (но я могу ошибаться) это связано с тем, что сам контроллер дисплея умеет работать только с двумя строками, а расширение до четырех происходит добавлением еще одного контроллера на две строки и физически на дисплее строки разведены через одну. По поводу пробелов, да наверно громоздко, но если задавать начальное положение в строке, то все равно придется использовать условные операторы и перерасчет адресов. А вот если писать функцию для отображения переменных в реальном времени без перерисовки всего экрана, то там свободное позиционирование понадобится обязательно. Позже думаю реализовать возможность вывода переменных, мне нужно будет выводить температуру и мощность верхнего и нижнего нагревателя в реальном времени и само время работы.
А не пробовали вместо задержек читать busy flag?
Сам когда-то тоже писал на задержках, но ругал себя за это.
чтение busy flag не избавляет от задержек. Строб быстрее, чем в пол микросекунды все равно дергать нельзя.
Я, чтобы их полностью исключить использую буфер.
Я, чтобы их полностью исключить использую буфер.
Изначально думал читать флаг, но просмотрев форумы решил на задержках, ибо везде пишут, что производительность контроллера дисплея не очень и чтение флага не сильно скажется на увеличении скорости работы. Как вариант можно поэкспериментировать с уменьшением пауз.
Лет 10 назад, они все так и подключались :) без I2C, есть еще вариант на сдвиговом регистре.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
STM32 и LCD2004A без I2C интерфейса