[nik135 0]

Добрый день!

 

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

Желательно в виде драйвера для linux.

 

Какая максимальная производительность у данного решения. процессор ti-dm3730.

 

зы. извините, новичок в этом деле :rolleyes:

[Jury093 2]

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

Желательно в виде драйвера для linux.

чисто на поиграться, скорость будет никакая..

смотрите в даташите на АРМ подходящее количество свободных пинов в одном банке, идущие подряд - обзываете их (для себя) "шиной"..

настраиваете в режим GPIO и работаете, или через свой драйвер в ядре или из юзерспейса.. грубо говоря, организуете две п/п - чтение и запись

 

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

лучше присмотреть удобоваримый интерфейс (а-ля канал памяти) из давинчи наружу и забуферизировав, пользоваться всякими плюшками типа ДМА

или смотреть в сторону ФПГА, типа десериализатора - давинчи по SPI в фпга, а оттуда параллельной шиной наружу..

 

Какая максимальная производительность у данного решения. процессор ti-dm3730.

на свободный пин прицепите осцилл и прогой на 10 строк сами все увидите..

Изменено 25 января, 2013 пользователем Jury093

[afad 0]

Какая максимальная производительность у данного решения. процессор ti-dm3730.

Делал для LPC1768, работающего на частоте 100 МГц, без особых ухищрений на С получилось записывать 4 Мегаслова в сек (чтение элемента массива из памяти и запись его в gpio, формирование импульса WR, инкремент указателя массива, и так по циклу). Возможно можно как-то оптимизировать, или написать на асме, вероятно можно увеличить скорость в несколько раз, но мне не нужно было, поэтому не заморачивался.

 

[DASM 0]

а толку то - проц только и будет занят этим. Надо аппаратно такое.

[_basile 0]

а толку то - проц только и будет занят этим. Надо аппаратно такое.

 

Причем тут - это? А когда проц будет писать через внешнюю шину - он небудет "только и занят этим" ?

Да, там - DMA можно задействовать, но это - не во всех случаях.

 

[DASM 0]

Я про DMA и говорю, мы же все таки ARM обсуждаем, а не 51-ый

[jcxz 184]

а толку то - проц только и будет занят этим. Надо аппаратно такое.

Кому надо? Топикстартеру? Он нигде не писал, что пересылка должна идти постоянно. Скорей всего - это кратковременные транзакции.

Ранее делал что-то подобное - кратковременные пересылки пакета в неск. килобайт. Запрещал прерывания и программно гнал через GPIO.

Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине.

Я шёл путём оптимизации протокола этой GPIO-шины - после всех оптимизаций у меня на передачу одного слова требовалась одна запись в порт GPIO. При таком алгоритме я передавал весь блок за неск. десятков или сотен микросекунд - это не мешало работе ISR-ов.

Не использовал сигналы синхронизации (типа CS или WR) на каждое слово. Синхронизировал начало пакета, потом просто гнал весь пакет. Предварительно необходимо весь код это выполняющий переместиить в кеш CPU или разместить его в ОЗУ.

Работало в двунаправленном режиме.

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

 

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

[aaarrr 63]

Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине.

У процессора кэш и далеко не одна шина, так что выигрыш никуда не денется.

[jcxz 184]

Кеш не бесконечен - значит будут кеш-промахи.

Да, вроде шина не одна, но по факту, из опыта SSP+DMA (LPC1778), SCLK=30МГц, при приоритете доступа к шине CPU выше чем DMA, наблюдал разрывы в аппаратно формируемом SSEL (SSP-мастер).

При установке приоритета DMA выше чем CPU, эти разрывы пропадали. Благо у LPC1778 есть регистр приоритетов арбитража шины.

Писал об этом здесь ранее.

[DASM 0]

Так "dm3730" процессор, а не простенький LPC1778. Человек писал про шину, а у процессоров обработки потокового видео DMA явно не для мигания гирляндой. С 16 кбайт I-cache выигрыш будет, даже на не очень длинных транзакциях.