Связь двух контроллеров по SPI. Опции

[Jenya7]

у меня есть драйвер на Mega168. мне понадобилось связать две платы вместе. из свободных имеющихся интерфейсов есть только SPI. думаю сделать Master-Slave. с мастером все понятно а как организовать слейв на SPI?

интересно такой пример будет работать со стороны слейва?

Код

ISR(SPI_vect)
{
    uint8_t command, reply;
    command = SPDR;   // Slave has received
    switch(command)
    {
        case 1: reply = 101; break;
        case 2: reply = 102; break;
        case 3: reply = 103; break;
    }
    SPDR = reply;     // Slave sends on next SPI          
}

Сообщение отредактировал Jenya7 - Mar 16 2016, 08:44

[Палыч]

с мастером все понятно а как организовать слейв на SPI?
интересно такой пример будет работать со стороны слейва?

Начну со второго вопроса: да, теоретически будет работать.

Теперь об организации ПО мастера и подчиненного устройства. Подозреваю, что с мастером Вам не все понятно, раз возникли вопросы с режимом slave. Например, в Вашем примере:
1) устройство-мастер передаёт по SPI первый байт (байт команды)
2) подчиненное устройство приняв по SPI байт через некоторое время запустит программу обработки прерывания от SPI;
3) программа обработки прерывания считает принятый байт с регистра, определит его значение и положит на регистр байт ответа; на всё это (шаг 2-3) потребуется время - Вы должны определит максимальное время на ответ подчиненного устройства, при этом учесть время работы других более приоритетных процедур обработки прерывания.
4) устройство-мастер выждав после передачи время, необходимое для гарантированной реакции подчиненного устройства на первый байт, производит считывание байта ответа.

[ILYAUL]

SS - в помощь

[Lerk]

И обратите внимание, что обрабатывать данные в прерывании - моветон. Обработчик прерывания должен срабатывать максимально быстро, вся обработка данных - в теле программы.

[Jenya7]

Начну со второго вопроса: да, теоретически будет работать.

Теперь об организации ПО мастера и подчиненного устройства. Подозреваю, что с мастером Вам не все понятно, раз возникли вопросы с режимом slave. Например, в Вашем примере:
1) устройство-мастер передаёт по SPI первый байт (байт команды)
2) подчиненное устройство приняв по SPI байт через некоторое время запустит программу обработки прерывания от SPI;
3) программа обработки прерывания считает принятый байт с регистра, определит его значение и положит на регистр байт ответа; на всё это (шаг 2-3) потребуется время - Вы должны определит максимальное время на ответ подчиненного устройства, при этом учесть время работы других более приоритетных процедур обработки прерывания.
4) устройство-мастер выждав после передачи время, необходимое для гарантированной реакции подчиненного устройства на первый байт, производит считывание байта ответа.

попробую. спасибо.

SS - в помощь

кстати да. а как слейв знает что выбрали его? реализовать какой нибудь пин интерапт?

И обратите внимание, что обрабатывать данные в прерывании - моветон. Обработчик прерывания должен срабатывать максимально быстро, вся обработка данных - в теле программы.

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

[Палыч]

SS - в помощь

IMHO, ждать помощи от SS в данном случае нецелесообразно. Его использование, конечно же, упростит ПО на мaster'е, но формирование этого сигнала на подчиненном устройстве программным способом - неосуществимо, аппаратным способом - слишком громозко...

[ILYAUL]

А зачем Slave формировать SS - это дело мастера

[Палыч]

это дело мастера

Нужно дать понять мастеру, что подчиненное устройство произвело операции необходимые для обмена, а до той поры приостановить обмен. Поскольку инициатором обмена по SPI всегда выступает мастер, то задействовать SS нужно именно мастера. В этом случае сигнал на SS мастера формирует, естественно, подчиненное устройство.

[Lerk]

Нужно дать понять мастеру, что подчиненное устройство произвело операции необходимые для обмена, а до той поры приостановить обмен. Поскольку инициатором обмена по SPI всегда выступает мастер, то задействовать SS нужно именно мастера. В этом случае сигнал на SS мастера формирует, естественно, подчиненное устройство.

