[Yuranum 0]

Здравствуйте! Очень нужна помощь. Мне нужно реализовать обмен данными по

протоколу SPI между мастером и моим устройством на ATMega32 (slave). От

мастера идёт пакет данных 12 байт, мне нужно их принять и в ответ

выслать свой пакет 12 байт.

В связи с этим несколько вопрос:

Если в режиме slave флаг прерывания выставляется не по низкому SS, а по

окончанию сдвига 1 байта (если я правильно понял) ,то как понять какой

это байт по счёту пришёл? И какой соответственно слать мне.

 

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

пояснениями ,как реализовать данную передачу :)Пишу в CodeVisionAVR.

[GDI 0]

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

 

как понять какой

это байт по счёту пришёл?

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

[Yuranum 0]

Ну да, SPI это интерфейс.

Обмен стандартный через SPDR, т.е одновременная сдвиговая передача.

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

Спрашивайте какие ещё нужны данные, я уточню :)

[zombi 0]

Например, slave включиться на середине передачи. Или помеха на линии. И он будет считать 1й байт , например, как 3й, 2й как 4й и т.д. Бывает такое?

А что "мастер" об этом думает?

Мастер должен позаботиться о том чтобы небыло такого!

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

[Yuranum 0]

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

[zombi 0]

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

Так какой протокол?

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

Можно, конечно, попросить этого человека, чтобы прописал номер байта в сам байт.

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

 

[S.A.G 0]

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

[Yuranum 0]

Так какой протокол?

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

 

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

 

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

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

 

по моему надо замерить как нибудь и установить timeout приема данных от Master-а

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

[GDI 0]

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

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

[zombi 0]

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

Для номерации 24-х тетрад 4-х бит не хватит.

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

 

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

[vap 0]

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

 

Первый, потупее и не универсально, но меньше писанины: сигнал 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-ом. Причем протокол можно написать однажды и больше не трогать - там просто нечего менять.

[defunct 0]

Была у меня идея поставить счётик, но тогда нет никакой синхронизации по началу передачи получается.

Мастер инициирует передачу. Если вы пишете слейв, то просто обнуляйте счетчик байт по неактивному SS.

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

 

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

 

 

SPI_START, SPI_STOP, SPI_FILL, SPI_ESCAPE, SPI_ESCAPED_START, SPI_ESCAPED_STOP, SPI_ESCAPED_ESCAPE, SPI_ESCAPED_FILL.

Сильно много служебных символов не нужно. Достаточно FLAG / ESCAPE (стандартно это 0x7E / 0x7D).

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

[alexeyv 0]

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

 

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

 

Путей для изучения есть несколько:

1. Спросить автора протокола - самый правильный вариант

2. Поднять документацию на устройство, в случае недоступности автора - в нормальной конторе должа быть документация/описание на конторские/самостийные протоколы

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

 

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

- прерывание или опрос

- ожидание синхрослова (если он есть) или вычисление паузы между пакетами

- ответ на запрос в том же пакете или в отдельном

- и т.д. и т.п. - зависит от построения протокола

Изменено 31 января, 2011 пользователем alexeyv