Есть некий контроллер (ПО недоступно), который управляет 4 семисегментными индикаторами при прмощи 4 регистров 74НС164 - последовательный вход, параллельный выход, соединенных последовательно. Т.е. есть стробирующая последовательность и есть последовательность данных. Работа ведется на частоте 100 кГц. Задача - подключиться к данному контроллеру ATMEGой 32 на частоое 16 МГц и перехватывать данные для индикации и выводить их на ЖКИ.
Вопрос: возможно ли для данной цели применить SPI модуль в SLAVE режиме. Понятно, что SS в данном случае придется принудительно занулить. Но возможна ли правильная работа модуля SPI без управляемого мастером SS. В доке сказано, что мастер высоким уровнем SS указывает на окончание посылки. В ланном случае SS будет постоянно в 0.

А может возможно зацепиться SS от паралельной загрузки одного из этих регистров ?
Или если между посылками есть пауза то попробовать засинхриться по ней ...

Да, засинхронизироваться по паузе не только можно, но просто нет другого варианта, т.к. от регистров толку мало. Хочу понять, работа SS необходима, или можно его тупо подтянуть к массае?

Может проще UARTом в синхронном режиме?

1 SS на массу, а в прерывании по таймеру паузы нужно переинициализировать SPI.
2 завести SS от OCRxx может так быстрее получиться инициализацию делать.
или поставить резистор и если не понравиться то пользовать 1 вариант.

Интересно, а программное подключение PuP резистора к SS не приведет к инициализации SPI? Это было бы вааще красиво.

47-100 кОм ну не знаю, даже если сработает то рассчитывать на надежность такого варианта не хочется

Во-первых надо посмотреть откуда сигнал поступает. То есть как он формируется. Если не SPI, а програмно, то не уверен.

Во-вторых. Честно говоря я не понимаю зачем брится топором. Зачем притягивать за уши лишнюю хрень. Можно даже на АЦП повесить и отслеживать осциллограмму входного сигнала, но зачем!

При частоте импульсов 100кГц и тактовой частоте меги 16М можно паралельно заниматься синтезом голоса и проговаривать что она там выводит.

Возьмите самое простое решение. Импульсы строба подайте на Int0 и при входе в прерывание читайте сигнал данных. Правильно определите нужный фронт.

Во-первых надо посмотреть откуда сигнал поступает. То есть как он формируется. Если не SPI, а програмно, то не уверен.

Во-вторых. Честно говоря я не понимаю зачем брится топором. Зачем притягивать за уши лишнюю хрень. Можно даже на АЦП повесить и отслеживать осциллограмму входного сигнала, но зачем!

При частоте импульсов 100кГц и тактовой частоте меги 16М можно паралельно заниматься синтезом голоса и проговаривать что она там выводит.

Возьмите самое простое решение. Импульсы строба подайте на Int0 и при входе в прерывание читайте сигнал данных. Правильно определите нужный фронт.
[/quote]

К сожалению, это уже пройденный этап. При такой частоте, даже, если выбросить из программы все прочее, в там и работа всех 3 таймеров и задействованные остальные прерывания, (работает основная программа) Если писать на С, то по подсчетам, такая ф-я займет более 60 % ресурса. А это слишком много. Программа реально не успевает. Я пропускаю 20 -40 % импульсов. Вот так.

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

- не пишите на Си (простите если обидел, сам уже давно мечтаю на нем писать)

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

Поясняю. Есть уже готовое серийное устройство, в которое невозможно допаивать ничего. Есть всего несколько свободных ног (INT2 и полностью SPI, хотя, вру, его тоже придется разводить программно - эти ноги управляют ЖКИ). Есть также потребность завести на данное устройство новую информацию с прибора, с которым можнообщаться вышеописанным способом. Так, что стааить одновибраторы, или нагромождать что-либо невозможно. Нужно просто подключиться и снимать данные.

Не в обиду. Не надо грешить на зеркало,если рожа кривая.

На скорости 14 я отличаю импульсы 2мкс от 4мкс + 2 таймера +Usart с автоопределением частоты и управлением потоком + сама работа. На 16 тоже + 10 програмных фильтров (выделяю DTMF) и преобразую звук из одного стандарта в другой на лету.

