HRP-N3 - серия источников питания с максимальной пиковой мощностью в 350% от MEAN WELL

Пример управления LCD по линии UART

Новичок
 
Регистрация: 06.01.2013
Сообщений: 47
Репутация: 27
0 20
0 0
 
08.01.2015 20:46 #1
В любительских радио конструкциях широкое применение находят символьные LCD дисплеи на контроллере HD44780. При своей простоте, он занимает достаточно большое количество портов ввода-вывода микроконтроллера. Даже при подключении по 4-х битной шине, необходимо использовать минимум 6 выводов МК. Если не нужно считывать с LCD данные, то линию R/W можно подключить на землю.

Чтобы не загружать дисплеем ресурсы основного МК, можно применить драйвер на основе ATiny2313, который будет принимать команды по UART и отправлять их в контроллер дисплея (Рисунок 1). Таким образом, для управления LCD нужно всего две сигнальных линий Rx и Tx. Если обратной связи с драйвером не нужно, то вывод Rx основного МК можно не подключать.

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

Для управления дисплеем нужно несколько основных команд: init (инициализация LCD), clr (очистка дисплея), Pxx (установка курсора в указанный адрес) и D_ (данные выводимые на дисплей).

После отправки команды init, происходит инициализация дисплея (Листинг 1).

Дисплей 16*2 условно разбит на 4 сектора (Рисунок 2), каждый из которых имеет 8 адресов. Таким образом, при отправке команды нужно указывать сектор (А,В,С,D) и номер адреса (1..8). Для установки курсора в 1 позицию, нужно отправить команду PA1, где P – позиция, А – номер сектора, 1 – номер ячейки.

Конец ввода каждой команды определяется с помощью клавиши Enter (0x0D). На этом этапе программа переходит к изъятию данных с ОЗУ и последующим сканированием. Инициализация аппаратного UART со скоростью 2400 бод/с показана на Листинге 2. Фьюзы биты ATiny2313 установлены на работу от внешнего кварца на 4 МГц, деление на 8 выключено.

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

На каждую верно введенную команду, драйвер будет отвечать -Ок. Это нужно только для обратной связи с ведущим МК. Если данные введены не верно, или не точно передались, то появиться сообщение -error. На Рисунке 3 показан пример ввода данных (123) в LCD дисплей.

Чтобы очистить определенные ячейки дисплея, нужно установить адрес, с которого будет начинаться очистка Pxx и с помощью команды D_ отправить пробелы (0х20). Для очистки всего экрана используется команда clr.

Как-то так, делал на скорую, нужно было связать LCD по UART каналу. Можно сделать и по другому конечно. Комментируйте, предлагайте..
Изображения
Тип файла: gif Fig_3.gif (5.8 Кб, 0 просмотров)
Тип файла: gif List_1.gif (5.4 Кб, 0 просмотров)
Тип файла: gif List_2.gif (4.3 Кб, 0 просмотров)
Тип файла: jpg Fig_1.jpg (54.4 Кб, 0 просмотров)
Вложения
Тип файла: rar протеус + hex.rar (20.2 Кб, 0 просмотров)
Оценка
Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650. Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель.
Специалист
 
Аватар для antonydublin
 
Регистрация: 22.09.2010
Адрес: г. Донецк
Сообщений: 868
Репутация: 380
371 0
3 0
 
09.01.2015 06:06 #2
Денис, я с Вами не согласен.
Немного неясны предпосылки, хоть идея и не нова:
http://easyelectronics.ru/soprocessor-vvoda-vyvoda.html, а в более широком смысле http://www.rlocman.ru/shem/schematics.html?di=65893 и более универсальна.

Несколько примеров.
Некогда занимались приборами учёта, нужны были выносные «дистанционные» счётчики. Решение выглядело именно так: собственно счётчик на MCU1_UART->[RS485]->MCU2_UART->LCD. Занимались системами дозирования, конв. весами и т.п. Решение для дистанционного отображения (и управления) выглядело аналогично – выносной дисплей. Так же поступаем при многоточечном контроле температуры и давления, где в сеть собирается много всего (со своей индикацией или без) плюс с одним индикатором на всю сеть. Во всех без исключения случаях принято использовать стандартизированный Modbus с пакетной передачей. Единожды реализованный в девайсе программный драйвер и протокол позволят не только организовать удалённое отображение, но и подключить датчик/устройство к сети АСУТП. Общение с таким де факто «законченным» устройством даёт следующие преимущества, кроме упомянутой стандартизации (т.е. наличия стандартных и пользовательских команд Modbus): общение в формате «запрос/ответ», явная адресация ведомых, проверка целостности (контрольная сумма), коды ошибок/диагностики.

