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

[AlexandrY]

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

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

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

[winner]

Зря вы здесь связались с линуксом

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

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

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

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

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

Простой отказ от драйверов и прямое управление периферией не так прост как может показаться.

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

Проще выкинуть линукс, и взять что-то типа FreeRTOS.

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

[AlexandrY]

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

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

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

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

[winner]

Не появился, а есть в at91sam9g45 другой DMA с цепочечной обработкой. Но он сидит на AHB будет занят на диски и звук и вы точно к нему не подступитесь ибо он будет слишком плотно использоваться драйверами линукса.

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

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

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

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

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

как еще Вам объяснить ?

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

[stas17]

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

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

[AlexandrY]

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

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

[winner]

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

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

[AlexandrY]

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

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

[winner]

Не оговаривается только то, кто ничего не говорит.

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

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

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