Основной проц ATmega640. Задействованы почти все ножки. Управление - 10 клавиш, индикация - ЖКИ WH2004. Заказчику понадобились ещё ножки у 640 для работы. Он предложил перенести клавиши и ЖКИ на отдельный пульт управления. А МК связать.

Родились такие мысли:
1. Связать по UART или SPI. Что эффективнее в данном случае будет? С SPI пока не работал.
2. Модули обработки клавиш и ЖКИ полностью перенести в отдельный МК.
Но тут встаёт вопрос быстродействия. Модули для ЖКИ выводят на него строки слов, да и вообще кучу данных. Пока даже ума не приложу, как это всё передавать на отдельный МК. Стоит ли делать такое разделение задач? Может есть другие более оптимальные вариатны?

Так прикрутить к ЖКИ сдвиговый регистр (74HC164, CD4094 etc.) и управлять им по SPI вроде ничто не мешает. Быстродействие там побоку в общем-то - приходится ждать, пока ЖКИ готовность даст... Есть вполне рабочий, хоть и корявый, код на ASM (SPI программный, будет работать на чём угодно).
Пробегал ещё вариант связи основного контроллера с клавой/индикацией по I2C, поищите...

Выносить или нет в отдельный МК вам решать. Только ничего страшного или нового в таком решении нет. Получается обычный алфавитно-цифровой терминал, только с очень усеченной клавиатурой и маленьким дисплеем. Связать его с основным МК лучше через UART. Т.к. в принципе входящий (дисплей) и исходящий (клавиатура) потоки у терминала независимы. А SPI как синхронный интерфейс, обяжет вас синхронизировать эти потоки. Вообще последовательный асинхронный канал де-факто стандартный вид связи для терминалов и использовался раньше в ЕС ЭВМ и СМ ЭВМ.
Только рекомендую вам взять за основу какой-либо существующий терминал (команды и способы управления им), а не выдумывать свой отличный от других "велосипед".

Страшное есть - за стоимость двух AVRок (в прочем и почти за одинарную) берется контроллер совсем другого уровня и/или связка с FPGA/CPLD

Я хорошо помню про вашу идеологию и любовь к МК "другого уровня" Только ИМХО не стоит в очередной раз навязывать ее всем подряд. Если устройство не крупносерийное или стоимость электроники мала в общей стоимости всего устройства, то цена еще одной AVRки никак не сравнима со стоимостью времени освоения нового кристалла. Тем более, что тут похоже сам заказчик диктует условия применения.

И переделывается все устройство... Даже если принять, что разработчик знаком с железом другого уровня, получаем затраты на проектирование и изготовление железа, тестирование железа, написание нового софта, комплексное тестирование, замену обородования у заказчика (старое придется просто забрать и выбросить)... в итоге затраты "от ~10k$" против, "до 1$ за вторую AVRку и 20-ти часов работы"?

а сдвиговый регистр не на жк? на кнопки и индикацию можно применить. 595 микруха не дорогая.
или нужно именно дисплей выносить?

Выносится дисплей и клавиши. Думаю программные модули управления ЖКИ не переносить в отдельный проц, а передавать по UART только сигналы управления ЖКИ. Иначе слишком большой объём данных придётся передавать.

Связать два мк в любом случае сложнее и дольше по времени чем что-то сделать на основе уже имеющегося мк. Две единицы требующие программирования/отладки на плате в любом случае хуже чем одна. При всех равных. Кроме того SPI или UART`ов много не бывает. Клавиатуру можно включить в матрицу, используя ноги ЖКИ, при 4-битном интерфейсе без поллинга будут доступны для клавиатуры 5 ног, к ним добавить еще 2 и 10 кнопок уже можно повесить. Это решение без всяких регистров сдвига, чисто софтверное. Итого 8 ног + несколько резисторов для развязки на все про все. Сколько задействовано ног сейчас, и сколько нужно свободных ?

Слышал про такое. А где бы поподробнее про это посмотреть?

Предполагантся, что вторая AVR будет по приезду к заказчику на толлейбусе припяна на соплях к порезанной в лапшу имеющейся плате и все это займет 20 часов БЕЗ "проектирования, изготовления, тестирования, нового софта", причем экземпляр один и других не будет.... Если речь идет о таком стиле, то предупреждать надо при постановке задачи.

Тогода сам Бог велел забыть об AVR навсегда и осваивать новое, ибо когда какрты лягут так, что нужно будет сделать РАЗРАБОТКУ и сложнее, и быстрее и дешевле (а случится это всенепременнейше), то будет облом.

Где тут про "условиях применения"? требующих конкретно 640?

Так на вскидку не скажу. Если в двух словах, то ноги идущие на ЖКИ являются строками в матричной клавиатуре. Раз в 5 - 50 мС они переводятся на вход (можно использовать все, кроме строба записи), затем по очереди активируются линии столбцов матрицы, строки опрашиваются, анализируются нажатые кнопки. По нескольким отсчетам (антидребезг) делаем вывод о факте нажатия. В остальное время, переведя ноги столбцов на вход, работаем с ЖКИ. Нужно только предусмотреть, чтобы эти два события не пересекались во времени, например кнопки в прерывании, а ЖКИ в основном цикле. Ну и кнопки развязать резисторами, чтобы в случае удержания нескольких сразу, не коротились линии к ЖКИ. Ну и подтяжки. Можно и по другому, например на строки подавать уровень по очереди, а читать строки, так вообще направлением ног не нужно будет голову забивать. Вобщем алгоритм может быть разным.

У Atmel есть AppNote - AVR242: 8-bit Microcontroller Multiplexing LED Drive and a 4 x 4 Keypad (doc1231.pdf).

Если просто не хватает ножек, поставьте дополнительный регистр, на вход или на выход. Можно через SPI.


UART и отдельный контроллер для клавиатуры/индикации гораздо лучше, только времени займет больше, чем простое расширение "ножек". Если нужно сделать очень быстро - не связывайтесь, за "пять минут" связать два МК и переделать прогу не успеете.

Нажмите для просмотра прикрепленного файла
Я делал по уарт. Решение очень удобное из-за конструктивных преимуществ. Дисплей и клавиатура обычно закреплен на передней панели устройства, а основная плата - в основании. Сразу уходит туча длинных помехонеустойчивых проводов (На фотке первый образец, дисплей приклеен таки на основание).
И обмен можно сделать беспротокольный, закодировав команды установки позиции вывода на экран неотображаемыми символами. Символы просто уходят в другое устройство без всяких подтверждений. Естественно, размер циклического буфера и скорости передачи и обработки должны быть выбраны соответствующе.

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

Чего же не было? На испытаниях по 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с он ну никак не сможет среагировать. Так зачем ему чаще события показывать? Это же лишь мельтешение символов на экране создает. Либо я не понимаю, что такое "в реальном времени" по-вашему? Предсказанные события?
А это собственно без разницы где обновлять эту часть - в буфере или непосредственно на экране.