Не все примеры, с точки зрения программирования, являются корректными.
Однако я постараюсь показать проблему с точки зрения новичка.
Понимание происходящего в микроконтроллере очень важный момент.
.
В самом начале, как только очередной самоделкин открывает для себя мир микроконтроллеров, в его мозгу разрывается бомба.
- "А что, так можно было!?"
- "Круто!"
- "Это же можно сделать все что угодно!"
Пусть в меня бросит камень тот, у кого это было не так.
.
Проблемы начинаются практически сразу, как только вместо мигающих светодиодов к МК подключаются всевозможные датчики и исполнительные механизмы. Вдруг оказывается что МК не резиновый, капризный, да еще почему то и тормозной. Вот в этот момент и приходит понимание, что можно многое, но не все.
.
Одним из камней преткновения является время цикла. Чем больше скетч тем больше времени занимает цикл - первый вывод самоделкина. Конечно это утверждение не совсем верное, но доля правды в нем есть. Однако основным фактором тормозов является качество кода скетча и используемых библиотек.
.
Ярким примером этого является библиотека LiquidCrystal и LiquidCrystal-I2C. Это та самая библиотека без которой не обходится проект с применением LCD дисплея на чипе HD44780. Конечно у пользователей FLProg есть альтернатива в данном случае. Ну например использовать наработки ecoins. Однако мучить себя изучением сего монументального труда, не каждый может себе позволить. Сама библиотека в целом не плоха, но есть в ней некоторые функции которых следует остерегаться и по возможности избегать да и применение в ней команды delay отрицательно сказывается на результат. Вот к примеру в ПБ LCD_V2.18 исключены некоторые отрицательные моменты и скорость обработки его кода увеличилась на порядки. Конечно же речь идет о простом его применении, без русификации и доп. наворотов.
.
Мысль о написании данной статьи пришла ко мне во время тестирования ПБ Энкодер Pro.
Суть в том, что у данного блока есть два типа выходов. Первый это числовой выход Count, на который выводится информация о количестве совершенных энкодером шагов и второй тип это логические выходы Up и Down, на которых отрабатываются импульсы согласно тех же совершенных энкодером шагов. Так вот если с первым типом все ОК, то второй напрямую зависит от времени цикла выполняемой программы. Один импульс может быть совершен минимум за два цикла, т.е. в одном цикле на выходе блока "1" на следующем "0" и т.д. Соответственно если вы умудрились сделать цикл в 250мс, что не предел для новичка, то импульсы будут совершаться два раза в секунду (250х2), а это ну совсем не гут.
.
Рассмотрим пример с тестовым скетчем для ПБ Энкодер Pro.
.
Вариант 1 (используется штатный блок дисплея)Показать
Вариант 2 (используется блок дисплея LCD_V2.18)Показать
Желающие могут самостоятельно протестировать проекты. Потребуется дисплей на 4 строки, 4 кнопки, энкодер, ну и конечно же какой нибудь МК (AVR или ESP32). Не забудьте изменить пины, если у вас не ESP32. Как говорится - Доверяй, но проверяй.
.
При работе со штатным блоком дисплея, отчетливо видна задержка вывода данных со счетчика который подсчитывает количество импульсов.
Данные со входа Count выводятся моментально, т.к. приходят на блок дисплея сразу с блока энкодера. А вот импульсы с выходов Up и Down считаются счетчиком и только после этого попадают на дисплей.
При работе с блоком дисплея LCD_2.18 такая задержка почти не видна.
В связи с этим крайне не рекомендую использовать штатный блок дисплея, если у вас на дисплей выводится одновременно много данных.
.
Чуда не произошло. Точней оно произошло, но совсем не то чего хотелось бы.
