Точка опоры (17.07.2008 16:13, просмотров: 112) ответил rezident на Ответ на сообщение cvv про SPI.1. Изо всех сил стараюсь не кормить троллей. 2. Продаю импортные ЭК - https://shop.fulcrum.ru/buy
-
- Другими словами: cvv(198 знак., 17.07.2008 17:47)
- ИМХО как один из вариантов VladimirYU(243 знак., 18.07.2008 08:18)
- ИМХО, близка к 100%. Особенно, если это - весь мэйн и есть. А что мешает писать в SPDR данные сразу по появлению флага SPIF ? Данные будут передаваться с задержкой (валидные на момент завершения предыдущего обмена), но верные. - Точка опоры(17.07.2008 18:04)
- Пока что я не решился изза неопределенность во времени его появления. тоесть я не хочу первым байтом стартовать считывание а вторым - собственно читать актуальное значение. - cvv(17.07.2008 18:13)
- если мучает задержка, то сделай второй байт -- пустым (нулевым), а отдавай реальные данные третьим. какие проблемы? - bialix_(18.07.2008 14:49)
- Посмотрите как реализован обмен в SPI EEPROM 25-й серии. Первый байт - код операции, затем пару байт адрес, затем уже данные. Причем при чтении EEPROM первые байты, полученные в ответ на передачу кода операции и адреса, мастером игнорируются. rezident(47 знак., 17.07.2008 19:11, ссылка)
- Пока что я не решился изза неопределенность во времени его появления. тоесть я не хочу первым байтом стартовать считывание а вторым - собственно читать актуальное значение. - cvv(17.07.2008 18:13)
- Тоесть между каждой передачей мастер держит SS в 1 а я на слейве проверяю PINB2? Хотя гонку это не устраняет. Или мож я воюю с ветряной мельницей и все будет и так без проблем работать? - cvv(17.07.2008 17:10)
- Пока !SS=1 всё сброшено, нет ни приёма ни передачи.When the SS pin is driven high, the SPI slave will immediately
reset the send and receive logic, and drop any partially received data in the Shift Register. - Точка опоры(17.07.2008 17:19)
- Мне кажется что мы говорим о разном. - cvv(17.07.2008 17:33)
- Пока !SS=1 всё сброшено, нет ни приёма ни передачи.When the SS pin is driven high, the SPI slave will immediately
reset the send and receive logic, and drop any partially received data in the Shift Register. - Точка опоры(17.07.2008 17:19)
- Дык слейв без SS в AtMega и не работает вроде. Кроме того, а как без slave select в SPI вообще можно обеспечить фреймовую синхронизацию-то? - rezident(17.07.2008 16:41)
- Так же как и в UART - преамбулами, таймаутами - Shura(17.07.2008 17:44)
- Какими преамбулами/таймаутами? Ты синхронный интерфейс с асинхронным путаешь. Пройдет один-единственный сбой по SCLK и амбец! Без сигнала фреймовой синхронизации ты уже не синхронизируешь обмен по SPI до тех пор, пока не будут rezident(102 знак., 17.07.2008 19:29)
- Схуйли это? Не получив внятного ответа за n мсек мастер останавливает обмен на m мсек. Не получив ни одного валидного запроса за x мсек слейв переинициализирует SPI. n<x<m Вот и вся недолга с таймаутом. С преамбулой примерно то же самое - Shura(17.07.2008 22:36)
- Это может и работает, но для случая постоянного обмена по SPI двух интеллектуальных устройств (МК) и наличии пакетного протокола верхнего уровня. Но я бы в таком случае лучше UART использовал :) - rezident(17.07.2008 22:57)
- SPI быстрее как минимум на порядок - Shura(18.07.2008 09:46)
- Дык таймаутами и ограниченной по времени реакцией слейва эта разница нивелируется. Какой смысл тактировать SPI частотой скажем 10МГц (передача 1 байта за 0,8мкс), если слейв успевает "обдумывать" команды в реальном времени (без буферизации) за rezident(415 знак., 18.07.2008 13:08)
- "Аппаратурой UART" никаких ты ошибок не нафиксируешь, если медленнее канал, то и обнаружение сбоя будет во столько же раз медленнее, чудес не бывает - Shura(18.07.2008 14:54)
- C чего бы это медленнее? О сбое в SPI я узнаю только через время отведенное для приема мин. пакета. А о неверно принятом символе в UART я узнаю сразу же после его приема, по ошибкам четности, бряка в линии, неправильного стопа. - rezident(18.07.2008 15:45)
- К тому же при нормальной реализации интерфейсов в МК(наличии буфера на 1 байт) время "выгребания" слейвом потока из буферов UART и SPI одинаково. Так что тактировать SPI на порядок более высокой частотой нет смысла. rezident(403 знак., 18.07.2008 15:55)
- Ну эти допущения с потолка взяты поэтому никакого практического смысла не имеют - Shura(18.07.2008 16:00)
- Да ладно, большинство ошибок не дают никаких флагов. Т.к. вылазят на пакете а не на байте - Shura(18.07.2008 15:47)
- Дык все равно получается, чем раньше обнаружишь ошибку, тем быстрее можно повторить передачу битого пакета. - rezident(18.07.2008 15:58)
- К тому же при нормальной реализации интерфейсов в МК(наличии буфера на 1 байт) время "выгребания" слейвом потока из буферов UART и SPI одинаково. Так что тактировать SPI на порядок более высокой частотой нет смысла. rezident(403 знак., 18.07.2008 15:55)
- C чего бы это медленнее? О сбое в SPI я узнаю только через время отведенное для приема мин. пакета. А о неверно принятом символе в UART я узнаю сразу же после его приема, по ошибкам четности, бряка в линии, неправильного стопа. - rezident(18.07.2008 15:45)
- "Аппаратурой UART" никаких ты ошибок не нафиксируешь, если медленнее канал, то и обнаружение сбоя будет во столько же раз медленнее, чудес не бывает - Shura(18.07.2008 14:54)
- Дык таймаутами и ограниченной по времени реакцией слейва эта разница нивелируется. Какой смысл тактировать SPI частотой скажем 10МГц (передача 1 байта за 0,8мкс), если слейв успевает "обдумывать" команды в реальном времени (без буферизации) за rezident(415 знак., 18.07.2008 13:08)
- SPI быстрее как минимум на порядок - Shura(18.07.2008 09:46)
- Это может и работает, но для случая постоянного обмена по SPI двух интеллектуальных устройств (МК) и наличии пакетного протокола верхнего уровня. Но я бы в таком случае лучше UART использовал :) - rezident(17.07.2008 22:57)
- Схуйли это? Не получив внятного ответа за n мсек мастер останавливает обмен на m мсек. Не получив ни одного валидного запроса за x мсек слейв переинициализирует SPI. n<x<m Вот и вся недолга с таймаутом. С преамбулой примерно то же самое - Shura(17.07.2008 22:36)
- Какими преамбулами/таймаутами? Ты синхронный интерфейс с асинхронным путаешь. Пройдет один-единственный сбой по SCLK и амбец! Без сигнала фреймовой синхронизации ты уже не синхронизируешь обмен по SPI до тех пор, пока не будут rezident(102 знак., 17.07.2008 19:29)
- Всё можно довести до крайности. Например - притянуть !SS к земле навечно. - Точка опоры(17.07.2008 16:54)
- Так же как и в UART - преамбулами, таймаутами - Shura(17.07.2008 17:44)
- Другими словами: cvv(198 знак., 17.07.2008 17:47)