roboforum.ru

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

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

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

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

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

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

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

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

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

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

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