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

В очередной раз напоминаю, вы в теме AVR. Периодически встречаю ваши сообщения. От вас нет элементарного понимания, в каком вы разделе находитесь. Практически все ваши рассуждения отталкиваются от 1 - ARM. 2 - Использование ОС. Для вас нет проблемы времени, насколько я понял. Для других есть.

"Визуально". Я изначально отметил, если нет динамики. Просто вывод какой то инфы на дисплейчик.

Форум не запрещает писать в любых темах, тем более, что я когда-то занимался AVR/PIC. Не начинайте срач и не передергивайте, как в прошлый раз!
Так вот. "Торможение" программы - не более 4 мс, а для критичных по времени реакции событий есть прерывания. Зато визуально на дисплее не будет характерного эффекта замедленной перерисовки, которая в случае сравнительно быстроменяющейся информации создаст неприятное визуальное впечатление.
Я всего лишь высказался на основе своего реального опыта работы, а он у меня весьма немалый накопился теперь уж.
Я лично пробовал когда-то отправлять на дисплей по одному символу каждую 1 мс. На 0802 или на 1602 еще пойдет. Но на 1604 и 2004 уже визуально плохо смотрится и того не стоит. Более того, если отправляете каждую 1 мс, то проверять занятость дисплея НЕ нужно, поскольку все операции, за исключением двух, занимают не более 43 мкс.

Я и написал метод, при котором не нужно опрашивать флаг готовности. Как бы само "каждые 1 мс" об этом и говорит. У меня в активе приборы, блоки управления станками. Клиенты не жаловались. VFD был выбран, когда были требования к высокой вибрации. ЖКИ периодически меняли. На одном предприятии небольшая серия блоков управления термоформовочными станками с VFD работают круглосуточно где то с 2011-2013 годов.

Плата 24 входа. 16 выходов. Сдвиговые регистры. Матричная клавиатура. Символьный VFD дисплей 20х4. ATMEGA32A. ОС в помине нет. Прерывание только аппаратный таймер настроенный на 1 мс. Конечные автоматы, программные таймеры. Вот о чем речь. Вывод на дисплей каждые 1 мс, чтобы весь основной цикл выполнялся с запасом. Мало того, так как VFD быстрый, у меня на него не по символьно, а построчно. То есть по 20 символов каждые 1 мс. Итого. 4 адреса строк, 4 строки. Цикл 8 мс. Вроде так. Надо проект поднимать. При этом нет торможения программы.

Какое это имеет отношение к теме автора про ШИМ-генератор? Тут вообще другая тема!

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

весьма неумное решение.
выводить нужно сразу весь буфер.
на один символ нужно 37 мкс. возьмем с запасом - 40 мкс. итого 84 байта будет отправлено за 40 * 84 = 3360 мкс или 3,36 мс. глаза даже не заметят, как обновляется экран.
это ты своим алгоритмом делаешь их медлительными.

Прямое. Генератор сигналов, ШИМ. Вывод на дисплей. Опрос кнопок. Метод, как распределить, раздробить процессы. Чтобы все делать псевдопараллельно. Один из способов. Понравится ТС, не понравится, будет он применять или нет, это он уже будет сам решать. Я показал один способ.

Ведите себя конструктивно на форуме. Критикуя, предлагай. Как и положено себя вести профессионалам. От слова профессия. Вид деятельности.

Добавлено after 4 minutes 43 seconds:
Чтобы этот диалог был конструктивным и обоснованным, возьмите дисплей. И начинайте играть с времянками. Задача. Вывести на дисплей стандартным способом на все его заполнение. 8х2, 16х2, 20х4. Неважно. Замерьте время от начала отправки данных до окончания.
Я это все уже делал. Почему и стал применять такой метод. Не везде. Потому что согласен. При динамике такой способ не очень. Но то такэ... Все зависит от задачи.

Есть ещё нюанс. Если все правильно помню. На двух строчный дисплей можно выводить разом. 4 строчный только с заданием адресов строк. Иначе будет выводить через строку.

