реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> SPI. Протокол обмена между Mater<>Slave, с подтверждением приёма от Slave.
PheeL
сообщение Feb 25 2013, 11:15
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 32
Регистрация: 24-11-07
Пользователь №: 32 633



Интересует, какие есть варианты протокола обмена по шине SPI, когда Master и Slave разные по производительности устройства, и необходимо на принятие пакета от мастер-устройства выдавать пакет подтверждения об успешном приёме(т.е. как минимум проверить crc пакета. иными словами, мастер тактирует шину, а слейв ещё не готов отдать ответ). А также вариант, когда слейв исполняет команду и должен сигнализировать мастеру о готовности передачи пакета с данными. Пока есть только вариант с дополнительной сигнальной линией индикации от слейва к мастеру. Есть ли програмный вариант протокола обмена по синхронным шинам для решения подобных проблем?
Go to the top of the page
 
+Quote Post
Слесарь
сообщение Feb 25 2013, 11:32
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 2 884
Регистрация: 7-11-09
Из: Ростовская обл.
Пользователь №: 53 484



Цитата(PheeL @ Feb 25 2013, 14:15) *
Интересует, какие есть варианты протокола обмена по шине SPI, когда Master и Slave разные по производительности устройства, и необходимо на принятие пакета от мастер-устройства выдавать пакет подтверждения об успешном приёме(т.е. как минимум проверить crc пакета. иными словами, мастер тактирует шину, а слейв ещё не готов отдать ответ). А также вариант, когда слейв исполняет команду и должен сигнализировать мастеру о готовности передачи пакета с данными. Пока есть только вариант с дополнительной сигнальной линией индикации от слейва к мастеру. Есть ли програмный вариант протокола обмена по синхронным шинам для решения подобных проблем?

Обычно ведомый сообщает ведущему о том что он готов получить новые данные по хардовому прерыванию и ведущий прерывается раз такое дело чтоб передать новые данные ведомому.
А программный протокол SPI делал когда не изучил еще модуль SPI контроллера, как сильно я тогда заблуждался, все давно реализовано в "железе".
Go to the top of the page
 
+Quote Post
igorle
сообщение Feb 25 2013, 12:18
Сообщение #3


Местный
***

Группа: Свой
Сообщений: 338
Регистрация: 14-07-12
Пользователь №: 72 753



Стандартных решений - два.
1) Чисто программное - чтение регистров из слэйва. Например один - для чтения crc последней команды записи. Другой регистр - статус. Передав команду, мастер сначала проверяет что команда прошла успешно (по crc), а потом начинает поллить (периодически считывать) регистр статуса

2) Если есть техническая возможность - используют еще одну дополнительную линию для получения прерывания по готовности

Обычно производители SPI устройств закладывают возможность обоих вариантов, а в дальнейшем пользователь смотрит - может ли он использовать прерывания, или нет.
Go to the top of the page
 
+Quote Post
Lagman
сообщение Feb 25 2013, 20:27
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 875
Регистрация: 28-10-05
Пользователь №: 10 245



AD7793 после конфигурирования на непрерывную выдачу результата сигнализирует о новом значении выдавая импульс (The DOUT/RDY falling edge can be used as an interrupt to a processor, indicating that valid data is available)на MISO.
Go to the top of the page
 
+Quote Post
SBE
сообщение Feb 25 2013, 20:57
Сообщение #5


Частый гость
**

Группа: Участник
Сообщений: 108
Регистрация: 8-09-05
Пользователь №: 8 384



Похожая проблема у меня возникала при соединении двух МК через SPI. В отличие от аппаратных slave устройств, на которые ориентирован SPI, ведомый МК может быть не готов к обмену, может не иметь жесткого тайминга по обработке пакета или команды и т.д.
Наиболее изящным решением стало использование выдающего команды хоста как SPI-slave, с дополнительной линий запроса на обмен вместо дополнительной линии индикации готовности. Тогда ведомый МК, будучи SPI master, может притормозить обмен под свою скорость обработки команды.

Go to the top of the page
 
+Quote Post
PheeL
сообщение Feb 26 2013, 08:33
Сообщение #6


Участник
*

Группа: Участник
Сообщений: 32
Регистрация: 24-11-07
Пользователь №: 32 633



Спасибо. В принципе я услышал всё, что хотел по данному вопросу. Подводя итог можно выделить два основных пути решения проблемы:
1) Дополнительная сигнальная линия с вариантами использования как индикации готовности от слева мастеру, так и в интвертном режиме, когда хост является слейвом. А-ля RTS/CTS/DTR/DSR. Предположительно заведён на аппаратное прерывания хост устройства. Лучший вариант если есть такая аппаратная возможность.
2) Поллинг мастером слейва. Мастер периодически либо постоянно выставляет запрос на данные от слейва тактируя шину в ожидании сигнального байта/пакета готовности обмена. Чисто программный вариант. Степень загрузки основного ядра контроллера мастер устройства при обмене зависит от настроек периферии, а также от наличия аппаратных возможностей для разгрузки основного ядра хост устройства(SPI+DMA+IRQ).
Go to the top of the page
 
+Quote Post
igorle
сообщение Feb 26 2013, 09:51
Сообщение #7


Местный
***

Группа: Свой
Сообщений: 338
Регистрация: 14-07-12
Пользователь №: 72 753



Все правильно. Из личного опыты - если программистов не принуждать, то они норовят имплементировать только поллинг. Даже если линия интераптов разведенеа. Им так проще.
Go to the top of the page
 
+Quote Post
vladimir_orl
сообщение Jul 12 2013, 04:25
Сообщение #8


Частый гость
**

Группа: Участник
Сообщений: 191
Регистрация: 18-09-12
Из: Орёл
Пользователь №: 73 591



Вот тоже по долгу службы занимаюсь этим вопросом. Вот что узнал.

В конце посылки из 8 бит мастер переводит линию LCLK в 3 состояние для того чтобы слэйв со своей стороны сигнализировал об ошибках поднятием этой линии в 1. Так что переход в 1 после перерыва - это просто мастер снова выставил 1 на тактовой линии.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 28th July 2025 - 00:47
Рейтинг@Mail.ru


Страница сгенерированна за 0.01399 секунд с 7
ELECTRONIX ©2004-2016