Разнесение задач из одного МК на два МК - выносной пульт ДУ. Связь двух МК. Опции

[SZ0]

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

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

[Harbinger]

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

[rezident]

1. Связать по UART или SPI. Что эффективнее в данном случае будет? С SPI пока не работал.
2. Модули обработки клавиш и ЖКИ полностью перенести в отдельный МК.

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

[zltigo]

Только ничего страшного или нового в таком решении нет.

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

[rezident]

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

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

[defunct]

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

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

[arttab]

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

[SZ0]

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

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

[Andrey_B]

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

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

[SZ0]

Клавиатуру можно включить в матрицу, используя ноги ЖКИ

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

[zltigo]

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

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

Если устройство не крупносерийное или стоимость электроники мала в общей стоимости всего устройства, то цена еще одной AVRки никак не сравнима со стоимостью времени освоения нового кристалла.

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

Тем более, что тут похоже сам заказчик диктует условия применения.

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

[Andrey_B]

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

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

[Visor]

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

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

[Огурцов]

Задействованы почти все ножки.

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

1. Связать по UART или SPI.

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

[Dog Pawlowa]

1. Связать по UART или SPI.

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