AT91SAM9G45 и Linux, Работа с интерфейсами (SSC, SPI..) Опции

[stas17]

Здравствуйте! Мне нужно передавать данные от FPGA к ОС Linux. Скорость передачи довольно высокая - 3 МБайт/сек. Проблема в работе с интерфейсами.
Во-первых, проблема в выборе между SSC, SPI... (может какой-нибудь другой последовательный интерфейс).
Во-вторых, самое главное то, что драйвера под Linux нужно писать самому, а насколько я понимаю - это очень трудоемкий процесс, тем более, что подобного опыта у меня еще не было. Использование SPI представляется более логичным, но в данной системе это должно быть так: FPGA - Master, a Linux - Slave, но Linux, насколько я понимаю, не может быть Slave...И вообще, какие драйвера написать сложнее, на SPI или SSC?
Посмотрел довольно много информации по этим вопросам и конкретных решений пока не нашел...
Может у кого-нибудь есть опыт работы в подобных вопросах?
Заранее благодарен!

[winner]

подобного опыта у меня еще не было.

Это и есть во-первых slave реализовать самому минуя интерфейс ядра для spi - вообще не проблема если Вы работали с spi at91xxx и знакомы с ядром linux. В использовании для этого ssc я лично вообще смысла не вижу.

PS С ssc я погорячился - нужно исходить из задачи, сколько данных, как они передаются - периодически, постоянно, блоками одинаковый длины или непрерывно и тд.

Сообщение отредактировал winner - Aug 17 2010, 09:51

[stas17]

Это и есть во-первых slave реализовать самому минуя интерфейс ядра для spi - вообще не проблема если Вы работали с spi at91xxx и знакомы с ядром linux. В использовании для этого ssc я лично вообще смысла не вижу.

Не могли об этом поподробнее рассказать?

PS С ssc я погорячился - нужно исходить из задачи, сколько данных, как они передаются - периодически, постоянно, блоками одинаковый длины или непрерывно и тд.

Пакеты, предположительно по 100 КБ, должны передаваться постоянно...

Сообщение отредактировал stas17 - Aug 17 2010, 13:16

[winner]

Не могли об этом поподробнее рассказать?
Пакеты, предположительно по 100 КБ, должны передаваться постоянно...

Подробней - я боюсь тогда проще драйвер написать за Вас. Если кратко - уберите описание ресурсов нужного интерфейса в ядре и работайте с ним напрямую, сконфигурировав под свою задачу - у Атмел куча примеров, думаю найдете и для slave spi. По крайней мере у at91sam9260 два интерфейса - я так и делал, только мне нужно было в режиме master - с одним работал как обычно через api ядра (вернее не я а драйвер dataflash) а другой использовал в своих целях программируя напрямую - ставил свой обработчик прерываний и перекидывал данные используя pdc. В Вашем случае похоже Вы сами не знаете что нужно - я ничего посоветовать не могу - что делать с полученные данными если юзерспейс их не успел прочитать, какой величины иметь буфер, с какой частотой идут блоки данных, нужно данные обрабатывать или сразу на внешнее устройство скидывать, как организованы данные - обособленные блоки или просто непрерывный поток и для юзерспейс неважно где начало а где конец блока. и тд.

[VslavX]

под свою задачу - у Атмел куча примеров, думаю найдете и для slave spi. По крайней мере у at91sam9260 два интерфейса - я так и делал, только мне нужно было в режиме master - с одним работал как обычно через api ядра (вернее не я а драйвер dataflash) а другой использовал в своих целях программируя напрямую - ставил свой обработчик

У меня тут вопрос возник - как корректно работать с DMA (aka PDC) в юзерспейсе. Ведь DMA требует физический адрес, а в юзерспейсе у нас только виртуальные, да еще принадлежащие контексту конкретного процесса (что значит не в любой момент могут быть физически отображены). Получив буфер от malloc() в юзерспейсе нельзя даже быть уверенным что этот буфер физически непрерывен, а не надерган менеджером памяти из нескольких разнесенных физических страничек В ядре то понятно - получили буфер, конвертнули его в список дескрипторов физических страниц и поехали. Неужто в Линуксе есть API для руления физической памятью из юзерспейса? (Сомнение есть, потому как это хорошая дыра в безопасности)

[winner]

У меня тут вопрос возник - как корректно работать с DMA (aka PDC) в юзерспейсе. Ведь DMA требует физический адрес, а в юзерспейсе у нас только виртуальные, да еще принадлежащие контексту конкретного процесса (что значит не в любой момент могут быть физически отображены). Получив буфер от malloc() в юзерспейсе нельзя даже быть уверенным что этот буфер физически непрерывен, а не надерган менеджером памяти из нескольких разнесенных физических страничек В ядре то понятно - получили буфер, конвертнули его в список дескрипторов физических страниц и поехали. Неужто в Линуксе есть API для руления физической памятью из юзерспейса? (Сомнение есть, потому как это хорошая дыра в безопасности)

Честно говоря не могу придумать для чего это все делать в userspace я работал на уровне ядра. Мало того что буфер непрерывный, нужно чтобы еще и память была некешируемая иначе в устройство может улететь совсем не то что хочется