[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. Он похож на С.


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

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


Буду какой-нибудь стартер кит искать... Без железа как-то не изучается...



Буде выглядеть (очень хочется надеяться) вот так:
http://youtube.com/watch?v=YUMBEWBN0Pg

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

К огромному сожалению, в моем круге общения разработчиков электроники (не виртуальных, а реальных) нет совсем...

На всякий случай: Коллеги из Москвы, может у кого-нибудь завалялся ненужный более стартер-кит для каких-нибудь доставабельных несложных CPLD? :-)

Скажите, это в форуме по ПЛИСам.
Если бы в Питере, я Вам помог, а в Москве нет зацепок.

В общем-то, идея работает, но криво, поэтому появилась новая

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

Идея показала свою в целом состоятельность, если убрать подтверждения Такое ногодрыжество вполне сносно работает аж до 10 МГц, дальше не хватает производительности контроллера. Ну и на этих 10 МГц, естественно, все остальные задачи курят, т.е. МК занимается фактически только приемом данных.

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

Идея пока недообдумана, нужно рисовать

Велосипед не изобретаю?

хотел применить NCV7608 в каскаде несколько таких в пределах 30 метров, SPI до 5MHz,
но если проблема в приёме возникнет с ними, разрулить это на контроллере -проблеммно я смотрю, а делать на плис тактирование MISO- CLK_RET , это плис

Приятно почитать себя самого через 6 лет.

Докладываю:
Идея с CPLD был верной, задачка решилась, проект закрылся, зато еще один ребенок свет родился, пока эти годы прошли

Спасибо еще раз всем за помощь.

Чувствую себя тупым хвойным деревом "Дуб".
Простите меня, пожалуйста, что я так трудно дохожу.
Беру таймаут на подумать и порисовать.

На всякий случай, предпосылки такие:
1. Заранее не известна длина кабелей между модулями.
2. Заранее не известно количество каскадированных регистров. Есть максимальное количество, которое обусловлено размерами буферов в приложении в контроллере.

Похоже, самым простым способом понять будет попробовать 9-битную посылку.