Ситуация:
Есть DSP-процессора и процессор SAM7X256. Общение между ними по SPI каналу в режиме DMA (PDC в случае с SAM7X256) большим потоком данных - 1кбайт, при этом SAM7X256 в режиме slave.
Проблематика:
Для того, чтобы SAM7X256 правильно начал принимать весь пакет - он должен запустить SPI-DMA перед тем, как DSP начнет передавать данные, иначе он все равно примет эти данные (если нет таймаута по приему), т.к. посылка закольцована, но структура принятых/переданных данных будет неправильной.
Задача:
Настроить алгоритм поиска момента активазиции режима slave SPI-DMA SAM7X256.
Решение.
1-ый способ.
Он основан на том, что существует какая-то временная пауза (пусть она составляет 5 мс) в общении двух процессоров
1) запускаем таймер на 2 мс;
2) разрешаем прерывание по поиску полож.фронта выбор slave SPI SAM7X256 (прерывание NSS Rising Interrupt);
3) в случае возникновения прерывания NSS Rising Interrupt перезапускаем таймер на 2 мс;
4) в случае срабатывания таймера разрешаем работу slave SPI-DMA;
5) после работы slave SPI-DMA возвращаемся в п.1 или просто разрешаем повторный slave SPI-DMA
2-ой способ.
Надо думать как еще сделать. Возможно использование допол.ножек.

Какие еще будут предложения?

1кБайт - это объем, поток какой?


Придумать протокол верхнего уровня для восстановления синхронизации - это куда лучший способ, чем ловить паузы.
И в связке с DSP, ИМХО, логичнее использовать SSC.

Хм, я чего-то недопонял - если SAM7 в режиме Slave - то тактовая на SPI вроде должна генерироваться вторым процессором? И пока тактовая на SPI не пойдет - то данных SAM7 принимать по SPI не будет - автоматически будет ждать начала пакета. Так в чем именно проблема?

Вам надо из синхронного протокола сделать асинхронный. В таком случае либо SSC, либо городите свой мини-протокол более высокого уровня. Хотя, если с SPI у вас возникают проблемы такого плана, то SSC ситуацию не спасет.

Правда, возникает ряд вопросов -
- почему SAM - slave ?
- почему, если это ваша система, Вы не знаете, на какой размер данных нужно запускать PDC ?
- почему, если SAM - slave, возникают-таки проблемы с PDC ? Он же работает по клоку от мастера, т.е. зарядили PDC, дождались окончания приема, зарядили следующий буфер...

Попробую уточнить проблему:
Предположим подали питание на оба процессора, они проинициализировались, но каждый по разному. Предположим master быстрее и начал передавать данные размером 1024 байт, а slave не успел. Пусть slave начал принимать со 2-ого символа, т.о. он примет 1023 байта, затем он ждет приема последнего байта, дожидается его. Но при этом получается, что 1 байт в slave - это 2-ой в master, 2 байт в slave - это 3-bй в master ... 1024 байт в slave - это 1-ый в master. Т.о. получается смещение данных.
Данную проблему можно решить, если master подождет slave. Но предположим, что находимся в отладке на slave, а мастер работает самостоятельно, тогда проблема возникает вновь.


Ну будет SAM-мастером, то проблема нужно будет решать у другого процессора, который slave.

Размер известен - 1024 байт

Да это так. Постом выше я попытался дать более точную деталировку проблемы

1. Используйте SSC - так у Вас хотя бы не будет проблем с синхронизацией внутри слов (а с SPI в slave-режиме они будут).
2. Используйте протокол верхнего уровня для разбора принятых данных.

Используйте тайм-аут. Если за заданый промежуток времени PDC не вычитал нужный объем (не сгенерировал прерывание), значит у вас сдвиг - сбрасываете указатели и заново инициализируете PDC.

Вы жестко привязаны к типу интерфейса ?
Передача односторонняя ?

Хм, протяните еще одну линию, которая будет изображать из себя "BUSY" и по ней стартуйте прием.

Ну у SPI есть такой пин - SLAVE SELECT (не помню как он называется в AT91). Типа CS для слейва.
Или с ним проблема тоже?

Вот посмотрел
Он называется NPCS0/NSS у SAM7X256.

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

Резюме: 1-ый способ удался и надежно работает, осталось только CRC32 добавить