Для простоты считайте CLK входом черного ящика, а MISO выходом. И все станет на свои места.

Не встает
Потому что даже если это - черный ящик, то всегда есть ближайший к контроллеру регистр, который будет выдавать на MISO данные через незначительное (в буквальном смысле) время после фронта CLK.

Еще раз повторюсь, что моя схема представляет из себя условно говоря сдвиговый регистр длиною в 1024 (2048, 4096,...) байт, непосредственно подключенный к контроллеру. Внутри - да, там есть ощутимые задержки, но вот ближайший к контроллеру регистр работает практически синхронно с мастером.

Господа, вы уже начинаете поражать отсутствием воображения

Пояснения.
SPI-master это SPI-мастер
Slave1, Slave2, Slave3, SlaveN это сдвиговый регистр подключенный к SPI. Пускай для определенности это будет 74HC595. 74HC595 включены в цепочку MOSI последовательно, т.е. MOSI поступает на вход SER, а выходным сигналом является Q'h, который идет на вход SER следующего регистра.
CLK это выходной тактовый сигнал передатчика SPI-master
CLK_RET это входной тактовый сигнал приемника SPI-master
delay1, delay2, delay3, delayN это задержка распространения сигнала в линии
prop - это задержка выдачи выходного сигнала Slave относительно фронта тактового сигнала CLK. Для 74HC595 эта задержка не превышает 30нс.
Если слейвы находятся на одинаковом расстоянии друго от друга, а сигнал CLK проходит последовательно через них, то значение delay будет одинаковым. Причем одинаковым как для CLK, так и для MOSI. Для каждого последующего Slave входной сигнал данных будет отставать от CLK всего лишь на величину prop. Задержка же CLK накапливаться не будет!
Соответственно входной сигнал SPI-master CLK_RET будет иметь задержку относительно LCK на 2*N*delay. Но входной сигнал MISO будет иметь эту же самую задержку относительно CLK и задержку равную prop относительно CLK_RET.
В такой схеме максимальная тактовая частота ограничивается только максимальным временем задержки самого медленного из слейвов, но никак не длиной цепочки. Конечно же тактовая частота не может превышать максимальной тактовой частоты слейвов. В случае цепочки из нескольких 74HC595 ее можно тактировать частотой 30МГц (гарантированное значение по даташиту).
Естественно линия должны быть рассчитана и согласована на такую частоту.

Эти данные уже стоят на выходе регистра. А после заднего фронта (среза?) CLK, когда они меняются, есть время до следующего фронта, когда контроллер их будет забирать. А сдвиг во всех регистрах происходит одновременно, ибо они синхронные.

Еще раз скажу.
Чтобы сдвиг последующего регистра сдвига не происходил раньше предыдущего
выполняйте правила заведения CLK.
Я как мог объяснил. Неужели Вы в первый раз встречаете гонки фронтов ?
Иначе получите бред.
rezident тоже привел диаграммы.
Не спешите. Вот еще аналогия.
Труба с кранами, открывающимися на короткое время. М.б. не очень удачная аналогия, но как-то ...
Если Вы откроете вначале выходной вентиль, то между последним и предпоследним куском появится воздушная пробка.

[quote name='alexander55' date='Dec 3 2007, 10:36' post='332169']
Еще раз скажу.
Чтобы сдвиг последующего регистра сдвига не происходил раньше предыдущего
[/quote]
ВОТ!!!! ВОТ ОНО!!!
[/quote]

Я понял, спасибо всем большое

