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

Просто у нас Samsung ARM не сильно популярны. А так камень весьма популярен

http://www.dave-tech.it/pages/product-b2.htm - правда, за порт eCos они, гады, 900 евро хотят
http://topmicrosystems.com/html/teb44b0.phtml
http://www.armkits.com/Product/s3cev40.asp

Камень реально хорош.

Так может сэкономить 900 евро ? У меня 3 штучки дома валяются.
Явно AT91M55800A забьет

Да нету особых глюков - на удивление все работало согласно документации.
Корпус "приличный", можно разводить BOX+SDRAM 16-бит на двух слоях, работает в оверклоке до 80 МГц. Минус по нонешним временам - нету MMU. Видеоконтроллер - на сегодня тоже слабоват, не поддерживает TFT (видеовыход 8-битный, для формирования цвета - дизеринг), нет автоподдержки тач-панелей (да и полоса АЦП сверху 100Гц вроде как ограничена). Четыре года назад BOX был весьма симпатичным, но сегодня я выбрал бы SHARP 79525-ый (несмотря на валяющуюся в кладовке коробку BOX-ов)

ИМХО, если не нужен MMU (а он седьмому ядру не очень нужен) и TFT, то 44B0X выглядит предпочтительнее, чем Sharp 79520.
Sharp 79525, конечно, крут, но ног мало: 16 бит шина памяти и 12 бит на экран не очень
вдохновляют.

А у меня 558000 несколько штук валяется

1. Все зависит от целей - по ряду причин лично мне 558000 более интересен.

2. Опять же - готовый порт eCos. Скорость не всегда важна, LCD мне не нужен. А вот стартовать с гоового порта всегда приятно.

3. Готового порта public eCos на box нет, самое ближайшее, что есть - SNDS100
http://topmicrosystems.com/html/keb50100.phtml

Она на S3C4510.

Можно взять готовую "макетку" у dch - EVM50100
http://www.ucrouter.ru/hardware.html

S3C4510 тоже довольно интересный камень. Но не знаю, для старта лично мне 558000 нравится больше.

MMU точто не нужен, а вот 32К ОЗУ на кристалле у Sharp LH79520 могут быть очень полезными - прерывания и критические процедуры.

LH7952(4|5) интересны boot ROM - в том числе по I2С умеет бутиться. LH79525 интересен USB device, Ethernet, SSP, I2C. LCD "полноценный" опять же, не всегда нужен - CSTN 8 бит часто вполне ок.

Есть "макетка" под него - EVM79525 - но ее никак до продажного состояния не доведут.
http://www.ucrouter.ru/hardware.html

По ценам Sharp не так приятен, как Samsung

Противнее всего, что нет порта eCos ни на один из шарпов

Уж если выбирать из относительно простых камней, имеющих LCD, и порт eCos, то Cirrus EP7312 самое то. Но в нем нет DMA - а лично для моих задач это очень плохо.

А что за проблема с портом eCOS под него?
была проблема только с Pb - Free корпусом.
а так приличный камень.

да никаких проблем. Но нет его готового в public domain для S3C44B0X. Я, по крайней мере, не нашел

Ну или "уговорить" бесплатно отдать
http://www.dave-tech.it/pages/product-b2.htm

Видео меня интересует скорее как опция, а вот что прельщает, так
это очень гибкая работа с памятью. Кроме того с BOX-ом, есть уже опыт работы.Попробую. А там гляди и до 558000 руки дойдут.

посмотрел, нет его.
можно на eCos рассылке спросить. может кто и вышлет.
или самому дописать. за основу взять тот-же 558000.

У самсунговских S3C4510B, S3C4530A и S3C44B0X есть один существенный минус: commercial temp. only. Это не всегда важно, вероятно, он все же будет работать при -, но в серьезные проекты уже не поставишь. Так что под проекты с "-" придется заводить другую платформу.

