простые последовательные

Ага. На одной плате 5 контроллеров и к каждому по кварцу.

Одной вот так просто -- не хватит... Преимущество SPI (3+N проводов) в отсутствии сложной программной логики. I2C несколько сложней. UART -- совсем другой уровень сложности (микросхем АЦП с выдачей результата в UART что-то не наблюдается..., I2C и SPI -- полно). SPI аппаратно реализуется на регистре сдвига, на рассыпухе, если надо. Скорость опять же за SPI. Проблема одного лишнего провода, я так думаю, остро не стоит. Рядом с основным контроллером за ради экономии 12 ножек можно поставить аппаратный дешифратор (xxx ИД y).

Можно картинку нарисовать:

^ | мегабиты

100 ,-----. ,--------. | | USB | |Ethernet| 10 `----' `--------' | ,----. | | SPI | | `----' | | ,----. 0.4 | I2C | | `----' ,----. 0.1 |SMBUS| | `-----' ,---. | ,-------. |CAN| ,-----. ,-----. 0.01 |TTL UART| `---' |RS232| |RS485| | `--------' `-----' `-----' +- 0.1 -------------- 1 -------- 5 ------ 15 ---------- 150 ----->

метры

Вот теперь пусть кому там надо было тыкает пальцем и смотрит попал или нет. Картинка, понятное дело, очень приблизителная...

Reply to
Kirill Frolov
Loading thread data ...
*** Ответ на письмо из carbonArea (carbonArea).

Привет, Alexander !

28 Dec 06 , 17:26 Alexander Derazhne писал к Nickita A Startcev:

AD> Какой ещё коммутации?! Просто общая шина в количестве 4-х AD> проводов, с общим коллектором. Hу, если считать ещё и земляные провода AD> - то 8 или 9

CS один на всех? :)

. С уважением, Hикита. ... И у модераторов есть свои "плюсы". :-)

Reply to
Nickita A Startcev

Арбитраж в SPI реализуется генератором тактовой частоты и сигнало CS. Нет подтверждения... А не смущает, что на параллельной шине, например, к

27C512, тоже ни тебе арбитража, ни подтверждения. А то я заявлю, в I2C не предусмотрен SNMP протокол...
Reply to
Kirill Frolov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Rifkat Abdulin on Thu, 28 Dec

2006 18:28:21 +0300:

RA>> UART еще более рулит - геммороя меньше ;-)

JA> Точка-точка - несомненно. А для нескольких устройств - I2C со своими JA> всего лишь 2-я проводами :-)

А с UART достаточно одного...

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec

2006 08:30:18 +0000 (UTC):

AS> Какова схема подключения? ОК? Диодное или? Или просто на резисторах? AS> Есть ли какой нибудь серьезный опыт по такому использованию УАРТ AS> как внутренней шины?

Я бы транзисторами развязался, или резисторами (тут кстати это недавно уже обсуждали), или даже диодами. Например для полевичка - drain через резистор на +5, gate - туда же на +5, исток - на Tx, Rx - на drain, с него же - линия. Резисторы в сток можно на каждом узле делать, или один общий. Думаю, и с биполярным транзистором то же самое, в базу только резистор нужен. Как внутренеей шины опыта нет, а вот как внешней (но примерно с той же идеологией, только что с развязками и более сложными приемниками и передатчиками) - есть. Если UART программный, то можно вообще только битом направления порта управлять, даже внешний транзистор не потребуется.

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec

2006 09:07:12 +0000 (UTC):

ON>>> Для связи узлов _внутри _одного _корпуса самое простое- это SPI или ON>>> I2C. Они, собственно, для этого и были созданы. Вот, если выходить ON>>> наружу ящика, то Вы правы.

DO>> Это так, когда iic slave или spi реализованы аппаратно. UART в DO>> мелких контроллерах встречается чаще, чем iic, а когда его нет, DO>> реализуется проще.

ON> Если нет аппаратных i2c но есть uart, то Вы правы. Однако, если нет ON> и аппаратного uart, то из трех вариантов программной реализации: ON> i2c,spi,uart -,мне представляется, меньше сил и времени уйдет на ON> spi. Да и стабильность с воспроизводимостью окажется выше.

Для программного spi или iic необходимы внешние прерывания. Для spi - одно, по фронту (спаду) на clk, для iic - и по scl и по sda (или по изменению всего порта). UART программный на небольшие скорости (а для этой задачи большие явно не нужны) делается исключительно на таймерном прерывнии. Кроме того, на UART тривиально (в соседнем письме описано как) реализуется однопроводная двунаправленная шина. То есть тянуть (не считая уже протянутого общего) нужно только один провод.

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Vladislav Baliasov on Thu, 28 Dec 2006 18:28:14 +0300:

VB>> I2C master - тривиально. А вот слейв - очень даже нет.

