SRAM в AVR, хорошо, да мало Опции

[CD_Eater]

Забавно, что в архитектуре AVR формально присутствуют регистры RAMPX, RAMPY, RAMPD для работы с ОЗУ сверх 64 Кбайт. Скорее всего, эта потенциальная возможность никогда не будет осуществлена из-за дороговизны памяти и дешевизны более продвинутых ядер. Даже в AVR32 больше 64К ОЗУ пока нет.

А сколько нужно памяти в МК? Для каждой задачи - по-разному. Но изготавливаются микроконтроллеры по какому-то усреднённому соображению, наверное, из расчёта стоимости кристалла, а не потребности юзеров (где ассортимент АВРок от "no SRAM" до "Full 64Kbytes"?). Жалобы на нехватку ОЗУ нередки, вот недавно проскочила.

Нужно заметить, что память для разных целей нужна разная. Для локальных переменных и стека - быстрая, для буферов - большая. Вот последней-то (сравнительно медленной и большой) как раз и не хватает. Фактически на АВРке нельзя сделать более-менее нормальный буфер для временного хранения пришедших пакетов. У меня такая потребность возникает часто. Хочу хотя бы 32 Кбайта.

Какие решения предлагаются?
1) В некоторых АВРках можно подключить внешнюю память. Что это означает на практике? Что будет ещё как минимум 2 немаленьких корпуса на ПП (память и защёлка адреса) и будут заняты 16 I/O ног МК. И что будет пучок сравнительно длинных высокочастотных дорожек на ПП (гудбай, АЦП), то есть, место потенциальных граблей и необходимость повышенного внимания к аккуратности изготовления ПП и монтажу. Да, нерадостная картина.
2) Можно поставить FRAM. 32 Кбайта - это 4 бакса, и мы просто выходим за рамки интересующей ценовой категории. Не то.
3) Можно поставить последовательную SRAM, 32 Кбайта - примерно 1 бакс, управление по SPI 20 МГц. Вещь! Казалось бы, наилучшее решение, то что надо. Но вот что удивительно - такое впечатление, что я первый, кому это надо. Статус производства - Active, но на зарубежных складах их в наличии нет. Один поставщик согласился привезти их в Москву. Очень привлекательное предложение, хотя и потребуется ждать более 3 месяцев (т.к. эту память сначала нужно произвести!).

Я не могу понять, почему положение таково. Хочу услышать ответ на вопрос:
Как эмбеддеры выкручиваются из ситуаций с нехваткой оперативной памяти в МК?

Может быть, есть какой-то 4-ый вариант (кроме тех трёх, которые перечислены)?
Или может быть, берут заведомо более дорогой и мощный камень, несмотря на то, что с задачей справилась бы обычная АВРка, будь у неё больше памяти?
Всё-таки ATtiny+SerialSRAM < 3$, а за три бакса никакой МК с 32 Кбайтами ОЗУ не найти. Почему это кажущееся идеальным решение не популярно среди эмбеддеров? Может, они про него просто не знают...

[zhevak]

Я не могу понять, почему положение таково. Хочу услышать ответ на вопрос:
Как эмбеддеры выкручиваются из ситуаций с нехваткой оперативной памяти в МК?

нехватает памяти, говоришь? Да... есть такой момент.
Мы тоже с этим же столкнулись. Наш девайс должен опрашивать около двухсот устройств в 485-ой сетке, полученные от них данные складывать в таблицу и затем эту таблицу отсылать компу через Ethernet.

Сначала я взял, что было под-руками -- готовый девайc: Mega8, FM25C256, ENC28J60. Во фраме организовал хранение таблицы адресов (запросов) и таблицы результатов. Все влазит, и даже свободное место остается. Но, узким местом стала память самой Меги. Дело в том, что Ethernet-контроллер и фрам сидят на SPI. И перекачивать инфу из фрама в ENC-ишку все равно нужно через оперативу Меги. А у нее всего один килобайт на все про все! В результате пришлось нарезать UDP-поток на мелкие пакетики по 300 байт. Т.е. примерно в пять раз мельче, чем хтелось бы. Не смертельно, но неприятно. Сейчас в нерешительности -- то-ли заложить Мегу64 с той-жк фрамой, то-ли одну SAM7S256 поставить.

Скорости не важны. Поток информации от 485-х девайсов в сторону компа не более 10 кбайт/с.

А вообще было бы не плохо иметь в своем распоряжении RAM с последовательной шиной. Поддерживаю!