2Starichok51. Я использую системный тик. Из прерываний убрался вообще. Оставил только критические моменты. Генераторы, ФИУ, программный ШИМ, BAM. У меня даже динамическая индикация крутится в основном цикле. И при этом нет мигания сегментов, знакомест. Потому что основной цикл крутится с запасом за системный тик. 0,1-1 мс, 5 мс, 10 мс

Пример 1.
Пример 2.

HD44780 имеет память на 2х40 символов. А уж как они делятся на строки - это зависит от дисплея. 1602 первую строку начинает с адреса 0x00 по 0x0F, а дальше заполнение пойдет вне пределов видимости на экране, вплоть до адреса 0x40. У дисплея 2004 задействовано максимальное число символов - 80, но строки дисплея отображаются на адресное пространство контроллера через 1 строку. В принципе, если в ОЗУ микроконтроллера это учесть, то можно выводить без команды переключения строк, непрерывно.

Да, и вон даже Starichok51 верно заметил, что на большом 4-хстрочнике вывод через 1 мс будет визуально медленным. Я лично это раньше пробовал - визуально заметна задержка между перерисовкой первого и последнего символа на дисплее. Раза в 3 надо бы быстрее выводить.

Конструктивно уже было предложено - либо использовать маленький 1602, где визуально практически не заметно, либо уменьшить интервал раза в 3, до 300 мс, либо выводить за один раз за 4 мс (не забывая про вообще прерывания для других быстрых дел), либо ... блин, забыл, че хотел написать. В общем, всё тут ясно, как бы вот.

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

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


Принято.

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

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

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

И кстати, перечитайте мои сообщения. Почему я раздробил отправку адресов строк и символов. Системный тик. Выполнение основного цикла должно выполняться с запасом за системный тик. У меня подход такой, понимаете? Так как используются программные таймеры, чтобы не было разбросов по выполнению временных интервалов, основной цикл, что бы в нем не было, должен проворачивать все процессы менее чем за системный тик. И торможение программы на несколько миллисекунд, это проблема. Программные таймеры начнут врать. Про пребывания я уже писал. Я убрался вообще из них. Флаги, критические секции.

Все дисплеи которые я использовал вели себя без тормозов… вот пример своей стандартной библиотеки для АВ… тест для ЖКИ 1604… запись производится построчно… алгоритм сделан таким образом, что при завершении заполнения последней строки, заполнение строк опять начинается с первой… через каждую секунду символы строк меняются… первая цифра в четвёртой строке показывает значения счётчика который считает от 0 до 9… изменение значения в счётчике происходит каждые 130 мс. И это значение выводится на экран… как можно увидеть, никаких тормозов нет.

Тест написан для шильда ардуины нано (мега328Р; 16 МГц)… подключение ЖКИ: RS – PD7; R/W – GND; E – PB0; четырёх битная шина P4 – PB1; P5 – PB2; P6 – PB3; P7 – PB4.

А эта версия примерно в два раза медленнее выводит значения на экран (весь экран заполняется примерно за 11 мс)…

Но глазами этого не увидеть…

Речь идёт о том, что:
1 - Команда очистки экрана занимает примерно 1600 мкс.
2 - В случае полного обновления экрана эта операция займет несколько мс.

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

Ребят, я немного о другом. LCD тормозит при пониженных температурах, также в datasheet упоминается, что напряжение регулировки контраста зависит от температуры. Интересует опыт в этом вопросе.
Даже при +15 C уже тормозит и мигание при изменении шага было почти не видно.

Demiurg, а как ты отмеряешь ровно 1 мс без прерывания таймера?

Два варианта. Прерывание, в прерывании переинициализация таймера, инкремент счётчика. Или проверка флага.

Спойлер

Код:

void init_soft_timers (void)

