Вы что не понимаете, SPI слейв генерит ответ всегда если нет CS. Какое параллельно?
Для случая кольца там не один лишний провод, а 150.

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

А вот вы, сами можете делать то, что предлагаете - по SPI.

Ок 127.

Во-первых, там аббревиатура SS (slave select), а не CS. Во-вторых, если SS=1, то слейв отключен от шины.

И главное, когда SS=0 (подключен к земле), то выход слейва определяется программистом (см. таблицу 69 на стр.165 документа DOC2464O), поэтому, естественно, если все выходы слейвов объединены, то их надо установить как инпут, чтобы не мешали друг другу. Учите матчасть.

Ну-ну, дерзайте.

2 defunct
А я вот, как раз бы поспорил с вот этим утверждением:
Но с другой, так сказать, стороны...
Допустим нам нужно обеспечить межпроцессорное взаимодействие между
AVR и каким-нить ARM. Как известно, накладные расходы на прерывания у ARM не очень
хороши, а в силу того что i2c интерфейс является "адресным", большинство производителей
не прикручивают к нему DMA (поправьте меня если я не прав)
И соответственно, при использовании i2c на больших скоростях и при большой загрузке, мы
рискуем сильно загрузить нашего "старшего" брата
Если же использовать для связи со старшими товарисчами интерфейсы которые там
поддержаны DMA(например 485), то это сильно упростит им жисть...


P.S. Ну, это типа мысли на тему "Первые шаги"

SS/CS сути не меняет. Я так и сказал - если не CS. что значит CS=0.
В параллельном включении вы предлагаете использовать общий CS.


ну-ну. особенно если слейв это какой-нибудь штатный eeprom, скажем AT25. Или MCU с неконтроллируемым SO выходом.


Тормозите что ли? Ну нельзя в разрыв
-> miso[chip0]mosi -> miso [chip1] mosi -> miso [chip2] mosi -> .... -> miso[chip150] ->mosi ->
включить тремя проводами, как не крути.
Зы, а ведь и включить то так нельзя
На сигналы посмотрите
Ну да ладно.

Я еще раз повторюсь - я бы не стал выбирать SPI для 150 устройств, я бы выбрал шину.
Так что "дерзать" придется вам.



Сравните количество прерываний в случае с I2C и в случае с SPI для системы допустим из 20 устройств, взаимодействующих между собой (мульти-мастер режим).
- I2C будет отсеивать все лишние обращения автоматически, и будет разрешать конфликты шины (когда 2 мастера одновременно что-то захотят передать.
- SPI же будет генерить прерывания на "любой байт" предназначенный этому устройству или не предназначенный, плюс придется еще вручную обслуживать коллизии на линии и организовывать переповторы. Допустим имеем кольцевое включение о котором тут заикнулся GM. Тогда чтобы передать сообщение от 1-го процессора 10-му, это сообщение должно быть принято и ретранслированной процессорами 2, 3, ... 9, которые находятся между 1-м и 10-м.

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

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

485 это конечно гут - та же шина, но со своими плюcами/минусами:
гибко +
дорого -
Очень сомневаюсь, что в рамках одного кропуса для межпроцессорного обмена кто-то пользует 485.

А если использовать мультиплексоры/демультиплексоры для связи с устройствами и регистры с последовательной загрузкой для управления ими и CS-ами? Тогда, получается, избегаем проблем со 150-ю устройствами на одной шине, и у МК и устройств используется стандартный SPI.

Ну, defunct, вы меня озадачили. По-моему, у вас каша в голове(:-)

Объясните ВНЯТНО, ЧТО нельзя включить тремя проводами и ПОЧЕМУ? На КАКИЕ сигналы надо посмотреть? Что вы в них углядели такого особенного, недоступного простым смертным?

Мда... И как они будут разбираться какое прерывание "первое", какое "второе" и главное - когда сдвигаются данные а когда ответы слейвов. Вот уж точно от безысходности такое городить. "Альтернатива - утки!". Уж если соединяем много учтройств, то мое решение было бы таким - если есть устройства которые умеют только I2C и все они находятся в пределах одной платы - I2C, если таких устройств нет или они разнесены - 485.

я насчет этого:


Включаем ->???[Проц0]MOSI -> ??? [Проц1] MOSI -> ???[Проц2] MOSI -> .... -> ???[ПроцN] MOSI ->
каждая "->" - это провод. (их количество не считая клока, будет равно количеству процессоров)
каждый "???" - это вопрос, к какому сигналу подключать? объясните плз.
Поидее надо бы к SI, но ведь вот незадачка SI с MO совмещен, а ведь надо как-то со сл. устройством связываться...
Получается идея с последовательным соединением накрылась хоть сколько проводов не бери... Или я что-то не понял?

Не поняли. Не обращайте внимания на название, смотрите на суть процесса. Представьте себе 8-битный сдвиговый регистр, выход этого регистра подключаете к входу второго сдвигового регистра, а его выход в свою очередь - ко входу третьего. Выход третьего подключаете к входу первого, получится кольцо. Клоки подключаете параллельно ко всем трём регистрам. Вот вы получили примитивную модель того, что находится внутри периферии SPI каждого МК. За сим, с богом, вперед!


Ну поставьте в прерывании счётчик, когда счётчик=1, принимаете данные, обнуляете счетчик и выставляете ответ, какая тут безысходность? Какие утки:-)?

Не нравится так, дёргайте общей для всех слейвов ногой SS, вот вам и начало "первого" прерывания будет.

Вообще вы меня удивили. Этак можно договориться до того, а как usart понимает, что передаётся 5-й бит, а не 6-й?

