Связь mega8 -> t2313 по SPI, работать работает, но в чем же соль Опции

[amost]

здравствуйте.

пришлось связать два камня по SPI. передача данных в одну сторону Mega8 (master) --> tiny2313. инициализацию мастера и слейва сделал по ДШ.

mega8:

Код

void SPIinit(void)
{
    DDRB |= (1<<PIN_SPI_MOSI) | (1<<PIN_SPI_SCK) | (1<<PIN_SPI_SS);
    SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);
}

t2313:

Код

void USIinit(void)
{
    DDRB = (1<<USI_PIN_DO);
    PORTB |=  (1<<USI_PIN_DI) | (1<<USI_PIN_SCK);
    USICR = (1<<USIOIE) | (1<<USIWM0) | (1<<USICS1);            
}

отправляю байт

Код

void SPI_send_byte(char data)
{
    SPDR = data;
    while( !(SPSR & (1<<SPIF)) )
    ;
}

принимаю на тиньке

Код

ISR (USI_OVERFLOW_vect)
{
    USISR |= (1<<USIOIF);

    usi_in_buf[gBuf_ind_in] = USIDR;
    gBuf_ind_in++;
}

после получения каждого нового символа передаю его слэйвом по UART.

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

Код

    SPI_send_byte('b');
    _delay_loop_1(48);
    SPI_send_byte('a');
    _delay_loop_1(48);
    SPI_send_byte('d');
    _delay_loop_1(48);
    SPI_send_byte(' ');

-- слэйв принимает нормально. да, если нужно то mega запущена на 16МГц, tiny2313 -- 8МГц. клок на SPI на мастере делится на 16. если делить на 128 то нормально принимает при значении задержки между символами приблизительно 3мкс (начинает принимать нормально при _delay_loop_1(15)).

изначально, было две версии:
1. передача очередного байта начинается до завершения передачи предыдущего. думаю этот вариант исключается поллингом флага SPIF, и флага WCOL. (?)
2. тинька не успевает обрабатывать поток данных. этот вариант тоже вроде как исключил -- понизил частоту клока, сократил до минимума обработчик прерывания. пробовал даже после 4-5 принятых в ОЗУ символов запрещать прерывания на слэйве и спокойненько выдавать буфер в UART.

теоретически, могу оставить задержки между символами. но хочется же знать в чем соль. хотя бы на чьей стороне? мастер/слэйв?

да, мой первый проэкт именно на C. могу чего-то не знать.

[amost]

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

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

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

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

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

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

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

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

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

[SasaVitebsk]

с этой позиции я и читал ДШ, где в упор не увидел и слова о необходимости синхронизации каждого байта по линии 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, использовать битстаффинг и выделять информацию прямо из битового потока.