{
   sys_tick = 0;
   ST_TCNT = 0;
   ST_OCR = SYS_TICK;

#ifdef __IOTINY13_H
   ST_TCCR |= ((1<<ST_CS1) | (1<<ST_CS0));
#endif

#ifdef __IOTINY13A_H
   ST_TCCR |= ((1<<ST_CS1) | (1<<ST_CS0));
#endif

#ifdef __IOM8A_H
   ST_TCCR |= (1<<ST_CS2);
#endif

#ifdef __ST_INTERRUPT__
   set_bit (ST_TIMSK, ST_OCIE);
#endif
}

#ifdef __ST_INTERRUPT__

#pragma vector = TIMER2_COMP_vect

__interrupt void SysTimerComp (void)

{

   ST_OCR += SYS_TICK;

   sys_tick++;
}
#endif

#ifdef __ST_NO_INTERRUPT__

void proc_sys_tick (void)

{

   static u08 _proc_sys_tick;



   switch (_proc_sys_tick)
   {
      case 0:
         init_soft_timers ();
         _proc_sys_tick = 1;
         break;

      case 1:
         if (ST_TIFR & (1<<ST_OCF))
         {
            ST_TIFR = (1<<ST_OCF);
            ST_OCR += SYS_TICK;
            sys_tick++;
         }
         break;
   }
}
#endif

__C_task main (void)

{

   wdt_enable (WDTO_15_MS); // ������������ ����������� �������. 16 ��.

   Init_Events ();



   __enable_interrupt (); // ���������� ���������� ����������.

   while (1)
   {
      __watchdog_reset ();

      proc_sys_tick (); // Если без прерывания таймера.

      kbd_drv ();

      proc_device ();

      Process_Events ();
   }
}

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

Так как у меня основной цикл всегда выполняется с запасом в пределах системного цикла, то временные задержки получаются довольно точными. Единственный момент. Установка программного таймера может произойти в любой момент в пределах системного тика. Но, так как я об этом нюансе знаю, то никогда свой программный таймер не ставлю на одиночное срабатывание. Если речь идёт о десятках и сотнях мс, этот нюанс нивелируется. Выше я выкладывал ссылки на видео. Динамическая индикация спокойно работает в основном цикле. Программный таймер настроен на 1 мс. Разбег максимум десятки тактов. Индикаторы работают четко, без миганий.

1 Я очистку экрана делаю лишь один раз – при инициализации ЖКИ и более ИМХО она не нужна… по крайней мере не вспомню когда она может понадобится ещё… если нужно часть символов убрать, то я просто вывожу пустой знак "$32" на то место и этого достаточно…
2 Я не использую при обновлении всего экрана процедуру очистки… считаю что она избыточна для данного ЖКИ… просто выводя на дисплей другие символы, они заменяют старые… зачем что-то дополнительно очищать?

ИМХО это ошибочное действие… выше я объяснил как можно не применять очистку тем самым уменьшить задержку для вывода очередного обновления символов…

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

И в мыслях не было затевать спор. Я лишь показал свой подход к реализации вывода символов на дисплей… если Вам удобен свой подход, то мне незачем оспаривать ваше желание… делайте как Вам будет угодно, мне лично всё равно как Вы это делаете…

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

Тогда уточните, о какой точности идёт речь. Потому что я ответил на ваш вопрос.
Первый вариант, это прерывание аппаратного таймера настроенного на 1 мс. В прерывании инкремент переменной счётчика.
Второй вариант. Прерывание таймера отключено. По флагу инкремент переменной счётчика.
Пусть у нас основной цикл. Взвели программный таймер. Пусть это будет динамическая индикация. Пусть у нас 6 разрядов. При тике 1 мс мы получаем 166 гц. Приемлемо. Взводим таймер. Таймер с периодом. Крутится основной цикл. Если соблюдается условие, что итерация основного цикла происходит с запасом за системный тик, то разбег до нескольких единиц или десятков тактов. Пусть 100 тактов максимум. Мы получаем разбег при частоте кварца 16 МГц 0,0000065 с.
Теперь я ответил на ваш вопрос?