[en0t 0]

Здравствуйте, подскажите что к чему.

Есть есть задача связать at91sam7s256(мастер) и attinny85(слейв) по SPI, всё сделал как написано по даташиту, связь есть но странная.От мастера к слейву данные доходят нормально а вот от слейва они как будто идут с задержкой в 2 байта.

Как будто приём SPI настроен на 24 бита.

 

 

прием мастером осуществлён вот так

AT91PS_SPI pSPI = AT91C_BASE_SPI;
while( !( pSPI->SPI_SR & AT91C_SPI_TDRE ) ); // transfer compl. wait
pSPI->SPI_TDR = (dat & 0xFFFF) | (((~(1 << 2)) & 0xF)<< 16);


while( !( pSPI->SPI_SR & AT91C_SPI_RDRF ) ); // wait for char

return (unsigned char)( pSPI->SPI_RDR ); // it's important to read RDR here!

 

 

зы. тяжёло описать правельно что у меня происходит но думаю кто с этим сиалкивался поймёт.

[aaarrr 69]

тяжёло описать правельно что у меня происходит но думаю кто с этим сиалкивался поймёт.

Постарайтесь все-таки.

 

P.S. Подозреваю, что где-то при предыдущих передачах не читается RDR. Если все передачи организованы так, как в приведенном фрагменте, то значит проблема где-то в другом месте.

[en0t 0]

aaarrr , спасибо действительно помогло.

 

вот ещё есть вопросик.

 

SlaveSPITransfer:
        out        USIDR,r16
        ldi        r16,(1<<USIOIF)
        out        USISR,r16
SlaveSPITransfer_loop:
        in        r16, USISR
        sbrs    r16, USIOIF
        rjmp    SlaveSPITransfer_loop
        in        r16,USIDR
        ret

 

 

в данном примере для слейва сначало идет передача а потом приём.А можно наоборот сначала прием обработка и передача. а то как то вся логика теряется.

спасибо

[aaarrr 69]

в данном примере для слейва сначало идет передача а потом приём.А можно наоборот сначала прием обработка и передача. а то как то вся логика теряется.

А как вы себе это представляете? Если SPI что-то принимает, то, соответственно, обязан и что-то передавать. И это что-то должно быть загружено заранее.

Все остальное решается протоколами верхнего уровня.

[en0t 0]

да я понимаю , спросил так на всякий случай, а вдруг.

Все остальное решается протоколами верхнего уровня.

а это как , ткните ссылкой если не затруднит.

[aaarrr 69]

а это как , ткните ссылкой если не затруднит.

Ссылкой не ткну, но все и так очевидно - добавляйте don't care байты там, где слейву нужно "подумать", или работайте в режиме запрос-ответ.

[en0t 0]

aaarrr, ещё раз спасибо.Буду думать примерять.

[t25a3 0]

У меня была почти такая же проблема с SPI только я его использовал и использую с PDC.

В первом случае в шине стояли резисторы по 300 Ом... Из-за этого спустя некоторое время при отправке команд протокольных и прочее пакет сдвигался на один байт... выпаял резисторы поставил перемычки глюк исчез!

Потом опять проявился этот эффект но это по моему мнению уже было связанно с загруженностью одного из контроллеров при попытке отправить команду или данные тут же сдвигался на один байт! именно передача со слейва!

Взял за правило инициализировать PDC при следующем приеме передаче одновременно и на прием и на передачу!

[strannyi 4]

Потери в PDC еще возникают из-за загруженности внутренней шины ARM-а

Замечал такое когда работа идет на высоких скоростях.

[aaarrr 69]

У меня была почти такая же проблема с SPI только я его использовал и использую с PDC.

В первом случае в шине стояли резисторы по 300 Ом... Из-за этого спустя некоторое время при отправке команд протокольных и прочее пакет сдвигался на один байт... выпаял резисторы поставил перемычки глюк исчез!

А объяснить Вы столь странную связь можете? Я - нет. И очень-очень сильно сомневаюсь, что дело было в резисторах.

 

Потери в PDC еще возникают из-за загруженности внутренней шины ARM-а

Замечал такое когда работа идет на высоких скоростях.

Когда PDC пытается отгрызть более 1/8 пропускной способности шины - да, бывает. Правда, одного SPI для этого мало.

 

 

P.S. Если кто не заметил, проблема топикстартера решена.

[t25a3 0]

А объяснить Вы столь странную связь можете? Я - нет. И очень-очень сильно сомневаюсь, что дело было в резисторах.

 

Могу! Помехи от двигателя постоянного тока. Из за резисторов вероятность возникновения глюка стала 0.99! Практически всегда после начала работы шумящего элемента глюк вылезал! Поставил перемычки вероятность возникновения снизилась примерно до 0.01. А с работой шагового двигателя (и такой имеется в приборе, требовалась реализация микрошага) вероятность глюка повысилась до 0.3 - 0.4. Проблему решил программно. При ошибке CRC slave устройства перезапускали SPI и перенастраивали канал PDC. Работоспособность восстановилась. Байты бегали туда сюда, данными модули между собой обменивались)

 

P.S. Если кто не заметил, проблема топикстартера решена.

мне кажется эта тема и проблема будет всегда возникать)))

пора бы выложить рекомендации в отдельную тему форума по настройке и работе с SPI)))

Изменено 21 мая, 2010 пользователем shrek

[aaarrr 69]

Могу! Помехи от двигателя постоянного тока.

Сдвиг на один байт объяснить можете? Ведь не на один бит, не на 5, 6 или 11, а ровно на байт. Такая умная помеха?

 

мне кажется эта тема и проблема будет всегда возникать)))

пора бы выложить рекомендации в отдельную тему форума по настройке и работе с SPI)))

Это большой и неблагодарный труд. Вообще, для понимания работы атмеловского SPI из SAM7 нужно:

1. Изучить даташит

2. Изучить аппноту для толкования неясностей даташита (а они есть)

3. Задать вопрос здесь, если не помогло :)

[xelax 0]

Вообще, для понимания работы атмеловского SPI из SAM7 нужно:

1. Изучить даташит

2. Изучить аппноту для толкования неясностей даташита (а они есть)

3. Задать вопрос здесь, если не помогло :)

 

Я бы ещё один пункт добавил.

4. Изучить errata.

 

Он весьма обширный, в том числе и на SPI.

[t25a3 0]

Сдвиг на один байт объяснить можете? Ведь не на один бит, не на 5, 6 или 11, а ровно на байт. Такая умная помеха?

счетчик PDC делает декремент после принятия именно байта. Возникла помеха SPI посчитал что это очердной тактовый импульс (или несколько, или вообще не посчитал что был тактовый импульс). В PDC байты ушли раньше положенного (или вообще не ушли, т.е. уйдут при следующем обращении мастера к слейву), а мастер допустим еще передает (к случаю если PDC слейва раньше примет байты). Если прерывание быстро обрабатывается (например PDC заново инициализируется в начале работы подпрограммы обработки прерывания, а частота тактовых импульсов SPI не превышает 1МГц), то получается мастер еще не окончил предыдущую передачу, а слейв уже новую начинает...

Примерно по тому же принципу если бы слейв был настроен на прием передачу 8 байт, а мастер на прием передачу 9 байт.

Изменено 27 мая, 2010 пользователем shrek

[aaarrr 69]

Возникла помеха SPI посчитал что это очердной тактовый импульс...

...и данные сместились на бит, а никак не на байт. А уж PDC тут вообще ни при чем.