Прикидывал тут будущий девайс и вспомнился сабж.
На сайте вроде прописан как "масс продакшн", в продаже вроде тоже есть, но что-то не видно, чтобы с ним кто-то работал. Хотя вроде и цена сходная, и корпус пристойный, поддержка любой внешней памяти,
видео на борту...
Может обнаружены какие-то ужасные глюки?

Раз пошел такой , плесну-ка и я свою бочку дегтя...


Только условия не написаны. А в начале документа - 33MHz @ 3.0V 85C. Страшно...


Что влечет за собой усугубление требований к плате - бесплатного сыра не бывает.


Только не стоит забывать, что PDC здесб совсем не такой, как в SAMе.
Если нужно принимать непрерывный поток по UART - пляска с бубном обеспечена.

И вообще, samsung-и, имхо, гораздо удачнее в смысле архитектуры.

Да, оверклокинг - это стремное занятие. А так красивая частота 1.8432*2*9 = 33.1776. Т.е. кварц 3.6864 на входе, и умножаем на 9.40 Мгц на 4 слоях - мне это не кажется страшным.Пляски с бубном описаны в либе, на которую я дал ссылку. Да, PDC там не такой красивый, но хорошо, что он есть! Например, для обмена с AT45DB и опроса периферийных контроллеров по RS-485 блоками фиксированной длины то, что надо.

Разумеется, я далек от того, чтобы считать этот камень идеальным. Но, учитывая готовый порт eCos, этот камень имеет полное право, чтобы его использовали. И, например, по сравнению с LPC22xx при работе из внешего SRAM, он выиграет у него по скорости за счет своего "убогенького" PDC. При том что AT91M55800A сделан чуть ли не по технологии 0.35 (кристалл - 29 кв. мм.), а LPC - 0.18. К вопросу о силе идеологии...

Сообщение отредактировал Evgeny_CD - Apr 9 2006, 12:47

Сравнение в высшей степени некорректно: ну не предназначен LPC для выполнения кода из
внешней SRAM, "идеологией" не предусмотрено

Конечно, с этой точки зрения не корректное Но когда я выбираю камень для проекта - мне пофиг, кто там чего предусматривал, я на результат смотрю (в рамках требований проекта).

Ну а теперь читаем их-же doc1745.pdf c 33MHz и какие выводы делаем?
По поводу THUMB - если судить по ядру, то да и ARM тоже. Но написано в мануале странно :-(
Ну вот, а 32 уже за два такта..... вместо 3 у LPC. Начинаем отигрываться....
Причем 2 такта, это только если "просто просуммировать" а если подумать...
То все хуже - попробуйте взглянуть, как будут выглядеть последовательные обращения
к памяти. Ну и errata, тоже почитать при этом не поленитесь.
Теперь осталось взять конкретную "1Мбайт 15 нс статики - 5..6 баксов."
и посмотреть как она конкретно с этим чипом монтируется. Называйте тип - разберемся.
Практически диаграмма без претензий обеспечивается при дополнительном WS, когда
фронты, например, NWE разнесены на полтакта от прочих сигналов. Вот на эти два раза по полтакта
= 1такт и выигрывает _реально_ Atmel у LPC, который два раза по такту на это заложил.
Кстати 32bit 15ns статика прекрасно будет смотреться и на 60Mhz LPC22xx и даже с его тремя тактами.

Обычный устаревающий камешек требующий обязательной внешней обвески Flash+RAM и практически непригодный для работы из Flash.

Ок, оставим оверклокерство в покое. Для меня важнее другое: у меня будет плисина на шине, с которой будет блочный обмен. И если делать процессором типа LPC, но тоскливо - на каждую тразакцию два раза занимаем шину. А вот если SPI PDC, но один раз занимаем шину. Вот тут мы и отыграемся Насчет последовательного обращения - поясните, плиз.

Память - давайте рассмотрим Samsung K6R4008V1 (с шиной х 8).

Насчет времянок - да, надо аккуратно все выписать и проверить. Но, на худой конец, пару корпусов мелкой логики добавится. Не смертельно.Насчет флеши - я высказал свою точку зрения. Камень, понятно, не молодеет. Но нету пока идеальных камней для eCos - в каждом случае приходится чем-то жертововать.

В том-то и дело, что и нет. Все наоборот. Atmel в _идеальном_ случае 6 тактов (запись+автоматически_встваляемый_chipselect_waitstate+чтение=3такта два раза по 16бит)на запись/чтение 32бит против тех-же 6 тактов (запись+чтение=6тактов один раз 32bit)
но на почти ВДВОЕ большей частоте.

Мануал с диаграмами и errata дают ответ на этот вопрос.
А на пальцах - имеем только ДВА фронта на такт и по этим двум фронтам не сделать все необходимые
действия по выставлению адреса, выборки, RD, ожиданию данных, фиксации данных, _снятию_выборки_, выставлению нового адреса, снова выборки,......
НЕ ВОЗМОЖНО СДЕЛАТЬ. Посему минимум один такт пропускают, но продолжают говорить о
1 такте :-) Реклама, короче.

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

Злой я сегодня...
Описанный Вами режим пересылки (память1->память2) действительно будет занимать
6 тактов на 32 бит слово. Но ведь вовсе не обязательно работать по одному -
если использовать 4, то пересылка одного займет 4.5 такта...

Я так разумею:
* пришло слово по SPI (16 бит для удобства)
* записалось оно в регистр данных SPI
* выставили мы запрос на PDC
* он внутри себя сформировал адрес
* "внушил" ядру, что в следующем такте оно курит
* получив доступ к шине, выставил на нее сформированный адрес и данные из регистра данных SPI.
* завершил транзакцию, и передал управление шиной ядру

