Есть плисина. У нее есть два потока во "внешний мир" - входной и выходной. Есть буферный 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 достаточно серьезно занимаются. Так что есть шанс...