[grabin 0]

подскажите пожалуйста,

 

- сколько на самом деле потребляет этот процессор, ибо информация противоречивая.

 

- какую внешнюю память посоветуете использовать совместно с ним?

 

- какие ограничения у trial-версии VisualDSP++?

 

- чем прошивать процессор? (говорят, JTAG - дорог, можно ли чем нибудь ещё?)

 

- есть ли какая-нибудь схема с использованием данного процессора, с обвязкой и т.п. ?

 

И еще нескромный вопрос. Если у кого есть ненужная уже отладочная плата, пусть самодельная, с blackfin-ом, я готов купить.

 

 

Заранее благодарен!!!

[Pathfinder 0]

Энергопотребление зависит от тактовой частоты и напряжения питания ядра. По этому поводу есть целая статья EE-229 "Estimating Power for ADSP-BF533 Blackfin® Processors" тут: http://www.analog.com/UploadedFiles/Applic...083EE229v01.pdf

 

Внешняя память зависит от задачи - если надо немного (0.5-4MБ) но быстрой, например для задач ЦОС, лучше SRAM. Я использовал 10нс Samsung-овскую, но много других вариантов. Если надо много памяти (МБ 128), и ее быстродействие не критично, надо ставить SDRAM.

 

Для загрузки IMHO проще всего использовать SPI DataFlash от Atmel или что-то подобное.

 

Примеры схем можно посмотреть на www.analog.com и www.blackfin.org

[grabin 0]

большое спасибо за ссылку на статью, именно то, что нужно.

 

не могли бы вы дать ссылки на схемы, я не нашёл ни на analog.com, ни на blackfin.org, если честно.

 

и ещё, уточните название SRAM микросхемы (10нс Samsung-овской)

 

спасибо.

[Pathfinder 0]

Примеры схем можно взять например тут: http://blackfin.uclinux.org/frs/?group_id=7

и тут: http://www.analog.com/UploadedFiles/Associ...ual_Rev_2.0.pdf . Вообще на форуме эта тема всплывала не однократно, так что ищите.

SRAM например K6R4016v1d (256x16бит 10нс), но есть много других вариантов совместимых по ногам, с теми же параметрами.

[dinam 1]

Вот уже неделю как подцепил SDRAM 16 Мбайт K4S281632А-UC60 к BF532. Схему брал из"ADSP-BF533 Blackfin® Processor

Hardware Reference". В некоторых случаях правда пока работает нестабильно :-(. Но думаю это победимо. Может у кого опыт есть по работе с SDRAM?

[dxp 64]

Вот уже неделю как подцепил SDRAM 16 Мбайт K4S281632А-UC60 к BF532. Схему брал из"ADSP-BF533 Blackfin® ProcessorHardware Reference".

А другая разве есть? Там вообще только один варинат включения SDRAM. Если только саму память из нескольких чипов юзать.

 

В некоторых случаях правда пока работает нестабильно :-(. Но думаю это победимо. Может у кого опыт есть по работе с SDRAM?

А в чем проявляются проблемы, нестабильность? У меня пока боевая плата не готова, но в ките все работает прекрасно.

[dinam 1]

Вот что пока получилось. Внутренний тест SDRAM проходит нормально. При считывании по PPI из внутренней памяти BF532 нет ошибок. При считывании по PPI из SDRAM иногда возникают ошибки, в начале пакета, но не в первом. Передача происходит пакетами по 64 байта. Такое оущение что Blackfin или SDRAM в какие-то моменты затыкаются, а потом опять продолжают отвечать. Т. к. тесты на бегущий 0 и бегущую 1 проходят без проблем. А ошибки возникают при тестировании случайными значениями. В BF532 все прерывания отключены, к асинхронной памяти обращений нет. PPI работает на 24 МГц 8 бит, SDRAM 80 МГц.

[dxp 64]

Вот что пока получилось. Внутренний тест SDRAM проходит нормально. При считывании по PPI из внутренней памяти BF532 нет ошибок. При считывании по PPI из SDRAM иногда возникают ошибки, в начале пакета, но не в первом. Передача происходит пакетами по 64 байта. Такое оущение что Blackfin или SDRAM в какие-то моменты затыкаются, а потом опять продолжают отвечать. Т. к. тесты на бегущий 0 и бегущую 1 проходят без проблем. А ошибки возникают при тестировании случайными значениями. В BF532 все прерывания отключены, к асинхронной памяти обращений нет. PPI работает на 24 МГц 8 бит, SDRAM 80 МГц.

Похоже, что не в самом контроллере SDRAM проблемы, а где-то на стыке. Чтение через DMA делаете? Может где-то тут "собака порылась"? :) Посмотрите внимательнее errata на ревизию вашего чипа в контексте DMA, PPI и контроллера SDRAM.

