Вопросы по борьбе с артифактами на LCD экране
- Войдите на сайт для отправки комментариев
Доброго времени суток. Возник у меня следующая ситуация: Подключал я LCD экран к ардуинке и радовался выведенным символам на экран. Скажу сразу подключался я по 4 битной шине. Всё классно когда экран лежит рядом. Но если увеличить длину линии хотябы до 0.5 метра. В какой то момент линия начинает ловить наводки и на экране появляются артифакты. Для лечения пробовал и кондеры припаивать в цепь питания экрана и резистор переносить и запитывать экран напрямую от источника питания. Всё равно возникают артифакты. Вопрос: Как побороть артефакты на экране? Возникло две мысли которые хотел бы с вами обсудить. Что если использовать 8 битную шину? Насколько она устойчива к наводкам? и что если после отправки данных на экран по 4 или 8 битной шине, потом их считывать и сравнивать? Если сумма не сошлась, отправлять по новой на экран данные. Ну и тут вопрос по скорости передачи. Не будет ли схема с передачей и считыванием данных в 4 битном режиме слишком медленной? Жду ваши мысли по моим вопросам.
Мысль есть такая: в юрисдикции общего собрания собственников МКД принять закон запрещающий экранам работать с артифактами. Как смотрите на такой вариант решения?
Эффективность решения примерно на том же уровне, что и предложенные в первопосте.
Мысль есть такая: в юрисдикции общего собрания собственников МКД принять закон запрещающий экранам работать с артифактами. Как смотрите на такой вариант решения?
Мысль есть такая: в юрисдикции общего собрания собственников МКД принять закон запрещающий экранам работать с артифактами. Как смотрите на такой вариант решения?
Интересное решение по поводу запретить, но увы не реализуемое.
Эффективность решения примерно на том же уровне, что и предложенные в первопосте.
Порекомендуйте тогда решение чтобы было эффективным?
Но если увеличить длину линии хотябы до 0.5 метра.
По-моему, решение на поверхности
Попробуй использовать для передачи данных на дисплей 4 экранированных провода. Все экраны соединить вместе и на GND.
Ещё как вариант перейти на i2c, может даже подключить кабелем utp.
Update: Может быть даже по четырехбитной шине тоже через UTP попробовать подключить. Там как раз 4 пары. Один провод пары как сигнальный, второй на GND. И так все.
I2c это конечно хорошо, но вот у меня на руках сейчас контроллер от аппарата по продажи воды. Сделан на амега32 и внём весь порт б занят для экрана и еще две ноги порта д. Я год имею дело с этими контроллерами, не разу не видел чтобы экран подключённый к этому контроллеру артефачил. Вчера прозвонил шлейф от экрана до контроллера. Линия отвечающая за переключение между режимами чтение запись у экрана подключена к земле. Отсюда сделал вывод что 8 битная шина надёжней, ну и решил спросить у сообщества кто что по этому думует?.
Возникло две мысли которые хотел бы с вами обсудить. Что если использовать 8 битную шину? Насколько она устойчива к наводкам?
Тоже самое, только скорость в два раза выше, можно уменьшить в два раза тактовку и как результат - в два раза меньше глюков.
и что если после отправки данных на экран по 4 или 8 битной шине, потом их считывать и сравнивать? Если сумма не сошлась, отправлять по новой на экран данные.
Верно мыслишь. Но придётся написать самому этот кусок кода с проверкой команд и данных на дисплей.
Ну и тут вопрос по скорости передачи. Не будет ли схема с передачей и считыванием данных в 4 битном режиме слишком медленной? Жду ваши мысли по моим вопросам.
Делал давно по I2C шине С ПРОВЕРКОЙ отправляемых данных на контроллер. Была та-же самая проблема - при многосуточном прогоне появлялись кракозябры. Здесь всё зависит от умения, если сможешь написать свою библиотеку или функцию - всё будет ОК. Про скорость ->> И советую почитать DiHalta, он написал на асме полный конечный автомат, который прямо в прозрачном режиме и только на железных интах последовательно отправлял данные в контроллер. Запускал одновременно ЧЕТЫРЕ дисплея по I2C - глюков не было. Единственное но - придётся изобретать что-то типа диспетчера задач или как-то делать приоритеты, чтобы "кто-то" не помешал обмену данными с контроллером. Это касаемо нескольких дисплеев, с одним, думаю, норм всё будет.
Вчера прозвонил шлейф от экрана до контроллера. Линия отвечающая за переключение между режимами чтение запись у экрана подключена к земле. Отсюда сделал вывод что 8 битная шина надёжней, ну и решил спросить у сообщества кто что по этому думует?.
Скоростью тактовки управляешь именно ты, можешь больше, можешь меньше. Если контроллер успевает "схавать" - всё норм, если нет - возникают ошибки. Причём они имеют свойство накапливаться и артефактов становится всё больше и больше.
Если сумеешь сделать что-то типа диспетчера экрана с последовательным выводом данных на дисплей. Допустим, 20Х4 = 80 байт. Типа буфера дисплея. Ну и далее побайтово обновляешь дисплей. Я делал раз в секунду, всё норм.
К сожалению я "остыл" к ардуино и атмелам, пересев на стм...
Если проблема в накоплении, то что мешает иногда перерисовать весь экран?
Вчера прозвонил шлейф от экрана до контроллера. Линия отвечающая за переключение между режимами чтение запись у экрана подключена к земле. Отсюда сделал вывод что 8 битная шина надёжней, ну и решил спросить у сообщества кто что по этому думует?.
Скоростью тактовки управляешь именно ты, можешь больше, можешь меньше. Если контроллер успевает "схавать" - всё норм, если нет - возникают ошибки. Причём они имеют свойство накапливаться и артефактов становится всё больше и больше.
Позвольте уточнится. Скорость тактовки это частота работы мк? Тогда такой вопрос. Тогда получается чем выше частота работы мк, тем больше вероятность артефактов?
Не совсем так... контроллер (если память моя не подводит) ждёт выставления данных на шине + импульс строба, на считывание. Посему, чем чаще импульсы стробирования - тем выше тактовка.
Уважаемые прошу опять совета. Нашел код работы lcd экрана с чтением флага занятости. Запустил код работает, в протеуси при симулации видно что мк читает lcd экран. Но вот беда на сам экран ничего не выводится. Я уже голову сломал в чем проблема. Подскажите что не так.
В протеус нет картинки или в железе ?
Пока в протеусе. В железене нету возможности проверить на данный момент.
Пока в протеусе. В железе нету возможности проверить на данный момент.
На том же сайте где вы взяли код - есть проект для Proteus и HEX файл в проекте для Atmel Studio - с ними картинка есть !
Да оно работает, но если вы посмотрите функцию lcdIsBusy то вы увидите что она закоментирована. Если её раскоментировать происходит именно то о чем я писал выше.
Вы хотите странного просто. Надо большое расстояние - экранируйте линии или ставьте второй контроллер рядом с экраном.
Та нет, странного я не хочу. Просто зачем делать экран если можно этот вопрос в программе решить
Если данные искажаются по дороге - то программа не поможет !!! Экран то не знает что ему приходят кривые данные и он не умеет проверять данные на правильность !!!
Взять плоский шлейф и каждый второй провод на GND с обоих концов - может и заработает.
Ещё вариант - на середину кабеля или ближе к LCD повесить повторитель.
Пока в протеусе. В железе нету возможности проверить на данный момент.
Ипать_капать ты тяжек на_падЪйом, шо пипец.
ПрАтеус нибуЙа нипаказатель работоспособности в железе и в софте!!!
Советую забросить ЭТУ идею, ибо не_сдюжишь ты её асилить... ((((((((((((((((((((
Если так рассуждать, то мы бы до сих пор сидели в каменном веке. А я хочу научится решать эту задачу
Дык ты её изначально неправильно построил. Команду контроллеру нужно давать В ТЕЛЕ ОТПРАВКИ КОМАНДЫ и проверять там-же, а не как у тебя, послали и... когданить проверили. Это не правильно априори!!!
В нете есть библа ПОЛНОСТЬЮ на асме, байт в 200-300, уотт там всё сделано классно и "быстро" и она работает. Аффтора не помню, дело было лет 10 назаТ...
Учись... у тебя вся жизнь впереди...
Никто тебе толком ничего не подскажет... помехоустойчивость наука очень тонкая... тоньше чем у комара...
Начнём с того... что пол метра шлейки уже плохое решение...