Шина I2C, отключение питания одного из slave на шине Опции

[DVR]

Всем добрый день!

Вопрос такой: будет ли работать шина I2C, если отключить питание одного из нескольких I2C-Slave ? При этом физически подключение к шине незапитанной микросхемы остаётся. Мастером является AVR с аппаратной поддержкой I2C.

[=GM=]

будет ли работать шина I2C, если отключить питание одного из нескольких I2C-Slave?

Будет.

[aaarrr]

Будет.

Не слишком ли категорично? А если слейв тоже AVR?

[=GM=]

Не слишком ли категорично? А если слейв тоже AVR?

Шина данных айтуси делается на основе так называемого "проводного ИЛИ", обычно на транзисторах с открытым коллектором. Клоки слейвов - вход с большим сопротивлением, или в 3-м состоянии, если отключено.

(А как вы поняли, что мой ответ категоричен? На мой взгляд - краткий и исчерпывающий ответ)

[aaarrr]

Шина данных айтуси выполнена с помощью проводного ИЛИ, обычно на транзисторах с открытым коллектором. Клоки слейвов - вход с большим сопротивлением, или в 3-м состоянии, если отключено.

Проводного И. Клоки слейвов могут быть и выходом.

(А как вы поняли, что мой ответ категоричен? На мой взгляд - краткий и исчерпывающий ответ)

Правильный ответ: зависит от схемотехники I2C слейва.

[rezident]

Правильный ответ: зависит от схемотехники I2C слейва.

Плусадын!
Защитные диоды входных сигналов SCL и SDA на обесточенном устройстве I2C могут создать такой ток утечки, что работа шины будет заблокирована. Так что однозначного ответа нет.

[DVR]

Проводного И. Клоки слейвов могут быть и выходом.
Правильный ответ: зависит от схемотехники I2C слейва.

А если неизвестна схемотехника слейва и из даташита про неё ничего не ясно? Есть ли какой-нибудь способ развязать работающие и отключенные устройства на шине?

Сообщение отредактировал DVR - Aug 19 2008, 15:08

[aaarrr]

Тогда остается только ставить ключ. Или проверить наличие защитных диодов, но это, ИМХО, неправильно.

[DVR]

Тогда остается только ставить ключ. Или проверить наличие защитных диодов, но это, ИМХО, неправильно.

А не подскажете какой ключик можно было бы взять ?(питание +3,3В)

[aaarrr]

Можно собрать на дискретных элементах или поставить интегральный - ADG721, например.

[DVR]

Можно собрать на дискретных элементах или поставить интегральный - ADG721, например.

Спасибо за Ваши советы.

[=GM=]

Клоки слейвов могут быть и выходом

Да? Это с какого припрыга?

Посмотрите хотя бы назначение SCK для слейва, скажем, для атмега88 (документ 2545м, таблица 18-1, страница 164). Там чётко показано, что клок является входом.

[aaarrr]

Да? Это с какого припрыга?

Прежде чем пытаться давать советы другим, ознакомьтесь со стандартом I2C:

7 TRANSFERRING DATA
..
If a slave can’t receive or transmit another complete byte of data until it
has performed some other function, for example servicing
an internal interrupt, it can hold the clock line SCL LOW to
force the master into a wait state.

Стандарт разработан компанией NXP(Philips), Atmel может писать что угодно. Тем более, что выходом SCL у слейва бывает далеко не всегда.

[rezident]

Да? Это с какого припрыга?

Слейв может (имеет право) удерживать "низкую" часть уровня сигнала на шине SCL. В полном соответствии со спецификацией I2C.

[AHTOXA]

Прежде чем пытаться давать советы другим, ознакомьтесь со стандартом I2C:

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

[aaarrr]

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

Я уже писал, что это зависит от схемотехники драйверов выводов I2C. Если Вы подключите к шине, например, ATмегу с выключенным питанием, то она просадит линии в "0" по пути: Линия шины -> защитный диод -> шина питания ("0").

[Laptop]

По хорошему, если неизвестно как в устройстве организован интерфейс, то можно поставить диод и параллельно ему резистор килоом эдак 15-20 в SDA и только резистор в SCL. Но все это при низкой скорости обмена...
А если делать честно, то только развязывать ключами.

[aaarrr]

По хорошему, если неизвестно как в устройстве организован интерфейс, то можно поставить диод и параллельно ему резистор килоом эдак 15-20 в SDA и только резистор в SCL. Но все это при низкой скорости обмена...

Как поставить диод? Если катодом к выводу слейва, то шина все равно зависнет. Если наоборот, то он будет всегда закрыт.

[Laptop]

Как поставить диод? Если катодом к выводу слейва, то шина все равно зависнет. Если наоборот, то он будет всегда закрыт.

да, промашка вышла тогда все только по честному, с ключами.

[AHTOXA]

Если Вы подключите к шине, например, ATмегу с выключенным питанием, то она просадит линии в "0" по пути: Линия шины -> защитный диод -> шина питания ("0").

А-а-а, понял
А может мега просто запитается через этот диод? ))

[aaarrr]

А может мега просто запитается через этот диод? ))

Может. Только шине от этого легче не будет

[AHTOXA]

Может. Только шине от этого легче не будет

Если мега будет запитана, то может не завесит? :-)))

Во, нашёл явное упоминание про это в даташите на м32 (стр 170):

Note that all AVR devices connected to the TWI bus must be powered in order to allow any bus operation.

[rezident]

Как поставить диод? Если катодом к выводу слейва, то шина все равно зависнет. Если наоборот, то он будет всегда закрыт.

Можно попробовать развязать полевиком так, как Philips предлагает для согласования уровней.



Только такую пару на каждый слейв, который может быть обесточен, придется ставить.

[Laptop]

Ну вот опередили с правильным вариантом ) При этом устройство 1 это то которое отключают. И можно вместо транзистора на SCL ставить диод, если не надо клоки притормаживать.
А вообще док у Филипса на тему I2C много, иногда полезно почитать.

[=GM=]

Если Вы подключите к шине, например, ATмегу с выключенным питанием, то она просадит линии в "0" по пути: Линия шины -> защитный диод -> шина питания ("0").

Ну-ка, ну-ка, как это она просадит, интересно? Никакой просадки не будет, т.к. защитный диод подключен минусом к 0-й шине питания.

[AHTOXA]

Там два диода:

[aaarrr]

Ну-ка, ну-ка, как это она просадит, интересно? Никакой просадки не будет, т.к. защитный диод подключен минусом к 0-й шине питания.

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

Детский сад, честное слово.

[=GM=]

Плусадын! Защитные диоды входных сигналов SCL и SDA на обесточенном устройстве I2C могут создать такой ток утечки, что работа шины будет заблокирована. Так что однозначного ответа нет

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

[ILYAUL]

Сколько видел в своей практике всевозможных устройст с шиной I2C и с отключением их по питанию (если не нужны в данный момент) проблем с шиной не встречал.

[=GM=]

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

По условию задачи плюсовая шина питания слейв-устройства отключена. Покажите путь тока, если сможете.

("Плюс" и "минус" диода это жаргон)

[SasaVitebsk]

Кстати на форуме Точки Опоры обсуждали как раз проблему, что "отключенное устр-во благополучно запитывается от шины I2C и прекрасно работает".

А это как раз человеку и не надо было. Так что всётаки шину необходимо отключать.
Оно и понятно. Раз мы уже оперируем к разработчикам шины, то давайте вспомним, что её спецификация не допускает подключение устр-в "на горячую". Для этого существуют другие шины. Например DS 1-wire.

[ReAl]

Да? Это с какого припрыга?
Посмотрите хотя бы назначение SCK для слейва, скажем, для атмега88 (документ 2545м, таблица 18-1, страница 164). Там чётко показано, что клок является входом.

"Если бы это было да, так нет"
А причём тут таблица 18-1 на странице 164 документа 2545M, если она касается интерфейса SPI, а не I2C ?

Зато вот для I2C прописано в нескольких местах
The SCL line is pulled low until TWINT is cleared.
Для слейва это принципиально, ему надо обработать состояние конца передачи байта, а он может не сразу в прерывание войти и т.д., он вообще в слипе мог быть. Всё это время мастер должен покорно ждать.

21.7.3 Slave Receiver Mode
...
In all sleep modes other than Idle mode, the clock system to the TWI is turned off. If the TWEA
bit is set, the interface can still acknowledge its own slave address or the general call address by
using the 2-wire Serial Bus clock as a clock source. The part will then wake up from sleep and
the TWI will hold the SCL clock low during the wake up and until the TWINT Flag is cleared (by
writing it to one). Further data reception will be carried out as normal, with the AVR clocks running
as normal. Observe that if the AVR is set up with a long start-up time, the SCL line may be
held low for a long time, blocking other data transmissions.

По условию задачи плюсовая шина питания слейв-устройства отключена. Покажите путь тока, если сможете.

"пуля дырочку найдёт"
Как это шина питания "отключена" ?
И от внутренностей микроконтроллера?
И от остальных микросхем на плате, своим плюсовым выводом содединённый с плюсовым выводом микроконтроллера?
Скажем, операционник какой-то ширпотребный, который при вольте питания работать, естественно, не будет, но вполне может кушать несколько сот микроампер от шины питания платы, которая "отключена" от блока питания, но подключена к микроконтроллеру и через "верхний" защитный диод - к той линии, к которой подключен вход.
Элементарный тест - плата с мегой168, парой 74hc595 и ЖКИ на 44780, т.е. даже операционников нет.
Подаём 5 вольт через 4.7к на ногу SCL контроллера (подключена только к контроллеру да к площадке от неприпаянных часов DS1338), имеем напряжение около 1,7 вольта. Т.е. нашёлся путь для тока (5-1,7)/4,7 = 0,7мА.
Недозапущенный контроллер вполне может столько кушать.
А был бы на плате ещё какой-нибудь LM358, так ещё что-то сожрал бы.

А вот цитатка из документации на LPC2368

7.18.1Features
•I2C0 is a standard I2C compliant bus interface with open-drain pins.
•I2C1 and I2C2 use standard I/O pins and do not support powering off of individual devices connected to the same bus lines.

Т.е. фирма понимает суть проблемы и один канал I2C сделала с "истинно открытым стоком" (и они такие даже если I2C не используется), а не программно включаемым при активации I2C-контроллера, как на остальных двух и как это у AVR сделано. В результате нет не только специальных защитных диодов на питание, но и паразитных от верхнего МОП-транзистора.

[aaarrr]

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

Куда утечки? Вам схемку с диодами нарисовали - покажите, куда потечет.

По условию задачи плюсовая шина питания слейв-устройства отключена. Покажите путь тока, если сможете.

Напряжение на шине питания отключенного устройства какое? Ток оно способно потреблять, или нет?

("Плюс" и "минус" диода это жаргон)

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

[rezident]

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

Какой может быть ток утечки при штатной работе, если к "верхнему" защитному диоду прикладывается либо напряжение обратной полярности (лог.0 на шине) , либо напряжение близкое к нулю (лог.1 на шине). "Нижний" диод вообще всегда смещен в обратном направлении, т.к. отрицательных напряжений на шине быть не должно. А вот когда напряжение питания будет отсутствовать, то через "верхний" защитный диод ток и потечет. Причем этого тока может хватить, чтобы запитать малопотребляющие MCU. Например, в случае с MSP430 сам такое наблюдал неоднократно. Когда через внешний делитель, на который подается напряжение, MSP430 получает питание и при отсутствии супервизора работает. Ему ведь всего минимум 1,8В для работы достаточно.
Кстати, это довольно старая "шутка" с паразитным питанием. На нее напоролись еще в те времена, когда только появились КМОП-микросхемы из серии К176. КМОП-микросхемы работали даже если у них забывали подать питание на соответствующий вывод. А выяснялось это только под нагрузкой какого-либо выхода или на высоких частотах.

[zhevak]

Всем здесь присутствующим предлагаю провести маленький тест.

Я на этот наткунлся года два назад, и оно меня очень сильно поразило. Не смотря на то, что я об этом явлении знал теоретически (практически как-то не удавалось сталкиваться, может просто везло?), я все же был крайне удивлен увиденному. Теперь позвольте поделиться этим с вами.

На семинаре Texas Instruments раздали eZ430 (в простонародии -- "ёжик"). Многие из вас тоже ходили на такие семинары и тоже получили такого же ежика. Теперь откройте ежика и достаньте платку с F2013. Возьмите любой цифровой тестер (у меня китайский M-838), и померяйте сопротивление питающей цепи на диапазоне 200 Ом или 2 кОм. Ничего не заметили? -- Устройство заработало от тестера!

Идем дальше. Гасим свет, делаем в комнате интим (девок в шею. У нас свои игрушки!) и вновь подцепляемся к плате тестером только на этт раз к земле и к ллюбой свободной ноге. Притушенный свет позволяет увидеть еле-еле мерцающий светодиодик. Устройство работает!

Те же самое можно проделать и с другой Тексавской демо-платкой с тех же семинаров. Я говорю о плате Touch Demo -- красная такая, с четырьмя квадратиками. Пороговое напряжение у красного ЛЭДа ниже, чем у зеленого, поэтому эффект питания микросхемы через входа более заметен.

Мы видим не только то, что через входы "выключенной" микросхемы утекают токи, способные зажечь ЛЭД, но также видим, что MSP430F20xx способна работать при низком напряжении питания. Нижний предел работоспособности у MSP430 я не проверял, а вот у TINY2313 -- проверял. Тайни сохраняет работоспособность до 1.2 В.

Еще вопросы есть?

[Сергей Борщ]

А если неизвестна схемотехника слейва и из даташита про неё ничего не ясно?

В даташите обычно приводят максимально допустимые напряжения на выводах. Если там для выводов I2C указано Vdd+0.3v, то диод есть. Если там абсолютное значение напряжения - скорее всего нет.

КМОП-микросхемы работали даже если у них забывали подать питание на соответствующий вывод. А выяснялось это только под нагрузкой какого-либо выхода или на высоких частотах.

Угу. Или странно сбоили даже в статике. Расследование показало, что пока хоть на одном входе была единица - 561ЛА7 работала. Но вот когда в схеме возникало состояние, когда на все входы всех элементов подавались нули - на выходах "почему-то" единицы исчезали.

[=GM=]

Поисследовал входные сопротивления обесточенных I2C устройств. Скажу следующее.

1) Если выводы SCK и SDA ведомого (слейв) устройства выполнены в виде открытых стоков, как например в AT24C512, то вполне можно снимать с них питание.

2) Если на выводах SCK и SDA ведомого (слейв) устройства присутствуют защитные диоды, как например в Atmega8515, то снятие с них питания может привести к блокировке SCK и SDA линий, так что я поторопился сказать, что шина I2C всегда будет работать при снятии питания с одного из слейвов.

3) Правильный ответ дал aaarrr в посте #5: работоспособность зависит от схемотехники I2C слейва.

4) To aaarrr насчёт проводного И. Проводное И или ИЛИ, зависит от точки зрения на предмет, поскольку функции в некотором смысле дуальны, но вот цитата из дейташита на AT24C512 "The SDA pin is bidirectional for serial data transfer. This pin is open-drain driven and may be wire-ORed with any number of other open-drain or open collector devices" (doc1116o, c.3). Насколько помню, раньше это называлось Монтажное ИЛИ.

5) To aaarrr насчёт детского сада. Я не обижаюсь, но и не приветствую, поскольку атмосферу форума это не улучшает, да и вас не красит, прошу впредь держать себя в рамках приличия.

[aaarrr]

4) To aaarrr насчёт проводного И. Проводное И или ИЛИ, зависит от точки зрения на предмет, поскольку функции в некотором смысле дуальны, но вот цитата из дейташита на AT24C512 "The SDA pin is bidirectional for serial data transfer. This pin is open-drain driven and may be wire-ORed with any number of other open-drain or open collector devices" (doc1116o, c.3). Насколько помню, раньше это называлось Монтажное ИЛИ.

Цитата из The I2C-bus specification:

5 GENERAL CHARACTERISTICS

...The output stages of devices connected to the bus
must have an open-drain or open-collector to perform the
wired-AND function.

Еще раз повторю, что Атмел к стандарту I2C отношения не имеет никакого, и ссылаться на их документы не стоит.

[zhevak]

[code]

Еще раз повторю, что Атмел к стандарту I2C отношения не имеет никакого, и ссылаться на их документы не стоит.

Замечу так же, что АТМЕЛ официально нигде не называет свои модули по имени "I2C", только как "TWI". А значит, что АТМЕЛ не обязан соблюдать стандард I2C.

[rezident]

Замечу так же, что АТМЕЛ официально нигде не называет свои модули по имени "I2C", только как "TWI". А значит, что АТМЕЛ не обязан соблюдать стандард I2C.

Дык Atmel не пожелал платить роялти (royalty) за использование trademark I2C, вот и извернулся с названием TWI.

[zhevak]

Дык Atmel не пожелал платить роялти (royalty) за использование trademark I2C, вот и извернулся с названием TWI.

ага, и это освободило АТМЕЛ от четкого следования стандарту. Т.е. АТМЕЛ однозначно объявил свой TWI вне стандарта I2C. Другое дело, что TWI получился очень похожим на I2C, так это случайность. Поэтому, в жарких спорах об I2C, на АТМЕЛ никак нельзя ссылаться. У него свой стандарт -- twi.

[Syberian]

Порты AVR многофункциональные, и на всех стоят неотключаемые диоды на питание и землю. Поэтому, отключенный AVR (и всё, что подключено снаружи к выводу Vcc меги) будет "питаться" от шины I2C, и ничего хорошего из этого не выйдет.

[sseett]

[code]

Замечу так же, что АТМЕЛ официально нигде не называет свои модули по имени "I2C", только как "TWI". А значит, что АТМЕЛ не обязан соблюдать стандард I2C.

Сейчас не называет. А ранее называл (в старых аппликухах попадалось).

[ReAl]

ага, а ещё они гнутся и сваливаются
ага, а вот с SPI у ATMEL всё путём, потому что они его так SPI и называют Моторола в своё время не запатентовала это слово и заодно логотип, как филипс сделал с I2C.

[defunct]

ага, а вот с SPI у ATMEL всё путём, потому что они его так SPI и называют Моторола в своё время не запатентовала это слово и заодно логотип, как филипс сделал с I2C.

В SPI нечего патентовать. Любой студент в состоянии придумать такой интерфейс самостоятельно.
I2C все же гораздо сложнее.

[aaarrr]

Любой студент в состоянии придумать такой интерфейс самостоятельно.

Дык для патента это даже лучше

[=GM=]

А вот интересно, почему в качестве протокола для обмена в МК (и ПК) не используется код манчестер-2? Всего-то, договориться, что перепад 1-0 даёт 1, перепад 0-1 даёт 0, в начале байта посылать 0 в течение 3То/2.

[aaarrr]

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

[zhevak]

А вот интересно, почему в качестве протокола для обмена в МК (и ПК) не используется код манчестер-2? Всего-то, договориться, что перепад 1-0 даёт 1, перепад 0-1 даёт 0, в начале байта посылать 0 в течение 3То/2.

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

[ReAl]

В SPI нечего патентовать. Любой студент в состоянии придумать такой интерфейс самостоятельно.
I2C все же гораздо сложнее.

Что-то мне кажется, что если бы дело было в патенте, то в AVR не было бы I2C вообще без покупки права использования, а с покупкой было бы и название (на ARM7 лиценизию купили и называют его ARM7). А так, как мне кажется, дело только в использовании "зарегистрированной торговой марки".
Если бы Моторола зарегистрировала на себя слово SPI, то пришлось бы Атмелу независимо от простоты этого интерфейса или выдумывать другое слово (как выдумано для I2C), или покупать право использования слова.
Может, раньше дело и в патенте было, да только срок действия истёк. Долго довольно если где-то было I2C - то но так и называлось, видать тогда без покупки права вообще нельзя было использовать, а с покупкой - можно и назвать "честно". А потом срок патента истёк и начали делать все, кому не лень, но называть по-другому.

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

У микрочиповских однопроводных EEPROM разве не манчестер-2?


http://www.microchip.com/wwwproducts/Devic...ocName=en535099

Кстати, обратите внимание - на этой страничке Микрочип возле слова I2C прикручивает ™, возле microwire и spi - нет.
Возле слова manchester - тоже нет. Но возле своего слова UNI/O - прикручивает, теперь кто бы не сделал такое же - или должен купить у микрочипа право на применение слова, или придумывать другое.

[aaarrr]

У микрочиповских однопроводных EEPROM разве не манчестер-2?

Чума. Для шестиногих PIC'ов самое то

[=GM=]

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

Ну, положим, сложность манчестера вы преувеличиваете, он сопоставим по сложности с rs232, и на порядок проще, чем тот же I2C. Преимущества очевидны, один провод, нет постоянки, посылай хоть по радио. Но самое главное преимущество - СУЩЕСТВЕННОЕ ослабление требований к стабильности клоков приёмника и передатчика. Допустима общая нестабильность 25% на ОДИН бит, в то же время в rs232 всего 5% на ДЕСЯТЬ бит, что позволяет работать на МК с внутренним генератором без калибровки.

У микрочиповских однопроводных EEPROM разве не манчестер-2?

Да, он самый. Спасибо за ссылку, не знал, с удовольствием почитал. Много чего надстроили над физуровнем(:-)

[aaarrr]

Ну, положим, сложность манчестера вы преувеличиваете, он сопоставим по сложности с rs232, и на порядок проще, чем тот же I2C.

Нет, это вы преуменьшаете. RS232 проще хотя бы потому, что приемнику не нужно восстанавливать тактовую частоту. I2C - вообще синхронная шина.

Попробуйте на МК написать слейв, работающий как микрочиповский EEPROM - в диапазоне 10-100kHz.

[=GM=]

RS232 проще хотя бы потому, что приемнику не нужно восстанавливать тактовую частоту

Ну, это формальный подход, на самом деле, в манчестере тоже можно обойтись без восстановления, хотя можно и восстановить если надо. Пара-тройка дополнительных строчек кода.

I2C - вообще синхронная шина

Хоть это и синхронный протокол, но гораздо сложнее манчестера. Одни старт-стопные условия замучают. Попробуйте съэмулировать с помощью АВР МК работу иипром с иис-протоколом хотя бы на скорости 400 кГц. Я знаю, о чём говорю, поскольку в своих изделиях применяю программный иис обмен на скорости 5Мбод, 200 нс такт.

Попробуйте на МК написать слейв, работающий как микрочиповский EEPROM - в диапазоне 10-100kHz

Легко, при условии, что и вы в свою очередь напишете программу приёма одного байта по рс232 для того же диапазона скоростей. Заодно и объясните всем, на каком принципе вы будете различать байты 0хF0, 0xF8, 0xFC и тому подобное. (Замечу в скобках, что код для приёма будет работать на любой скорости 10-100, несмотря на то, что скорости заявленной иипром различаются в 10 раз, а манчестер допускает увеличение скорости на интервале одного бита не более, чем на 100%.)

[zltigo]

..что приемнику не нужно восстанавливать тактовую частоту.

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

[aaarrr]

Ну, это официозный подход, на самом деле, в манчестере тоже можно обойтись без восстановления, хотя можно и восстановить если надо. Пара-тройка дополнительных строчек кода.

