[=AK= 14]

Вы тут долго спорили что интерфейсы и протоколы это разные вещи

Вы обмишулились. Спутали меня с моим оппонентом. Перечитайте сообщение №25 еще раз внимательнее, если до вас не дошло.

 

I2C спецификация включает как электрическую часть, так и формат данных

Тем не менее, в предлагаемом варианте в рамках каждой из плат - чистый I2C. И для мастера абсолютно все равно, что происходит в кабеле - ему кажется, он непосредственно он общается со своими слэйвами, находящимися в паре сотен метров от него. Следовательно, I2C мастер имеет полное право сказать, что "I2C и на 250 метров работает". А то, как происходит доставка на такое расстояние, - разве что-то меняет в этом факте?

 

Какой это к черту I2C? Вы его еще в IP запихайте и скажите что у вас I2C на тыщи километров работает.

А вот через IP прозрачно для I2C мастера никак не получится. Изучайте I2C. Если так и не поймете, почему через не получится - обращайтесь, я объясню.

 

Как общаться? Между собой - никак. Центральная управляющая программа должна быть на ПК.

Вредный совет. Так, конечно, в принципе делать тоже можно, но это наименее предпочтительный вариант, в силу своей ненадежности, наихудшей из возможных. ПК выключили - все встало.

[slavka012 0]

Тем не менее, в предлагаемом варианте в рамках каждой из плат - чистый I2C. И для мастера абсолютно все равно, что происходит в кабеле - ему кажется, он непосредственно он общается со своими слэйвами, находящимися в паре сотен метров от него. Следовательно, I2C мастер имеет полное право сказать, что "I2C и на 250 метров работает". А то, как происходит доставка на такое расстояние, - разве что-то меняет в этом факте?

Ладно, я свое мнение уже высказал по данному вопросу.

 

А вот через IP прозрачно для I2C мастера никак не получится. Изучайте I2C. Если так и не поймете, почему через не получится - обращайтесь, я объясню.

А я думаю получится. Почему это нет?

[=AK= 14]

А я думаю получится. Почему это нет?

Потому что при связке через IP невозможно выдержать времена, требуемые I2C. В этом принципиальное отличие от того варианта, который я предложил.

 

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

 

А тормозить они у вас будут в любом случае, независимо от реализации. Вот представьте себе устройство (даталоггер), которое, скажем, раз в 100 мс читает и пишет несколько байт в I2C EPROM. Теперь вы эту EPROM выносите наружу и связываете с мастером I2C через IP, используя любой имеющийся на рынке экспандер I2C. Будет у вас такой даталоггер работать? Нет.

[Гость @Ark]

Вредный совет. Так, конечно, в принципе делать тоже можно, но это наименее предпочтительный вариант, в силу своей ненадежности, наихудшей из возможных. ПК выключили - все встало.

В данной ситуации - наиболее простое в реализации решение. Потому и посоветовал.

[slavka012 0]

Потому что при связке через IP невозможно выдержать времена, требуемые I2C. В этом принципиальное отличие от того варианта, который я предложил.

 

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

В I2C нет никаких требуемых времен. И слэйв и мастер могут торомозить работу другой стороны чтобы подогнать под свою скорость.

 

А тормозить они у вас будут в любом случае, независимо от реализации. Вот представьте себе устройство (даталоггер), которое, скажем, раз в 100 мс читает и пишет несколько байт в I2C EPROM. Теперь вы эту EPROM выносите наружу и связываете с мастером I2C через IP, используя любой имеющийся на рынке экспандер I2C.

Да вы меня не агитируйте! :) Я бы такой хренью заниматься бы не стал в любом случае. Сценарий-то вы предложили явно нелепый.

[=AK= 14]

В I2C нет никаких требуемых времен. И слэйв и мастер могут торомозить работу другой стороны чтобы подогнать под свою скорость.

Хи-хи... Я же вас просил - изучите I2C, прежде чем нести ахинею. В этом режиме слэйв не успеет через IP затормозить мастера в момент непосредственно после старта. Потому что тормозить он обязан быстро, иначе мастер убежит - не догонишь.

 

Сценарий-то вы предложили явно нелепый.

Опять хи-хи. Я вам такой даталоггер могу живьем показать. Уже лет 15 выпускается серийно.

 

Ладно, я свое мнение уже высказал по данному вопросу.

Как выяснилось, ваше мнение сформировалось вследствие элементарного недостатка знаний.

[slavka012 0]

Хи-хи... Я же вас просил - изучите I2C, прежде чем нести ахинею. В этом режиме слэйв не успеет через IP затормозить мастера в момент непосредственно после старта. Потому что тормозить он обязан быстро, иначе мастер убежит - не догонишь.

Вы немножко на шаг вперед думать можете? Тормозить мастера может фальшивый слейв, самостоятельно, пока не дождется ответа от реального слейва.

Я вам такой даталоггер могу живьем показать. Уже лет 15 выпускается серийно.

Не надо меня за идиота держать. Я не сомневаюсь, что они выпускаются. Нелепо его к памяти по I1C через интернет подрубать.

[=AK= 14]

Вы немножко на шаг вперед думать можете? Тормозить мастера может фальшивый слейв, самостоятельно, пока не дождется ответа от реального слейва.

Распишите подробнее, как это, по-вашему, должно происходить.

 

Нелепо его к памяти по I1C через интернет подрубать.

Странно. Это же ваша собственная идея была, которую вы высказали в посте №38. А сейчас продолжаете спорить, что она работоспособная - вот даже "фальшивый слейв" придумали.

 

Интересная аберрация сознания...

[slavka012 0]

Странно. Это же ваша собственная идея была, которую вы высказали в посте №38. А сейчас продолжаете спорить, что она работоспособная - вот даже "фальшивый слейв" придумали.

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

 

