caxapa.ru :: По аналогии с toggle-бит , можно и весь байт повторять,так как дуплекса все равно не будет, а 7 - ми битное общение не очень радует. Можно и CRC16. Про согласование скорости это обязательно. Мегабиты не нужны.

Dany (11.03.2008 21:47, просмотров: 95) ответил rezident на Логичнее всего выбрать такую скорость тактирования/передачи, чтобы slave заведомо успевал данные к конвейеру SPI подтаскивать.

По аналогии с toggle-бит , можно и весь байт повторять,так как дуплекса все равно не будет, а 7 - ми битное общение не очень радует. Можно и CRC16. Про согласование скорости это обязательно. Мегабиты не нужны.

Ответить

- Весь байт не получится повторять, если только вам не односторонняя передача нужна. - rezident(11.03.2008 21:49)
  - Передача двухсторонняя, но не дуплекс. Сперва мастер передает данные, а от слейва "мусор", который можно заменить на эхо. Затем наоборот слейв передает (мастер читает), от мастера "мусор",который можно заменить на эхо. - Dany(11.03.2008 21:56)
    - А как мастер тогда узнает, что ему ответ правильный гонят, а не повтор предыдущего байта или содержимое пустого буфера SPI? Раз уж SPI изначально "предрасположен" к фреймовой структуре, то нужно ее и поддерживать. - rezident(11.03.2008 21:59)
      - А про фреймы... Не встречал я никакого(наверное, плохо искал) контроля фрейма,считается что SPI внутриплатный и ошибок возникать не должно. SPI либо работает, либо не работает... - Dany(11.03.2008 22:06)
        
        SPI это синхронный интерфейс. У него нет начала и конца, как в I2C или асинхронных протоколах. Когда есть клок, происходит обмен данными. Откуда (от какого именно тактового импульса) отсчитывать начало байта? Это априори неизвестно. rezident(350 знак., 11.03.2008 23:41)
        
        SS(Slave select) присутствует, и с протоколами обмена с периферией немного знаком. Вопрос в том, контролировать весь фрейм(CRC16) или побайтно, или вообще не контролировать(как связь с переферией).Соотвественно если побайтно, то ввести повторную пос Dany(50 знак., 12.03.2008 08:47)
        
        Контролировать и повторно передавать весь фрейм не есть гуд на этом интерфейсе. С увеличением размера фрейма, а это логично на SPI, полезная скорость обмена резко упадет при обнаружении ошибок. blackbit(423 знак., 14.03.2008 02:36)
        
        Если длина (количество байт) фрейма заранее не известна, то контролировать весь фрейм с помощью CRC несколько затруднительно. Если же длина заранее определена, то лучше CRC на весь фрейм. Или сделать такую комбинацию rezident(387 знак., 12.03.2008 19:59)
        
        Так вот такую комбинацию и рассматриваю, только симметричную...пока слейв получает от мастера команду и ее параметры он ретранслирует каждый получаемый байт. Когда же настает его время передавать данные МАСТЕР ретранслирует каждый получаемый байт. В Dany(98 знак., 13.03.2008 21:04)
        
        А зачем слейву от мастера принимать собственные данные? Он же не сможет прервать передачу в случае ошибки, обменом-то мастер рулит. Это явно лишнее ИМХО. - rezident(13.03.2008 22:47)
        
        После данных он отправит байт успешного(все байты совпали) или неуспешного сеанса связи, по которому Мастер определит дальнейшие действия с данными. - Dany(13.03.2008 22:54)
        
        Еще раз. Контролем транзакции управляет мастер. Главная задача - обеспечить целостность/достоверность передачи данных при минимальных издержках. rezident(526 знак., 13.03.2008 23:48)
        
        Но я ничуть не против "симметрирования" обмена! Просто считаю это излишеством реализации. Если это упростит написание вам каких-то общих модулей и библиотек, то пускай будет так. - rezident(13.03.2008 23:20)
        
        Всем спасибо за обсуждение темы, особенно rezident. Остановлю свой выбор на: данные + CRC16, в обе стороны. - Dany(14.03.2008 16:45)
        
        Хорошо будет, если еще и о полученных результатах доложите. Ну там получившаяся скорость обмена, надежность протокола и обнаружения ошибок. Наверняка еще кому-нибудь пригодится. Теория теорией, а практика - критерий истины ;) - rezident(14.03.2008 20:02)
        
        Результаты получились следующие... Скорость обмена SCK = 62.5kHz(выше не требовалось). Master аппаратный, Slave программный. Надежность протокола сводится к надежности CRC16.Также введен сигнал готовности Slave к передаче данных(буфер для передачи Dany(409 знак., 25.03.2008 19:41)
        
        Как будут результаты, обязательно доложу :)Тут еще тонкость будет, SPI Slave программнный. На какую скорость рассчитывать даже не знаю:) - Dany(17.03.2008 12:20)
        
        Вот и решил убедится, делает ли кто контроль принятых/переданных данных. Или отлаживают связь по SPI и считают что ошибок не будет... - Dany(11.03.2008 22:18)
        
        Байтовая синхронизация выборкой и есть контроль фрейма. Мне казалось, без нее никто и не работает. - Vladimir Ljaschko(11.03.2008 23:29)
      - не очень понял вопроса... Суть такая, перед отправкой следующего проверять эхо на совпадение с предыдущем, если совпадение то дальше, иначе не удачная сессия. - Dany(11.03.2008 22:03)

Микроконтроллеры