Я не вижу причин, по которой такая транзакция будет отличаться от транзакции ядра.



Кроме двух фронтов еще есть куча фронтов, полученных на задержках. Причем это не формирователи импульсов на задержках, а вполне корректные задержанные фронты. Вот на них все и делается в ядре проца.

Спорить дальше бесполезно, нужно брать в руки плату, делать jump сам на себя из ОЗУ, и смотреть хорошим осцилом, что на шине творится.

С камнем не работал. C памятью - работал. И думать и читать умею.
На счет внимательнее читать - ну давайте, например, почитаем о
11.8.2 Data Float Wait State
11.6.3 Early Read Wait State
И посмотрим, какая память позволит без них обойтись.
Дабы получить красивую картинку, как 11-15 в мануале.
Тут поминалась Samsung K6R4008V1 (с шиной х 8) - в свободном доступе мануала не нашел -
бросьте в меня ссылкой.
Errata имеет обширные стенания по поводу WS по NWAIT. В принципе отношения не имеет, просто бегло
просматривал показалось :-(





Долго, хлопотно :-(




Так и будет, только какое отношение все это имеет к, например, работе с памятью линуксового ядра на данном чипе :-(

1. Дата шит на память:
http://www.samsung.com/Products/Semiconduc...08v1d_rev20.pdf
2. Из дата шита: Data Hold from Write Time Min 0 ns!

3. Поскольку у нас все будет в пределах одного cs - Chip select change wait states не мешают

4. Data float wait staitе тоже не нужон.

5. Early read wait states тоже не надо.

Так что диаграммы будут супер красивые

По поводу PDC и ПО: лично мне надо будет обрабатывать до 4 мбайт в секунду на уровне блочного обмена между процом и FPGA. SPI у AT91M55800A либо MCK либо MCK/32, так что в пике как раз 4 мбайта и получится (на длинных блоках, у меня будут по несколько КБ). И то, что на эти операции я затрачу в два раза меньше циклов, чем LPC22xx, да еще и не нарушая работу проца (вход в прерывание - выход из него) - это даст мне колоссальный выигрыш.

Смотрите. На каждое 16 битное слово в варианте AT91M55800A я будут тратить 1 такт шины. В варианте LPC22xx я будут тратить (в фоне постоянно крутятся задачи, так что "висеть" только на SPI нельзя!)
* чтение - 3 такта
* запись - 2 такта
* вход в перывание - (чтение двух 32 битных слов по шине) 6 тактов
* выход из прерывания - (чтение двух 32 битных слов по шине) 6 тактов
(по обработке прерывания я могу ошибится - поправьте, если что не так)

Итого: 17 тактов на пересылку одного 16 битного слова из FPGA в память. Если воспользоваться SSP и его FIFO на 8 слов, то проигрыш будет не так ужастен, но все же. Это у вопросу о том, к чему приводит тупое сравнение по МГц...

Проверять на плате ничего особо и не надо - и так все стало ясно после прочтения доки.

Сообщение отредактировал Evgeny_CD - Apr 9 2006, 15:30

Понятия data float и early read относятся только к работе с флеш памятью,
быстрой статике все это фиолетово.

P.S. Кажется, тему пора уже закрыть. В маразмы скатываемся...

Кто-нибудь по китайски разумеет? Нашелся сайт с eCos для S3C44B0X:

From: jourdon_shell <jourdon_shell@163.com>

We have a stable version of the eCos ported to S3C44B0X. It have been used in several projects. If you are interested in this, you can visit http://www.devbone.com or contract with me.
Best Regards
Sonys

Начал переписку с человеком...

Хорошо. C памятью будет все прекрасно.
Продолжим. Продолжим, не из моего упрямства а из-за моего ИНТЕРЕСА. У меня где-то на
периферии сознания висит задача немного похожая на нижеописанную. И если, вдруг, Вы наконец
вышли на реальную работу, то мне ОЧЕНЬ интересно было-бы поплотнее пообщаться.


Ну четыре мегаБАЙТА уже не получится - при 33MHz клоке и соответственно вдвое меньшей частоте
SPI пиковая два с хвостиком.
Хотя в данном случае slave, а про тактовую slave в мануале молчек...
Причем без учета дергания select (в master минимум 4 такта). Ну a LPC тут вообще далеко -
там 7,5MHz потолк. Но не о нем речь. Пусть будет 2, тем более что меня устроит 256KB :-)


На прерываниях явно экономия будет, если блоки килобайтовые, но "не нарушая" это уже перебор.
Не нарушать Вы будете ровно до того момента, пока процессору в собственых регистах работы
хватит :-( Кэша у него нет, так-что к памяти он полезет очень быстро и будет ждать.
Правда тормозиться будет не очень часто - приблизительно каждые 32 такта, хотя, полагаю отнюдь
не на один такт - едвали предусмотрено разруливание доступа к памяти "встык", без дергания CS.
Значит два? три? такта. Что в принципе тоже очень неплохо.

Ну а дальше что делать, когда в память прилетели килобайты? Для начала определить, что прилетели.
Какой механизм предполагается использовать? В любом случае без затрат ресурсов он работать не
будет :-( Причем разруливать все надо будет оперативно, аппаратной поддержки кольцевых
буферов я не заметил, посему во весь рост проблема оперативного обнаружения паузы, блокировки?
SPI и перепрограммирования PDC.







Проработав в Китае довольно продолжительное время, могу сказать, что китайцем нужно родиться
:-). Особенно в части 'технического' языка - ну например, кто скажет что означают три иероглифа
'голубой', 'алмаз', и 'будущее' употребленные вместе?

А так - онлайновые переводчики. Я иногда пользуюсь, например, этим

http://www.worldlingo.com/en/products_serv...translator.html

Только на русский не переводите - вообще мрак :-(