[User1285 0]

А не хотите ли задействовать по 2 SPI у каждого процессора ? Т.е. один на приём, второй на передачу. И сразу всё просто, никаких мучений.

У контроллера все остальные выводы заняты другими функциями, потому из доступных для общей связи остается один SPI.

 

[vitan 2]

А вообще можете подсказать какие могут быть подводные камни в подобных решениях как у меня?

Да никаких особо не вижу, за исключением того, что результат от первого контроллера вернется в процессор значительно позже. Получается, что для контроллера в мастере нужно включить некий режим, при котором у него разрядность данных будет равна 25*<разрядность одного контроллера>, причем нужно еще указать, что поток состоит из 25 частей, и каждая попадет в разный слейв. Сомневаюсь, что такой режим там есть...

[MiklPolikov 0]

У контроллера все остальные выводы заняты другими функциями, потому из доступных для общей связи остается один SPI.

 

Что бы не гадать на кофейной гуще, правду ли я написал про гибель тактового сигнала, возьмите провод 50см, повесьте по его длинне несколько конденсаторов, имитирующих суммарную ёмкость входов 30 процессоров, подайте тактовый сигнал 12МГц, и посмотрите осциллографом, что получилось. Ставлю на то, что там будет чистая синусоида и биения.

[Plain 168]

Достаточно регулярных буферов на тактовый и выборку, а тактовый и выход хвоста вернуть второму (ведомому) модулю мастера одинаковыми линиями, и такой "колбасой" можно хоть экватор обогнуть на 1 ГГц.

 

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

[User1285 0]

Да никаких особо не вижу, за исключением того, что результат от первого контроллера вернется в процессор значительно позже. Получается, что для контроллера в мастере нужно включить некий режим, при котором у него разрядность данных будет равна 25*<разрядность одного контроллера>, причем нужно еще указать, что поток состоит из 25 частей, и каждая попадет в разный слейв. Сомневаюсь, что такой режим там есть...

такого режима там действительно нет, это все будет делаться программно.

 

 

Что бы не гадать на кофейной гуще, правду ли я написал про гибель тактового сигнала, возьмите провод 50см, повесьте по его длинне несколько конденсаторов, имитирующих суммарную ёмкость входов 30 процессоров, подайте тактовый сигнал 12МГц, и посмотрите осциллографом, что получилось. Ставлю на то, что там будет чистая синусоида и биения.

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

Вот подобные подводные камни меня и интересовали.

Надеюсь получиться с ними справиться используя дополнительные буферы.

 

 

Достаточно регулярных буферов на тактовый и выборку, а тактовый и выход хвоста вернуть второму (ведомому) модулю мастера одинаковыми линиями, и такой "колбасой" можно хоть экватор обогнуть на 1 ГГц.

А что имееться ввиду под "регулярным" буфером?

Я читал что именно так делать правильно, возвращать на другой SPI вместе с тактовой частотой, однако , к сожалению, у меня на мастере выделяется всего один SPI на всю цепочку контроллеров.

Есть ли какие-то методы чтобы засинхронизировать входные в мастер данные (MISO) с его исходящей тактовой частотой?

 

[Plain 168]

Тогда тяните все тактовые и данные "звездой", т.е. линиями с одинаковой задержкой.

[Maverick_ 15]

такого режима там действительно нет, это все будет делаться программно.

что за процессор будет собирать данные с 25-30 SPI ?

и на какой тактовой частоте он будет работать?

разрядность данных у SPI одинаковая?

 

в принципе я не видел процессора с таким количеством SPI - Вы будете делать SPI програмно, правильно понял Вашу фразу?

[User1285 0]

Тогда тяните все тактовые и данные "звездой", т.е. линиями с одинаковой задержкой.

Так данные идут цепочкой, как же я их сделаю звездой....

По поводу тактовых звездой я думал, но неудобно очень получается..

 

что за процессор будет собирать данные с 25-30 SPI ?

и на какой тактовой частоте он будет работать?

разрядность данных у SPI одинаковая?

 

в принципе я не видел процессора с таким количеством SPI - Вы будете делать SPI програмно, правильно понял Вашу фразу?

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

Разрядность данных у всех процессоров одинаковая.

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

 

[Lmx2315 2]

Так данные идут цепочкой, как же я их сделаю звездой....

По поводу тактовых звездой я думал, но неудобно очень получается..

 

..из-за чипселектов?

Оставьте его один на всех, а в формате передаваемого пакета по SPI предусмотрите софтовую адресацию. Там же можно реализовать как персональную передачу, так и "широковещательную".

Но это конечно будет работать только в одну сторону.

[User1285 0]

..из-за чипселектов?

Оставьте его один на всех, а в формате передаваемого пакета по SPI предусмотрите софтовую адресацию. Там же можно реализовать как персональную передачу, так и "широковещательную".

Но это конечно будет работать только в одну сторону.

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

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

[Xenia 35]

Почему бы не использовать дополнительные микросхемы-повторители (без инверсии) на два канала (SS и SCLK) при каждом МК? Логика такая: сигналы SS и SCLK от мастера тянутся до повторителя, находящегося возле слейва, после чего повторенные сигналы достаются данному слейву, а затем тянутся до следующего повторителя (при следующем слейве). Тогда и эффект задержки в цепи не будет мешать, какой бы длинной эта цепь ни была.

[User1285 0]

Почему бы не использовать дополнительные микросхемы-повторители (без инверсии) на два канала (CS и SLK) при каждом МК? Логика такая: сигналы CS и SLK от мастера тянутся до повторителся, находящиимся около слейва, после чего повторенные сигналы достаются данному слейву, а затем тянутся до следующего повторителя (при следующем слейве). Тогда и эффект задержки в цепи перестанет мешать, какой бы длинной эта цепь ни была.

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

Если я неправ, то поправьте меня пожалуйста.

 

[Xenia 35]

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

 

Для устойчивой работы SPI важно только то, чтобы не набегала задержка между SCLK и MOSI/MISO, поскольку именно SCLK синхронизирует оба последних. А поскольку в предлагаемом варианте длины проводников, соединяющих пары МК, одинаковы, то мы вправе полагать, что и задержку они дают одинаковую. А, стало быть, рассинхронизация в парах между SCLK и MOSI/MISO не возникнет, хотя суммарная задержка по цепи будет накапливаться.

 

Другое дело, что при замыкании в кольцо, возникнет проблема связи между мастером и последним звеном цепи, т.к. их сигналы SCLK могли сильно разойтись. Между тем, последняя проблема эффективно решается тем, что у мастера-МК (только у него одного!) должен быть второй экземпляр SPI, работающий в режиме Slave с концевым членом цепи.

[vitan 2]

А как насчет мультиплексоров? Судя по буферам внешние микросхемы можно ставить. Можно найти достаточно маленькие и с большим количеством каналов. Будете подключать нужный канал на время общения. А, если там можно вместо SPI взять I2C, то там вообще NXP делает кучу мультиплексоров, которые по этому же I2C и управляются. Если взять скоростные, то учитывая количество контроллеров, оно может и по скорости подойти.

[Maverick_ 15]

может стоит взять какую-то STM32 (для примера) c 6 SPI (аппартных) и на каждый аппратный SPI повесить по 4-5 слейвов

На мой взгляд так будет лучше...