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

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

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

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

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



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

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

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

Трудности всегда присутствуют когда начинаешь с нуля, но в linux драйверы писать одно удовольствие нужно просто понимать что делаешь. Если ldd читать времени нет - вот галопом по европам:
http://opennet.ru/docs/RUS/lkmpg26/
Вот то что в любом случае Вам понадобится для работы с dma
http://free-electrons.com/doc/dma.pdf
Вообще тут http://free-electrons.com/docs/ много информации в доступной форме в виде слайдов, для ознакомления и получения ориентира весьма неплохо.

Зря вы здесь связались с линуксом, у атмела счетчик PDC только до 64 Kб а дальше надо успеть до окончания передачи пакета отработать прерывание и запрограммировать следующий дескриптор пересылки по DMA. Поскольку у Atmel-ов нет цепочечной обработки дескрипторов.
Большие сомнения, что всегда из юзерспейса вы успеете обработать такие прерывания в срок не пропатчив свой линукс на риалтайм.

Простой отказ от драйверов и прямое управление периферией не так прост как может показаться. Поскольку PDC может использоваться или затрагиваться еще кучей драйверов разной периферии, то придется профильтровать все драйвера на предмет конфликтов использования PDC. А это адская и никому не нужная работа.
Проще выкинуть линукс, и взять что-то типа FreeRTOS.

О проблеме " риалтайма линукса" я уже задумывался, и смотрел в сторону FreeRTOS, eCOS и т.д., но тогда по-моему появится проблема в отладке и написании драйверов, разве нет?

По большому счету я согласен - в linux нужно понимать что делаешь, здесь не прокатывает тупое кликанье мышью. К счастью.



В "стандартном" pdc два указателя - на текущий и на следующий буфер, никогда не задумывались - для чего это сделано ?



Очевидно Вы не видели даташит на at91sam9g45 - там появился dma контроллер с поддержкой scatter/gather.



Никаких проблем не вызвает прямое использование - даже наоборот.



Проще купить готовый продукт.

Не появился, а есть в at91sam9g45 другой DMA с цепочечной обработкой. Но он сидит на AHB будет занят на диски и звук и вы точно к нему не подступитесь ибо он будет слишком плотно использоваться драйверами линукса.
Вы и выбрали для прямой работы PDC потому что он не такой востребованный и его можно попытаться исключить из использования в драйверах.
При этом все равно получаете дикую головную боль когда Atmel захочет апгрейдить свои драйвера под линукс.

В дальнейшем предлагаю ссылаться на первоисточник:
http://www.atmel.com/dyn/resources/prod_do...nts/doc6438.pdf, а не на предположения о том что я не читал или не читал.

У Атмела есть и slave и master SPI, но вопрос в другом: насколько я понимаю линукс по умолчанию является Master и как из него сделать Slave я не знаю...





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



спасибо, сейчас буду изучать)



Я согласен, что у меня сейчас в 100 раз больше вопросов, чем ответов, но а разве может быть по-другому в начале изучения чего-то серьезного?

При поверхностном осмотре - все дрйверы для g45 теже самые что и для младших контроллеров, по крайней мере чтобы использовать dma контроллер есть конкретный пункт меню в конфигураторе - всегда можно запретить драйверам лезть к dma.



Я ничего не выбирал - задача четко не сформулирована, да и мне это не нужно.




Да причем тут linux - я говорю о том чтобы написать свой драйвер который будет напрямую работать с spi контроллером миную api ядра для spi - как еще Вам объяснить ?



Что такое linux - это ядро предоставляющее некоторый уровень абстракции над железом, то есть любой драйвер должен предоставить функционал в соответствии с требованиями ядра - это простые ф-ции типа открыть, закрыть, прочитать, записать, изменить настройки. Остальным частям ядра не нужно знать как устроено это железо - они вызывают эти функции не напрямую а через api ядра. Так вот никто не мешает вам не использовать api ядра а общаться с контроллером напрямую в своем драйвере - достаточно чтобы ядро не пыталось параллельно с ним работать, для этого и нужно исключить из поля видимости ядра это устройство.

Вы хотите сказать, что если написать такой драйвер, то независимо от режима работы (Master или Slave) все будет зависеть от драйвера(и в драйвере будет прописано кто посылает запросы, а кто на них отвечает)?

Сказано было по существу, что человек не смог совладать с HAL уровнем линукса под SPI с сделал программу напрямую обращающуюся к регистрам периферии.
Это уже не драйвер, а костыль для преодоления границ юзерспейса.
Но и при этом надо тщательно следить чтоб этому костылю не мешали другие драйвера, а главное нет никакой инфы какая достижима производительность с таким решением.

Перестаньте искажать чужие слова - лучше за своими следите и читайте даташиты иногда прежде чем заявлять что у атмел нет scatter/gather. Я управлял spi напрямую потому что мне нужна была скорость и spi был единственный скоростной интерфейс.

Не оговаривается только то, кто ничего не говорит.
Но ваше утверждение, что скорость в линуксе легче достичь отказавшись от драйверов противоречит вашему же утверждению что драйвера писать там очень легко.
Вот что забавно.