Привет!
Thu Dec 28 2006 23:17, Vladislav Baliasov wrote to Jurgis Armanavichius:
JA>> Спасибо за информацию, не знал! Я, честно признаться, не очень большой JA>> спец по SPI. Подумал, что ряд микросхем, поддерживающих этот протокол, JA>> могут служить каким-то ориентиром. VB> Опять - не _протокол_, а _интерфейс_. Это разные вещи.
Так зачем тогда советовали SPI? Тогда можно было просто сказать: "имеем три провода, организуем последовательный обмен данными с TTL уровнями" :-)
JA>> Изучив порядок работы с ними я резонно подумал, что отсутствие JA>> идентификации и завязка на выполнение каких-то действий по сигналу JA>> CS/ о чем-то говорят... VB> Hи о чем это не говорит. Тут говорить можно лишь о логике работы VB> конкретной микросхемы.
Хм... Ты не понял. Я резонно предположил, что при наличии интерфейса SPI вполне вероятно появление желания присоединить в систему флэшку, поддерживающую этот интерфейс. А может и еще какие подобные микросхемы. Иногда (причем, частенько) именно так и бывает. Тут же окажется, что для этих компонентов придется заводить отдельные CS/. В результате мы получим 5-7 проводов вместо всего лишь двух. Вот я об этом.
JA>> Hо все равно непонятно, как работать в этом интерфейсе с несколькими JA>> слэйвами... VB> Управляя с помощью разных -CS.
Вот, вот. Число проводов заметно возрастет.
VB> Hо если нет потребности в обратной связи (приеме данных от абонента), VB> то вполне можно передавать пакеты, содержащие адрес абонента. По CS VB> синхронизируемся, а дальше все просто.
Вне сомнения, если городить что-то замкнутое, нестандартное, без требования последующей модернизации, - конечно, можно делать как угодно, не обращая никакого внимания на сложившиеся реалии. Hо тогда не нужно это поделие называть "SPI" :-)
JA>> Вот I2C - совсем другое дело :-) Там адрес устройства прямо и JA>> недвусмысленно присутствует непосредственно в первом же байте :-) VB> I2C слейв хорош только аппаратный. Программно реализовывать - мучительно VB> и коряво.
I2C мастер - вообще нечего говорить, проще некуда. I2C слейв - геморройнее, но для простой задачи управления моторчиком - тоже ничего особо сложного.
VB> Использовать UART - много проще. А если есть проблемы с стабильностью VB> тактовых частот - можно использовать самосинхронизирующиеся протоколы, VB> для этого хватит и простого таймера (само собой, только при относительно VB> небольших скоростях).
Его проще реализовать, если он набортный. Hу или если взять готовое решение, которое коллега Орлов предложил. Правда, выходы тогда нужно развязывать. С I2C - дешевле: всего два резистора на всю компанию :-) Впрочем, еще лучше все организовать по однопроводному UART'у :-)
Юргис