[dinam 1]

Чтение через DMA делаете?

А по другому через PPI не получиться. ;) Чтение errata ни к чему не привели. Посмотрел по осциллографу длина FIFO PPI+DMA у меня получилась 23 байта, т. е. запас по времени вполне приличный. Почти микросекунда! В общем пока идей нет :-(

[dxp 64]

Чтение через DMA делаете?

А по другому через PPI не получиться. ;) Чтение errata ни к чему не привели. Посмотрел по осциллографу длина FIFO PPI+DMA у меня получилась 23 байта, т. е. запас по времени вполне приличный. Почти микросекунда! В общем пока идей нет :-(

Там, по ходу, дело не в скорости (типа не успевает) - так бы он ни разу не работал, а в конфликте при передаче по шинам - где-то какой-то запрос иногда вызывает коллизию. Попробуйте поиграть с параметрами пересылки - длиной, режимами DMA. Попробуйте, к примеру, перекачивать из SDRAM в PPI не напрямую, а, скажем, из SDRAM во внутренний буфер, а из него уже в PPI. Некузяво, конечно, но вдруг какой-нито момент обнаружится. В общем, экспериментировать надо, возможно, удастся локализовать.

[dinam 1]

Конечно буду пытаться локализовать засаду. Спасибо!

[dinam 1]

Вот что пока нарыл. Возникает ошибка опустошения FIFO PPI. По осциллографу видно что Blackfin почему-то не читает SDRAM и поэтому FIFO опустошается. Hикаких DMA ошибок не возникает.

[alexdsp 0]

dinam

 

Мне кажется, что у вас проблема в следующем.

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

Например, есть память от Micron MT48LC8M16A2-75TG (я такую сейчас использую).

Она физически разбита на 4 банка по 4 мегабайта.

Если, к примеру, PPI читает данные с банка-0, то если вы вставляете, между делом (например, инструкциями процессорного ядра) дополнительные циклы обращения к этому-же банку, то перед каждым таким обращением контроллер SDRAM будет вставлять precharge на страницу, а после этого, когда модуль PPI потребует снова свои данные из SDRAM, то опять возникнет precharge. Результат: сильнейшая потеря производительности.

Например, у меня - по PPI бежит видео 27мбайт/сек. Если в это время, мне вздумется писать или читать данные в/из того-же банка с которым в настоящий момент работает PPI, то я добьюсь переполнения/опустошения FIFO PPI и всё.

Единственный выход, это реализовать механизм доступа с двойной буферизацией. Например, пока PPI читает предварительно подготовленные данные из банка0, готовятся данные в банке1. После вывода всего блока из банка0, буфера меняются местами. В такой схеме SDRAM работает намного эффективнее.

Смотрите у себя, может в этом дело.

Удачи

[dinam 1]

Победа! Я "подтормаживаю" PPI прекращением подачи PPI_CLK, на время пока не будет готов следующий пакет. Так вот описанную мной проблему удалось решить удлинив на пол такта время подачи PPI_CLK на Blackfin.

Изменено 9 декабря, 2005 пользователем dinam