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

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

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

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



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

Подробней - я боюсь тогда проще драйвер написать за Вас. Если кратко - уберите описание ресурсов нужного интерфейса в ядре и работайте с ним напрямую, сконфигурировав под свою задачу - у Атмел куча примеров, думаю найдете и для 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 был единственный скоростной интерфейс.

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

Иногда лучше молчать



Ваша нелюбовь ко всему что связано с linux мне известна, но иногда раскрывайте глаза - легкость написания драйверов никак не связана со скоростью работы устроств. С spi так получилось что атмеловский контроллер не поддерживает CS обоих уровней, что для универсальной ОС как linux неприемлемо, поэтому в угоду универсальности атмеловские драйверы написаны далеко не оптимально с точки зрения скорости. Я бы еще закрыл на это глаза но там не оказалось того функционала который предусмотрен ядром linux а у атмел просто не был реализован.

Работа с периферией в линуксе через самописный драйвер - не такая сложная задача (на уровне принять отправить)

Автору - посмотрите в сторону SMC - широкая (относительно) шина, сигналы управления (RD, WR, CS)... но на ПЛИСине придется реализовывать ФИФО...

а что это за шина? я пока толкового описания о ней найти не могу....

SMC - Static Memory Controller
Загляните в даташит

UPD: SMC был на SAM9260... тут другая... EBI однако

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

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

Ясно, значит меня просто ввела в заблуждение Ваша фраза про "юзерспейс не успеет забрать данные".
Про кеш, то понятно. В некоторых процессорах есть очень зачетная фича - поддержка когерентности кеша и памяти - ядро снупит шину и инвалидирует/флашит кеш при необходимости. В тех же MPC83xx от Фрискейла, например, такое сделано.

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

В 83xx это сделано именно на уровне интерфейса ядра с шиной, про кэш и MMU при разработке программы можно вообще не вспоминать - никаких инструкций инвалидации вызывать не надо. Эта фишка вообще стала только недавно появляться и заточена она не столько под DMA как под многопроцессорные системы. Ядро следит за шиной, и если по ней проходит транзакция записи каким-то другим мастером (не данным ядром) и адрес приемника совпадает с закэшированным, то эта строка кэша автоматом инвалидируется. Если же кто-то хочет читать по шине данные, а они еще не записаны из кэша (Writeback кэш, например), то ядро ставит abort/retry, забирает шину, флашит данные из кэша, и отдает шину обратно. Потом жаждущий данных сторонний мастер делает retry и забирает свеженькую информацию. Не думаю что такое возможно на ARM-ах, сейчас тут писк моды Multilayer Bus Matrix - замучается ядро такое снупить. Хотя, может я и не в курсе - АРМы разные бывают.

P.S. Извините за оффтопик.