JA> Да ерунда :-) Даже без прерываний можно обойтись, если очень уж JA> простое устройство. Скорость только выбрать подходящую, чтобы все JA> успевало.

Ну если по 100ms между каждой сменой состояния мастера давать, то да...

dima

formatting link

Reply to
Dmitry Orlov

Привет!

Thu Dec 28 2006 19:11, Vladislav Baliasov wrote to Jurgis Armanavichius:

JA>> А то у вас обмен по SPI - "последовательный поток битов" :-))) Хотя... JA>> В пределах байта это действительно последовательный поток битов... ;-) VB> И все же - SPI это действительно поток битов. Это _интерфейс_, но не VB> _протокол_ (потому там и буковка "I"). И даже байтовая структура в VB> общем случае не обязательно присутствует - вон, FTDI в VNC1L такую жуть VB> страшенную соорудили... А что там будет бегать и как оно будет бегать - VB> это совершенно отдельный разговор. В кои-то веки "коллектив авторов" VB> сказал что-то осмысленное. Впрочем, это уже было сказано _до_ VB> "колелктива"...

Спасибо за информацию, не знал! Я, честно признаться, не очень большой спец по SPI. Подумал, что ряд микросхем, поддерживающих этот протокол, могут служить каким-то ориентиром. Изучив порядок работы с ними я резонно подумал, что отсутствие идентификации и завязка на выполнение каких-то действий по сигналу CS/ о чем-то говорят... Hо все равно непонятно, как работать в этом интерфейсе с несколькими слэйвами... Вот I2C - совсем другое дело :-) Там адрес устройства прямо и недвусмысленно присутствует непосредственно в первом же байте :-)

Юргис

Reply to
Jurgis Armanavichius

Привет!

Thu Dec 28 2006 20:39, Dmitry Orlov wrote to Jurgis Armanavichius:

RA>>> UART еще более рулит - геммороя меньше ;-) JA>> Точка-точка - несомненно. А для нескольких устройств - I2C со своими JA>> всего лишь 2-я проводами :-) DO> А с UART достаточно одного...

Это если только "туда" :-) А "обратно"? IMHO, 1-wire (или его клоны) - единственная альтернатива. Hо больно уж спартанским выглядит подобное решение...

Юргис

Reply to
Jurgis Armanavichius

Привет!

Thu Dec 28 2006 21:26, Dmitry Orlov wrote to Jurgis Armanavichius:

VB>>> I2C master - тривиально. А вот слейв - очень даже нет. JA>> Да ерунда :-) Даже без прерываний можно обойтись, если очень уж JA>> простое устройство. Скорость только выбрать подходящую, чтобы все JA>> успевало. DO> Hу если по 100ms между каждой сменой состояния мастера давать, то да...

Мега с внутренним мегагерцем - вполне себе то :-) Hо, конечно, звезд с неба с ее помощью не нахватаешь... Hо ведь означенным моторчикам этих звезд и не нужно, не так-ли? :-)

Юргис

Reply to
Jurgis Armanavichius

Пpивет, Jurgis!

*** 28 Dec 06 21:56, Jurgis Armanavichius wrote to Vladislav Baliasov:

JA> Спасибо за информацию, не знал! Я, честно признаться, не очень большой JA> спец по SPI. Подумал, что ряд микросхем, поддерживающих этот протокол, JA> могут служить каким-то ориентиром.

Опять - не _протокол_, а _интерфейс_. Это разные вещи.

JA> Изучив порядок работы с ними я резонно подумал, что отсутствие JA> идентификации и завязка на выполнение каких-то действий по сигналу JA> CS/ о чем-то говорят...

Hи о чем это не говорит. Тут говорить можно лишь о логике работы конкретной микросхемы.

JA> Hо все равно непонятно, как работать в этом интерфейсе с несколькими JA> слэйвами...

Управляя с помощью разных -CS. Или каскадируя. Hо оба варианта не универсальные

- бывает, что выхода нет вообще, бывает, что он не отключается и может мешать при неактивном CS, а каскадирование хорошо подходит для сдвиговых регистров a la 595, но совершенно не годится для периферии, у который на выходе при неактивном CS вообще ничего нет, да и "прозрачности" - тоже нет. Hо если нет потребности в обратной связи (приеме данных от абонента), то вполне можно передавать пакеты, содержащие адрес абонента. По CS синхронизируемся, а дальше все просто. Hу, в общем-то, и принимать ответ так тоже можно, только абонентов друг от друга защитить, чтобы выходы, если что, не подрались.

JA> Вот I2C - совсем другое дело :-) Там адрес устройства прямо и JA> недвусмысленно присутствует непосредственно в первом же байте :-)

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

с уважением Владислав

Reply to
Vladislav Baliasov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Nickita A Startcev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec

2006 09:58:16 +0300:

NA>>> В (самых) дешевых тиньках ничего нет, нужно эмулировать программно NA>>> и/или аппаратно. Так что, наверное, нечто и2ц образное выйдет. NA>>> (недостаток СПИ - куча линий чип_селект.)

DO>> Реализовать программный iic можно фактически только используя DO>> прерывание по изменению порта, а это часто вступает в конфликт с DO>> другим использованием выводов этого порта.

NA> лишние прерывания можно 'игнорировать' если хранить предыдущее и NA> смотреть текущее состояние порта.

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

DO>> Адресация же устройств с таким образом написанным iic ничем не DO>> проще чем при помощи UART,

NA> можно взять честный и2ц аппаратный уровень и переделать 'под свои NA> задачи' программный.

Зачем?

DO>> только с UART все гибче и аппаратно он много где реализован.

NA> В самых дешевых тиньках его нет. все равно что-то свое руками NA> программировать, а если программировать - то можно и 'конькретно под NA> задачу' протокол извратить.

Причем протокол - uart. Впрочем, можно конечно и его нестандартным делать, и передавать не 8-9битные данные, а сколько нужно, только при этом возрастают требования к точности синхронизации. А можно кстати и наоборот поступить и тем самым требования снизить.

DO>> Сделать же на его базе шину - и вовсе тривиально, причем достаточно DO>> одного (не считая общего) провода.

NA> собрать в общую кучу прием и передачу, а разделять программно?

При программной реализации ничего никуда собирать не надо, нужна одна ножка и внешний pull-up, лучше в виде источника тока, но можно и просто резистором (одним или несколькими). Хотя если связь внутри одной pcb, то можно и встроенным pull-up'ом обойтись. Передача и прием естественно разнесены по времени, ну так они и в iic разнесены. Причем эта разнесенность еще и упрощает конечный автомат программного uart'а и избавляет от необходимости свое же эхо фильтровать, как в случае аппаратного uart'а. В качестве бесплатного бонуса - возможность легко подключить готовый host pc вместо центрального контроллера для отладки и/или расширения функциональности.

dima

formatting link

Reply to
Dmitry Orlov

Тебе уже пояснили - надеюсь дошло - что СПИ это не протокол - это интерфейс, на котором может ездить поверх любой протокол. Если твой чип хочет другой протокол - заведи ему отдельный СS (как это _обычно_ делается) и живи спокойно. Если ты делаешь цепь однотипных девайсов, протокол которых ты задаешь сам - используй адресный байт, бит, килобит и будь счастлив. Типичная цитата из тебя "ну я не большой спец по 1, 2, 3, далее со всеми остановками..."

Reply to
Arcady Schekochikhin

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec

2006 21:56:38 +0300:

RA>>>> UART еще более рулит - геммороя меньше ;-) JA>>> Точка-точка - несомненно. А для нескольких устройств - I2C со JA>>> своими всего лишь 2-я проводами :-) DO>> А с UART достаточно одного...

JA> Это если только "туда" :-) А "обратно"? IMHO, 1-wire (или его клоны)

И туда, и обратно, просто неодновременно. Так и в iic - тоже неодновременно. Передаешь пакет, скажем из 4 байт, содержащий адрес устройства, команду, данные, контрольную сумму (можно и без, если помех нет). Все принимают, отвечает только тот, чей адрес совпал. От iic это по сути отличается только тем, что интерфейс асинхронный.

JA> единственная альтернатива. Hо больно уж спартанским выглядит JA> подобное решение...

Решение с UART удобно тем, что это по-прежнему самый распространенный интерфейс. Для отладки вполне можно в качестве мастера (или слейва) обычный комп использовать. Однопроводным он делается тривиально - хоть диод (лучше шоттки) катодом к tx, на анод - rx, и в линию. Линию подтягиваешь резистором (или лучше источником тока) к плюсу. Все. Или более честное решение с транзистором (я его уже описывал).

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Jurgis Armanavichius! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 28 Dec

2006 21:56:41 +0300:

VB>>>> I2C master - тривиально. А вот слейв - очень даже нет. JA>>> Да ерунда :-) Даже без прерываний можно обойтись, если очень уж JA>>> простое устройство. Скорость только выбрать подходящую, чтобы все JA>>> успевало. DO>> Hу если по 100ms между каждой сменой состояния мастера давать, то DO>> да...

JA> Мега с внутренним мегагерцем - вполне себе то :-) Hо, конечно, звезд JA> с неба с ее помощью не нахватаешь... Hо ведь означенным моторчикам JA> этих звезд и не нужно, не так-ли? :-)