Зачем называть сигнал о готовности ведомого - SS? Назовите его, например, DR - data ready, и никто не будет путаться о чем, собственно, идет речь.

[ILYAUL]

Нужно дать понять мастеру, что подчиненное устройство произвело операции необходимые для обмена, а до той поры приостановить обмен. Поскольку инициатором обмена по SPI всегда выступает мастер, то задействовать SS нужно именно мастера. В этом случае сигнал на SS мастера формирует, естественно, подчиненное устройство.

MISO - нет овета (нуного) не принял.(Повтор) Есть принял. Кстати пока мастер обрабатывает ответ , Slave успеет "спрятать" данные

[Палыч]

Зачем называть сигнал о готовности ведомого - SS?

Так сигнал обозначен в документации от производителя МК: сигнал о готовности ведомого устройства заводится на SPI, работающего в режиме master, на ту из ног, которая обозначается SS.

MISO - нет овета (нуного) не принял.(Повтор) Есть принял.

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

[ILYAUL]

SPI - Это дуплекс , если Slave положил правильный ответ в SDR , то мастер его получит - даже если не захочет

[501-q]

Приветствую!

Так сигнал обозначен в документации от производителя МК: сигнал о готовности ведомого устройства заводится на SPI, работающего в режиме master, на ту из ног, которая обозначается SS.

Ну зачем же так?!