По поводу AT91M55800A можно заметить следующее:
* -40 изначально
* по дата шиту максимальная тактовая - 40 Мгц
* обращение к внешней памяти за 1(!) такт - это фирменная фишка атмеловских процов. Привет LPC22xx с его 3 тактами на чтение - 40 Мгц AT91M55800A даст те же 20 MIPS в ARM моде, что и 60 Мгц LPC22xx!
* одно питание 3.3В, IO проца можно питать от 5В
* проц, не смотря на заслуженный возраст, никто не собирается снимать с производства, в мае 2005 года вышла новая ревизия доки
* проц объективно хорош - не зря его не сняли
-- простой и понятный, дока читается легко и непринужденно
-- богатство периферии
.... 3 UART с PDC
.... SPI с PDC
.... RTC честный с автономным питанием
.... 2 (!) x DAC
.... 2 (!) x ADC
* есть готовая отладочная борда AT91EB55, ее не трудно повторить - схема есть
* на атмеловском ftp лежит отличная библиотека для работы со "старыми" (до SAM эпохи) ARM'ами, в том числе исходники загрузчика для AT91EB55

ftp://81.80.104.162
LOGIN: at91dist
PWD: distrib
! ftp при входе в директорию нижнего увовня не дает возможности вернуться назад. Надо перелогониваться.

Done. Ждемс...Тогда уж проще SNDS100 (S3C4510B) порт взять.

Ну просто счастье какое-то :-).
Правда и мегагерц там 33 а не 40, и шина максимум 16bit, и процессор только THUMB, и Flash память для 'фишечного' 1 тактового обращения неизвестно-ли существует-ли в природе в отличие от 'обычной' 50-70ns. А если 'обычную' поставить, то сколько тактов будет .... Ой!

Читаем доку:doc1727.pdf, Master Clock Frequency Max 41.8 MHzИ не страшно, как я уже сказал, она транзакцию за 1 такт проводит.А вот это подробнее. Ядро там ARM7TDMI. Читаем доку:
ARM7TDMI Technical Reference Manual на странице 1-10
http://www.arm.com/pdfs/DDI0029G_7TDMI_R3_trm.pdf
This section provides a summary of the ARM, and Thumb instruction sets:
• ARM instruction summary on page 1-12
• Thumb instruction summary on page 1-19.
The ARM7TDMI processor uses an implementation of the ARMv4T architecture.А зачем тупить-то? 2Мбайта флеша нынче <2$ стоят. 1Мбайт 15 нс статики - 5..6 баксов. При старте перегружааемся в раму и вперед. Во флеше можно оставить ROMFS, а для eCos 1М кода + данных, если без гуя - это очень даже хорошо. Так что камень не так плох, как многим кажется.

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


Только условия не написаны. А в начале документа - 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. К вопросу о силе идеологии...

Сравнение в высшей степени некорректно: ну не предназначен 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 слов, то проигрыш будет не так ужастен, но все же. Это у вопросу о том, к чему приводит тупое сравнение по МГц...

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

Понятия 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

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

Есть плисина. У нее есть два потока во "внешний мир" - входной и выходной. Есть буферный SDRAM. ПЛИС висит на ЩД и SPI.

Запрограммировали мы через ШД, что блок с такого адреса такой длины буферного SDRAM надо загнать в проц (подробности SDRAM контроллера и дополнительного буферирования опускаем). Запрограммировали SPI + PDC, выделив сплошной болок памяти под это. Запуститили SPI. Выполняем другие задачи, пока не поступит прерывание от PDC, что пересылка завершена. Далее процесс повторяется с другим блоком памяти проца.

Процесс передачи в другую сторону происходит либо аналогично, либо совмещенно.

А "другие задачи" разбираются с этими данными. Обработка будет не сильно сложная (по большому счету - смена порядка следования блоков данных, да дописывание хидеров), пересылок память-память не будет. Если хорошо подумать, от PDC эффект будет очень большой.

Если вдруг не выяснится некий глобальный косяк с камнем, то на AT91M55800A я настроен серьезно. А eCos в проекте будет по любому.

Естественно, буду рад пообщаться с квалифицированным специалистом.

Апаратная поддержка с размахом! и плисина и собственная буферная память к ней. Я понимаю, что там еще и Ethernet... И процессор до кучи который будет заниматься обработкой которая:

но зато на нем:


