SPI SAM7X256 в режиме slave и при использовании PDC, поиск момента синхронизации Опции

[bookevg]

Ситуация:
Есть 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-ой способ.
Надо думать как еще сделать. Возможно использование допол.ножек.

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

[VslavX]

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

[bookevg]

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

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

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

Правда, возникает ряд вопросов -
- почему SAM - slave ?

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

- почему, если это ваша система, Вы не знаете, на какой размер данных нужно запускать PDC ?

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

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

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

[amw]

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

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

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

Сообщение отредактировал amw - Nov 11 2008, 12:20