Что касается по-подробнее, то что вам не понятно -- после приема каждого байта приемник имеет право удерживать клок в нуле на время обработки этого байта. Что еще надо объяснять? IP-вставка будет тормозить передатчик на время пока данные уйдут на другой конец и реальный приемник не отпустит клок, вот и все. Считаете, что это не прозрачно -- ваше право. Но это в полном соотвествии с протоколом I2C. Почитайте, это назыается clock stretching.

 

Так в чем говорите ахинея-то заключается?

[=AK= 14]

Что касается по-подробнее, то что вам не понятно -- после приема каждого байта

Бита

 

приемник имеет право удерживать клок в нуле на время обработки этого байта. Что еще надо объяснять? IP-вставка будет тормозить передатчик на время пока данные уйдут на другой конец и реальный приемник не отпустит клок

Вот величину этого времени и надо объяснить. Конкретно - назовите цифру, которая гарантирует, на ваш взгляд, работоспособность предлагаемого вами варианта. Желательно - с объяснением, почему вы назвали именно такое время.

 

Считаете, что это не прозрачно

Конечно, непрозрачно. Я вам уже привел несколько примеров, для которых предлагаемое вами решение оказалось непрозрачным:

- Мастер, не умеющий делать clock stretching

- Даталоггер, которому требуется обеспечить запись в EEPROM за определенное время

[slavka012 0]

Бита

 

Cпасибо, но я не нуждаюсь в ваших поправках. После каждого БАЙТА.

 

Вот величину этого времени и надо объяснить. Конкретно - назовите цифру, которая гарантирует, на ваш взгляд, работоспособность предлагаемого вами варианта. Желательно - с объяснением, почему вы назвали именно такое время.

Не занудствуйте. любое время, хоть 100ms.

- Мастер, не умеющий делать clock stretching

 

Вы чего? Для мастера этого понятия вообще нет, мастер всегда клок генерирует! Что он, сам свой клок растягивать будет? :01:

 

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

Изменено 12 мая, 2010 пользователем ar__systems

[=AK= 14]

Cпасибо, но я не нуждаюсь в ваших поправках. После каждого БАЙТА.

Извольте. Но в этом случае предлагаемая вами система не способна ничего прочитать из удаленного слэйва. Она у вас write-only, и, вдобавок, игнорирует Ack, поскольку, к моменту генерации нерастянутого 9-го клока в байте, Ack от слэйва никак не успеет дойти через IP (надо полагать, фиктивный Ack мастеру вы собираетесь подсовывать своим "фальшивым слэйвом"). :cranky:

 

Не занудствуйте. любое время, хоть 100ms.

Ну, раз уж начинает проясняться, что у вас система однонаправленная (искалеченный вариант write-only), то этот вопрос, действительно, становится неактуален. Предположение, что вы имели ввиду такую... м-м-м... странную систему (что, очевидно, вызвано вашим тотальным непониманием, как работает I2C - иначе такая странная система и в страшном сне не приснилась бы) , полностью объясняет и вашу неспособность отличить предлагаемое вами решение "через IP" от нормального удлинителя I2C, и ваши основания для утверждений о "работоспособности" и "прозрачности" вашего решения, и ваше искреннее недоумение при мысли, что мастеру зачем-то надо растягивать генерируемый им клок. Предлагаю вам сделать следующий шаг и разработать систему think-only - ей вообще не будет нужно ни проводов, ни эфира.

[slavka012 0]

Извольте. Но в этом случае предлагаемая вами система не способна ничего прочитать из удаленного слэйва. Она у вас write-only, и, вдобавок, игнорирует Ack, поскольку к моменту генерации нерастянутого 9-го клока в байте Ack от слэйва никак не успеет дойти через IP (надо полагать, фиктивный Ack мастеру вы собираетесь подсовывать своим "фальшивым слэйвом"). :cranky:

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

 

Ладно, проехали. Нет у меня времени бодаться с таким упрямцем как вы. Любому человеку с мозгами уже было бы понятно что имею ввиду. К слову сказать, поддержка клок-стретчинга -- требование спецификации и ваши "Мастер, не умеющий делать clock stretching" (Повторюсь для особо одаренных -- стретчинг делает слейв - мастер должен только следить за этим) НЕ ЯВЛЯЮТСЯ ПОЛНОЦЕННЫМИ I2C устройствами.

[=AK= 14]

А где ваше утверждение, что клок-стретчин на уровне битов работает? Вы все еще это утверждаете?

Несомненно, работает. Прочитайте, наконец, спецификацию I2C (который уж раз прошу), в данном случае - раздел 8.1. :1111493779:

 

Если до вас опять не дойдет, попросите кого-нибудь перевести вам следующую фразу из раздела 8.3: "the clock synchronization mechanism can be used to enable receivers to cope with fast data transfers, on either a byte level or a bit level." :twak:

 

стретчинг делает слейв - мастер должен только следить за этимх

Ага! Лед тронулся! Ранее вы утверждали, что "для мастера этого понятия вообще нет, мастер всегда клок генерирует!" - а сейчас признали, что мастер все-таки участвует в процессе растягивания клока (хотя и продолжаете при этом нести до смешного алогичную ахинею, будто бы "стретчинг делает (один только) слейв"). Глядишь, так до вас вскорости и синхронизация на уровне битов перестанет быть секретом. :disco:

 

бодаться с таким упрямцем как вы

А меня наоборот, развлекает общение с вами. Напоминает процесс решение ребуса: трудно было угадать заранее, какие фантастические идеи о том, как работает I2C, бродили в вашей голове. Вознаграждение пришло, когда стали прорисовываться те дикие химеры, которые двигали вашим пером. Я такой чудовищной картины заранее представить, конечно, не мог. Повеселили... :)