готовые библиотеки поддержки ЖКИ, в которых есть готовые функции вывода символа на дисплей
Да, это так,но в этих библиотеках обычно нет обработки даже символа возврата каретки,не говоря о чем-то еще.
Типично это функция вывода символа в заданную позицию,и написанная на ее основе функция вывода строки начиная с заданной позиции. Причем кусок который на индикатор не влез - чаще всего просто обрезается.
и максимум, что еще будет нужно, добавить обработку символов перевода строки и возврата каретки
Именно об этом я и говорил. А кроме перевода строки и возврата каретки вполне востребована инверсия и мигание.
Если мы пишем свою функцию - то и позицию и признаки инверсии/мигания мы можем просто передать ей в качестве аргументов.
Если мы используем printf то это придется сначала закодировать в строку в виде спецсимволов,а потом обратно эту строку разбирать.
Потому что printf был ориентирован на
последовательный вывод данных в терминал,а разбором и визуальной интерпретацией этого потока занимался уже он. В случае же МК и ЖКИ придется реализовывать эту интеллектуальную составляющую терминала в самом устройстве. И я не вижу чем тут подход с printf лучше чем использование itoa() и либо самописных либо библиотечных (если есть) функций рисования символов на индикаторе.
Вот если выводим информацию в uart и ее отображением занимается терминальная программа на компе - тогда да, можно и printf.
Хотя проще sprintf в строковый буфер и потом uart_puts(кстати - у меня он библиотечный). Да,существует способ привязать stdout к последовательному порту и тогда будет работать printf,но это требует дополнительных телодвижений.
другой эмуляции будет не нужно.
Спорное утверждение. Если это например распространенный у китайцев графический индикатор от Нокии - то и позиционирование надо и шрифты.
например, библиотечка от Peter Fleury для символьных ЖКИ, уже умеет всё, что надо
[/quote]
А у этой библиотеки существует версия новее 2003 года? Я вот не находил. Хотя у меня интернет медленный уж очень.
Соответственно, для всех индикаторов которые появились за прошедшие два десятка лет - придется решать вопросы совместимости.
А двадцать лет это не два-три года,ни на что особо не влияющие.
В результате получается что если вывод чего-то на индикатор является в устройстве функцией второстепенной - то да,можно поставить что-то старое и простое,о чем библиотека знает. Но в этом случае и каких-то особых требований к форматированию вывода нет.
Если же интерфейс с пользователем является важной составляющий функциональности устройства - то нет смысла пытаться выжать невозможное из примитивного индикатора,лучше сразу ориентироваться на более продвинутые модели. А тогда потребуется и цвет и шрифты - в результате если продолжать хотеть использовать printf то придется написать вполне себе полноценный эмулятор терминала.
Ну и в подтверждение моих слов - всё же в графических программах под Xorg вывод текста на экран не через printf обычно делается. Соответственно,чем ближе мы подходим к полноэкранному интерфейсу,особенно если с элементами [псевдо] графики - тем менее удобен printf и больше усилий на написание разбора того что он навыводил в эмуляторе терминала.
Вот только что прикручивал к своей программе библиотеку microrl (micro readline) для работы через uart с компом и обнаружил что автор не учел разного поведения эмуляторов терминалов при выдаче esc-кода возврата курсора на N позиций назад. Если число позиций возврата больше чем расстояние от начала текущей строки - то линуксовая текстовая консоль оставляет курсор в первой позиции. А xterm переводит его на предидущую строку и возвращает на оставшееся количество позиций. Хорошо что это вылезло еще в процессе экспериментов с библиотекой,собранной под линуксом,до запихивания ее в прошивку МК.
Я вообще стараюсь по возможности погонять куски кода под линуксом и/или в симуляторе прежде чем на МК их переносить. Меньше возиться с отладкой непосредственно на МК приходится. Всё же я не настолько крут чтобы сразу писать безошибочный код.
почти все используют готовые библиотеки поддержки ЖКИ, в которых есть готовые функции вывода символа на дисплей, и максимум, что еще будет нужно, добавить обработку символов перевода строки и возврата каретки, другой эмуляции будет не нужно.
