roboforum.ru

Как правильно сконфигурировать SPI для работы слэйвом через DMA?

Я написал драйвер SPI с DMA для Linux. За основу был взят spi_s3c24xx.c, и работа по прерываниям заменена на DMA, и при запросе на чтение сразу возврат (мне нужна только запись). Все работает нормально. Но мне нужно чтобы SPI был слэйвом. В иницализации SPI убрал бит MSTR, и настройку nSS на выход. Теперь после запуска DMA прерывание от него не генерируется. Пробовал nSS притягивать к земле. Код драйвера в прицепе. Что я делаю не так?

Нашел пару косяков в своем коде (неправильно устанавливал режим пинов) и в патче, который применял для активизации SPI (не прописан пин CS в описании драйвера). Проблему это не решило

.zip Архивы с робофорума только у меня битые??? или отстал от жизни и новую версию архиватора пропустил?

А кто мастер в системе?

Идеи на вскидку:
Если есть возможность Проверить связку без ОС могут быть косяки или фичи в работе SPI + DMA
Слейв без дма работает?
Проверить конфиг регистры дма, спи или их в системе никто не перезаписал.
Проверить или все конфиг биты стоят, бывают они прячутся по датащиту

Вроде нашел бяку. На момент записи байта в регистр данных для SPI в режиме подчиненного, на входе SCK должен быть 0 (использую режим 0, для режимов 2 и 3 подозреваю что должна быть единица). Иначе в регистре SPSTA бит REDY сбрасывается, и при попытке начать передачу возникает коллизия. Похоже что это вообще плохая идея использовать SPI слэйвом. Даже при DMA задержка между окончанием передачи байта и выдачей следующего зависит от кучи факторов, слэйв будет пропускать клок.

Возможно ты просто что-то делаешь не так. Просто я не уверен, что тут много программистов хотя бы твоего уровня, кто может тебе помочь. По моим оценкам (после весьма поверхностного изучения) все задержки в АРМ-е просчитывамы, т.е. очередь приоритетов и конфликтов с прерываниями и т.д. ясна. На всех шинах реализуемы арбитры и ловцы ошибок. Стесняюсь спросить - ты смотрел примеры кода (для МК такие есть, возможно и для АРМ9 тоже есть?) - там ДМА и в хвост и в гриву....

Да примеров DMA и в коде ядра навалом, в том числе и в драйверах специально для S324XX. Разумеется, я их смотрел, не с нуля же я драйвер писал. Я уверен, что проблема именно в том, как работает SPI - потому что при однобайтной транзакции DMA отрабатывает нормально, и генерирует прерывание - но потом бит готовности SPI все время сброшен.

dccharacter писал(а):все задержки в АРМ-е просчитывамы, т.е. очередь приоритетов и конфликтов с прерываниями и т.д. ясна

Разумеется, просчитывамы. Теоретически. Вот только на практике для того чтобы просчитать все это, надо иметь кучу данных - кто, когда, куда обращается и т.д ----> нереально. Отчетливо видно на осциллографе - если постоянно гнать данные через SPI мастер например из /dev/zero/, то транзакции начинаются почти через равное время, и между байтами почти всегда одинаковые промежутки. А если одновременно с этим, например, видео включить с карты памяти - полный хаос.

с картой памяти это понятно, оно тож дма юзает

Посмотри приоритет твоего дма потока, ибо не должно оно быть разное если ты выделил отдельный поток дма, разве кто в лине его еще трогает криво либо на время запрещает.

Не знаю как в проце на миньке дма устроено, но класика должна сразу отрабатывать если шина данных не занята

Мож клок SPI понизить, чтоб успевало данные с спи забрать. Или критична пропускная способность?

Посмотреть еще хорошо или СПИ своего буфера маленького не имеет аппаратного, он может помочь не так часто дергать дма, в некоторых контролерах с которыми работал такое есть.

или вводить какой нить хендшек, че мод данные в буфер записаны, шли дальше, если это не с АЦП

Еше мысля в копилку 32 бит архитектура очень не любит работать с 8 битными данными, жует побайтно долго и капризничает иногда

Aseris писал(а):Посмотри приоритет твоего дма потока, ибо не должно оно быть разное если ты выделил отдельный поток дма, разве кто в лине его еще трогает криво либо на время запрещает.

Чего это не должно? Шина одна, и разделяется между несколькими потоками DMA и процессором. Включаем второй поток DMA - первый реже сможет забирать данные из памяти. Процессор часто обращается к памяти - DMA чаще приходится ждать освобождения шины. Запущено больше процессов - пауза между передачей блоков через DMA непредсказуема.

Проблемы с DMA нет. Есть проблема с SPI. Но я пока забил на это. Проще сделать внешнее устройство слэйвом, и гнать данные блоками, а между блоками проверять готовность девайса.

Добавлено спустя 8 минут 28 секунд:

Aseris писал(а):или вводить какой нить хендшек, че мод данные в буфер записаны, шли дальше, если это не с АЦП

Так и делаю. Это не АЦП. Это ЦАП Суть девайса в том, чтобы забирать данные от мини в свой буфер, а потом выдавать на внешний ЦАП с частотой, независимой от тактовой частоты мини2440. Должен быть стабильный поток, независимо от загрузки мини.