=AK= 18 11 мая, 2010 Опубликовано 11 мая, 2010 · Жалоба Вы тут долго спорили что интерфейсы и протоколы это разные вещи Вы обмишулились. Спутали меня с моим оппонентом. Перечитайте сообщение №25 еще раз внимательнее, если до вас не дошло. I2C спецификация включает как электрическую часть, так и формат данных Тем не менее, в предлагаемом варианте в рамках каждой из плат - чистый I2C. И для мастера абсолютно все равно, что происходит в кабеле - ему кажется, он непосредственно он общается со своими слэйвами, находящимися в паре сотен метров от него. Следовательно, I2C мастер имеет полное право сказать, что "I2C и на 250 метров работает". А то, как происходит доставка на такое расстояние, - разве что-то меняет в этом факте? Какой это к черту I2C? Вы его еще в IP запихайте и скажите что у вас I2C на тыщи километров работает. А вот через IP прозрачно для I2C мастера никак не получится. Изучайте I2C. Если так и не поймете, почему через не получится - обращайтесь, я объясню. Как общаться? Между собой - никак. Центральная управляющая программа должна быть на ПК. Вредный совет. Так, конечно, в принципе делать тоже можно, но это наименее предпочтительный вариант, в силу своей ненадежности, наихудшей из возможных. ПК выключили - все встало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Тем не менее, в предлагаемом варианте в рамках каждой из плат - чистый I2C. И для мастера абсолютно все равно, что происходит в кабеле - ему кажется, он непосредственно он общается со своими слэйвами, находящимися в паре сотен метров от него. Следовательно, I2C мастер имеет полное право сказать, что "I2C и на 250 метров работает". А то, как происходит доставка на такое расстояние, - разве что-то меняет в этом факте? Ладно, я свое мнение уже высказал по данному вопросу. А вот через IP прозрачно для I2C мастера никак не получится. Изучайте I2C. Если так и не поймете, почему через не получится - обращайтесь, я объясню. А я думаю получится. Почему это нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба А я думаю получится. Почему это нет? Потому что при связке через IP невозможно выдержать времена, требуемые I2C. В этом принципиальное отличие от того варианта, который я предложил. А раз невозможно выдержать времянки - то мастер не сможет работать с удаленным слэйвом точно так же, как с локальным (а именно это и есть "прозрачность"). Более того, существует множество упрощенных реализаций мастеров I2C, которые вообще не смогут работать с тормозящими слэйвами, которые получатся у вас при связке по IP. А тормозить они у вас будут в любом случае, независимо от реализации. Вот представьте себе устройство (даталоггер), которое, скажем, раз в 100 мс читает и пишет несколько байт в I2C EPROM. Теперь вы эту EPROM выносите наружу и связываете с мастером I2C через IP, используя любой имеющийся на рынке экспандер I2C. Будет у вас такой даталоггер работать? Нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Вредный совет. Так, конечно, в принципе делать тоже можно, но это наименее предпочтительный вариант, в силу своей ненадежности, наихудшей из возможных. ПК выключили - все встало. В данной ситуации - наиболее простое в реализации решение. Потому и посоветовал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Потому что при связке через IP невозможно выдержать времена, требуемые I2C. В этом принципиальное отличие от того варианта, который я предложил. А раз невозможно выдержать времянки - то мастер не сможет работать с удаленным слэйвом точно так же, как с локальным (а именно это и есть "прозрачность"). Более того, существует множество упрощенных реализаций мастеров I2C, которые вообще не смогут работать с тормозящими слэйвами, которые получатся у вас при связке по IP. В I2C нет никаких требуемых времен. И слэйв и мастер могут торомозить работу другой стороны чтобы подогнать под свою скорость. А тормозить они у вас будут в любом случае, независимо от реализации. Вот представьте себе устройство (даталоггер), которое, скажем, раз в 100 мс читает и пишет несколько байт в I2C EPROM. Теперь вы эту EPROM выносите наружу и связываете с мастером I2C через IP, используя любой имеющийся на рынке экспандер I2C. Да вы меня не агитируйте! :) Я бы такой хренью заниматься бы не стал в любом случае. Сценарий-то вы предложили явно нелепый. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба В I2C нет никаких требуемых времен. И слэйв и мастер могут торомозить работу другой стороны чтобы подогнать под свою скорость. Хи-хи... Я же вас просил - изучите I2C, прежде чем нести ахинею. В этом режиме слэйв не успеет через IP затормозить мастера в момент непосредственно после старта. Потому что тормозить он обязан быстро, иначе мастер убежит - не догонишь. Сценарий-то вы предложили явно нелепый. Опять хи-хи. Я вам такой даталоггер могу живьем показать. Уже лет 15 выпускается серийно. Ладно, я свое мнение уже высказал по данному вопросу. Как выяснилось, ваше мнение сформировалось вследствие элементарного недостатка знаний. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Хи-хи... Я же вас просил - изучите I2C, прежде чем нести ахинею. В этом режиме слэйв не успеет через IP затормозить мастера в момент непосредственно после старта. Потому что тормозить он обязан быстро, иначе мастер убежит - не догонишь. Вы немножко на шаг вперед думать можете? Тормозить мастера может фальшивый слейв, самостоятельно, пока не дождется ответа от реального слейва. Я вам такой даталоггер могу живьем показать. Уже лет 15 выпускается серийно. Не надо меня за идиота держать. Я не сомневаюсь, что они выпускаются. Нелепо его к памяти по I1C через интернет подрубать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Вы немножко на шаг вперед думать можете? Тормозить мастера может фальшивый слейв, самостоятельно, пока не дождется ответа от реального слейва. Распишите подробнее, как это, по-вашему, должно происходить. Нелепо его к памяти по I1C через интернет подрубать. Странно. Это же ваша собственная идея была, которую вы высказали в посте №38. А сейчас продолжаете спорить, что она работоспособная - вот даже "фальшивый слейв" придумали. Интересная аберрация сознания... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Странно. Это же ваша собственная идея была, которую вы высказали в посте №38. А сейчас продолжаете спорить, что она работоспособная - вот даже "фальшивый слейв" придумали. Это был пример. По моему это ясно. Разумеется работоспособный. Но это не значит что я его рекомендую к использованию. Что касается по-подробнее, то что вам не понятно -- после приема каждого байта приемник имеет право удерживать клок в нуле на время обработки этого байта. Что еще надо объяснять? IP-вставка будет тормозить передатчик на время пока данные уйдут на другой конец и реальный приемник не отпустит клок, вот и все. Считаете, что это не прозрачно -- ваше право. Но это в полном соотвествии с протоколом I2C. Почитайте, это назыается clock stretching. Так в чем говорите ахинея-то заключается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 12 мая, 2010 Опубликовано 12 мая, 2010 · Жалоба Что касается по-подробнее, то что вам не понятно -- после приема каждого байта Бита приемник имеет право удерживать клок в нуле на время обработки этого байта. Что еще надо объяснять? IP-вставка будет тормозить передатчик на время пока данные уйдут на другой конец и реальный приемник не отпустит клок Вот величину этого времени и надо объяснить. Конкретно - назовите цифру, которая гарантирует, на ваш взгляд, работоспособность предлагаемого вами варианта. Желательно - с объяснением, почему вы назвали именно такое время. Считаете, что это не прозрачно Конечно, непрозрачно. Я вам уже привел несколько примеров, для которых предлагаемое вами решение оказалось непрозрачным: - Мастер, не умеющий делать clock stretching - Даталоггер, которому требуется обеспечить запись в EEPROM за определенное время Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 12 мая, 2010 Опубликовано 12 мая, 2010 (изменено) · Жалоба Бита Cпасибо, но я не нуждаюсь в ваших поправках. После каждого БАЙТА. Вот величину этого времени и надо объяснить. Конкретно - назовите цифру, которая гарантирует, на ваш взгляд, работоспособность предлагаемого вами варианта. Желательно - с объяснением, почему вы назвали именно такое время. Не занудствуйте. любое время, хоть 100ms. - Мастер, не умеющий делать clock stretching Вы чего? Для мастера этого понятия вообще нет, мастер всегда клок генерирует! Что он, сам свой клок растягивать будет? :01: Даже ваш даталоггер сможет работать по локалке, если ему надо пару байт записать. Изменено 12 мая, 2010 пользователем ar__systems Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 13 мая, 2010 Опубликовано 13 мая, 2010 · Жалоба Cпасибо, но я не нуждаюсь в ваших поправках. После каждого БАЙТА. Извольте. Но в этом случае предлагаемая вами система не способна ничего прочитать из удаленного слэйва. Она у вас write-only, и, вдобавок, игнорирует Ack, поскольку, к моменту генерации нерастянутого 9-го клока в байте, Ack от слэйва никак не успеет дойти через IP (надо полагать, фиктивный Ack мастеру вы собираетесь подсовывать своим "фальшивым слэйвом"). :cranky: Не занудствуйте. любое время, хоть 100ms. Ну, раз уж начинает проясняться, что у вас система однонаправленная (искалеченный вариант write-only), то этот вопрос, действительно, становится неактуален. Предположение, что вы имели ввиду такую... м-м-м... странную систему (что, очевидно, вызвано вашим тотальным непониманием, как работает I2C - иначе такая странная система и в страшном сне не приснилась бы) , полностью объясняет и вашу неспособность отличить предлагаемое вами решение "через IP" от нормального удлинителя I2C, и ваши основания для утверждений о "работоспособности" и "прозрачности" вашего решения, и ваше искреннее недоумение при мысли, что мастеру зачем-то надо растягивать генерируемый им клок. Предлагаю вам сделать следующий шаг и разработать систему think-only - ей вообще не будет нужно ни проводов, ни эфира. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
slavka012 0 13 мая, 2010 Опубликовано 13 мая, 2010 · Жалоба Извольте. Но в этом случае предлагаемая вами система не способна ничего прочитать из удаленного слэйва. Она у вас write-only, и, вдобавок, игнорирует Ack, поскольку к моменту генерации нерастянутого 9-го клока в байте Ack от слэйва никак не успеет дойти через IP (надо полагать, фиктивный Ack мастеру вы собираетесь подсовывать своим "фальшивым слэйвом"). :cranky: Опа. сообщение мистическим образом поменялось? А где ваше утверждение, что клок-стретчин на уровне битов работает? Вы все еще это утверждаете? Ладно, проехали. Нет у меня времени бодаться с таким упрямцем как вы. Любому человеку с мозгами уже было бы понятно что имею ввиду. К слову сказать, поддержка клок-стретчинга -- требование спецификации и ваши "Мастер, не умеющий делать clock stretching" (Повторюсь для особо одаренных -- стретчинг делает слейв - мастер должен только следить за этим) НЕ ЯВЛЯЮТСЯ ПОЛНОЦЕННЫМИ I2C устройствами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 13 мая, 2010 Опубликовано 13 мая, 2010 · Жалоба А где ваше утверждение, что клок-стретчин на уровне битов работает? Вы все еще это утверждаете? Несомненно, работает. Прочитайте, наконец, спецификацию 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, бродили в вашей голове. Вознаграждение пришло, когда стали прорисовываться те дикие химеры, которые двигали вашим пером. Я такой чудовищной картины заранее представить, конечно, не мог. Повеселили... :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться