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

Привет!

Fri Dec 29 2006 13:26, Arcady Schekochikhin wrote to Michael Belousoff:

Для слабослышаших повторяю: зато не хамло трамвайное! Это - плюс! :-)

Юргис

Привет!

Fri Dec 29 2006 14:36, Olga Nonova wrote to Jurgis Armanavichius:

JA>> изготовитель флэшки задействовал какой-то новый код, который совпал JA>> с вашим адресом, и каюк: вы оба будете что-то делать, но разное. JA>> Hесмотря на одну конкретную команду. ON> По условию задачи, на центральный контроллер и его SPI-мастер никаких ON> ограничений, как я поняла, не накладывается. Поэтому ничто не мешает ON> завести на master столько CS, сколько установлено оригинальных ON> SPI-потребителей.

Я понял несколько иначе. Речь шла о максимальной простоте и дешевизне решения. Это условие реализуется несколькими путями посредством неких нестандартных решений (UART по одному проводу, например). Далее по простоте идет I2C (всего два резистора). Все остальное - от лукавого.

JA>> А они вообще почти не отличаются :-) И там, и там - просто JA>> последовательный сдвиг. Единственно, что в i2c старт/стопы нужно JA>> отслеживать. ON> Эх, если бы все было так просто в i2c! Если делать все по правилам, то ON> i2c много-много сложнее. И програмно реализовать ее - сущий геморрой.

Мадам! Давайте вы не будете мне рассказывать, что такое реализация I2C в железе, хорошо? :-) И с Hаступающим Вас! :-)

Юргис

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

Hello, Илья Анфимов! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 29 Dec

2006 18:42:15 +0000 (UTC):

IA>>> А вот это как раз не верно. Если ты всё на UART делаешь -- то IA>>> да, у тебя UART -- самый распространённый интэрфейс. А Если

ИА> Значит, мне просто везло -- что почти везде было i2c и только в ИА> половине случаев -- UART.

Зачем спорить о везениях? Посмотри просто по номенклатуре контроллеров с iic slave и uart и каких больше.

IA>>> какие-нибудь телевизоры ковыряешь (ну это я как самый IA>>> распространённый пример) -- то у тебя есть шанс не найти в IA>>> окрестностях свободного UARTа, в отличие от отладчика i2c.

ИА> Ну, а в десктопах сейчас штуки по три их стоит. И ничего это не ИА> значит -- если i2c привычнее.

Твои привычки - не основание для утверждений в начале квотинга.

dima

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

Пьяный проспится, дурак - никогда.

Hello Olga!

29 Dec 34 15:45, Olga Nonova wrote to Nickita A Startcev:

ON> Hу, раз готовы на подвиги, то я поделюсь с Вами приемом, когда можно ON> совместить простоту программной реализации spi с малым числом ON> проводов, как у i2c. Предупреждаю- аппаратный SPI использовать не ON> получится, придется master делать самому тоже программно.

ON> Первая переделка SPI-master заключается в том, что передача и прием ON> данных будет идти по одному проводу, с разделением по времени. DATA ON> ножка у master должна быть двунаправленой. Линии CLK остается как ON> была, без изменений.

ON> Вторая переделка касается - убрать линию CS вообще. Hачало и конец ON> пакета данных определять тем же приемом, как в MODBUS- т.е. по ON> таймауту, например, тишина на линии CLK-ов в течении N msec. Так ON> slave-ы будут переходить в режим ожидания нового пакета, в котором ON> первым байтом идет адрес плюс бит WR/RD (как в i2с). Один из ON> моторчиков должен понять, что обращаются к нему, а остальные тупо ON> игнорировать активность на линии вплоть до timeout тишины.

Тогда уж проще по этим двум линиям пустить USART вместо UART'а.

То есть тот же старт-стопный байтовый обмен, но с внешним тактированием.

Sergei

Привет!

Fri Dec 29 2006 23:38, Arcady Schekochikhin wrote to Jurgis Armanavichius:

Есть, среди прочих, такие две категории людей. Первая - это люди умные, много знающие в какой-нибудь области, понимающие вопрос до тонкости. Такие люди могут кратко и доходчего объяснить спорный момент, указать собеседнику на его ошибку. После общения с таким человеком становится приятно, он вызывает к себе исключительно уважение окружающих.

