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

[technik-1017]

Можно в прерывании (например 1 ms) выводить по одному символу на дисплей (задержка будет обеспечиваться за счёт прерывания). Данные на дисплей будут выдаваться из буфера (массив в памяти). И для того, что бы поменять символы на дисплее нужно будет только заполнять буфер дисплея нужными значениями.
Как это работает можно посмотреть здесь uC/avr_menu:
https://disk.yandex.ru/d/GBRtXyNC0KdEeA
В примере показана работа с двумя буферами дисплея: пока заполняются данные в буфер дисплея на дисплей выводится данные из другого буфера (для исключения видимого изменения данных на дисплее).

[ARV]

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

[НовыйДень]

А что, дисплей - это самая главная деталь конструкции и обязательно нужно ставить цветной TFT 480х420 туда, где по функционалу достаточно текстового 1602? Тем более, что медлительность интерфейса дисплея как раз и обходится с другой стороны - не через постоянный опрос бита BSY, а через прерывания таймера, который просто отсчитает заданный интервал. Никаких проблем!
Я тут говорю не о 72 МГц, а о несоразмерности длительности поллинга в пересчете на такты. Если величины 125 нс и 40 мкс - это еще терпимо, то 14 нс и 40 мкс - это уже неэффективность. Мышление программиста должно быть гибким, а не следовать единственному выученному 10 лет назад методу.

[OKF]

C Arduino.ru:

apollo-mega.jpg

(197.95 КБ) 145 скачиваний

[ARV]

об том и речь... взять МК на 72 Мгц, решить задачу 2*2, и бороться за то, чтобы МК ни наносекунды не простаивал... гибкость - она такая гибкая...

я уже интересовался, сколько стоит миллисекунда "простоя" МК в ваших проектах... а то не понятно, в чем "эффективность" измеряется.

[Jack_A]

[uquote="ARV",url="/forum/viewtopic.php?p=4229035#p4229035"]... берут 72-мегагерцовый МК и пишут программу управления термоядерным реактором...[/uquote]
Я тоже им завидую, бо мне пришлось в прошлом тысячелетии на Меге 8МГЦ измерять в реальном времени 4 канала хоть и 50-Гцовых, но по 64 точки на период, рассчитывать где-то там с дюжину параметров с плавучкой и функциями, следить за кнопками управления, выдавать по запросу нужную лабуду на этот самый дисплей, да ещё и по RS485 от компа верхнего уровня отбрехиваться. Опрос готовности дисплея не использовал.
Сам удивляюсь - как это мне удалось. Вспомню - вздрогну.
----------------------

Спойлер

Немножко лукавлю: АЦПшной частью занимался подчинённый мелкий МК и выдавал уже готовые оцифрованные точки.
-------------------
PS Кажется, мои усилия пропали даром. Судя по не обновляемому годами их сайту, фирме уже крындец. И не мой уход тому причиной - глобальные и местные обстоятельства. Ну как тут будешь компенсировать реактивку без польских конденсаторов...

[НовыйДень]

Видимо, у ARV мало опыта в деле, зато много опыта в словах, коль не понимает, какие бывают задачи и конструкции Выучил один-единственный способ, а посылка по прерываниям для него уже настолько сложная тема, что он аж в ступоре Ну чтож, бывает и такое! 1,5 мс молотить в ожидании бита - это конечно похвально. хахаха.
Хотя какая, в сущности, неразрешимая сложность в организации отправки команды по прерыванию таймера? Сложно для понимания? Ну что тут сказать, бывает, бывает.
Я раньше встречал две крайности. Вторая крайность - на СТМке через DMA и таймер организовать полностью автоматическое дергание всеми ногами и заставить непрерывно по кругу слать буфер дисплея. Был тут, на радиокоте и на другом форуме один "товарисчь" с характерным ником STM32F0, особо радевший за этот способ. Ну да, я тоже попробовал тот способ. Не понравилось, оверинжениринг.
Так что, есть две крайности, а истина - она посередине.

[Jack_A]

[uquote="НовыйДень",url="/forum/viewtopic.php?p=4229058#p4229058"]... дисплей - это самая главная деталь конструкции и обязательно нужно ставить цветной TFT 480х420 ?[/uquote]
... с анимацией и озвучкой
У программистов это называется "бантики завязывать".

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

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

[НовыйДень]

Я имел ввиду посередине между полностью автоматической постоянной перерисовкой дисплея и полностью ручным ногодрыгом через ожидание. И говорил, что если на 8 МГц МК такое ожидание еще ниче, пойдет, то при 72 МГц МК это уже будет слишком большим процентом неэффективного расходования частоты МК. И даже в конкретных цифрах - 40000/14. Потому что 72 МГц неспроста же выбирают. Значит, они нужны для другой работы. И не обязательно, что простой дисплей подразумевает несложную работу. На квадрокоптере вон вообще две лампочки, а математики - дайбоже.

[ARV]

до тех пор, пока не узнаю, в чем смысл экономии "простоя", останусь при своем мнении. если на 8-битном 8-мегагерцовом МК тупое ожидание 1,5 мс зачастую ничего не стоит, то на 32-битном 72-мегагерцовом и подавно. а неумение организовать простейшие алгоритмы без DMA и т.п. аппаратной поддержки тоже многое сообщает о программисте

[НовыйДень]

Ваше право, каждый выбирает свой путь, у каждого свой багаж опыта. Если у вас всё сводится к
[uquote="ARV",url="/forum/viewtopic.php?p=4228404#p4228404"]я использую библиотеку, которая работает по ожиданию готовности контроллера ЖКИ, т.е. считывает его регистр статуса и анализирует бит занятости. т.е. как бы делает кучу "лишних" обращений. <...> я настаиваю на том, что <...> по прерываниям, не только не даст положительного эффекта, но и ничего, кроме гемора, не даст вообще.[/uquote]
то это ваше священное право, коль вы испытываете гемор с организацией передачи по прерываниям.
Видимо, вы просто не понимаете разницы между 72 МГц и 8 МГц и выполняемых задачах. Но это тоже ваше право не понимать и тупить пять раз подряд. Вы свободны и вольны делать что вам лично угодно. Но это не говорит о том, что вы безоговорочно правы. Просто вы не совсем верно информированы по теме, только и всего. Но это тоже ваше священное право быть плохо информированным, не понимать и тупить. Так что на ваши права никто не покушается, вы свободны в своем решении тупить.

[veso74]

Как фанат аналоговой техники, некоторое время назад я был категорически против использования микроконтроллеров для простых действий: реле времени, температуры и т.п. Во время своих экспериментов с микроконтроллерами для хобби понимал, что с цифровыми методами намного проще. Хоть реле времени, хоть датчик температуры я уже предпочитаю подключать к микроконтроллеру и думаю уже радикально противоположное - все: на микроконтроллери . (друг шутит: уже предохранитель - с MCU ).

Здесь не все профессионалы (примерно 90%), а примерно MCU и программирование для отдыха и хобби. MCU в большинстве случаев в цикле (почти) ничего не делать. Так что загрузка данных на дисплей с методической погрешностью будет работь, а в хобби это важно. А напр. мне попадались профессионалы, которые так и остались на уровне "сложной" простой операции (написание все кода: только на ассемблере). У их устройство никогда не усложняется в функционале. Всегда нет времени.

Всегда можно лучше. Правда, каждый способ интересен, но не стоит усложнять до бесконечности. Современные контроллеры допускают загрузку по, казалось бы, неоптимальным алгоритмам. И если это улучшите, эффект будет (почти) нулевым (в 95% случаев на практике). ЦОС с MCU не все делаем. Правда, не буду управлять атомную станцию, ни в Космос не буду летать со своим конструкциями. Личное мнение. (частично пользуюсь переводчиком БГ -> РУ)

P.S. ATmega328P в Arduino Nano пишет обе строки на LCD1602 (123456789012345 и ABCDEFGHIJKLMNOP) за 9632 µs (с двумя перемещения позиции курсора: в начале строк). Однако код состоит из 4 строк.

[ARV]

конечно, я не понимаю разницы между 72 Мгц и 8, потому что никто так и не смог объснить, какие такие задачи не позволяют "тупить" на 72 Мгц, как никто и не смог объяснить или хотя бы продемонстрировать, на что полезное будут потрачены сэкономленные 1,5 мс...

лично я ни разу не сталкивался с тем, что об этом нужно беспокоиться на 8 Мгц, хотя приходилось решать достаточно "большие" задачи - МК успевал "в реальном времени" абсолютно всё. поэтому я и не могу представить, чем можно нагрузить 72 Мгц. это как если бы для текстового редактора не хватило мощности i7. кстати, я в курсе, что плоды рук современных программистов не на всяком i7 нормально работают, и даже знаю, почему...

[Dimon456]

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

[ARV]

как раз в этой ОС процессор не скучает: где-то проскакивала инфа, что на каждое нажатие клавиши на клаве винда выполняет больше команд, чем было выполнено за весь полет к Луне Аполлона. современные программисты умеют рационально использовать мощность аппаратуры!

[Dimon456]

современные программисты умеют

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

[НовыйДень]

Динамическое управление частотой, режимы пониженного энергопотребления? Не, не слышали, так? Вот именно.

поэтому я и не могу представить, чем можно нагрузить 72 Мгц.

Ничего страшного, просто мало у вас опыта Не расстраивайтесь, что-то более сложное вам просто не нужно.

[Dimon456]

что-то более сложное вам просто не нужно

Обрисуйте, какой нибудь пример.

[НовыйДень]

Ранее по тексту уже писал "какой-нибудь пример".

[Dimon456]

Где?

Добавлено after 8 minutes 41 second:
Все понятно, примера не будет.