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


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



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

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

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

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

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




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

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

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

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

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

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

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

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

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


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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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