В вашем случае:
1. Перепишите прерывание (о котором я писал) на ASM. Типа

push wpl
in wpl,pinx
....

2. Во всех остальных прерываниях поставьте первой командой
__enable_interrupt(); Если у Вас сохраняется в этих прерываниях слишком большой контекст, то тоже придётся переписать на ASM


Ну и третье, - а может есть другой подход чем следить за динамической индикацией. Один раз мне принесли прибор фирмы "Овен" СИ-8 (по моему). Задача та же. Вынести индикацию на несколько метров. Причём предлагали абсолютно аналогичное решение. А, в тоже время, сам прибор располагает интерфейсом rs485. Я к разработчикам письмо. Они мне доку плохинькую. Разбирался-разбирался - не получаю ответа. Ещё письмо с примером своей команды - они мне ответ с исправленным CRC. Оказ. не весь пакет считается. Подправил и всё гуд. Можно посмотреть не только текущую индикацию, а полное состояние.

Sergio66 Задача - подключиться к данному контроллеру ATMEGой 32 на частоое 16 МГц и перехватывать данные для индикации и выводить их на ЖКИ. Вопрос: возможно ли для данной цели применить SPI модуль в SLAVE режиме. Понятно, что SS в данном случае придется принудительно занулить. Но возможна ли правильная работа модуля SPI без управляемого мастером SS. В доке сказано, что мастер высоким уровнем SS указывает на окончание посылки. В данном случае SS будет постоянно в 0.

Ответ: возможно. После принятия восьми бит возникнет флаг приема SPIF, ну и соответствующее прерывание.

Если примените нижеприведенный код для обработки прерываний от ведомого SPI, то в буфере у вас все время будут последние 4 байта, принятые от вашего устройства, основной программе останется только читать их. Синхронизация будет автоматическая, если ваше устройство будет включаться позже, чем атмега16. Расходы по времени на прием одного байта ничтожные - порядка 16 тактов.

Код

           .dseg                ;
buffer:    .org   0x0100        ;
           .cseg                ;
spispy:    in     r10,SREG      ;
           in     r16,SPDR      ;
           st     x+,r16        ;
           andi   xl,0x03    ;
           out    SREG,r10      ;
           reti                 ;

К GM.
Это простая реализация очереди. Она может применятся где угодно. Пожалуйста приведите пример инициализации SPI в таком режиме. Я, к сожалению, такого не нашёл. Насколько я понял необходимо забивать адрес слэйва. Похоже я понял неправильно.

Адрес слейва не нужен(:-(. Это вы спутали с иис. Но сложного ничего нет. Инициализация приведена на с. 140 документа 2466м (на атмегу16). Для надежности можно еще сделать бит MSTR=0 в регистре SPCR, хотя это значение по умолчанию.

Я не понимаю, что такое "простая реализация очереди". У меня введен кольцевой буфер на 4 байта. Поскольку у автора топика четыре семисегментных индикатора (которые скорее всего работают в статике), то этого достаточно.

To Sergio66 Можно еще попробовать синхронизироваться с помощью SS. Подключите его к свободной ноге и коммутируйте время от времени с периодом кратным периоду одного бита. Так можно поймать начало передачи(:-). Из описания следует, что при переходе SS 0-1 содержимое приемника будет переписываться в буфер, невзирая на незавершенность.

Блин точно. Переклинило. В SPI вааще ничего нет, так ещё можно и фронт менять, если мне память не изменяет.

Фронт менять можно... Из того же документа: Serial Periferal Interfase -> SS Pin Functionality -> SPI Data Register: Page 141: Table 59. CPOL and CPHA Functionality... Есть четыре режима передачи по SPI: Mode 0 - Mode 3

2 Sergio66: Может быть проблема здесь?

Оно?

Да это оно и есть. Принимать посылки начал, Однако, есть еще некоторые неясности. Не все байты правильно принимаются. Например, при передаче последовательности 0x01020304 вааще ничего непринимается. Т.е. не возникают прерывания по завершению приема. Но уже живет!