В контроллере мало памяти? Добавляем мозгов :)

[Slabovik]

Думы над стратегией управления хоть каким-то большим экраном посредством микроконтроллера приводят к выводу, что у значительной части МК для этого как-то катастрофически мало ОЗУ, чтобы было можно без проблем иметь оперативный доступ к содержимому памяти экрана (с проблемами обычно можно, но как-то коряво это и, как минимум, достаточно долго).
Сами же микроконтроллеры как правило не имеют возможности увеличивать объём своего ОЗУ данных. Ну чтож, прикрутим своё ОЗУ.
Понадобится нам как минимум один порт под организацию шины данных + ещё сколько-то линий управления потоком этих данных. Ну и конечно микросхемы (да, я люблю микросхемы )



Получилось довольно просто. На схеме блок внешней памяти на 64кБ. Микросхемы взяты весьма доступные, по 32 кБ. На счётчиках реализован регистр хранения адреса, по которому идёт обращение к памяти. Можно было поставить и простые регистры, но у счётчиков есть приятность - данные, хранящиеся в них, можно изменять, т.е. инкрементировать и декрементировать. Это полезно.

Для дешифрации команд применён простейший трёхразрядный дешифратор ИД7 и три линии другого порта (здесь это порт D, но в принципе ничто не мешает ему быть каким угодно). Вот список



Для команды 000 (чтение)

• если нужно, выставляем (корректируем) адрес ячейки.
• выставляем направление порта C на чтение
• даём управляющий код 000
• один (а при тактовой выше 15 МГц два) NOP (чтобы микросхемы памяти выдали достоверные данные - у них задержка может быть и 55 и даже 70 нс)
• читаем порт C
• заканчиваем операцию управляющим кодом 111.

Для остальных команд попроще. Направление порта можно устанавливать один раз перед группой команд. Окончание каждой команды - выдача в порт кода 111.

зы: оказалось, достаточно просто. Есть конечно желание сделать автоматический инкремент-декремент, но здесь есть сложность, что если у одной команды (пусть запись) автоинкремент должен быть "пост", то у второй (чтение) автодекремент должен быть "пре". Но для этого надо больше микросхем
Ещё неплохо бы уметь считывать адрес, хранящийся в регистрах адреса. Это не сложно, но тоже нужен как минимум один буфер, ну и ещё одна линия порта управления, ибо три уже закончились

[Nikopol]

О здорово, возьму на заметку. Я правильно понимаю, что объём информации считываемый и записываемый за одну операцию не может превышать объём свободной памяти микроконтроллера?

[Slabovik]

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

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

Минусы такой организации очевидны - надо больше микросхем. И являются определяющими, если внешних устройств не много, одно или два, для которых и МК-шных портов хватает.
А вот плюсы начинают перевешивать, когда вдруг ног становится недостаточно. Ардуинщики, традиционно макетирующие проводками, любят 595-е регистры, в которые данные нужно засовывать последовательно, но это когда данных немного, дисплейчик там... А когда много? А ещё почитать? В принципе-то, ядро AVR-ки имеет неплохую производительность до 20 MIPS'сов и толкаться ему в паре килобайт внутренней памяти часто тесновато... (Остапа понесло)

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