ARM7 или Cortex-Mx SDIO SLAVE возможно ли ?, возможно ли сделать SDIO в режиме Slave? Опции

[detonator]

Может задача показаться немного страной и у многих появится идея решить её по другому.
( право каждого! Но не хотел бы чтобы тема была раскрыта и не укатилась в полёте мыслей участников в “тамтарары”. )

Давно просматривая возможность межпроцессорного взаимодействия на скоростях выше 25 МегаБайт в секунду.
Есть задумка реализовать это на интерфейсе SDIO сейчас воткнутом почти во всех микроконтроллерах. В режимах 4 или 8 битной шины такие скорости реализовать возможно.

Но не нашел контроллера ( приоритет ARM7/Cortex-Mx из за цены ) где возможно SDIO настроить на приём! Вывод CLK у всех интерфейсов настраивается как выход.
( Нюансы программной часть сейчас более тщательно просматриваю. )

Подскажите, пожалуйста, возможно ли настроить в микроконтроллере блок SDIO на приём?
Допускается обход стандартного алгоритма протокольной части. То есть возможно не придерживаться заложенного в стандарте этапов инициализацию , пересылку команд, и гнать просто данные в любом направлении ! Не важно данные идут от мастера к ведомому или на оборот.
Если есть предложения как возможно реализовать и на чем пишите, жду с нетерпением .

[aaarrr]

Подскажите, пожалуйста, возможно ли настроить в микроконтроллере блок SDIO на приём?

SDIO подразумевает четкое разделение host/card, контроллер последней в процессорах общего применения не встречается. Так что ответ - нет, нельзя.
Если устроит скорость 100Mbit, можно организовать соединение через [R]MII - процессоров с контроллером EMAC на борту сейчас тоже достаточно.

[KRS]

Подскажите, пожалуйста, возможно ли настроить в микроконтроллере блок SDIO на приём?

нет, нельзя, клоки только на выход везде. так что не обойти.

Если устроит скорость 100Mbit, можно организовать соединение через [R]MII - процессоров с контроллером EMAC на борту сейчас тоже достаточно.

А как через [R]MII можно соединить?

[aaarrr]

А как через [R]MII можно соединить?

Проводами крест-накрест

[KRS]

Проводами крест-накрест

так PHY нужны
или все таки можно MAC <-> MAC соединить прямо два LPCxx без свитчей и т.п. (на одной плате)

[aaarrr]

или все таки можно MAC <-> MAC соединить прямо два LPCxx без свитчей и т.п. (на одной плате)

Именно так. Для RMII получается всего 7 проводов.

[KRS]

Именно так. Для RMII получается всего 7 проводов.

данные 2 * 2 крест на крест = 4
клок 50 Mhz на оба

а еще два?

[aaarrr]

а еще два?

CRS_DV и TXEN.

[detonator]

Спасибо за быстрый ответ. наблюдение - тема укатилась в полёте мыслей участников в “тамтарары” уже на 3 сообщении. ( куда все спешат ? интересно как связаться по R[MII] создайте тему. )
на счет R[MII] это был самый первый рассматриваемый вариант. но проблема в том что на одном из контроллеров предполагается его задействовать по назначению. ( в этом сегменте микроконтроллеров в 2 R[MII] не так много и дороговаты ) ещё возможно соединиться по USB OTG но для этого если понадобиться сделаю новую тему.
А теперь по существу.
Пока SDIO на микроконтроллерах реализован только физическом и канальном уровне. То есть блок может передавать в нужном формате данные и формировать интерфейсные данные. А следующий уровень пока ещё не реализован и он делается программно. Происходит инициализация устройства , передача команды и приём или передача данных. Всё транзакции имеют свой вид пакета которые складываться по DMA в память
Хотелось бы более детально рассмотреть возможность подключении двух контроллеров при следующем алгоритме работы ( рассмотрим на примере SD карты роль которой выполняет один из контролёров ):
Получение блока данных из SD карты . хост в этот момент переводит шину в приём и по своим тактовым сигналам принимает пакет. SD карта ( в нашем случает микроконтроллер ) выдаёт пакет данных на той же частоте но уже по своему тактирующему сигналу.
( Получается что один контроллер находиться в стандартном режиме приёма пакета от слейва , а второй в стандартном режиме передачи пакета слейву. )
И тут остаётся только синхронизировать CLK . по светотехники это не сложно . ( надо посмотреть допустимые задержи на шине. )
Вопрос наверно в программной части .
Как вам подход? Имеет ли шанс такая реализация ?

Сообщение отредактировал detonator - May 15 2012, 04:10

[izerg]

Вы не рассматриваете возможность реализации двумя камнями ?
В первом - мост SDIO - во чтониудь поприятнее с буфером (возможно тот же RMII),
Во втором - небольшой кортекс для обработки задач.
В качестве первого камня - можно пробовать небольшой MAXII от Альтеры, реализацию SDIO slave на них попадалась.

[detonator]

Уже рассматривал! вопрос в финансовой части.
( сравнивал MAXII vs Lattice MachXO2(LatticeXP2), xillinx )
Цена моста дороже микроконтроллера. Эти данные потом попадают в память и обрабатываться.
( у логики нет достаточно памяти, надо порядка 32-64 кБ. )
Задачу по сути на CPLD/FPGA реализовать возможно. Но цена таких начинается от 5 долларов , а за такую сумму можно купить шустрый Сortex и всё сделать на нём с запасом по мощности.
Как не крути программируемая логика дорога для этого применения . А микроконтроллеры сейчас работают на схожих частотах и алгоритмов возможно реализовать больше за меньшие деньги.