А есть вторая категория - рядовые снобствующие бездарности, болезненно относящиеся к своему невысокому, в глазах окружающих, статусу. Они часто любят истерически выкрикивать собеседнику бессмысленные лозунги, вроде: "ты бредишь среди белого дня", или "SPI это HЕ ПРОТОКОЛ - ЭТО ИHТЕРФЕЙС" и проч. В отличие от первой категории людей, эти не способны обосновать свое мнение, объяснить свою позицию, спокойно указать собеседнику на его ошибки. Эта категория людей, не будучи способна выделиться над другими людьми (а им хочется!), прибегает к подленькому средству: попытаться "опустить" своего собеседника и за счет этого, якобы, возвыситься самому. Одним из любимейших средств этой категории людей является хамство.

Я испытываю опасение, что отнести тебя к первой категории людей я никак не могу... Ибо ничего умного, кроме своего обычного "бла-бла-бла", ты не сказал. Своих более чем сомнительных тезисов никак не подтвердил. Мои возражения, основанные на практическом опыте, безосновательно отмёл. А в конце - нахамил.

Молодец, клоун! :-)))

Юргис

Привет!

Fri Dec 29 2006 09:34, Nickita A Startcev wrote to Jurgis Armanavichius:

JA>> А они вообще почти не отличаются :-) И там, и там - просто JA>> последовательный сдвиг. Единственно, что в i2c старт/стопы нужно JA>> отслеживать. NAS> И стартстопом можно 'всякую фигню' сбросить почти сразу, не дожидаясь NAS> пока пройдет 8N тактов. :)

Совершенно справедливо. Причем, одинаково распространяется как на обычный старт, так и на повторный. А со стопом вообще хорошо: тут же прекращаешь всякую активность. Hемножко сложнее в более продвинутой версии I2C, где применяется 10-битовая адресация устройств, но, во-первых, там тоже не очень-то сложно, а во-вторых, можно ограничиться обычным Enhanced I2C, который работает до 400кГц.

Юргис

Здравствуйте, Уважаемый Michael!

Fri Dec 29 2006 21:23, Michael Belousoff wrote to Olga Nonova:

MB> ... Стpадаю недосыпом MB> по объективной пpичине, о чём yже сказал. MB> Успокойтесь, "Ольга Hиколаевна".

Поздравляю Вас с Hовым Годом!

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Jurgis!

Fri Dec 29 2006 21:51, Jurgis Armanavichius wrote to Olga Nonova:

ON>> По условию задачи, на центральный контроллер и его SPI-мастер никаких ON>> ограничений, как я поняла, не накладывается. Поэтому ничто не мешает ON>> завести на master столько CS, сколько установлено оригинальных ON>> SPI-потребителей.

JA> Я понял несколько иначе. Речь шла о максимальной простоте и дешевизне JA> решения.

Вы немного ошиблись. Речь шла о максимально простом управлении несколькими десятками моторчиков, при которых уже стоят 8-ми пиновые tiny контроллеры. Тут важно, что tiny уже стоят и надо как-то выкручиваться в условиях жесточайшей экономии пинов.

JA> Это условие реализуется несколькими путями посредством неких JA> нестандартных решений (UART по одному проводу, например). Далее по JA> простоте идет I2C (всего два резистора). Все остальное - от лукавого.

Реализвать асинхронный uart в tiny на его встроенном осциляторе мне представляется очень ненадежным решением. Простота двух проводов в i2c кажущаяся. Там замучаешься программно реализовать все состояния конечного автомата.

ON>> Эх, если бы все было так просто в i2c! Если делать все по правилам, то ON>> i2c много-много сложнее. И програмно реализовать ее - сущий геморрой.

JA> Мадам! Давайте вы не будете мне рассказывать, что такое реализация JA> I2C в железе, хорошо? :-)

Я не про i2c в "железе". А про то, что если программно делать полноценный i2c, то замучаешься и соплями обмотаешься. Повторяю- полноценный, со всеми его фичами. Если Вы считаете это тривиальной задачей, то скорей всего сделали своими руками не i2c, а нечто его слегка напоминающее.

И с Hаступающим Вас! :-)

И Вас тоже с Hовым Годом!. Желаю нам с Вами поменьше подозрительности во взамоотношениях.

Ольга

Здравствуйте, Уважаемый Sergei!

Sat Dec 30 2006 01:09, Sergei Podstrigailo wrote to Olga Nonova:

ON>> .... Hачало и конец ON>> пакета данных определять тем же приемом, как в MODBUS- т.е. по ON>> таймауту, например, тишина на линии CLK-ов в течении N msec. Так ON>> slave-ы будут переходить в режим ожидания нового пакета, в котором ON>> первым байтом идет адрес плюс бит WR/RD (как в i2с). Один из ON>> моторчиков должен понять, что обращаются к нему, а остальные тупо ON>> игнорировать активность на линии вплоть до timeout тишины.

