[Палыч 6]

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

-- слэйв принимает нормально.

Может я чего-то не доглядел в Вашей программе, но, имхо, у Вас проблемы со сбросом бита SPIF. При работе по прерываниям он сбрасывается автоматом при переходе по вектору. А вот, при работе по готовности - посмотрите внимательно в DS

[amost 0]

Ну, существует масса извращенных способов последовательной связи.

Если имеем битовый поток, клоки, то разбиение на байты или еще какие единицы - дело программы.

 

К примеру, самый простой способ - на меге (мастер) дергать SS (либо оно дергается автоматически), а на тиньке - это вход прерывания, по которому быстренько сбрасывается счетчик бит в SPI (это по спадающему фронту). Ну а по нарастающему - программе сообщается, что байт готов к употреблению.

 

А у автора топика такая система отсутствует как класс. Он надеется исключительно на авось. И "авось" зачастую работает. На то она и "авось". Это кому какая степень надежности устраивает. Может кто-то любит микропроцессоры, программа которых максимально похожа на человеческий разум - работает по настроению.

да нет, я не надеюсь на авось. Вы красиво критикуете надежность моей системы -- хорошо. я не мудренный опытом разработчик, я просто любитель, который делает для себя полные глюков "поделки". с этой позиции я и читал ДШ, где в упор не увидел и слова о необходимости синхронизации каждого байта по линии SS и сброса счетчика бит SPI. поймите, вопрос о выборе типа последовательной связи не стоит, это можно обойти.

 

Добавлю критики :)

И, к тому же, где входной индекс обнуляться будет?

Вообще-то это делается пресловутой очередью, поминаемой в форуме с завидным постоянством.

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

 

Может я чего-то не доглядел в Вашей программе, но, имхо, у Вас проблемы со сбросом бита SPIF. При работе по прерываниям он сбрасывается автоматом при переходе по вектору. А вот, при работе по готовности - посмотрите внимательно в DS

этот вариант я тоже рассматривал. в ДШ написано, что SPIF сбрасывается автоматически при первом чтении SPSR, т.е. он сбрасывается еще при выполнении поллинга. хотя, наверное, стоит попробовать сбрасывать самому.

 

спасибо всем за ответы. тема и правда бестолковая. можна закрывать.

[DpInRock 0]

с этой позиции я и читал ДШ, где в упор не увидел и слова о необходимости синхронизации каждого байта

Так это кому как. Если ВАМ надо, то разделяйте БИТЫ на нужные вам байты.

А я, к примеру, не собираюсь принимать байты, а использую данную периферию для детектирования некой заданной последовательности бит.

Мало ли для чего. А ДШ за вас думать не будет.

[SapegoAL 0]

с этой позиции я и читал ДШ, где в упор не увидел и слова о необходимости синхронизации каждого байта по линии SS и сброса счетчика бит SPI.

 

Открываем любой даташит. Я открыл, к примеру, даташит на atmega88. На странице 153 перед рисунком 67 читаем:

 

After each data packet, the Master will synchronize the Slave by pulling high the Slave Select,
SS, line.

 

О синхронизации каждого байта речи не идёт. Но если у вас нет более высокого уровня (деление на пакеты и контроль целостности), то как вы узнаете о том, что синхронизация сбилась? В этом случае проще осуществлять побайтную синхронизацию.

 

Из рисунка видно, что сам SPI одно из самых примитивных переферийных устройств. По сути, сдвиговый регистр. Совершенно очевидно, что при сбое по линии SCK (например проскочил помеховый дополнительный импульс по SCK), будет искажатся вся последующая информация. Из опыта применения сообщаю вам, что это действительно так и есть. При работе без сигнала SS приходится городить спец процедуру ресинхронизации между пакетами данных. Либо, как, по видимому применял DpInRock, использовать битстаффинг и выделять информацию прямо из битового потока.