Аппаратный SPI slave atMega8 Опции

[_Anatoliy]

Коллеги, что то я в трёх соснах запутался - нигде в доках не нашёл как слейв должен реагировать на команду чтения(раньше в этом режиме не доводилось работать).
Я по приёму первого байта (команды) сразу записываю в SPDR байт для отправки, а на выходе MISO при записи следующего байта выползает первый байт сообщения(мой код команды).

Код

        data = getchar();
        BufferCom[index_buf_spi++] = data;
        if (index_buf_spi == 1) {
            switch(data)
                {
                case 0x55:
                    length_command = 7;
                    command = data;
                    SPDR = level_db;
                    crc8 = data;
                    break;    
                case 0xaa:
            ....................

Помогите хорошим советом,плз.

[aiwa]

Я по приёму первого байта (команды) сразу записываю в SPDR байт для отправки, а на выходе MISO при записи следующего байта выползает первый байт сообщения(мой код команды).

Все правильно: при записи в мастером в SPDR значения для посылки слейву, запускается механизм обмена и в результате которого из слейва передается записанное в SPDR ранее. По приему слейвом первого байта, в Вашем случае команды, первый байт из слейва уже пришел к мастеру - для передачи записанного байта для отправки нужна инициация обмена со стороны мастера.
Тут два пути: записывать в SPDR байт для отправки заранее, либо со стороны мастера инициировать обмены пока не прийдет ожидаемый пакет.

Имхо, лучше организовать обмен в стандартном режиме: маркер начала, длина данных, данные, контрольная сумма.
Тогда у Вас отпадает необходимость в синхронизации запросов/ответов слейва.
Мастер, отослав командный пакет, может некоторое время гнать незначащие байты, в надежде получить ответ.




Сообщение отредактировал aiwa - Aug 4 2018, 12:34

[_Anatoliy]

Тут два пути: записывать в SPDR байт для отправки заранее, либо со стороны мастера инициировать обмены пока не прийдет ожидаемый пакет.

1). Вот тут и непонятки. Хорошо если команда чтения всего одна,как в моём случае.Заранее ясно что отправлять. А если их несколько? И для каждой команды нужно отправлять свои данные. Ведь до получения команды нельзя угадать какие данные нужно отправить.
2). Либо я чего-то не понял, либо совет от лукавого - я такие методы не приемлю.

[Genadi Zawidowsk...]

В описании некоторых устройств (и даже не микропроцессорных - а разнообразные индикаторы) - встречается требование на dummy byte перед чтением данных - как раз случай, когда на интерпретацию команды требуется не полтакта. Так что нормально.

[aiwa]

2). Либо я чего-то не понял, либо совет от лукавого - я такие методы не приемлю.

Ничего от лукавого: на плате 162 мега была соединена по spi с основным контроллером и служила расширителем ком-портов.
И по такому алгоритму прогонялись буфера нескольких протоколов.

Грубо говоря, со стороны мастера spi можете представлять usart-ом, с оговоркой что для получения байта от RX нужно что-то загнать в TX:
если у Вас есть что отослать - отсылайте посылку, если нечего - шлите 0xFF, с целью анализа полученого от слейва.

1. Отсылаете буфер команды.
2. Шлете некоторое количество 0xFF для получения от слейва маркера начала.
3. При получении во время 1. или 2. маркера начала засылаете 0xFF пока не вытащите от слейва весь буфер,
если маркера не было. останавливаете обмен до следующей необходимости.

Да и еще одно предостережение - при значительной разнице в частотах мастера и слейва, нужно предусмотреть эту разницу, мне пришлось между буфером и SPDR использовать регистр.

Сообщение отредактировал aiwa - Aug 4 2018, 16:35

[_Anatoliy]

В описании некоторых устройств (и даже не микропроцессорных - а разнообразные индикаторы) - встречается требование на dummy byte перед чтением данных - как раз случай, когда на интерпретацию команды требуется не полтакта. Так что нормально.

Согласен, я тоже к такому выводу пришёл самостоятельно. А в качестве dummy проще всего применять первый байт принятого сообщения, в моём случае код команды.

[_Anatoliy]

Ничего от лукавого: на плате 162 мега была соединена по spi с основным контроллером и служила расширителем ком-портов.
И по такому алгоритму прогонялись буфера нескольких протоколов.

Грубо говоря, со стороны мастера spi можете представлять usart-ом, с оговоркой что для получения байта от RX нужно что-то загнать в TX:
если у Вас есть что отослать - отсылайте посылку, если нечего - шлите 0xFF, с целью анализа полученого от слейва.

1. Отсылаете буфер команды.
2. Шлете некоторое количество 0xFF для получения от слейва маркера начала.
3. При получении во время 1. или 2. маркера начала засылаете 0xFF пока не вытащите от слейва весь буфер,
если маркера не было. останавливаете обмен до следующей необходимости.

Да и еще одно предостережение - при значительной разнице в частотах мастера и слейва, нужно предусмотреть эту разницу, мне пришлось между буфером и SPDR использовать регистр.

Не, что то я не въехал... А зачем тут маркер? И куда он может исчезнуть?
У меня протокол простейший, это видно из рисунка. Команда возвращается в качестве dummy.

Эскизы прикрепленных изображений

 

[aiwa]

Не, что то я не въехал... А зачем тут маркер? И куда он может исчезнуть?

Не обращайте внимания. Похоже, что я исходя из первого поста сделал ложное предположение, что слейвом является Ваша программа, а не внешнее устройство.
Соответственно маркеры относились к такому варианту.