Общее правило - CLK должен распространяться в одном направлении с данными, и задерживаться на одинаковое время (т.е. если ставим буфер, то чрез него нужно прогонять не только CLK, но и данные тоже. Мастер должен синхронизировать MISO с CLK, прошедшим цепочку слейвов, это тоже понятно, и даже технически реализуемо, за идею с SSC спасибо

Количество перешло в качество.

Это так Только вот SSC на AT91SAM7S по пинам пересекается с АЦП, который занят (все 8 каналов)....
Буду думать.

Подумал и выдумал вот такую схему.



Наверху - сугубо тестовые компоненты, нужные для симуляции.

Внизу (инвертора, счетчик и регистр) - собственно такой синхронный приемник на рассыпухе.

Идея в том, чтобы по приходящему клоку получить данные в регистр, счетчиком передать внутри 595 биты из сдвигового регистра в защелки, одновременно с этим сгенерить короткий импульс, по которому скидывается счетчик (чтобы не особенно зависеть от контроллера) и вызывается быстрое прерывание в контроллере.

По прерыванию параллельно считывается D0-D7. Вот такая затея.

Прошу критиковать

Плохая схема. Счетчик должен сбрасываться не сам по себе, а сигналом от мастера. Т.н. фреймовая синхронизация нужна. Иначе любая помеха по CLK и синхронизм приема пропал. ХЗ чего после этого HC595 принимать будет.

Ну а смысл? Информация поступает неуправляемым образом, т.е. если я не успел обработать прерывание и взять байт, то я не успел.

Готов согласиться с тем, что необходимо от мастера разрешать или запрещать прохождение прерывания. Т.е., допустим, посылаю я 4 килобайта, а принимаю 2. Чтобы лишний раз не грузить прерываниями контроллер, ставится "И" на выход от счетчика и сигнал от контроллера. Перед началом передачи на выход этот дается 1, соответственно, после приема всех необходимых 2 килобайт, прямо в прерывании разрешающий сигнал скидывается.

Еще мне кажется разумным придумать ресет регистру и счетчику, чтобы перед началом передачи их скидывать в ноль.



Помеха по CLK может нарушить прохождение данных в любом месте цепочки '165ых, с этим ничего не поделаешь по-моему.

Насчет фреймовой синхронизации - ну тогда надо маркировать начало и конец цепочки '165ых, другого способа я не вижу...

Точно так.
Если автор темы защелкнет данные с 595, то ладно.
А если данные не считаны, а уже сброс ?
У меня вопросы к автору темы:
- зачем потребовался 595 (разве uC недостаточно, в нем уже есть приемный сдвигатель)
- Вы считаете параллельный интерфейс предпочтительнее, чем последовательный
- зачем эта погоня за высокими тактовыми
- Вы думали насчет интерфейса типа SSP в LPC.
Для справки по LPC:
- это расширенный SPI, совместимый с Microwire, c TI и т.д.
- за счет FIFO uC возможнен обмен между мастером и слейвом до 128 <-> 128 бит без участия uC и без прерываний тоже (зарядили раз и сразу все -запустили-все считали за раз или постепенно).
Поставили бы плиску (CPLD хватит за глаза) и жили спокойно (минимальные размеры, универсальность, бегать с паяльниками и оциллогафами не надо, никаких переделок плат - все вопросы решаются перепрограммированием плиски).
Это мое мнение, я его Вам не навязываю.

Kitsok, Вы до сих пор не описали, зачем вообще нужна такая скорость и подобный сериализатор/десериализатор? Или я где-то это пропустил?
Может Вы просто очередной "изобретатель" бегущей строки?

... то ничего не произойдет в течении следующих 8 циклов клока. Если же я не успел считать данные с 595 в течении этого времени, то данные безвозвратно потеряны, и ничего с этим сделать нельзя, поскольку даже если бы я управлял клоком цепи '165 (мог бы остановить его), все равно мнгновенно остановить клок я бы не успел, поскольку C != inf.


В нем есть аж 2 приемных сдвигателя - в SPI и в SSC. Приемник SPI не может синхронизироваться в мастер-режиме от приходящего клока, а пины SSC заняты под используемый АЦП.

Отнють. Я вообще предпочитаю PDC, но жизнь заставляет....


Высокая тактовая частота вырисовывается из следующих соображений:
1. Длина выходной цепочки (макс.) - 4096 регистров.
2. Длина входной цепочки (макс.) - 2048 регистров.
3. Частота опроса входной цепочки должна быть 384 раза в секунду (исходя из максимальной скорости вращения энкодера, который может быть подключен к любому регистру в цепочке)
4. Поскольку клок у нас генерится SPI, то 384 раза в секунду должны также передаться 4096 байт

Вот отсюда и 12 мегагерц.

Нет, в сторону LPC я вообще не думал, мне бы с SAM7S разобраться бы до конца.


Ну прямо скажем, возможности SAM7S в этом плане получше. Я вообще прерывания не использую. Зарядил ПДП на все 4 килобайта по передаче и 2 кб по приему - и курю бамбук, отдавая время другим задачам. Как пришли данные - так их обработал и дальше в путь.



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

Что касается CPLD, то да, мысль в этом направлении ходит. Идея в том, чтобы на CPLD сделать синхронный приемник с FIFO, с параллельным интерфейсом к uC.
Проблема в том, что я не знаю, с чего начать двигаться в сторону CPLD, и пока не очевидны преимущества CPLD перед рассыпухой, если не считать FIFO и конечную вероятность потери данных.



Я выше описал, для чего нужны 12 МГц.
Конечная цель всего устройства - это дешевый интерфейс ввода-вывода к компьютеру для использования в любительском авиационном симуляторе. Т.е. много кнопок-тумблеров-галетников-энкодеров-клавиатур-АЦП по вводу и светодиодов-индикаторов-реле-шаговых моторов-сельсин-приемников по выводу.

Сериализатор-десериализатор нужен для реализации синхронного приемника с параллельным вводом в контроллер. Штатных средств контроллера не хватает.

Глобально Вы задумали.


Мои предложения.
1.Разделите быстрые датчики и медленные.
Тогда Ваши требования снизятся на 1-2, а то и 3 порядка.
2. На быстрые датчики можно ставить свои контроллеры.
3. Выстройте систему блочно. Иначе процесс будет бесконечным. Чем больше сделаете, тем больше проблем и тем дальше от конца работ.


Да ладно Вам прибедняться. Мы все друг у друга учимся (чему-нибудь и как-нибудь).


Если с FIFO, то лучше FPGA или местный uC. Т.е. распределенные контроллеры.


Рекомендую поизучать Verilog. Он похож на С.


И как это будет выглядеть, когда все сигналы получите и отправите.