Если диапазон частот 10-100, то без восстановления делать нечего. Микрочиповские EEPROM'ы восстанавливают.

Хоть это и синхронный протокол, но гораздо сложнее манчестера. Одни старт-стопные условия замучают.

Очередная цитата из стандарта:

6.2 START and STOP conditions
Within the procedure of the I2C-bus, unique situations
arise which are defined as START (S) and STOP (P)
conditions (see Fig.5).
A HIGH to LOW transition on the SDA line while SCL is
HIGH is one such unique case. This situation indicates a
START condition.
A LOW to HIGH transition on the SDA line while SCL is
HIGH defines a STOP condition.

Ну очень сложно.

Попробуйте съэмулировать с помощью АВР МК работу иипром с иис-протоколом хотя бы на скорости 400 кГц. Я знаю, о чём говорю, поскольку в своих изделиях применяю программный иис обмен на скорости 5Мбод, 200 нс такт.

Во-первых, I2S или I2C? Стандарт I2C не предусматривает передачи на скоростях выше 3.4 Mbit/s. Во-вторых, вы уже продемонстрировали, что не знаете элементарных вещей, поэтому позволю себе усомниться в ваших словах.

Легко, при условии, что и вы в свою очередь напишете программу приёма одного байта по рс232 для того же диапазона скоростей. Заодно и объясните всем, на каком принципе вы будете различать байты 0хF0, 0xF8, 0xFC и тому подобное.

Видите ли, стандарт RS232 не предполагает работу на плавающей скорости и не предусматривает механизмов для ее обеспечения (autobaud не в счет).

(Замечу в скобках, что код для приёма будет работать на любой скорости 10-100, несмотря на то, что скорости заявленной иипром различаются в 10 раз, а манчестер допускает увеличение скорости на интервале одного бита не более, чем на 100%.)

С восстановлением тактовой по синхропоследовательности будет.

[zhevak]

на каком принципе вы будете различать байты 0хF0, 0xF8, 0xFC и тому подобное.

1. Приемник, работающий по протоколу Манчестер-2, ре-синхронизируется при каждом принятом. Приемник, работающий по последовательному протоколу (UART), осуществляет синхронизацию в начале последовательности по приему стартового бита.
Иначе говоря, поскольку в UART синхрогнизация осуществляется один раз на 10 посылок (Start, 8 inforamtion bits and Stop), то получается, что устойчивость к стабильности частоты у UART-а на порядок ниже.

Т.е. получается вроде как Манчестер-2 более пригоден на практике. Но сейчас многие МК имеют внутренние RC-генераторы со стабильностью 2% и менее, что вполне достаточно для устойчивой связи по последовательному итерфейсу. А с другой стороны, кварцевые резонаторы не так уж дорого и стоят.
Т.е. опять-таки получается, что проблема (преимущество М-2) надумано.


2. Проблема остановки потока информации. (Например, клавиатура.) При использовании UART это решается легко. Устовие Stop на линии может длиться бесконечно долго. По условию Старт начинаем набирать байт.

Вопрос. Что мы будем делать в М-2 в такой же ситуации? По-битовая синхронизация -- это конечно хорошо. Но нужна еще и по-байтовая синхронизация, а так же не надо забывать про по-пакетную синхронизацию. Т.е. при использовании М-2 для устройств типа клавиатура, мышь или еще какой-нибудь датчик, соблюсти все виды синхронизации оказывается сложнее, чем в том же UART-е.

[zltigo]

Т.е. получается вроде как Манчестер-2 более пригоден на практике.

На практике у них совсем разные области применения - манчестер прежде всего в синхронных потоках работает.

[Rst7]

А вот интересно, почему в качестве протокола для обмена в МК (и ПК) не используется код манчестер-2?

В быту не используют Вояки, например, очень любят MIL-STD 1553 - как раз между всякими вычислителями и прочей начинкой ездящего/летающего/плавающего оружия данные гонять.

С другой стороны - эзернет на скорости 10МБит/с - он же, манчестер-2. Тут есть проникновение в быт