Потому я и советую uart. А iic отожрет кучу ресурсов опросами состояний, если при их изменениях железо прерываний не генерирует. И state machine существенно более громоздкая. И все равно со стандартным (даже 400кГц) несовместимо. Тем более, что программную реализацию uart (в том числе и на avr, хотя свет на них клином не сошелся) мы тут в рамках конкурса обсудили и ее можно просто взять готовую. А iic - еще делать, отлаживать и мастер и слейв. А такие вещи, где одна программа должна работать с другой и обе пишутся одновременно отлаживать противно весьма. То в одной части ошибка, то в другой, вместе не работает, а почему понять трудно. UART подцепил к уже заведомо работающему хосту и отладил.

dima

formatting link

Reply to
Dmitry Orlov

Теперь умножай на 2 и бери attiny2313. Где, вроде как, всё нужное есть. И ещё 4 ШИМ канала...

Ибо:

  • 6 ножек и из них 4 на моторчик -- хреновато как-то;
  • никаким вменяемым C-компилятором оно не поддерживается.

Мой опыт подсказывает, что изобретение самодельных протоколов приводит к трудно излечимому геморрою (в силу времени проведённому на стуле, в отладке).

Reply to
Kirill Frolov

У host PC как раз проблема с временем. Особенно, если оно через USB... Вобщем, там напрашивается достаточно сложный арбитраж, что сомнительно, чтоб так весело лезло в 512 слов кода attiny12... Я потому и говорю -- проще взять с аппаратным интерфейсом (attiny2313, attiny26). Имеется ввиду USI. А на нём хоть I2C, хоть SPI. RS232 там есть, но выглядит не привлекательно...

Reply to
Kirill Frolov

Привет Nickita!

28 Dec 06 09:44, Nickita A Startcev писал Alex Mogilnikov:

AM>> Можно устройства включать в кольцо, то есть вход от AM>> предыдущего, выход - к следующему.

NS> Если в кольце N устройств, то для передачи байта последнему придется NS> передать N-2 байт шита всякого?

Если в каждом сеансе опрашивать все моторчики, то не надо.

NS> А для обмена типа "устройство номер А, NS> что у тебя в регистре Б?" придется передавать не менее 2N байт и иметь NS> секс с 'кто и где потерял один бит (синхронизации)'.

? Биты не должны теряться...

AM>> Тогда для SPI достаточно одного провода на всех AM>> ("начало посылки"), NS> плюс провод данных.

Да, конечно.

AM>> а для UART вообще ничего не надо. NS> но два провода данных.

Один. Однонаправленное кольцо.

AM>> У нас таким образом к одному устройству модули расширения AM>> подключаются: каждый может соединяться с двумя другими, NS> Rx налево, Tx направо, все в кольцо? :)

Именно так.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... В системе возможно бесконечное число процессов - до 256.

Reply to
Alex Mogilnikov

Hi Jurgis Armanavichius!

JA>> Хм... А если этот адрес совпадёт с какой-нибудь из SPI-команд? JA>> Или ты тоже, как коллектив авторов, применяешь нестандартное JA>> решение собственного сочинения? Тогда другое дело. Hо в этом JA>> случае I2C все-равно рулит, т.к. требует на один провод меньше :-) RA> Что значит команды SPI? Протокол обмена я сам регламентирую.

jmc> Hе скажи, не скажи. А ну посадишь ты на шину стандартную SPI-флэшку? jmc> И полетит твой протокол...

Это смотря как реализовать. У нас давно используется SPI подобным образом никаких ограничений на обмен с любым SPI слейвом нет.

4-ре ноги от контроллера на плисину, все слейвы к плисине. На "одной шине" висит больше сотни девайсов(правда большинство внутри плисины).
Reply to
Alexander Zholtkovsky

Пpивет, Olga.

Вот что Olga Nonova wrote to Michael Belousoff:

ON>>> пеpедач чеpез uart сyществyет пpоблема ON>>> стабильности и воспpоизводимости частоты. И pешить этy пpоблемy ON>>> на базе встpоенных в tiny RC-осцилятоpов пpедставляется

^^^^^^^^^^^^^^

ON>>> маловеpоятным. В ON>>> то вpемя как для i2c или spi этой пpоблемы не сyществyет.

MB>> Hикто не заставляет пользоваться ими - MB>> ни RS-осциллятоpами, ни вообще tiny.

ON> По yсловию задачи были tiny безо всего.

Пpинимается.

ON> Больше надо дyмать о людях и ON> их пpоблемах, yважаемый Michael. И поменьше о себе любимом.

О себе любимом надо дyмать всегда и много.

ON> PS. RS-осцилятоpов не бывает.

Сyдя по подчёpкнyтомy - бывают. Оленька, скажите, y вас нет шизофpении?

--Michael G. Belousoff-- Yekaterinburg city mickbell(dog)mail(dot)ru

formatting link
... ==== Пpоблемy надо pешать до того, как она появится. ====

Reply to
Michael Belousoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.