[aaarrr]

куда все спешат ? интересно как связаться по R[MII] создайте тему.

Это не того масштаба оффтоп, чтобы куда-то выносить обсуждение.

Как вам подход? Имеет ли шанс такая реализация ?

Теоретически имеет, но:
- придется городить дополнительный интерфейс между контроллерами для "переговоров", т.к. по линии CMD общение отпадает
- нужна будет логика для передачи данных между двумя разными CLK-доменами (какая-нибудь мелкая CPLD), ей тоже придется управлять со стороны одного из МК

Вы бы пояснили смысл создания такого скоростного соединения между двумя мелкими МК.

[Altemir]

detonator
А нельзя просто по параллельному интерфейсу? Особенно, если у обоих контроллеров будет хотя бы EMC SRAM. При реализации подобных скоростей обычно применяют двухпортовую память, которая ставится между двумя контроллерами. При желании можно и без неё, но в скорости проиграете. Реализация простая - два кольцевых буфера.

[detonator]

Altemir
EMC занят на одном и возможно на втором он тож будет использоваться.

aaarrr
- придется городить дополнительный интерфейс между контроллерами для "переговоров", т.к. по линии CMD общение отпадает .
Я про это и пытался написать когда говорил про об обходе стандартного интерфейса.
( но думаю что заведя CMD на перекрывание может получиться оставить его . правда зачем . )


>> Вы бы пояснили смысл создания такого скоростного соединения между двумя мелкими МК.
Не так часто захожу на electronix.ru и пока не освоился. Так что пока воздержался бы о смысле такого соединения.

Спасибо за поддержку. Буду пытаться сделать соединение. О результатах постараюсь написать.

[Tano]

To detonator.
Ну что-то получилось?
Просматриваю такое решение между МК и ПЛИС.

[jcxz]

По-моему это задача реализации сферического коня в вакууме. Наверно до сих пор реализуется
Но в принципе ничего сложного в реализации по-моему нет, если в каждый момент времени рассматривать только передачу в одном направлении, а задачу определения направления и разрешения коллизий производить сторонними стредствами.
На передающей стороне программируете SDIO, а на приёмной - входящий CLK на счётный вход внутреннего таймера, ноги данных SDIO - в режим GPIO in, событие от таймера - на канал DMA, который считывает слово данных по данному событию с ног GPIO. Всё.
Хотя я не знаком особо с SDIO.

[Andrey Vasilyev]

В STM32 можно триггерить выдачу/прием данных с GPIO через DMA посредством event-ов, повешенных, например, на событие захвата таймера. А таймер можно сконфигурировать так, чтобы событие возникало по определенной ножке.
Таким образом, можно соединить на двух процессорах некоторый набор ног одного GPIO-порта (лучше, если с нулевого пина до 7 или до 15-го), а также ногу таймеров, и на передающей стороне через таймер триггерить передачу данных из SRAM на ноги GPIO, сконфигурировав также ногу таймера на вывод импульсов в соответствующее время, а на принимающей стороне ногу таймера сконфигурировать на генерацию event-а для запуска DMA, вычитывающего данные в соответствующий момент времени с GPIO в SRAM.
Коряво, но быстро и без участия ядра процессора.
Впрочем, все равно это получается хак, не переносимый на другие семейства процессоров. Да и за реализуемость не поручусь - сам я подобного не делал, и мало ли что я неправильно понял в документации.

[jcxz]

В STM32 можно триггерить выдачу/прием данных с GPIO через DMA посредством event-ов, повешенных, например, на событие захвата таймера...

Я писал как раз о подобном, только - применительно к LPC
Это реализуемо. Засада может быть только в задержках DMA: на LPC17x и других семействах LPC, до LPC177x приоритет доступа к шине у CPU (фиксирован), соответственно (имхо) из-за этого DMA может частенько подтормаживать (у меня были проблемы с этим на SSP на максимальных частотах, а здесь нужна ещё большая скорость DMA). На LPC177x можно режить проблему, повысив приоритет GPDMA через регистр арбитража доступа к шине.
На других процессорах придётся пустить сигнал обратной синхронизации (кроме сигнала строба данных (CS) передатчик->приёмник) - подтверждение приёмник->передатчик. На каждое чтение слова. Он будет идти с частотой строба, но сдвинут по фазе относительно него. И этот сигнал заводить на вход CLK таймера передатчика, генерящего события для TX-DMA.

Если-же приоритет доступа к шине у DMA-контроллера и нет проблем с задержками доступа к шине от DMA, то можно вообще обойтись одним импульсом сигнала синхронизации от TX и одним - готовности от RX, а дальше - слать данные блоком, внутри синхронизируя DMA-каналы от таймеров, не выводя сигналы таймеров наружу. И так - до некоторого размера блока, зависящего от разности частот задающих генераторов двух CPU (погрешности частоты генераторов). Далее - опять синхронизация и новый блок. Я почти так когда-то делал - работало стабильно
А если 2 CPU работают от одного генератора - так вообще халва

[Andrey Vasilyev]

Я писал как раз о подобном, только - применительно к LPC

У LPC (по крайней мере в LPC1768) вроде бы DMA не имеет доступа к шине, на которой висит GPIO?
Или ошибаюсь?

[jcxz]

Дело было уже давно и возможно я что-то путаю, но насколько помню - работало