Обычно активный сигнал SS на входе мастера переводит его узел SPI в режим ведомого (Master становится Slave'ом). SS -- это сокращение от Slave Select.

Сигнал о готовности ведомого устройства в шине SPI отсутствует, его нужно отдельно выдумывать. Я делал подтягиванием различных линий к определённым уровням (подойдут SCK, MOSI): мастер настраивает эти линии на вход без подтяжки, а слейв -- с подтяжкой. После включения SPI мастером у слейва эти линии остаются входами.

Но выделение отдельной сигнальной линии -- правильнее.

Илья

Сообщение отредактировал 501-q - Mar 17 2016, 04:58

[Палыч]

SPI - Это дуплекс , если Slave положил правильный ответ в SDR , то мастер его получит - даже если не захочет

Ключевое слово в Вашем утверждении - "если". Если подчиненное устройство успело положить правильный ответ до того, как мастер начал процесс обмена, то - да, мастер получит его. Но, если не успел, то и не получит.
Я и говорю: мастер должен предусмотреть достаточную задержку между своей посылкой и приемом ответа для того, чтобы подчиненное устройство гарантированно успело положить ответную информацию.

Обычно активный сигнал SS на входе мастера переводит его узел SPI в режим ведомого ...

В AVR активный сигнал на входе SS (на ноге SS, настроенной как ввод) разрешает работу сдвигового регистра SPI. И не важно в каком режиме работает SPI - master или slave. Для мастера низкий (активный) сигнал на входе SS фактически означает готовность подчиненного устройства. Этот сигнал теоретически можно было бы использовать при обмене между двумя МК, если бы в AVR была бы некая аппаратная реализация готовности подчиненного устройства, поскольку мастеру необходимо дождаться неких действий подчиненного устройства при передаче ответа. Наличие сигнала готовности подчиненного упростило бы ПО мастера. Поскольку готовность подчиненного устройства аппаратно не поддерживается в AVR, то мастер либо должен сделать необходимой длины паузу при приёме ответа, либо (что я считаю нерациональным) получить информацию о готовности подчиненного другим путем.

[ILYAUL]

Ключевое слово в Вашем утверждении - "если".

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

[Палыч]

элементарный повтор - сие таже задержка .

Если обмен между МК также примитивен, как и в примере ТС, то соглашусь: можно применить и повтор.

[Lerk]

В AVR активный сигнал на входе SS (на ноге SS, настроенной как ввод) разрешает работу сдвигового регистра SPI. И не важно в каком режиме работает SPI - master или slave. Для мастера низкий (активный) сигнал на входе SS фактически означает готовность подчиненного устройства.

1. Сигналом SS управляет мастер.
2. Если сигналом SS управляет не мастер, см. п.1.

19.3.2 Master Mode
When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the
direction of the SS pin.
If SS is configured as an output, the pin is a general output pin which does not affect the SPI
system. Typically, the pin will be driving the SS pin of the SPI Slave.
If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin
is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin
defined as an input, the SPI system interprets this as another master selecting the SPI as a
slave and starting to send data to it. To avoid bus contention, the SPI system takes the following
actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of
the SPI becoming a Slave, the MOSI and SCK pins become inputs.
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is
set, the interrupt routine will be executed.
Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility
that SS is driven low, the interrupt should always check that the MSTR bit is still set. If the
MSTR bit has been cleared by a slave select, it must be set by the user to re-enable SPI Master
mode.

[Палыч]

Под термином "мастер" понимается МК, SPI которого работает в "master mode".
Поэтому утверждение

Сигналом SS управляет мастер.

как говорит один мой коллега: "Всего лишь Ваша неправильная точка зрения".

[Lerk]

Под термином "мастер" понимается МК, SPI которого работает в "master mode".
Поэтому утверждениекак говорит один мой коллега: "Всего лишь Ваша неправильная точка зрения".

Какая прелесть, что она совпадает со мнением ребят из AVR.

[Gorby]

Сигнал о готовности ведомого устройства в шине SPI отсутствует, его нужно отдельно выдумывать.
Я делал подтягиванием различных линий к определённым уровням (подойдут SCK, MOSI): мастер настраивает
эти линии на вход без подтяжки, а слейв -- с подтяжкой. После включения SPI мастером у слейва эти линии остаются входами.

Но выделение отдельной сигнальной линии -- правильнее.

Илья

Бред сивой свинячьей кобылособаки! (с)

Включите мозг, товарищи! Если слейв не готов отдать данные сразу (в следующем слове за командой на чтение), то поезд ушел. Всё. Навсегда.
Вычитается при следующей команде чтения. А вот грамотный разработчик вводит в систему команд "чтение статуса".
И если есть команды долгоиграющие (стирание флеша например), то как раз чтением статуса и дожидаются конца операции.
Ну еще можно бит Ready и тд. И никаких манипуляций SS со стороны слейва! У вас уже есть прекрасный механизм передачи
данных - не надо его портить. Это ж надо додуматься!

[501-q]

Включите мозг, товарищи! Если слейв не готов отдать данные сразу (в следующем слове за командой на чтение), то поезд ушел. Всё. Навсегда.

[CENSORED]
"Сразу" -- это когда? На следующем такте SCK? Через 10 мкс? Через 10 мс? Через 10 секунд? Ага, "сразу" -- точный инженерный термин.

Слейв может подготовить данные и сообщить об этом мастеру. Поезд подождёт, пока ему разрешат ехать дальше.

Вычитается при следующей команде чтения. А вот грамотный разработчик вводит в систему команд "чтение статуса".

Грамотный разработчик сначала анализирует требования ко времени реакции слейва/системы и т.д.

Кстати, как реализовать команду "чтение статуса"? Или это единственная команда? Или всё же нужно сделать задержку/паузу на время подготовки слейвом ответа на команду мастера? И как эту задержку можно уменьшить (если нужно уменьшать)?

Илья

Сообщение отредактировал IgorKossak - Mar 21 2016, 08:51

[ILYAUL]

Кстати, как реализовать команду "чтение статуса"? Или это единственная команда?

Код

void Init (void) {
............
............

SPDR= "ОТВЕТ МАСТЕРУ";

}

void MAIN (void) }

while (1) {

  }
}

ISR (SPI_vect) {

SPDR= "ОТВЕТ МАСТЕРУ"; На будущее
}

[AI7]

4) устройство-мастер выждав после передачи время, необходимое для гарантированной реакции подчиненного устройства на первый байт, производит считывание байта ответа.

«Выжидать время, необходимое для гарантированной реакции подчиненного устройства» - наверно, нехорошо. Откуда вы знаете это гарантируемое время? Да и в процессе разработки программа в подчиненном МК может поменяться, поменяется и гарантируемое время. Каждый раз это отслеживать неудобно.
На мой взгляд, проще и удобней сделать так: мастер регулярно посылает стартовый байт и ждет, когда придет байт ответа. Раз пришел байт ответа, значит, периферийный МК закончил свои дела и переключился на обмен с мастером, можно начинать сеанс связи.