Сбоев, при такой связи без подтверждения, с МК управляющим ЖКИ небыло?
Можно поподробнее, как вы кодировали информацию?

Чего же не было? На испытаниях по ESD были. Но экран обновлялся каждую секунду, такой сбой допускается.



// 0XXX XXXX character to display 0x00 - 0x7f
// 10YX XXXX set position XXXXX Y (X и Y минус 1 - счет с нуля)
// 1100 0xxx clear screen
// 1100 1xxx init LCD
// 1101 0mmm set backlight mode
// 1101 1mmm set LED mode
// 1110 0mmm set sound mode
// 1110 1mmm show firmware version on position X=6, Y=2
// 1111 0mmm clear Line
// 1111 1000 stop RTC correction mode inside KBD:
// 1111 1001 start RTC correction mode inside KBD;

В этом случае предполагается __доработка__ существующего железа и софта, а не полная его замена.
А уж как именно она будет выполнена - это другой вопрос.

Положим пришел к Вам заказчик с предложением, добавить в ваш роутер еще 100 светодиодов (утрирую конечно) за n денег. Вы же не броситесь ставить ARM9 с +100 выводами, вместо Вами любимого NXP 144, ради этого. Логичнее нарисовать еще одну простецкую платку с этими светодиодами и подключить к уже имеющемуся и разведенному любому интерфейсу готовой платы. А с позиции софта - наваять еще один модуль без изменения логики основной программы, для управления этими светодиодами. Риск и затраты при таком подходе - минимальны.

Ну лет эдак ... назад я бы сам так сказал. Сейчас добавка atmega48 практически не добавляет ни сложности, ни цены. Зато даёт некоторую свободу. (кстати, такой "терминал", кажется, от SasaVitebsk, где-от по форуму пробегал).
Причём я бы рекомендовал для такого "терминальчика" взять минимально необходимое/оправданное подмножество команд VT100 - команды очистки экрана, строки, позиционирования курсора.
Что касается "дефицитности UART" - ЖКИ 4*20 = 80 символов.
На скорости 2400 - *полная* перерисовка экрана = треть секунды. Замена 1/4 части - меньше 0,1секунды.
На 9600 - всё в 4 раза быстрее. А это небольшие скорости для программной реализации.
Полагаю, что даже если у меги640 уже не осталось свободных UART - один модуль IC и один OC на каком-то из таймеров свободными остались и софт-UART мало займёт ресурсов - не намного больше, чем сканирование клавиатуры.
VT100 даст возможность отлаживать "терминал" отдельно, основную плату отдельно - на терминалке на PC. Т.е. основная плата будет себе посылать что-то в комп подмножеством VT100 команд и терминалка в углочке на поле 4*20 будет всё рисовать.

В настоящее время сделал так для ЖКИ на пульте: с управляющего МК передаётся состояние ножек для ЖКИ. Т.е. все сигналы управления и/или данные выставляются в переменной, которая тут же отправляется по уарт. Проблема только с частотой обновления экрана возникла, т.к. в некоторых местах программы экран обновлятеся очень часто. Поэтому пришлось поднять скорость обмена.

Довольно странное решение. Обновление всего экрана делать чаще, чем 1-3 раза в секунду нет смысла. Человеческий мозг, который обрабатывает визуальную информацию, довольно быстро "устает" от бОльшей частоты изменения этой информации. Так что период регенерации 0,3с...1с самый оптимальный и комфортный для пользователя. Поэтому нужно не скорость обмена поднимать, а снижать скорость регенерации или смены информации на дисплее. Возможно для этого придется ввести промежуточную буферизацию данных, отображаемых на LCD-модуле, в самом терминале. Но 80 байт на буфер экрана ИМХО не такие уж и большие накладные расходы.

Часть параметров необходимо отображать в реальном времени, поэтому так сделано. Ещё обновляется не весь экран, а лишь та часть, что меняется часто.

А c максимальной задержкой между получением данных и отображением в 0,3c это не реальное время по-вашему? Даже если пользователь сидит, внимательно следит за показаниями на индикаторе и держит руку на рубильнике, то быстрее, чем за 0,2-0,3с он ну никак не сможет среагировать. Так зачем ему чаще события показывать? Это же лишь мельтешение символов на экране создает. Либо я не понимаю, что такое "в реальном времени" по-вашему? Предсказанные события?
А это собственно без разницы где обновлять эту часть - в буфере или непосредственно на экране.