Помимо экономии ножек на МК (для чего существуют другие средства http://www.rlocman.ru/shem/schematics.html?di=149163, http://jap.hu/electronic/lcdif.html), Вы говорите «чтобы не загружать дисплеем ресурсы основного МК… в результате производительность основного МК увеличивается». Наверное я не прав, но если МК1 и МК2 расположены на одной плате, а не разнесены как в примерах выше, то получается несколько алогично, исходя из следующих соображений.

Собственно о предпосылках.
Как я понимаю, хорошим тоном считается всё общение МК с внешним миром (т.е. приём/передача данных) отдавать обработчикам прерываний. Так, к UART привязывают кольцевой буфер. Почти «мгновенная» запись всей посылки в буфер с последующей аппаратной обработкой/отправкой действительно быстрее: никаких ожиданий sbis -> rjmp на каждом байте, вместо этого выборка из буфера/сдвиг счётчика и запись в UDR по прерыванию TXCIE/UDRIE (флаги TXC и UDRE). Обратно, чтение и анализ входного буфера, который заполняется в обработчике RXCIE (флаг RXC), можно выполнять порциями тогда, когда МК действительно ничем не занят. Тем более, на скорости 2400.

Считаем, что линия RW используется.
Общение с LCD основано на время зависимых операциях, что обусловлено медлительностью контроллера HD44780 или любого другого (Fosc ~ 200-300кГц). Тогда, помимо последовательности задержек а) при инициализации, б) появлении данных на шине по изменению уровня на линиях E/RW, в) основная периодическая задержка возникает при проверке готовности LCD (LCD_BUSY_flag) перед чтением/записью данных/команд, т.е. вследствие ожидания выполнения контроллером LCD того или иного действия. Последнее ожидание для разных контроллеров, как правило, лежит в переделах 40-50мкс на команду, и несколько увеличивается при работе в 4-х битном режиме. Что даёт, например, единицы миллисекунд ожидания при выполнении команды очистки всего экрана.

Конечно, это всё аксиомы.
Но насколько часто нужно обновлять LCD в реальных устройствах, так что у МК просто не остаётся времени на всё остальное? К тому же, при быстрой смене изображений, пускай 10-20Гц, символы визуально будут сливаться. Если всё или почти всё общение с внешним миром построено на прерываниях, то в главный цикл выносится по сути три задачи:
а) чтение данных с периферии и математика их обработки,
б) анализ запросов и ответы master устройству на шине,
в) локальная индикация.

Несколько примеров.
Типичная задача пункта а) – последовательное чтение данных с внешнего многоканального АЦП по 2х, 3х или 4х проводной шине. В последнем случае часто используют аппаратный SPI, но учитывая, что современные АЦП допускают тактирование на цифровой шине 10-20МГц и выше, проблем с временными задержками не возникает и при работе с обыкновенным портом. Более конкретный пример – медленный АЦП AD7190 (с ним недавно возился). Линии CS, DIN, DOUT/RDY, SCLK (период 100нс). Обмен инициируется по низкому уровню на CS. Для своих 24 бит это не такой уж и медленный АЦП – 4.8кГц. Но в нём есть встроенные цифровые фильтры и, в зависимости от разных настроек, частота появления новых данных на выходе АЦП может быть намного ниже, скажем 10Гц. Но для МК на 10МГц время одного преобразования в любом случае тянется бесконечно. Поэтому на АЦП, пускай по таймеру, подаётся команда на преобразование (единичное или непрерывное), и МК продолжает заниматься обработкой предыдущих измерений, подготовкой данных для индикации и индикацией, анализом запросов master устройства и ответами по UART. Но как только выход RDY АЦП опуститься в ноль, что является источником предварительно настроенного внешнего прерывания для МК, последний считает очередное измерение АЦП, причём прямо в обработчике PCINT (INTx) – времени потребуется немного. Вернувшись в основной цикл и выгрузив всё из стека, МК вернётся к обыденным операциям.

Естественно, программа должна быть организована таким образом, чтобы время математической обработки было в разы меньше времени между опросами периферии. Это критично, например, при организации цифровых фильтров на МК, ведь нужно успеть просчитать до прихода новой точки измерений, чтобы не нарушалась Th. Котельникова. Но из «остатка» времени нахождения МК вне различных прерываний (приоритет не в счёт), из этих крупиц можно получить те миллисекунды, необходимые для обновления LCD в пункте в). Поэтому индикация всегда наименее приоритетна. Зачастую достаточно не чаще чем раз в 1с сменить показания, хоть внутри программы за это же время данные и будут пересчитаны сотни или тысячи раз.

