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

Есть ссылки на такой материал? Исходники там какие может( на С подобных языках естественно )

Посмотрите вот здесь, там много всяких апонтов по реализации и применению I2C.

Смотрел по этой ссылке какаето муть. Лучше свяжу кристалы по UART. Сделать простую адресацию, чтобы контроллер определился ему ли это команда прилитела, и всё будет пучком

Если есть возможность выбирать интерфейс, то лучше, ИМХО, выбрать SPI. Интерфейс быстрый, прост как пробка, а следовательно, вызывает меньше проблем при реализации. Проводов правда больше, но это не большая плата за остальные удобства.

По ссылке - переводы атмеловских аппнотов.

Флаг в руки, барабан на шею. Если предполагаете мультимастер - два флага.
Хинт: на I2C (хоть я его и не люблю), если устройств >2, будет проще, но придется ознакомиться с мутью.

+1. IIC есть смысл применять, ИМХО, если устройств действительно много. Если они далеко и лишних проводов нет. А с SPI гораздо проще, да и быстрее, наверное.

Связывать контроллеры по SPI как раз сложнее. Особенно если их больше 2. Обязательно необходим какой-то протокол.

Применить I2C значительно проще. Я связываю как память. То есть на контроллере слэйв, реализую имитацию 24с01. При этом адрес устройства - применяю уникальный.

Не могу согласится. Если их не более двух - вообще нет никаких проблем. Если более ... О каком протоколе Вы говорите? А что, в случае с IIC - нет?

И UART и SPI предполагают подключение точка-точка. Если нужно связать более 2х девайсов придется делать какую то обвязку. Так что в этом случае (БОЛЕЕ 2х девайсов) - I2C предпочтительнее. Если же девайсов 2 - то предпочтительнее использовать то, что останеться на них свободным Сложность обслуживания всех 3х вариантов реализации около 0.

Отнюдь. И параллелятся (ибо выходы трехстабильные) и в цепочку соединяются...

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

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

С точки зрения аппаратной, если рассматривать несколько устр-в, реализуются все интерфейсы с теми или иными ограничениями.
Если брать SPI и пускать кольцо, то пропускная способность падает пропорционально колличеству учитывая % протокола. Если параллелить, то требуются линии выборки.
Если брать UART, то требуются драйверы.
И лишь I2C и 1-wire допускают подключение дополнительных устр-в без внесения аппаратных изменений в линию.

Если учесть, что мы находимся в разделе для начинающих, то я и посоветовал так.
В случае с I2C есть протокол. Но он, фактически, определён самим стандартом. В случае SPI - этого нет. Разработчику самому придётся выдумывать протокол для связи своих устр-в. Причём если предполагается приём/передача данных/команд, то протокол будет - как положено. Обязательно байтстаффинг + адрес устройства + контроль целостности пакета и т.д.

Приведу пример, просто по приколу, реализации протокола с учётом передачи данных и команд.

Передача комманд
St-AdW-Ar-Cmd-Ar-Par1-Ar-Par2-Ar-....ParN-Ar-Sp

Передача данных
St-AdW-Ar-01-Ar-Dat1-Ar-Dat2-Ar-....DatN-Ar-Sp

Чтение данных
St-AdW-Ar-Cmd-Ar-Sp St-AdR-Ar-Dat1-Aw-Dat2-Aw-....DatN-Sp

Где
St - старт
Sp - стоп
AdW/AdR - адрес с битами записи/чтения соответственно
Cmd - команда
Ar/Aw - ASK
Par/Dat - параметры/данные