Ну, не очень это и оригинально, всё до меня уже сделали и все пользуются, в частности, вы, только не задумываетесь об этом. Грубо говоря, у многих коллег шоры на глазах, находятся в плену, так сказать, имбеддерских предрассудков(:-)...

Клок надо передавать всем одновременно, т.е. параллельное подключение. А CS вообще не нужен по большому счёту.

И, если только передавать, то нужно всего два провода.

Что касается "проблемно" - сможете подключить 150 иис устройств к одной шине? Получите ба-а-а-льшую проблему...

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

Для полноценного обмена вашим методом надо построить кольцо.
1->2->3->4 ..... ->N -> 1
Это накладно как с т.з. железа так и т.з. протокола.


К I2C 150-нет, а 128 запросто, она для этого и создана.


Если добавить еще одну шину и мост - 254 устройства к вашим услугам.
Проблем с обменом - никаких. Арбитраж выполняется аппаратно.

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

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

А это, по большому счёту, не так.

Если уж говорить о гибкости, из SPI модуля МК можно легко соорудить I2C-протокол, а вот наоборот - вряд ли получится! И это будет настоящая гибкость, а не высосанная из пальца. Я уж не говорю про скорость обмена, которая будет в ДЕСЯТЬ раз выше!

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


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

Можно подробнее - как при включении "звездой" без CS раздать нескольким (пусь будет двум для простоты) SPI-слейвам разную информацию. И главное, как при подключении звездой без CS или при соединении их последовательно (ваше первое предложение) получить ответ от всех устройств?С этим никто не спорит, только эта вещь для несколько, гм, другого.

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


Есть разница. Вы не можете просто так взять и подключить новое устройство к трем проводам без модификации либо схемы либо программы. А в случае с I2C - можете.

Абсолютно. Лишь бы эти провода не пришлось разъединять и добавлять новые. Как пример шины PCI/ISA - проводов больше чем у SPI, но тем не менее гибкость масштабирования систем на их основе - выше.


Да все верно. Вы правильно поняли мою мысль. Для SPI - гибкость подключения устройств на столько же недосягаяема в сравнении с I2C, на сколько для I2C недосягаема возможность получения 8Mbit/s в подключении точка-точка.


Это ваше мнение. Несомневаюсь, что когда вам понадобится соединить около 100 MK между собой в одну систему - вы выберете SPI.


Я говорил не об I2C модуле и не о SPI модуле, а об абстрактном модуле который выполняет определенную целевую функцию в системе - будь то датчик, клавиатура или LCD экран.


Особенно в кольце из 150 устройств.. Вы представляете сколько ресурсов уйдет на ретрансляцию сообщений?

Не спорю. Конечно вещь, для соединений "точка-точка".

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

2) Параллельное соединение мастера и двух слейвов. Посылаете два байта, первый - адрес, второй - данные. Слейв с соответствующим адресом отвечает, другой слейв молчит.

И где тут масштабируемость?!
Придется править код Master'a (и код каждого! слейва) при изменении количества слейвов в системе.


Схематически сомнительное решение опять-же. Без буферных элементов объединять два MISO с придавленным CS похорошему счету нельзя.. Итого каждый новый слейв - дополнительный буферный элемент. Масштабируемость просто "рулит".

В Вашем споре поддержу GM. Причины просты. Если разобраться, то путаются разные уровни протоколов. I2C более полный протокол. В нём мало мальски вводится понятие адресации устройств. Хотя, если разобраться по существу по I2C можно теоретически подключить тысячи устройств или наоборот никак не получится подключить 128.
Объяснюсь.
1) Почему не получится подключить 128. Адресное пространство побито м/у специальными устр-вами. Для примера для памяти как известно 0xa0. Но на самом деле не 0xa0, a 0xa0-0xfe. Таким образом если Вы применяете I2C память, то уже теряете 8 вместо одного устройства. Ну и т.д.
2) Почему у меня получится подключить 256 устройств. Да просто. Я под все устр-ва отведу один адрес. Например 0x20. А адресацию буду осуществлять двумя или тремя байтами субадреса. Что мне помешает?