Расскажу про пример I2C-подобной реализации, который лежит у меня на столе. Работает на скорости 5 мбод программно, на передачу посылается 37 бит, на приём передается 5 бит, затем принимается 16 бит. За 50 мкс я считаю преобразование Фурье на 1024 точки, в то же время на обмен(!) с устройством трачу 25 мкс. А мог бы гонять данные на скорости 25 мбод по аппаратной SPI с затратами 1 мкс. Сам виноват, не проконтролировал 4 года назад, теперь расхлёбываю.

2 устройства соединено?
и причем явно не AVR

А теперь понял. Т.е. вместо использования встроенного аппаратного SPI вы предлагаете замутить программный либо внешний на доп. сдвиговых регистрах. И соединить все 150 узлов 150-ю проводами. Тем самым вы планируете получить гибкость масштабирования и простоту реализации
Наши пути тут расходятся. Я не считаю ваш способ хоть сколько-нибудь гибким.

Ребята давайте не вводить в заблуждение друг друга. Теоретически я не вижу проблем ни в том ни в другом случае (SPI, I2C). Программные моменты - не в счёт. Это описывается один раз и всё. Если применяются стандартные устр-ва, то тут и вопросов не возникает, потому что протоколы стандартных устройств уже описаны и выше их не прыгнешь. Это не пример. Такой же пример - подключите по I2C стандартно 150 at24c512 или даже 127! Вот и весь разговор. Если говорить о проводах и быстрой коммутации (в кольце), то это тоже не проблема. Таких аппаратных решений за годы набралось - море. Вспомните к примеру корзину электроники 60 и как там были реализованы прерывания. Можно не сходя с места придумать кучу решений.

Но, если честно, то для подключения 150 и выше устройств я бы не стал использовать ни тот ни другой интерфейс. Конечно, смотря какие устройства. RS485 конечно предпочтительней, но и тут не всё гладко. Я вот сейчас планирую одно решение на 150-250 устройств. Так вот я посчитал и rs485 мне тоже не очень подходит. Надо что-то будет думать и создавать иерархию. Иначе по времени не справляюсь.

Так что чистая теория и практика - разные вещи. Как говорится "скажи мне какие устр-ва надо соединять, каков обмен планируется и я скажу какой интерфейс пользовать. Либо вообще разбить на несколько."
Не даром же их создавали. Все нужны. У всех свои плюсы и минусы. Для межпроцессорного обмена более практичен SPI. В текущем проекте я соединил м640 и м48 по I2C. И сэмулировал на ней 24с01. м48 работает на частоте 8мГц и постоянно спит. Так вот мне пришлось снизить частоту шины до 150кГц иначе м48 не успевала обрабатывать TWI в режиме слейва. А когда задумывалось, то планировалось сэкономить ноги, так как I2C шина уже использовалась в м640. Получилось за счёт скорости обращения к другим устройствам I2C. Так что универсальных решений не бывает. Надо смотреть по каждому случаю отдельно.

Ничего вы не поняли (или вы ваньку валяете(:-)?). Пытался вам на пальцах рассказать, что находится внутри модуля спи и как соединить несколько модулей спи, да видимо, вам не надо(:-).

А кто кого вводит в заблуждение? Вот лично у вас есть замечания к коменту #39 (с него все началось)?


согласен.

Но в данном конкретном случае, мне кажется, что GM в своих решениях пытается получить гибкость SPI сравнимуюс I2C за счет сторонних компонентов и усложнения обработки протокола и т.п. это уже неравные условия получаются.


Не смешите тапочки. Зачем мне объяснение как устроен SPI? это в любом даташите описано...

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

То, что вы предложили (кольцо из многих устройств с SPI интерфейсом) уже не будет SPI. И именно по причине внутреннего устройства SPI (16-и битовый закольцованный регистр поделенный между мастером и слейвом). Расскажите-ка лучше как мастер uC в вашем 1200-и битовом кольце (150 устройств), используя аппаратный SPI, обратится к стандартной SPI флешке стоящей, скажем, 75-ой в этом кольце.

Я уже давал аналогичный ответ. Расскажите как вы подключите 5-ую at24c512 к Вашей I2C шине. Речь идёт о подключении нескольких СВОИХ устройств на сколько я понимаю. Насчёт что это не будет SPI это спорно. Например есть 8-ми битный SPI и 16-ти битный. В самом SPI возможно менять фазы, полярность и прочее - и это всё равно SPI.

Никто не спорит. I2C хороший, проверенный временем, простой, очень гибкий, хорошо расширяемый интерфейс. С точки зрения подключения дополнительных устройств, возможно более гибкий. В плане стандарта. Но всётаки нельзя рассматривать оторвано от жизни. О чём мы говорим? Что допустим есть выходной разъём и на него выведена шина и мы ещё точно не знаем что там будет подключено но это "что-то" будет стандартным? Скажем в таком случае с I2C будет проще. Меньше контактов, отсутствие доп. корпусов. Но медленней. Можно запросто сделать также с SPI. Но проводов будет больше, возможно использование внешних элементов, зато будет выше скорость. Как правило, плата и программа изначально спроектирована и будущие возможности должны быть заложены изначально. С этой точки зрения оба протокола равноценны.

То есть я бы ответил так. Возможно всё! А вопрос о ЦЕЛЕСООБРАЗНОСТИ необходимо решать в каждом конкретном случае.

Приведу пример применения 50 микросхем EEPROM скажем. И вот вам очевидный для вас ответ только I2C становится неочевидным. Применение I2C будет аппаратно выглядеть хуже чем применение такого же числа SPI памяти. Кроме того дешифрацию данных устройств можно осуществлять в рамках того же SPI. Таким образом для разъёма достаточно 3 провода SPI + две выборки. Плюс максимум 1 доп. корпус на 8 микрух. Для I2C навеса будет не меньше, а скорость явно меньше.