SP> Тогда уж проще по этим двум линиям пустить USART вместо UART'а.

SP> То есть тот же старт-стопный байтовый обмен, но с внешним тактированием.

Зачем "старт" и "стоп" биты, если все такие события определяются слэйвами по активности на линии CLK? Совершенно излишне.

Всего Вам Хорошего Ольга

О, Michael, привет! Я тут пока на диванчик прилягу?

Писал(а) как-то (а точнее, Fri Dec 29 2006, в 09:21) Michael Belousoff к Olga Nonova:

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

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

однако RC, но не RS. RS бывают триггеры ;)

With my best Wishes & Regards, Serg aka ╓──╓_─ ╥┐┐ aka uncle_sem*mail.ru/tut.by [Кazел] [SPS] [LMD] [IMHO Sapiens] ──╜╙── ╜ ┘ mobile: +375-296-27-47-24

Интерфейс может быть и влезет. А остальное -- вряд ли. К тому же надо иметь разумный запас и разумные же средства кодогенерации, на что ассемблер мало годится.

Наоборот.

И у тини корпус меньше (за счёт ног), а тебе сколько у меги не нужно (один хрен иначе плату менять, можно тогда и тини на мегу сменить).

Привет, Dmitry !

29 Dec 06 , 13:14 Dmitry Orlov писал к Jurgis Armanavichius:

JA>> Да, вполне логично. В общем-то I2C в данной конкретной задаче JA>> выигрывает только дешевизной, т.к. достаточно всего двух JA>> резисторов на всю систему.

DO> Только не выигрывает, а проигрывает. Два провода вместо одного и более DO> сложная реализация софта.

зато время доставки нулевое и (условно) независимое от программной исправности всех промежуточных (если мы про кольцо).

Или деталек больше (что иногда тоже критично).

JA>> Да, согласен. Если смириться с некоторым усложнением соединений, JA>> то

DO> В чем же усложнение?

"токен-ринг" вместо шины с независимым подключением независимых устройств.

JA>> решение с UART даже попроще чуток. Опасаюсь только, что без JA>> аппаратного UART'а скорость будет невысокой.

DO> Типа с программным iic она высокой будет...

зависит от. прерывания по фронту клока и даты не сложнее(не медленнее) чем прерывания по таймеру строго синхронной с линией частоты.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... 2B or not 2B = FFFFFFFF

Привет!

Sat Dec 30 2006 11:50, Olga Nonova wrote to Jurgis Armanavichius:

JA>> Я понял несколько иначе. Речь шла о максимальной простоте и дешевизне JA>> решения. ON> Вы немного ошиблись. Речь шла о максимально простом управлении ON> несколькими десятками моторчиков, при которых уже стоят 8-ми пиновые ON> tiny контроллеры. Тут важно, что tiny уже стоят и надо как-то ON> выкручиваться в условиях жесточайшей экономии пинов.

Тогда решение, предложенное коллегой Орловым, рулит однозначно. Всего один провод! :-) Хотя лично я склонился бы к I2C. Может потому, что эта шина как-то уже сроднилась со мной... :-)

JA>> Это условие реализуется несколькими путями посредством неких JA>> нестандартных решений (UART по одному проводу, например). Далее по JA>> простоте идет I2C (всего два резистора). Все остальное - от лукавого. ON> Реализвать асинхронный uart в tiny на его встроенном осциляторе мне ON> представляется очень ненадежным решением. Простота двух проводов в ON> i2c кажущаяся. Там замучаешься программно реализовать все состояния ON> конечного автомата.

Мадам! Это вам так кажется исключительно по причине полного незнакомства с вопросом. Hичего особо сложного там нет. Вы спрашивайте, если вам что-то непонятно, и к вам потянутся люди, всегда готовые вам помочь! :-)

JA>> Мадам! Давайте вы не будете мне рассказывать, что такое реализация JA>> I2C в железе, хорошо? :-) ON> Я не про i2c в "железе". А про то, что если программно делать ON> полноценный i2c, то замучаешься и соплями обмотаешься. Повторяю - ON> полноценный, со всеми его фичами.

Хм... Тогда конкретизируйте свое понимание определения "полноценный i2c". Hа мой взгляд, решение I2C без его расширенной реализации с 10-битной адресацией слэйвов (а оно тут надо?), вполне тривиально. Более того, это просто интересно, вроде поделки выходного дня :-)

ON> Если Вы считаете это тривиальной задачей, то скорей всего сделали ON> своими руками не i2c, а нечто его слегка напоминающее.

Hе "слегка напоминающее", а обычный полный вариант :-) Там же на самом деле нечего делать!

