Здравствуйте! Очень нужна помощь. Мне нужно реализовать обмен данными по
протоколу SPI между мастером и моим устройством на ATMega32 (slave). От
мастера идёт пакет данных 12 байт, мне нужно их принять и в ответ
выслать свой пакет 12 байт.
В связи с этим несколько вопрос:
Если в режиме slave флаг прерывания выставляется не по низкому SS, а по
окончанию сдвига 1 байта (если я правильно понял) ,то как понять какой
это байт по счёту пришёл? И какой соответственно слать мне.

Я бы был очень признателен ,если бы кто-нибудь привёл пример кода с
пояснениями ,как реализовать данную передачу Пишу в CodeVisionAVR.

Для начала, SPI - это интерфейс, а не протокол, а вот Ваши передачи по 12 байт - это уже некий протокол, но не называйте его SPI.

Ответ очевиден - посчитать байты в прерывании, т.е. вести некую переменную как счетчик байтов, после принятия 12 байт, его нжно обнулять. Не совсем понятно как Вам надо работать, у Вас сперва мастер передает 12 байт, а потом дает еще 96 имрульсов на SCK чтобы считать Ваш ответ или Вы должны отвечать байтом ответа на каждый принятый байт? Да и вообще, слишком мало данных Вы даете по Вашей задаче.

Ну да, SPI это интерфейс.
Обмен стандартный через SPDR, т.е одновременная сдвиговая передача.
Была у меня идея поставить счётик, но тогда нет никакой синхронизации по началу передачи получается. Что будет если по какой-либо причине собьётся счётчик? Например, slave включиться на середине передачи. Или помеха на линии. И он будет считать 1й байт , например, как 3й, 2й как 4й и т.д. Бывает такое?
Спрашивайте какие ещё нужны данные, я уточню

А что "мастер" об этом думает?
Мастер должен позаботиться о том чтобы небыло такого!
Если передается более 1-го байта тогда используется протокол для синхронизации и проверки целостности пакета.

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

Так какой протокол?
Просто последовательность 12-ти байт? - это отсутствие всякого протокола.

Это как? Оч. интересно.

Привет всем,Юран,по моему надо замерить как нибудь и установить timeout приема данных от Master-а,(это время между посылками),после сработки последнего сбросить счетчик байтов, и юзать // SPI interrupt service routine ,здесь и обработать и передавать всякую.....

Что вы подразумеваете под протоколом? Я просто не очень, видимо, в это разбираюсь. Под протоколом я подразумевал - какие биты в каком байте отвечают за то или иное состояние.
А по поводу номера...Ну если взять полубайт, это 16 комбинаций. Но эт всего лишь одна из моих бредовый идей, но почему нет


Ну как варивнт...можно над этим подумать.

А сигнал CS вас на каждый байт будет или на всё сообщение? Какова длина линии передачи и в каких условиях она будет работать, цех, лаборатория и т.п., где будет использоваться ваше устройство? Вообще то нормальные протоколы имеют признаки начала пакета, это может быть какой-то специальный символ или пауза в передаче, как в ModbusRTU, или, в вашем случае это может быть отдельный сигнал CS, тогда он должен переходить в "0" в начале пакета, и подниматься в "1" после передачи последнего 12го байта. Еще нормальные протоколы имеют контроль целостности пакета в виде какой-то контрольной суммы, передаваемой в конце пакета.

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

И вариант предложенный Stepan_L (анализировать временной интервал между пришедшими байтами) мне нравится.

Вижу два пути.

Первый, потупее и не универсально, но меньше писанины: сигнал Slave Select подать заодно на вход прерывания, и настроить это прерывание как "edge triggered, по спаду". В этом вспомогательном прерывании обнулять счетчик байт.
По приему очередного байта счетчик увеличивается, после приема последнего байта - сообщение отдается основной программе на обработку.

Второй путь, которым я пошел в своем последнем проекте: над SPI реализовать простейший двунаправленный пакетный протокол:
Ввести коды SPI_START, SPI_STOP, SPI_FILL, SPI_ESCAPE, SPI_ESCAPED_START, SPI_ESCAPED_STOP, SPI_ESCAPED_ESCAPE, SPI_ESCAPED_FILL. Сделать простейшую подготовку пакета к передаче: приписывание в начало байта SPI_START, в конец - байта SPI_STOP, в середине пакета байты SPI_START, SPI_STOP, SPI_FILL, SPI_ESCAPE заменяются на пару байт, первый из которых SPI_ESCAPE, а второй - SPI_ESCAPED_START, SPI_ESCAPED_STOP, SPI_ESCAPED_ESCAPE и SPI_ESCAPED_FILL соответственно. На приеме проводить обратное преобразование.

Мастер формирует такой пакет и отсылает slave-у. Тот на лету декодирует, отдает на обработку, после обработки формирует ответ и ставит на отсылку. После этого мастер периодически присылает блок байтов SPI_FILL (означающих, что пакет не идет), и в ответ ожидает рано или поздно увидеть пакеты от slave-а.

В итоге получается полноценный и довольно эффективный протокол связи между мастером и простым slave-ом. Причем протокол можно написать однажды и больше не трогать - там просто нечего менять.

Мастер инициирует передачу. Если вы пишете слейв, то просто обнуляйте счетчик байт по неактивному SS.
При активном SS ведите прием. Как только насчитаете ровно 12 байт - обрабатывайте их как того требует протокол - т.е. распарсить сообщение, выполнить какие-то действия если требуется, сформировать 12 байтный ответ, и поставить его в очередь на отправку. До тех пор пока 12-ти нет, либо уже насчитали больше 12 - ничего не делайте.

А для защиты от помех обычно применяют код защиты (контрольная сумма всех байт/слов или CRC).



Сильно много служебных символов не нужно. Достаточно FLAG / ESCAPE (стандартно это 0x7E / 0x7D).
Дальше поверх стаффинга пустить любой протокол, но рекомендую не изобретать велосипед, а просто взять формат HDLC кадра

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

Путей для изучения есть несколько:
1. Спросить автора протокола - самый правильный вариант
2. Поднять документацию на устройство, в случае недоступности автора - в нормальной конторе должа быть документация/описание на конторские/самостийные протоколы
3. Подключится осциллографом и изучать, изучать и еще раз изучать!!!! - это уж при недоступности п.п. 1 и 2.

А реализация протокола на Вашей стороне - это уже плод Вашего полета мысли, вариантов масса:
- прерывание или опрос
- ожидание синхрослова (если он есть) или вычисление паузы между пакетами
- ответ на запрос в том же пакете или в отдельном
- и т.д. и т.п. - зависит от построения протокола

Сообщение отредактировал alexeyv - Jan 31 2011, 05:41