caxapa.ru :: Так вот такую комбинацию и рассматриваю, только симметричную...пока слейв получает от мастера команду и ее параметры он ретранслирует каждый получаемый байт. Когда же настает его время передавать данные МАСТЕР ретранслирует каждый получаемый байт. В

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

Так вот такую комбинацию и рассматриваю, только симметричную...пока слейв получает от мастера команду и ее параметры он ретранслирует каждый получаемый байт. Когда же настает его время передавать данные МАСТЕР ретранслирует каждый получаемый байт. В конце передачи при совпадении всех байт слейв(мастер) отправляет флаг успешной/ неуспешной сессии.

Ответить

- А зачем слейву от мастера принимать собственные данные? Он же не сможет прервать передачу в случае ошибки, обменом-то мастер рулит. Это явно лишнее ИМХО. - 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)

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