Если вот так по имеющейся отрывочной информации - либо в FPGA ВСЕ (в том числе и маленький процессор) заливать, либо что-то типа DSP, например, BF536/7 - последовательные порты у него
многофункциональны весьма, DMA само-собой, Ethernet родной. Памяти навесить по необходимости.
Я тут уже и китом под BF разжился, но чувствую не скоро руки дойдут....

Ethernet там совершенно не принципиален. Если когда и будет, но только для неторопливого telnet сервера. CS8900 самое то (под него дрова готовые в eCos есть).

По сути, речь идет о семействе устройств с возрастающей функциональностью. Взять BF537 может, и правильно было бы, но хочется "планов громадье" сократить и с разумными усилиями сделать версию lite-lite: 55800, ПЛИС с запасом, SRAM вместо SDRAM на буфера. А потом постепенно все расширять, доводить, вылизывать. Чтобы в итоге был единый репозиторий кода (С / *HDL), из которго make файлом получается прошивка для конкретного вида устройства.

Простенького 55800 хватит для нескольких устройств, потом добавим EP9302 (на него есть порт eCos от Cirrus), а потом, даст бог, и NIOS-II займемся (для него тоже есть eCos порт от Altera). NIOS был бы правильным решением, но начинать с него квалификация не позволяет (а позволить себе потратить еще год на то, чтобы стать HDL гуру я не могу - да и учиться надо на реальном проекте). Я вот смотрю, как у 3.14 неторопливо с Microblaze все получается, и страшно мне становится. А для всех этих "буферов" я планирую нанять толкового человека, который сделает lite-lite, и меня малость подучит, а далее видно будет - я, в общем, и целом, не самый тупой инженер ...

Самое главное, в этой стратегии, на которую я потратил 9 мес, просматривается четкая преемственность кода (все на eCos) и декомпозиция больших задач на понятные программные и аппаратные блоки. А это лично мне внушает легкий оптимизм, что время было потрачено не зря...

Тогда BF531 потом + CS8900 а уж потом...
Собственно и я с BF531 и начну в случае чего свою железку.
Ну а при вашем подходе к делу надеятся на "постороннего" временного?! инженера для не самой примитивной задачи в FPGA - как-то странно. Много, ОЧЕНЬ много внимания уделяете
"eCos", хотя по Вашем-же словам обработка там простая да и внешнего общения вроде как и не видать пока. Однажды обжегшись на "программистах" постарайтесь теперь не улететь в другую канаву!

Я все-таки надеюсь, что смогу осознать этот *HDL код хотя бы на уровне "изменить глубину буфера". Опять же, от девайса Lite до девайса PRO там более года пройдет, я планирую значительную часть этого времени потратить на освоение ПЛИСов.

Обработа простая в простых девайсах, по мере роста сложности девайса обработка будет несколько усложняться (но не смертельно), очень не хотелось бы ее потом отлаживать заново при переходе на новую ОСь.

eCos - это не фетиш, поизучав тему за 9 мес я понял, что в ОСях много похожего, и если для решения основных задач пользоваться минимальным набором API ОСи, то потом это можно перенести под что угодно, хоть под uCOS (но не автоматически, с правкой кода/переписыванием макросов).

Канава - штука опасная, для этого оппоненты и существуют, и форумы грамотные

Все-таки хочу попробовать реализовать эту "структуру мечты" с декомпозицией на слабо связанные блоки.

Да, еще забыл добавить по eCos.

Вот тут народ обещает к лету сделать порт eCos на AT91SAM9261
http://www.ronetix.com/starter_kit_9261.html

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

Так как с китайцем? или оно тоже денег хотят?

Этот пока в процессе, зато другой прислал свой вариант порта. Я сегодня добрый владейте!

http://rapidshare.de/files/17626362/ecos2....44b0x.rar_.html

Пока, как я понял, у них есть :-)))) уже целых два компонента для будущего кита:
• Eclipse - an open source IDE (screenshot)
• GNU Tools (compiler, linker, debugger, etc.)

:-))))))

спасибо
попробую на этой неделе проверить как это Port работает.
у меня десятка два плат с S3C44 есть не выбрасывать же их.

Нет, там не лохи. Они несколько лет именно eCos достаточно серьезно занимаются. Так что есть шанс...