Shura (17.07.2008 17:44, просмотров: 112) ответил rezident на Дык слейв без SS в AtMega и не работает вроде. Кроме того, а как без slave select в SPI вообще можно обеспечить фреймовую синхронизацию-то?-
- Какими преамбулами/таймаутами? Ты синхронный интерфейс с асинхронным путаешь. Пройдет один-единственный сбой по 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)