SPI на 12 МГц через длинные провода Опции

[Kitsok]

Добрый день!

Любительским образом разрабатываю устройство ввода-вывода для строительства "картонных кабин" для авиасимуляторщиков.

Непосредственно устройства ввода (кнопки, тумблеры, энкодеры) и вывода (светодиоды, 7-сегментные индикаторы) подключаются к сдвиговым регистрам ('165 и '595), регистры каскадированы и подключены к контроллеру, к SPI-порту через преобразователь уровней 3.3<->5 ADG3304 и инвертор '04 (нужен для инвертирования CS для '165.
Частота SPI выбрана равной 12 МГц из соображений производительности контроллера, периода опроса энкодеров и т.д.

Имеется разведенная плата, на ней - ветка из 8 '165 и 8 '595. Дальше шина оканчивается разъемом RJ-45, где имеется 4 сигнала и 4 "земли". Предполагается подключать дальше цепочкой следующие платы с регистрами(модули), делая таким образом длинную цепочку из сдвиговых регистров.
Последовательных резисторов на сигнальных линиях , впрочем как и подтяжек не стоит.... При подключении оконечных устройств непосредственно к плате никаких проблем нет, все работает как и задумано.

Опыты показали, что если подключить к этому RJ-45 произвольной длины (от 5 сантиметоров до 2 метров) кабель, то вся работа шины останавливается. Осцилографом еще не смотрел, но предполагаю завалы фронтов и, возможно, звон. Я так предполагаю, что если уж кабель вызывает отказ работы шины, то никакими ухищирениями со стороны модуля ситуацию исправить не получится, и нужно переделывать схему и переразводить плату.

Как решение предполагаю установку подтягивающих к +5 резисторов, буфера типа '125 и проходных резисторов 20-50 ом. Аналогичную схему планирую также ставить на всех последующих модулях. Соединяться все это хозяйство будет неэкранированной витой парой CAT5, земля и сигналы будут перевиты.

Поскольку ни образования, ни опыта в высокочастотной электронике у меня нету, прощу помощь уважаемых знатоков - поможет ли затея с буфером и резисторами?

Заранее спасибо!

[rezident]

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

[alexander55]

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

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

[Kitsok]

Точно так.
Если автор темы защелкнет данные с 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]

Высокая тактовая частота вырисовывается из следующих соображений:
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. Он похож на С.

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

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

[Kitsok]

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

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

Если с FIFO, то лучше FPGA или местный uC. Т.е. распределенные контроллеры.
Рекомендую поизучать Verilog. Он похож на С.

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

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

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

[alexander55]

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

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

[Kitsok]

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

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

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