nik135 0 24 января, 2013 Опубликовано 24 января, 2013 · Жалоба Добрый день! подскажите, где глянуть как организовать параллельную шину посредством gpio выводов. Желательно в виде драйвера для linux. Какая максимальная производительность у данного решения. процессор ti-dm3730. зы. извините, новичок в этом деле :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Jury093 2 25 января, 2013 Опубликовано 25 января, 2013 (изменено) · Жалоба подскажите, где глянуть как организовать параллельную шину посредством gpio выводов. Желательно в виде драйвера для linux. чисто на поиграться, скорость будет никакая.. смотрите в даташите на АРМ подходящее количество свободных пинов в одном банке, идущие подряд - обзываете их (для себя) "шиной".. настраиваете в режим GPIO и работаете, или через свой драйвер в ядре или из юзерспейса.. грубо говоря, организуете две п/п - чтение и запись если пины идут не подряд, то придется собирать байт/слово из битов, что заметно скажется на производительности.. лучше присмотреть удобоваримый интерфейс (а-ля канал памяти) из давинчи наружу и забуферизировав, пользоваться всякими плюшками типа ДМА или смотреть в сторону ФПГА, типа десериализатора - давинчи по SPI в фпга, а оттуда параллельной шиной наружу.. Какая максимальная производительность у данного решения. процессор ti-dm3730. на свободный пин прицепите осцилл и прогой на 10 строк сами все увидите.. Изменено 25 января, 2013 пользователем Jury093 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
afad 0 5 февраля, 2013 Опубликовано 5 февраля, 2013 · Жалоба Какая максимальная производительность у данного решения. процессор ti-dm3730.Делал для LPC1768, работающего на частоте 100 МГц, без особых ухищрений на С получилось записывать 4 Мегаслова в сек (чтение элемента массива из памяти и запись его в gpio, формирование импульса WR, инкремент указателя массива, и так по циклу). Возможно можно как-то оптимизировать, или написать на асме, вероятно можно увеличить скорость в несколько раз, но мне не нужно было, поэтому не заморачивался. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 23 марта, 2013 Опубликовано 23 марта, 2013 · Жалоба а толку то - проц только и будет занят этим. Надо аппаратно такое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_basile 0 24 марта, 2013 Опубликовано 24 марта, 2013 · Жалоба а толку то - проц только и будет занят этим. Надо аппаратно такое. Причем тут - это? А когда проц будет писать через внешнюю шину - он небудет "только и занят этим" ? Да, там - DMA можно задействовать, но это - не во всех случаях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 24 марта, 2013 Опубликовано 24 марта, 2013 · Жалоба Я про DMA и говорю, мы же все таки ARM обсуждаем, а не 51-ый Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 25 марта, 2013 Опубликовано 25 марта, 2013 · Жалоба а толку то - проц только и будет занят этим. Надо аппаратно такое.Кому надо? Топикстартеру? Он нигде не писал, что пересылка должна идти постоянно. Скорей всего - это кратковременные транзакции. Ранее делал что-то подобное - кратковременные пересылки пакета в неск. килобайт. Запрещал прерывания и программно гнал через GPIO. Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине. Я шёл путём оптимизации протокола этой GPIO-шины - после всех оптимизаций у меня на передачу одного слова требовалась одна запись в порт GPIO. При таком алгоритме я передавал весь блок за неск. десятков или сотен микросекунд - это не мешало работе ISR-ов. Не использовал сигналы синхронизации (типа CS или WR) на каждое слово. Синхронизировал начало пакета, потом просто гнал весь пакет. Предварительно необходимо весь код это выполняющий переместиить в кеш CPU или разместить его в ОЗУ. Работало в двунаправленном режиме. Хоть стороны обмена тактировались от разных задающих генераторов, но за время передачи блока частоты не успевали рассинхронизироваться. Делал в том же проекте вариант с DMA (растягивал по времени, добавлял синхросигналы на каждое слово, фоновое выполнение с кодом) - выигрыша в общей производительности системы не получал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 25 марта, 2013 Опубликовано 25 марта, 2013 · Жалоба Выигрыша от DMA в таком режиме не будет - если проц во время такой DMA-пересылки будет выполнять код - будут проблемы с арбитражом шины (если у DMA приоритет доступа ниже чем у CPU), как следствие - замедление работы DMA, следствие - возможные ошибки протокола обмена по этой вашей GPIO-шине. У процессора кэш и далеко не одна шина, так что выигрыш никуда не денется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 25 марта, 2013 Опубликовано 25 марта, 2013 · Жалоба Кеш не бесконечен - значит будут кеш-промахи. Да, вроде шина не одна, но по факту, из опыта SSP+DMA (LPC1778), SCLK=30МГц, при приоритете доступа к шине CPU выше чем DMA, наблюдал разрывы в аппаратно формируемом SSEL (SSP-мастер). При установке приоритета DMA выше чем CPU, эти разрывы пропадали. Благо у LPC1778 есть регистр приоритетов арбитража шины. Писал об этом здесь ранее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 25 марта, 2013 Опубликовано 25 марта, 2013 · Жалоба Так "dm3730" процессор, а не простенький LPC1778. Человек писал про шину, а у процессоров обработки потокового видео DMA явно не для мигания гирляндой. С 16 кбайт I-cache выигрыш будет, даже на не очень длинных транзакциях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться