caxapa.ru :: Если длина (количество байт) фрейма заранее не известна, то контролировать весь фрейм с помощью CRC несколько затруднительно. Если же длина заранее определена, то лучше CRC на весь фрейм. Или сделать такую комбинацию

rezident (12.03.2008 19:59, просмотров: 101) ответил Dany на SS(Slave select) присутствует, и с протоколами обмена с периферией немного знаком. Вопрос в том, контролировать весь фрейм(CRC16) или побайтно, или вообще не контролировать(как связь с переферией).Соотвественно если побайтно, то ввести повторную пос

Если длина (количество байт) фрейма заранее не известна, то контролировать весь фрейм с помощью CRC несколько затруднительно. Если же длина заранее определена, то лучше CRC на весь фрейм. Или сделать такую комбинацию пока слейв получает от мастера команду и ее параметры он ретранслирует каждый получаемый байт. Когда же настает его время передавать данные в этом фрейме он передает данные и в конце CRC для этих данных. Если в ретранслируемой команде или ее параметрах мастер получает несоответствие, то он заканчивает фрейм деактивацией CS/SS, а слейв у себя сбрасывает очередь запроса и очищает буфер.

Ответить

- Так вот такую комбинацию и рассматриваю, только симметричную...пока слейв получает от мастера команду и ее параметры он ретранслирует каждый получаемый байт. Когда же настает его время передавать данные МАСТЕР ретранслирует каждый получаемый байт. В 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)

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