[alexander55 0]

Вот я не могу понять, почему сигнал приходит и уходит? Когда до n-го бита доходит переключение CLK, он вдвигается в соседний триггер, а не в Master. А Master тактируется локально, а не отраженным от конца линии (????? а если там терминатор?) сигналом.

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

[Kitsok 0]

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

 

Не встает :)

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

 

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

[rezident 0]

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

SPI-master........Slave1..............Slave2...............Slave3...................
......SlaveN

CLK----->delay1---->|------>delay2------>|------>delay3------>|------->.......---->delayN----|
                                                                                             |
CLK_RET<-delay1<-----------delay2<---------------delay3<---------------........<-------------|
MOSI---->delay1->|prop|--->delay2---->|prop|---->delay3---->|prop|--->.......-->delayN->|prop|-|
                                                                                               |
MISO<----delay1<-----------delay2<--------------delay3<---------------........<-delayN<--------|

Пояснения.

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МГц (гарантированное значение по даташиту).

Естественно линия должны быть рассчитана и согласована на такую частоту.

[Сергей Борщ 143]

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

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

[alexander55 0]

Не встает :)

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

 

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

Еще раз скажу.

Чтобы сдвиг последующего регистра сдвига не происходил раньше предыдущего

выполняйте правила заведения CLK.

Я как мог объяснил. Неужели Вы в первый раз встречаете гонки фронтов ?

Иначе получите бред.

rezident тоже привел диаграммы.

Не спешите. Вот еще аналогия.

Труба с кранами, открывающимися на короткое время. М.б. не очень удачная аналогия, но как-то ...

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

[Kitsok 0]

Еще раз скажу.

Чтобы сдвиг последующего регистра сдвига не происходил раньше предыдущего

ВОТ!!!! ВОТ ОНО!!! ;)

 

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

 

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

[alexander55 0]

ВОТ!!!! ВОТ ОНО!!! ;)

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

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

[Kitsok 0]

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

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

Буду думать.

[Kitsok 0]

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

 

 

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

 

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

 

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

 

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

 

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

[rezident 0]

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

[Kitsok 0]

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

 

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

 

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

 

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

 

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

 

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

 

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

[alexander55 0]

Счетчик должен сбрасываться не сам по себе, а сигналом от мастера.

Точно так.

Если автор темы защелкнет данные с 595, то ладно.

А если данные не считаны, а уже сброс ?

У меня вопросы к автору темы:

- зачем потребовался 595 (разве uC недостаточно, в нем уже есть приемный сдвигатель)

- Вы считаете параллельный интерфейс предпочтительнее, чем последовательный :)

- зачем эта погоня за высокими тактовыми

- Вы думали насчет интерфейса типа SSP в LPC.

Для справки по LPC:

- это расширенный SPI, совместимый с Microwire, c TI и т.д.

- за счет FIFO uC возможнен обмен между мастером и слейвом до 128 <-> 128 бит без участия uC и без прерываний тоже (зарядили раз и сразу все -запустили-все считали за раз или постепенно).

Поставили бы плиску (CPLD хватит за глаза) и жили спокойно (минимальные размеры, универсальность, бегать с паяльниками и оциллогафами не надо, никаких переделок плат - все вопросы решаются перепрограммированием плиски). :)

Это мое мнение, я его Вам не навязываю.

[rezident 0]

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

Может Вы просто очередной "изобретатель" бегущей строки?

[Kitsok 0]

Точно так.

Если автор темы защелкнет данные с 595, то ладно.

А если данные не считаны, а уже сброс ?

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

 

У меня вопросы к автору темы:

- зачем потребовался 595 (разве uC недостаточно, в нем уже есть приемный сдвигатель)

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

- Вы считаете параллельный интерфейс предпочтительнее, чем последовательный :)

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

 

- зачем эта погоня за высокими тактовыми

Высокая тактовая частота вырисовывается из следующих соображений:

1. Длина выходной цепочки (макс.) - 4096 регистров.

2. Длина входной цепочки (макс.) - 2048 регистров.

3. Частота опроса входной цепочки должна быть 384 раза в секунду (исходя из максимальной скорости вращения энкодера, который может быть подключен к любому регистру в цепочке)

4. Поскольку клок у нас генерится SPI, то 384 раза в секунду должны также передаться 4096 байт

 

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

- Вы думали насчет интерфейса типа SSP в LPC.

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

 

Для справки по LPC:

- это расширенный SPI, совместимый с Microwire, c TI и т.д.

- за счет FIFO uC возможнен обмен между мастером и слейвом до 128 <-> 128 бит без участия uC и без прерываний тоже (зарядили раз и сразу все -запустили-все считали за раз или постепенно).

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

 

Поставили бы плиску (CPLD хватит за глаза) и жили спокойно (минимальные размеры, универсальность, бегать с паяльниками и оциллогафами не надо, никаких переделок плат - все вопросы решаются перепрограммированием плиски). :)

Это мое мнение, я его Вам не навязываю.

 

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

 

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

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

 

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

Может Вы просто очередной "изобретатель" бегущей строки?

 

Я выше описал, для чего нужны 12 МГц.

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

 

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

[alexander55 0]

Высокая тактовая частота вырисовывается из следующих соображений:

1. Длина выходной цепочки (макс.) - 4096 регистров.

2. Длина входной цепочки (макс.) - 2048 регистров.

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

 

3. Частота опроса входной цепочки должна быть 384 раза в секунду (исходя из максимальной скорости вращения энкодера, который может быть подключен к любому регистру в цепочке)

4. Поскольку клок у нас генерится SPI, то 384 раза в секунду должны также передаться 4096 байт

 

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

Мои предложения.

1.Разделите быстрые датчики и медленные.

Тогда Ваши требования снизятся на 1-2, а то и 3 порядка.

2. На быстрые датчики можно ставить свои контроллеры.

3. Выстройте систему блочно. Иначе процесс будет бесконечным. Чем больше сделаете, тем больше проблем и тем дальше от конца работ.

 

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

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

 

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

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

 

Проблема в том, что я не знаю, с чего начать двигаться в сторону CPLD

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

 

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

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