На пункт б), учитывая, что он также построен на прерываниях, уходит не так уж много времени. Если нужно отослать по UART специальным образом организованные данные, основная трата ресурсов МК – это получение побайтового представления, пересчёт контрольных сумм и запись всего это в нужном порядке в массив на отправку.

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

А вот контрпример, в котором Ваш подход с аппаратным разделением задач эффективен и зачастую необходим. Это бегущие строки или псевдографика большой плотности, в частности с динамической индикацией. В двух словах: имеется множество многоканальных драйверов светодиодов с последовательной загрузкой (или просто регистров) – от нескольких десятков до нескольких сотен, данные в цепочке (цепочках) которых необходимо менять с частотой от 500Гц до 2-3кГц и выше (i.e. частота сканирования строк матриц светодиодов). Вся современная КМОП логика допускает на линии СLK 10-50МГц и выше. Поэтому если на физическое заполнение цепочки из тысячи бит времени в прерывании уходит относительно не много (без учёта физических задержек на м/с и повторителях), то много времени уходит на чтение и преобразование строк из массива виртуальной видеопамяти, который ко всему обновляется на каждом кадре формируемого изображения. Налицо множество операций копирования данных и побитовых операций: смена кадра каждые 10-20мс (для бегущих строк – побитовый сдвиг массива, зачастую многомерного, для псевдографики – полностью заполнение новыми данными, которые нужно ещё считать с карты памяти и возможно преобразовать), а также построчная выборка каждые 0.3-3мс из этого массива, двойная буферизация и переформатирование всего битового потока под разводку плат перед выводом.

В этом примере ресурсов 8-разрядного МК зачастую не хватает, а для RGB видеоэкранов тем более. Если все операции с массивами и функциями внутри программы можно пытаться оптимизировать, то в прерывании время вывода строки фактически фиксировано количеством бит и допустимой частотой СLK. Поэтому задачу формирования текущего изображения (обновления) видеопамяти и собственно «развертку» изображения действительно логично разделить между двумя МК, а лучше между МК и ПЛИС.

Вернусь к исходному.
Мне кажутся спорными следующие положения:
- для экономии выводов МК требуется ещё один МК;
- для экономии времени ЦПУ требуется ещё одно ЦПУ, причём последнее незагружено;
- для управления LCD требуется двухуровневая система команд, причём «родные» инструкции HD44780 замаскированы фактически дублирующим протоколом поверх UART с ограниченным набором команд;
- для получения простоты подключения LCD отказоустойчивость принесена в жертву, т.к. за мнимой простотой скрываются дополнительные проводники на платах и паяные соединения.

В случае необходимости дистанционной индикации/управления концепция абсолютно справедлива, только одного UART для больших расстояний будет недостаточно, что говорил в начале.

Идея эта, мне кажется, пришла из мира Arduino, как попытка облегчить платформу путём избавления от нескольких соединительных проводов:
http://playground.arduino.cc/Learning/SerialLCD,
http://arduino.cc/playground/Code/SerLCD,
http://www.maplin.co.uk/p/serial-uar...-arduino-n92dg.
Поэтому считаю такое решение «навязанным».
Оценка
Компания Компэл, официальный дистрибьютор EVE Energy, бренда №1 по производству химических источников тока (ХИТ) в мире, предлагает продукцию EVE как со склада, так и под заказ. Компания EVE широко известна в странах Европы, Америки и Юго-Восточной Азии уже более 20 лет. Недавно EVE была объявлена поставщиком новых аккумуляторных элементов круглого формата для электрических моделей «нового класса» компании BMW. Продукция EVE предназначена для самого широкого спектра применений – от бытового до промышленного.
Новичок
 
Регистрация: 06.01.2013
Сообщений: 47
Репутация: 27
0 20
0 0
 
10.01.2015 22:24 #3
antonydublin, да идея не новая. не давно увидел, что ардуино выпускает подобное по i2c только. Решил не искать готовых решений, а сделать самому по быстрому, тем более, что uart мне ближе как-то чем i2c. С одной стороны, действительно нужна еще одна микросхема для управления дисплеем, но если делать драйвер LCD, то без этого никак не обойтись. Конечно команды управления скрыты, мы только посылаем упрощенные, если можно так сказать. дело все-же более индивидуальное, под конкретную задачу.
В моем случае задача была скорее сэкономить выводы основного МК, нежели его производительность.
С уважением, Денис
Оценка
Ответ
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Оценка этой теме
Оценка этой теме:
Похожие темы
Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход
Электронные компоненты. Бесплатная доставка по России
Часовой пояс GMT +3, время: 19:58.
Обратная связь РадиоЛоцман Вверх