at91sam7s spi, Помогите понять что происходит Опции

[en0t]

Здравствуйте, подскажите что к чему.
Есть есть задача связать 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]

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

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

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

[en0t]

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]

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

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

[en0t]

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

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

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

[aaarrr]

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

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

[en0t]

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

[shrek]

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

[strannyi]

Потери в PDC еще возникают из-за загруженности внутренней шины ARM-а
Замечал такое когда работа идет на высоких скоростях.

[aaarrr]

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

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

Потери в PDC еще возникают из-за загруженности внутренней шины ARM-а
Замечал такое когда работа идет на высоких скоростях.

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


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

[shrek]

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

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

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

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

Сообщение отредактировал shrek - May 21 2010, 11:15

[aaarrr]

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

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

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

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

[xelax]

Вообще, для понимания работы атмеловского SPI из SAM7 нужно:
1. Изучить даташит
2. Изучить аппноту для толкования неясностей даташита (а они есть)
3. Задать вопрос здесь, если не помогло

Я бы ещё один пункт добавил.
4. Изучить errata.

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

[shrek]

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

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

Сообщение отредактировал shrek - May 27 2010, 07:08

[aaarrr]

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

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

[shrek]

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

сместились все правильно. если это был последний тактовый импульс для данного байта, но не последний для пакета или последний какая разница помеха может возникнуть в любом месте пакета, то SPI генерит флаг что мол буфер полный этот байт идет в PDC. Данные сместились то есть как бы слейв посчитал что пакет например из 9 байт принял, а мастер еще передает. Судя из моих рассуждений по идее данные смещались бы на биты, но не на байты, признаю ошибку, но... На осцыле данные смещались строго на 1 - 2 байта!!! бывали случаи даже гуляли по пакету (правда в одну сторону левую, если смотреть на осциле).

Сообщение отредактировал shrek - May 27 2010, 15:20

[aaarrr]

На осцыле данные смещались строго на 1 - 2 байта!!!

Тогда причину нужно искать в программе.

[shrek]

Тогда причину нужно искать в программе.

До включения ШИМ все работает как часы, без ошибок длительное время. На сколько включал на столько и работал прибор до включения ШИМ. Даю команду включения ШИМ каналов по SPI. Вот собственно вся дурь после этого и начинается... Причем канал ШИМ работает на шинный усилитель, шинный усилитель работает на пару транзисторов Si2301 Si2302, эта пара работает на транзистор IRLIZ34, последний работает на индуктивную нагрузку (обмотка двигателя). Таких каналов 7. 4 канала работают на шаговый двигатель, 1 канал комутит двигатель постоянного тока. причем 4 канала (которые работают на ШД) расположены ближе к разьему с которого раздается питание. Как только грубо говоря включаю двигатель постоянного тока начинает лезть помеха но влияния особого не оказывает (иногда возникают ошибки примерно раз в 5 - 10 минут). Как только включаю ШД то тут все и начинается . Ошибки каждую секунду идут.

Сообщение отредактировал shrek - May 28 2010, 07:17

[romazan]

Всем привет.
У меня такая проблема, шлю данные в дисплей, он не запускается. Ладно. Начинаю вручную отлаживать - F11, данные начинают выходить и дисплей нормально запускается. Пробовал ставить задержки в секунду!!! Такая-же байда. У кого есть идеи?

Прикрепленные файлы

 Blinky.rar ( 137.79 килобайт ) Кол-во скачиваний: 27

 

[Сергей Борщ]

У кого есть идеи?

Я бы поменял местами дерганье RS и ожидание окончания передачи:

CODE

    while(!(SPI0->SPI_SR & AT91C_SPI_TDRE))
       ;
    if(cmd==1){
        PIOB->PIO_SODR = LCD_RS;
        }
    else{
        PIOB->PIO_CODR = LCD_RS;
        }

[romazan]

Вроде помогло, но глюков дофига! Баги! Баги! В ручном режиме данные идут нормально - как запускаю в автомат, начинается ппц. То может вместо постановки курсора в позицию (0:0) унести его куда угодно, то вместо 3 в порт идёт 1. Добавил функцию Image - выводин изображение из массива, так на экране какая-то какофония из пикселей.

CODE

static void image(void){
volatile word a;
LcdSend( 0x20, LCD_CMD, 0);
LcdSend( 0x40, LCD_CMD, 0);
LcdSend( 0x80, LCD_CMD, 0);
for(a=0;a<=614;a++)
{
LcdSend(ImageGraf[a], LCD_DAT, 0);
};
};

[aaarrr]

Для отслеживания окончания передачи следует опрашивать флаг TXEMPTY, а не TDRF. В противном случае RS будет переключаться когда попало.

[romazan]

Спасибо за советы. Заработало. Буду с дисплеем разбираться, почему-то медленно заливается, вроде скорость на максимум поставил, но он всё равно тупит.