Delay в библиотеке liquidcrystal_i2c.h. Есть ли альтернативы?
- Войдите на сайт для отправки комментариев
Вс, 10/01/2021 - 23:24
Доброго времени суток, прошу мнения знатоков, совета.
Есть устройство - измеряет температуру и давление в колбе, реализована обратная связь, т.е. поддерживает заданные величины (давление - шаговым двигателем, температуру вторым шаговым двигателем). Весь код без библиотек, только loop и прерывания по таймеру. Всё реализовано на Arduino Mega.
Сейчас стоит задача: выводить текущие данные с датчиков на 1602 к примеру, три "страницы" листать кнопками: на 1-ой текущие значения °С и 
Ознакомившись с библиотекой liquidcrystal_i2c.h немного растерялся, ведь при вызове lcd.clear, home, и многих других используется delay, при том еще и немаленькая. Если кто-то готов дать совет - прошу исходить из того, что delay использовать в регулируемых мною процессах просто недопустимо, возможно есть альтернативы всё же?
Вопрос: как выводить данные на дисплей 1602 по шине I2c избавившись от delay?
И вопрос номер два: вот была эта библиотека написана, и работа периферии (дисплея) ДОЛЖНА подвешивать МК на какое-то время, не иначе. Честно, в голове не укладывается, не могу понять.
Вот, пытаюсь разобраться, забыл в вопросе упомянуть что i2c собственно и некритично использовать, для того Mega и была взята. Но тут вижу тоже есть delay
Есть задачи, где эти дилеи не страшны, поэтому библиотека вполне себе жизнеспособна. Если же избегать тяжёлых операций типа clear(), то 90% потребностей простого ардуинщика ею удовлетворяются.
Вместо clear забиваю дисплей пробелами, не знаю на сколько это правильно, но делеев нет при этом способе)))
m.yakovenko, вот Вы обратили внимание на наличие delay(), а ничего, что эта библиотека выводит один символ 2.9 мс? Другими словами, просто вывод двух строк по 16 символов займет более 100 мс.
Вам надо не пугаться delay(), а сформулировать четкие критерии: какие задержки для Вас допустимы (любой код создает задержки), а какие - нет. И, исходя из этих критериев либо писать/подбирать софт, либо подбирать "железо", ибо нет никаких гарантий, что использование первого попавшегося дисплея позволит удовлетворить требования сформулированных критериев.
Я с вами полностью, всецело согласен. А вы согласны ли с тезисом: LCD это периферия, работа с которой почему-то должна подвешивать процессор управляющего им устройства и это де-факто признаётся как норма?
Вот я не delay-диссидент, а просто не понимаю.
"выводит один символ 2.9 мс" - пусть себе выводит, зачем процессор тормозить-то, а не прекращать обмен данными с памятью дисплея на это время?
Собственно, выход я уже нашёл: 150 рублей. Ардуино Нано с LCD и кнопками в роли slave, моя Mega как мастер.
Но, конечно, хотелось всё в один МК поместить, а это два как-то как колхоз. Ну да ладно, это уже лирика.
"выводит один символ 2.9 мс" - пусть себе выводит, зачем процессор тормозить-то, а не прекращать обмен данными с памятью дисплея на это время?
Прошу не придираться к словам - надеюсь смысл понятен, что после вызова lcd.clear можно делать что-то полезное, а не стоять на месте.
Типичное замешивает мух в котлеты.
Никто не мешает написать отличную библиотеку, которая по таймеру кольцевой буфер выплёвывает в дисплей. Но для любительских нужд это не требуется. Если у вас рилтайм устройство - не используйте liquidcrystal, рисуйте код сами.
Ознакомившись с библиотекой liquidcrystal_i2c.h немного растерялся, ведь при вызове lcd.clear, home, и многих других используется delay, при том еще и немаленькая.
какая "немаленькая задержка"? 2 миллисекунды? Вы серьезно?
Вам уже выше сказали - вывод любой строчки на этот дисплей займет у вас как минимум на порядок дольше. И все это время ваша система точно так же "не будет делать ничего полезного". в том числе не будет реагировать на сигналы датчиков.
Если у вас столь критичнывй процесс, почему задержка в 30-50мс на время вывода строчки вас не трогает, а задержка 2мс на очистку дисплея - вдруг так важна?
По-моему вы просто не понимаете, о чем говорите. Вам кажется. что во время вывода данных на экран контроллер продолжает следить за вашим процессом. а во время задержки - он "тормозит". На самом деле разницы между командой вывода символа и командой очистки дисплея нет никакой - и там и там контроллер засыпает и тупо ждет 2-3 мс
"выводит один символ 2.9 мс" - пусть себе выводит, зачем процессор тормозить-то, а не прекращать обмен данными с памятью дисплея на это время?
Правильно, зачем тормозить процессор. Рисуем собственную библиотеку, которая ничего не выводит в шину и2с а аккуратно складывает байты для вывода в буфер. После формирования ВСЕГО буфера даём "отмашку" в виде флага и уходим из процедуры. Другая процедура, которая синхронизирована с таймером (например раз в 1 секунду) "смотрит" на флаг "отмашки" и если есть оба события (флаг + таймер) запускает третью процедуру, которая СПОКОЙНО байт за байтом выводит на АППАРАТНОМ уровне через вектор_TWI весь буфер на шину и2с. Всё будет без ДЕЛЕЕВ и на аппаратном уровне, время ПРОЦЕССОРА не будет затрачено ВООБЩЕ. Есть и подводные камни у этого метода, но куда-ж без них, зато БЕЗ делеев! )))
Вариант №1 (для джедаев) - работать с экраном без этой библы. Ну, тоесть, написать свою со всеми пирогами.
Вариант №2 простой, для лентяев. Использовать ДВЕ ардуины, соединенные любым простым способом, например по UART. Одной снимать показания и быстро выпинывать их во вторую. Вторая без всякой спешки работает со штатной библиотекой экрана. Если вместо второй ардуины взять ESP, то еще и на телефончик можно будет передавать
"выводит один символ 2.9 мс" - пусть себе выводит, зачем процессор тормозить-то, а не прекращать обмен данными с памятью дисплея на это время?
Ну так а кто будет выводить? Вот процессор и выводит. Все 2.9 мс. Можно сделать, чтобы выводил быстрее? Конечно можно! Можно, чтобы на порядок быстрее? Тоже можно. Вопрос, стоит ли этим заниматься? Ответ - стоит, если это решит Ваши проблемы. Мои, например, решились: http://arduino.ru/forum/apparatnye-voprosy/medlennaya-rabota-liquidcrystali2c А решит ли Ваши, я не знаю, конкретных цифр Вы не приводите.
Прошу не придираться к словам - надеюсь смысл понятен, что после вызова lcd.clear можно делать что-то полезное, а не стоять на месте.
Смысл как раз непонятен: я ни разу не использовал lcd.clear, объясните смысл этого действия.