С SPI разница конечно есть в связи с тем что ответ идёт. Но теоретически GM прав. Действительно софтово можно описать таким образом чтобы SLAVE устр-ва отвечали только после какой-нибудь процедуры. CS и SCK подавать паралельно. При добавлении нового устр-ва не требуется переписывать мастеру ничего. Конечно если все устр-ва будут иметь общий совтовый протокол. Если же подключаем устр-во которое не имеет такого протокола, то заводим на него отдельный CS.

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

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

К слову RS232 тоже бы не предназначен. Поставили драйвера и ПРИМЕНИЛИ ОПРЕДЕЛЁННЫЙ СОФТ и вот вам rs485 и другие возможности.

[quote name='namelos' date='Jul 6 2007, 18:27' post='269612']
И еще небольшой вопрос.A какaя связь между контроллерами является наиболее надежной и стабильной? RS232, I2C, SPI?

Я бы вам порекомендовал выбрать I2C. Тут уже говорили достоинства I2C - простота реализации (потребует только резисторы подтяжки),128 устройств на шине, скорость обмена 400кГц б/с. Скорость можно и повысить, если делать межпроцессорный обмен, до 1Мбит/с. Там в настройках AVR-ки, кажется, есть возможность.

RS-232 с применением микросхем RS-485 применяют, когда линии связи имеют длинну от десятков сантиметров до нескольких десятков метров. Скорости (реальные) могут доходить до 57600 бит/с.

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

Для вашего устройства с 40 датчиками DS1820, я думаю, подойдет и 100КГц на I2C. Датчики DS1820 довольно медленные устройства и опросить одно устройство чаще чем раз в 1сек у вас не получится.

Применять много устройств(микроконтроллеров) из-за 40 датчиков я бы вам тоже не советовал. Это будет дороже, чем 1 процессор, да и программа будет сложнее. Все можно сделать на 1 процессоре, датчики все(DS1820) посадть на одну линию и вперед!

Не смешите меня, лишний провод это накладно? Не хотите кольцо, сделайте параллельное подсоединение или смешанное.


Если точнее, то для 127, т.к. 0 адрес предназначен для широковещания.

Вы что не понимаете, 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 навеса будет не меньше, а скорость явно меньше.

К моей I2Cшине? Дико извиняюсь, но нигде не упоминал I2C, даже и в мыслях не держал. Так что, имхо, почти весь ваш пост лишь по ошибке адресован ко мне.



Дык, если исключительно СВОИ устройства, со строго определенным количеством и порядком в цепи, то такую цепочку можно заставить работать. Душераздирающее, конечно, зрелище: масштабы оверхеда для каждой транзакции при 150 устройствах поистине впечатляют.



Ох, не уверен, что все упирается в перевод или толкование слов "Serial Peripheral Interface". ИМХО, было бы разумно иметь возможность, чисто формально, проверить себя. Например:
Берем _любое_ стандартное устройство, заявленное разработчиками, как имеющее SPI. Подключаем в кольцо к другим 149 устройствам. Все 150 устройств работают правильно? В случае предложенного кольца ответ однозначный - нет. Ну значит это был не стандартный SPI, а что-то другое .

Ну, вы как-то выборочно читаете мои посты...не только кольцо, но и звезду! Чёткого определения SPI наверное нет, моторола выпустила протокол из-под контроля, так что куда он разовьётся и разовьётся ли, трудно сказать...Можно посмотреть на аналогию с RS232, практически никто не пользуется всякими dtr, dsr и т.п., но от этого никто не говорит, что это не RS232, согласны?

Экий вы! Ну поставьте стандартную SPI флешь в параллель с работающим кольцом из 150 устройств и будет вам щастье. И стоить это вам будет один дополнительный провод SS, делов-то.

А теперь покажите, как подключить 128-е устройство (я уж не говорю 151-е :-) к работающим по шине i2c 127-ми устройствам. Не думаю, что будет легко, и что подключение обойдётся в один провод.

Не, ну с I2C проще - берем ещё 2 провода и получаем ещё 127 устройств

Так иис модуль один, куда эти два провода подключать-то?

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

Для стандартной АТ24Схх памяти этот номер не пройдёт.