Пакетная синхронизация в SPI

[alberio]

Сижу-никак не соображу.
Есть две аврки, между собой соеденины по SPI. Одна постоянно мастер, другая - слэйв.

Мастер кидает пакет, в ответ на который слэйв выполняет нужные действия. Пакет в формате [ключевой символ (назначение пакета)][данные][CRC].

Принимает-то он принимает, но где начало пакета, а где конец - не знает.

Пока вижу только один выход. Преобразовывать все в ascii символы, ну а там уже будет символ начала пакета и символ конца. Но это ресурсы - время и память - преобразование в ascii, в слэйве обратно.
Но ведь есть пакетная синхронизация - вывод слэйв селект. Только вот никакого события камень не генерит при изменении уровня. Да, SPI-то включается, но прерывания нет. Только по приходу байта. А ждать в цикле времени нет...

Есть у кого-нибудь соображения?

[kison]

Есть у кого-нибудь соображения?

Если АВР свежая, то есть PCINT - настраиваем на фронт у SS и будет прерывание.
Если не свежая, то можно соединить SS с любым входом внешнего прерывания INTх, или даже на захват или компаратор. Правда одним выводом придется пожертвовать.

[niXto]

отследить конец пакета - поставить небольшую задержку (десяток циклов) после приема байта и программно отслеживая уровень на СС. Следовательно следующий байт - начало нового пакета

[Easyrider83]

Запускать таймер по приходу первого такта. По переполнению таймера заканчивать прием. Если принят весь пакет, останавливать таймер.

[baiderin]

А если пакеты разной длины?
Проще, если есть гарантированная пауза между пакетами.

[Easyrider83]

Ну тогда ключевой символ должен обнулять приемный массив, куда данные сваливаются. Я обычно такое на прерывании делаю. Пришел байт, сваливаем его в массив. Если байт начальный, обнуляем массив. Если длинна массива = длинне вашей передачи, ждать CRC, сравнить CRC, если верно, выставить флаг готово. Примерно так.

[nml]

.
Принимает-то он принимает, но где начало пакета, а где конец - не знает.

Вы же говорили, что у вас есть маркер начала пакета. В принципе, более ничего и не надо (SS - тоже надо время от времени делать, но это борьба с помехой - например, лишним или пропавшим стробом).

А так логика проста. Прерывание приема байта по SPI - там есть режим приема. То есть - ждем маркер, принимаем данные, конец - прием контрсуммы. За маркером может еще идти инфо о длине и назначении данных.

Если в режиме "ждем маркер" принят не маркер - просто ничего не делать.

Я как-то так делал двусторонний обмен между двумя МК (так получилось, что пришлось по SPI - хотя понятно, что это "через зад"). Я сделал так - мастер всегда передавал. Если ему сказать слэйву было нечего - передавал нули. Зато слэйв мог все время передавать и мастеру.

И протокол был такой (с обоих сторон) - 0 - ничего не делаем, ждем маркер. Принят маркер - следующий - идентификатор, котрый дает инфо - сколько байт и куда покласть после проверки КС. Принят идентификатор - знаем, сколько байт информации принять в буфер. Принято все - принимаем последний, контрсумму, проверяем, и если Ок - кладем на место и флаг.

Хотел сделать еще - если ошибка в КС, то дернуть SS, но МК были рядом и помех просто не наблюдалось, потому так и не реализовал

Ну а то что 99% времени туда-сюда гонялись нули - так это МК не особо-то нагружало, вошел в прерывание - нуль - самому сказать нечего - нуль - и выход. Пару десятков тактов

[alberio]

Ну тогда ключевой символ должен обнулять приемный массив, куда данные сваливаются. Я обычно такое на прерывании делаю. Пришел байт, сваливаем его в массив. Если байт начальный, обнуляем массив. Если длинна массива = длинне вашей передачи, ждать CRC, сравнить CRC, если верно, выставить флаг готово. Примерно так.

Так, примерно, я сейчас и делаю... Хотелось просто поавтоматизированей