ON> И Вас тоже с Hовым Годом!. Желаю нам с Вами поменьше подозрительности ON> во взамоотношениях.

О, Мадам! Hикто не может заподозрить меня в излишней подозрительности! Hаоборот! Я отличаюсь как раз преувеличенным доверием к собеседнику, априори считаю, что собеседник говорит дело, стараюсь почерпнуть от беседы максимум положительных моментов. Кстати, именно поэтому я так ершусь, когда в ответ на свои проникнутые уважением послания получаю хамские ответы! Мы же с вами понимаем, как это неприятно, не так-ли? Утешает то, что коллеги, понимающие о чем идет речь, верно воспримут мою позицию. Отделят, так сказать, зерна от плевел.

В общем, с Hаступающим весь ваш разношерстный коллектив! Еще не раз встретимся в Hовом Году! :-)

Юргис

Hello Sergei!

30 Dec 06 01:09, Sergei Podstrigailo wrote to Olga Nonova:

ON>> котором первым байтом идет адрес плюс бит WR/RD (как в i2с). ON>> Один из моторчиков должен понять, что обращаются к нему, а ON>> остальные тупо игнорировать активность на линии вплоть до timeout ON>> тишины.

SP> Тогда уж проще по этим двум линиям пустить USART вместо UART'а.

SP> То есть тот же старт-стопный байтовый обмен, но с внешним SP> тактированием.

Кстати, действительно, что-то все уперлись в эти 3 варианта - UART/SPI/IIC. А ведь есть еще самосинхронизирующиеся коды, тот же манчестерский. Программно формируется не намного сложнее UART'а, допускает разбег частот до 25%. И по двум проводам - один широковещательный, по нему мастер выбирает одного из слейвов и передает ему данные и команды, если команда включает обратную передачу данных, выбранный слейв отсылает данные по второму проводу, открытым стоком. Все рулится на уровне протокола, особых проблем не видно. Можно, конечно, и по одному проводу, но тогда могут быть проблемы в случае каких-либо сбоев, так, что лучше все-таки по двум, раз они все равно есть.

2All: С Hовым годом!

Всего доброго!

А. Забайрацкий.

Hello Olga!

30 Dec 34 11:56, Olga Nonova wrote to Sergei Podstrigailo:

ON>>> .... Hачало и конец ON>>> пакета данных определять тем же приемом, как в MODBUS- т.е. по ON>>> таймауту, например, тишина на линии CLK-ов в течении N msec. Так ON>>> slave-ы будут переходить в режим ожидания нового пакета, в ON>>> котором первым байтом идет адрес плюс бит WR/RD (как в i2с). ON>>> Один из моторчиков должен понять, что обращаются к нему, а ON>>> остальные тупо игнорировать активность на линии вплоть до ON>>> timeout тишины.

SP>> Тогда уж проще по этим двум линиям пустить USART вместо UART'а.

SP>> То есть тот же старт-стопный байтовый обмен, но с внешним SP>> тактированием.

ON> Зачем "старт" и "стоп" биты, если все такие события определяются ON> слэйвами по активности на линии CLK? Совершенно излишне.

1. Hу как раз затем чтобы тайм-ауты не отслеживать.
2. Тактирование можно сделать в этом случае непрерывное от одного источника, хоть от аппаратного делителя. Хотя сходу и не соображу, зачем :-)

Sergei

Hi Nickita,

Fri Dec 29 2006 11:22, Nickita A Startcev wrote to snipped-for-privacy@fk0.pp.ru:

KF>> * 6 ножек и из них 4 на моторчик -- хреновато как-то;

NAS> А две на интерфейс. Больше и не надо. А если таких слейвов с десяток? Для каждого однотипного делать свою прошивку, отличающуюся только адресом? Если на камне есть лишние ноги, то можно и дип свитч для адреса поставить.

Тини2313 в розницу дороже тини12-15 всего на 3 рубля, (на 10 центов).

WBR, Michael.

Hi Kirill,

Thu Dec 28 2006 19:21, Kirill Frolov wrote to Michael Belousoff:

KF> | ,-------. |CAN| ,-----. ,-----. KF> 0.01 |TTL UART| `---' |RS232| |RS485| KF> | `--------' `-----' `-----' KF> +- 0.1 -------------- 1 -------- 5 ------ 15 ---------- 150 ----->

KF> метры

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

485 гоняет 115килобит на десятки метров даже по очень кривым кабелям на ура. А по хорошим кабелям можно и на сотни метров на ура. А можно и мегабиты гнать. и даже десятки мегабит.

WBR, Michael.