Всем добрый вечер.

Извините за сумбурность, но что бы правильно задать вопрос надо хоть как - то разбираться. А я только - только начинаю.

Недавно сделал небольшую платку что бы освоить ARM9. На плате установлен AT91SAM9 + Spartan 3AN (висит на шине ARM) + 2 COM порта + NAND 2Gb + 8 Mbit SRAM + microSD + USB (slave) + ethernet 100Mb.

Так вот что с ней можно сделать? Допустим, если я хочу иметь на этой плате какую - нибудь ОС, например ANDROID или LINUX (т. е. как операционка портируется на нужный контроллер). Смогу ли я это сделать на таком железе.

На 8Mbit SRAM развернуть какую-либо "тяжелую" ОС типа linux или wince не выйдет, android - тем более.
Возможно получится запустить uClinux. А так смотрите в сторону "микроконтроллернех" ОС - eCos/FreeRTOS/scmRTOS и т.п.

Оперативку надо было ставить хотя бы 64 мегабайта, тогда был бы у вас андроид. А так только ртос или использование в режиме терминала.

Плата уже запушена в производство.
1. Посмотрел память SRAM что - то больших объемов у них нету. Физичиски места под 2 микросхемы есть. Может подскажите какую использовать. Нужно именно SRAM/
2. Хорошо, а вот хватило бы ресурсов контроллера (у него частота около 200 MГц) для Андроида?
3. Допустим у меня есть рабочее железо. Какие мои следующие шаги? Где мне взять Андроид? Как его адаптировать для данного контроллера или он уже адаптированный есть?

2 На этом нет смысла андроид ставить - atmel безнадежно отстал на рынке мобильных процессоров (возможно он их просто не интересует) - андроид интересен там где памяти от 256М и есть 2D/3D ускорители, аудио/видео ускорители.
3 http://www.at91.com/android4sam/bin/view/Android4SAM/WebHome

Любопытно было бы узнать причины.
По моему личному ощущению, для ARM9, SRAM не имеет смысла. Дорого. Малый объем. БЫстродействие нивелируется кэшем.

Спасибо за ссылку! Сам бы очень долго искал.


Причина проста. Коллега использует тот же контроллер, но память SDRAM, а я хочу использовать SRAM, что бы сравнить быстродействие.

За счёт кэша разница будет незначительная. Может процентов 30 выигрыша в производительности при 100 кратной разнице в цене. Андроид запихать может и получится, но смысла особого нет. Ядро + QT будем сильно компактнее.

А поясните поподробнее, что это значит. Что за ядро? QT это компилятор, но зачем его запихивать куда - то.

QT это библиотека, а не компилятор.

Могу сразу сказать результат.

У меня G45.
Сравниваем внутреннюю SRAM (лучше внешней, так ведь?) и внешнюю DDR2 (133M).

Численные данные я не готов представить (не ставил цели). Но вот чисто эксперимент - поставил.
Декодер JPEG располагал во внешней памяти DDR и во внутренней SRAM. Размер кода декодера - примерно 10 килобайт.
Замеряем по секундомеру (считаем голосом) время декодировки 12 мегапиксельной фотографии.

Итак результат - досчитываю до 12 в обоих случаях.

Причем, на DDR висит еще и экран, который разумеется, своим прямым доступом отъедает часть производительности.
И тем не менее, мои ожидания, что внутренняя SRAM - это круто, и что там следует разместить все самое нужное и полезное - не оправдалось. Хотя и я разместил там ОС, драйверы и всякое такое, но реального выигрыша не получил.

Я имею в виду, разумеется, выигрыш, ради которого стоит использовать микроскопическую и дорогую SRAM и жертвовать огромной DDR.

DpInRock, а могло это нивелироваться доступом к флеше, например, или еще чем? То есть проц бОльшее время там проводил, чем декодировал?

При работе с кэшем в большинстве задач различия будут на уровне единиц процентов. Даже при сравнении TCM (идеальный вариант SRAM) и внешней SDRAM.

Нет у меня флэша.
А по поводу чтения самого файла из SD - тут все честно. Я сначала читаю файл целиком в память, а уж потом запускаю (в данном случае). (Кстати, наличие избыточной памяти позволяет программировать все в наглую - буфера по 48 мегабайт для хранения декодированной картинки целиком - просто без вопросов).
Но на самом деле чтение 4 мегабайтного файла отнимает чуть больше секунды. Т.е. небольшой процент от декодирования.
---
Польза от срама пока одна - она готова и доступна сразу и не подвержена глюкам разводки.
--
Одна токо неприятность есть у кэша - это его инвалидация время от времени от прямого доступа.

прошу прощения, SD имелась ввиду

Имхо неинтересное сравнение.
В SRAM должен был располагаться не код декодера, а декодируемый файл.

А если немного подумать, то станет ясно, что раз кэш команд справляется со своей работой, то весьма вероятно и кэш данных также справляется со своей работой.

Тем более, что исходный файл сжатого изображения считывается существенно реже (ведь он сжатый) уже декодированных данных.

Да, точно, сорри.
Но все-равно, это только один из частных случаев, наиболее благоприятный для SDRAM.
Для полноты картины имхо надо рассмотреть еще 3 варианта:
-недостаточный кэш комманд
-недостаточный кэш данных
-недостаточный кэш и команд, и данных



У синхронной статики объемы до 72 Мбит я находил.

Ага. Только зачем?
Кэш в любом случае - всегда меньше возможных запросов. Именно поэтому его разрабатывают умные люди.
И расчитывают на вменяемых программистов.

Кроме того, лень лезть в даташит, что-то мне подсказывает, что быстродействие внешней SRAM не будет больше быстродействия DDR, а тем более DDR2. По крайней мере речь может идти об одном десятке процентов. Это по максимуму.

Можете ссылкой поделиться, я найти не смог. Или хотя бы производителя


Можете ссылкой поделиться, я найти не смог. Или хотя бы производителя

Самсунг, например, делает.

Я заказывал на digikey.com
Раздел память http://search.digikey.com/us/en/cat/integr...556980?k=memory
Одна из 72 Мбит микросхем http://search.digikey.com/us/en/products/C...0AXC-ND/1206004