Jump to content

    
Sign in to follow this  
nik135

параллельная шина из gpio

Recommended Posts

Добрый день!

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
подскажите, где глянуть как организовать параллельную шину посредством gpio выводов.

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

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

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

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

 

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

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

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

 

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

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

Edited by Jury093

Share this post


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

 

Share this post


Link to post
Share on other sites
а толку то - проц только и будет занят этим. Надо аппаратно такое.

 

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

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

 

Share this post


Link to post
Share on other sites
а толку то - проц только и будет занят этим. Надо аппаратно такое.
Кому надо? Топикстартеру? Он нигде не писал, что пересылка должна идти постоянно. Скорей всего - это кратковременные транзакции.

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

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

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

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

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

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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this