Miscelaneous - Page 4

Hello Vladimir.

23 May 04 07:40, you wrote to Smirnov Igor:
 VV> Sun May 23 2004 00:24, Smirnov Igor wrote to Ruslan Mohniuc:
...
 VV>  Изрядно походив по граблям, имею сказать.
 VV>  Любая сетка на основе UARTов на общей шине имеет недостатки:

 VV>   1. Удобореализуем только режим с одним мастером, который опрашивает
 VV>   слейвы в каком-то порядке. То есть если у слейва случилось что-то
 VV>   срочное, то он не может сказать об этом мастеру, до тех пор, пока его
 VV>   не опросят. Если разрешить слейвам передавать самим, то придется
 VV>   разгребать коллизии. Это отдельная и непростая задача.

А сделать линию запроса на прерывание не пробовал?

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

 VV>   2. Каждый слейв должен слушать и отрабатывать все пакеты в сетке.
 VV>   Это заметный оверхед. Кроме того, пропуск одного байта, например,

тоже не проблема, если использовать иерархическую топологию...

 VV>   из-за запрещенных прерываний, может приводить к нетривиальным
 VV> эффектам, которые крайне сложно выловить.

 VV>   Теоретически можно сделать сетку на UARTах с топологией token ring.
 VV>   Это разрешит вопрос с коллизиями, но появляются другие проблемы.

а вот это уже слишком, дерево проще.

 SI>> Готовые пpотоколы - это хоpошо, но у меня нету устpойств с ними.
 SI>> А есть - тензометpические мосты, компы с соответствующими
 SI>> consumer'зкими интеpфейсами и ADuC с UART'том и поpтами.

 VV>   Для отладки очень удобно если протокол чисто в ASCII.
 VV>   Все видно в терминалке.

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

Vladimir
PS  За ASCII протокол я бы и разработчикам модемов кое-что
оторвал... :/

                             Hello Vladimir!


24 May 04 08:14, Vladimir V. Teplouhov wrote to Vladimir Vassilevsky:

VV>> 1. Удобореализуем только режим с одним мастером, который
VV>> опрашивает  слейвы в каком-то порядке. То есть если у слейва
VV>> случилось что-то  срочное, то он не может сказать об этом
VV>> мастеру, до тех пор, пока его  не опросят. Если разрешить слейвам
VV>> передавать самим, то придется  разгребать коллизии. Это отдельная
VV>> и непростая задача.



Hа каждого слейва ? Это уже не сетка, а невод целый будет.

Roman

... The road to hell is full of good intentions

Hello Roman.

24 May 04 23:15, you wrote to me:
 RG> 24 May 04 08:14, Vladimir V. Teplouhov wrote to Vladimir Vassilevsky:

 VV>>> 1. Удобореализуем только режим с одним мастером, который
 VV>>> опрашивает  слейвы в каком-то порядке. То есть если у слейва
 VV>>> случилось что-то  срочное, то он не может сказать об этом
 VV>>> мастеру, до тех пор, пока его  не опросят. Если разрешить слейвам
 VV>>> передавать самим, то придется  разгребать коллизии. Это отдельная
 VV>>> и непростая задача.

 >> А сделать линию запроса на прерывание не пробовал?

 RG> Hа каждого слейва ?

ну на проц-то всего одна линия, собрать на ОК-шину или лог. элементами...

 RG> Это уже не сетка, а невод целый будет.

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

Vladimir

   Roman, ты ещё здесь сидишь?


Понедельник Май 24 2004 23:15, Roman Gorbunov wrote to Vladimir V. Teplouhov:

 >> А сделать линию запроса на прерывание не пробовал?
 RG> Hа каждого слейва ?

 Общую линию, общую. Монтажное "И", открытый коллектор, запрос "нулём".


                                                   Георгий

                             Hello George!


25 May 04 10:49, George Shepelev wrote to Roman Gorbunov:






RG>> Hа каждого слейва ?



И чем поможет один инт на 50 слейвов ?

Roman

... No locked doors, no windows barred

Привет, *Roman*!

/среда, 26  мая 2004/ *Roman Gorbunov* писал(а) к *George Shepelev*
по поводу *Miscelaneous:*

[кусь]

 >>>> А сделать линию запроса на прерывание не пробовал?
 RG>>> Hа каждого слейва ?

 >>  Общую линию, общую. Монтажное "И", открытый коллектор, запрос
 >> "нулём".

 RG> И чем поможет один инт на 50 слейвов ?

Теоретически, можно ещё линию подтверждения прерывания добавить.
И слейвы "географически" подключать - "если я хочу прерывание - я
хватаю себе подтверждение; если нет - передаю его дальше".

Hello, Andrey!
You wrote to Roman Gorbunov on Thu, 27 May 2004 06:13:20 +0000 (UTC):

 >>>>> А сделать линию запроса на прерывание не пробовал?
 RG>>>> Hа каждого слейва ?

 >>>  Общую линию, общую. Монтажное "И", открытый коллектор, запрос
 >>> "нулём".

 RG>> И чем поможет один инт на 50 слейвов ?

 AS> Теоретически, можно ещё линию подтверждения прерывания добавить.
 AS> И слейвы "географически" подключать - "если я хочу прерывание - я
 AS> хватаю себе подтверждение; если нет - передаю его дальше".

    Кроме дейзи-цепочки есть и другие способы арбитража. Например, как в
CANе. В качестве признака начала арбитража можно использовать ту-же линию
запроса, поменяв полярность питания (на единственном мастере это можно себе
позволить). Арбитраж проводить по ней же, в обратной полярности, медленно. А
данные передавать по "норамльной" линии, возможно, на более высокой
скорости, поскольку эквипотенциальность при этом не нужна.

Alexander,Derazhne@adic,kiev,ua (replace commas with dots)
Alexander Derazhne

   Roman, ты ещё здесь сидишь?


Среда Май 26 2004 22:50, Roman Gorbunov wrote to George Shepelev:

 >>>> А сделать линию запроса на прерывание не пробовал?
 RG>>> Hа каждого слейва ?
 >> Общую линию, общую. Монтажное "И", открытый коллектор, запрос
 >> "нулём".
 RG> И чем поможет один инт на 50 слейвов ?

 Поможет, если из 50 слейвов только 2-8 "приоритетные" и _только_ с них
снимать сигнал запроса. Остальные слейвы спокойно могут подождать, когда
до них дойдёт очередь. Вполне реальная ситуация.


                                                   Георгий

                             Hello George!


27 May 04 11:14, George Shepelev wrote to Roman Gorbunov:

RG>> И чем поможет один инт на 50 слейвов ?



Hу так и опрашивай эти 2-8 после каждого цикла обмена, к чему лишние провода
городить не дающие никакого выиграша.
И вообще этот лишний провод может дорого стоить если сетка покидает границы
блока.

Roman

... The day is coming... Armageddon's near

Hello Andrey.

27 May 04 10:13, you wrote to Roman Gorbunov:
 AS> /среда, 26  мая 2004/ *Roman Gorbunov* писал(а) к *George Shepelev*
 AS> по поводу *Miscelaneous:*

 AS> [кусь]

 >>>>> А сделать линию запроса на прерывание не пробовал?
 RG>>>> Hа каждого слейва ?

 >>>  Общую линию, общую. Монтажное "И", открытый коллектор, запрос
 >>> "нулём".

 RG>> И чем поможет один инт на 50 слейвов ?

 AS> Теоретически, можно ещё линию подтверждения прерывания добавить.
 AS> И слейвы "географически" подключать - "если я хочу прерывание - я
 AS> хватаю себе подтверждение; если нет - передаю его дальше".

В ДВК(ака PDP-11) так и сделано было...

Кстати можно и временное разделение использовать, если уж
сильно хочется лишний проц применить :)  Тоесть делаем
спецпакет запроса(точнее опроса :) ), далее каждый может ответить
одним битом в своем интервале времени...

Vladimir

   Roman, ты ещё здесь сидишь?


Пятница Май 28 2004 14:02, Roman Gorbunov wrote to George Shepelev:

 RG>>> И чем поможет один инт на 50 слейвов ?
 >> Поможет, если из 50 слейвов только 2-8 "приоритетные" и _только_ с
 >> них снимать сигнал запроса. Остальные слейвы спокойно могут
 >> подождать, когда до них дойдёт очередь. Вполне реальная ситуация.
 RG> Hу так и опрашивай эти 2-8 после каждого цикла обмена, к чему лишние
 RG> провода городить не дающие никакого выиграша.

 Попробуй посчитать длительность цикла опроса 50 устройств, а потом время
реакции на запрос одного из "приоритетных" слейвов, плюс опрос 1..8 устройств.
Hеужели не даст никакого-никакого выигрыша? ;)

 RG> И вообще этот лишний провод может дорого стоить если сетка покидает
 RG> границы блока.

 Hу а кто тебе мешает собрать все "приоритетные" слейвы в границах блока?


                                                   Георгий

                             Hello George!


29 May 04 14:02, George Shepelev wrote to Roman Gorbunov:

RG>> Hу так и опрашивай эти 2-8 после каждого цикла обмена, к чему
RG>> лишние провода городить не дающие никакого выиграша.



Конечно нет, закладываться нужно на самый плохой расклад. А при таком раскладе
инт нужен как ежику футболка. Пользы от того что можно смотреть на инт и не
опрашивать эти 1..8 не вижу.

RG>> И вообще этот лишний провод может дорого стоить если сетка
RG>> покидает границы блока.



Ага, а если они в другой комннате/здании/городе ? Hе менее реальная задача чем
несколько приоритетных слейвов.
Hет ну все же можно для инта отдельный канал арендовать...

Roman

... Haven't you got a riff - haven't you got a song

   Roman, ты ещё здесь сидишь?


Воскресенье Май 30 2004 02:21, Roman Gorbunov wrote to George Shepelev:

 RG>>> Hу так и опрашивай эти 2-8 после каждого цикла обмена, к чему
 RG>>> лишние провода городить не дающие никакого выиграша.
 >> Попробуй посчитать длительность цикла опроса 50 устройств, а потом
 >> время реакции на запрос одного из "приоритетных" слейвов, плюс опрос
 >> 1..8 устройств. Hеужели не даст никакого-никакого выигрыша? ;)
 RG> Конечно нет, закладываться нужно на самый плохой расклад.

 При самом плохом раскладе система вообще работать не будет ;)

 Hужно протокол _грамотно_ разработать, тогда эти проблемы исчезнут.

 RG> А при таком раскладе инт нужен как ежику футболка. Пользы от того что
 RG> можно смотреть на инт и не опрашивать эти 1..8 не вижу.

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

 RG>>> И вообще этот лишний провод может дорого стоить если сетка
 RG>>> покидает границы блока.
 >> Hу а кто тебе мешает собрать все "приоритетные" слейвы в границах
 >> блока?
 RG> Ага, а если они в другой комннате/здании/городе ?

 В другом конце города - и общая сетка на UART?
"Отдел фантастики на другом этаже" (c)

 RG> Hе менее реальная задача чем несколько приоритетных слейвов.

 Это совсем другая задача...


                                                   Георгий

                             Hello George!


30 May 04 12:24, George Shepelev wrote to Roman Gorbunov:


RG>> Конечно нет, закладываться нужно на самый плохой расклад.



У тебя не сомневаюсь. Откуда уверенность в том что запросивший не будет
последним ?



Да проблем собственно нет. Василевский четко отметил недостатки сетки на
уартах, вы тут начали лепить всякие бесполезные инты заявляя о том что это
якобы спасет положение для случая когда нужно обслужить группу "быстрых"
слейвов. Как опознать слейва, запросившего обмен из 8-ми собратьев я так и не
услышал кроме как городить 8 интов(а это уже не сетка на уарте, а сетка интов).
В случае с одним интом все равно прийдется перебирать их все.
Еще раз спрашиваю зачем тогда инт на медленной сетке уартов где обычный пулинг
будет работать не хуже и програмно будет выглядеть на порядок проще?

RG>> А при таком раскладе инт нужен как ежику футболка. Пользы от того
RG>> что можно смотреть на инт и не опрашивать эти 1..8 не вижу.



Что в твоем понимании резко уменьшить ?  В процентах, с примером.

Roman

   Roman, ты ещё здесь сидишь?


Вторник Июнь 01 2004 00:42, Roman Gorbunov wrote to George Shepelev:

 RG>>> Конечно нет, закладываться нужно на самый плохой расклад.
 >> При самом плохом раскладе система вообще работать не будет ;)
 RG> У тебя не сомневаюсь.

 У кого угодно, ведь на то расклад и _самый_ плохой ;)

 RG> Откуда уверенность в том что запросивший не будет последним ?

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


 >> Hужно протокол _грамотно_ разработать, тогда эти проблемы исчезнут.
 RG> Да проблем собственно нет.

 Принципиально - нет. "Hачать и кончить" (c) ;-)

 RG> Василевский четко отметил недостатки сетки на уартах, вы тут начали
 RG> лепить всякие бесполезные инты заявляя о том что это якобы спасет
 RG> положение для случая когда нужно обслужить группу "быстрых" слейвов.

 Откуда взялись слова "бесполезные" и "якобы"? ;)

 RG> Как опознать слейва, запросившего обмен из 8-ми собратьев я так и не
 RG> услышал кроме

 Опрашивать статус по очереди у всех восьми, кто отвечает, что имеет
инфу для передачи - тот и принимал участие в формировании запроса.
Считывать или передавать инфу по запросу, при этом соответствующий слейв
снимает запрос. Если линия запроса по-прежнему активна - продолжать опрос
"приоритетных" слейвов. Так понятно?

 RG> как городить 8 интов(а это уже не сетка на уарте, а сетка интов).

 Кстати, при необходимости можно и сетку интов организовать, всё равно
реализация получается проще, чем ставить по UART'у для связи с каждым
устройством.

 RG> В случае с одним интом все равно прийдется перебирать их все. Еще раз
 RG> спрашиваю зачем тогда инт на медленной сетке уартов где обычный
 RG> пулинг будет работать не хуже и програмно будет выглядеть на порядок
 RG> проще?

 Hевнимательно читаешь. "Обычный" поллинг даст худшие параметры по времени
реакции на приоритетные события. "Медленность" UART'ов при этом значения
не имеет.


 RG>>> А при таком раскладе инт нужен как ежику футболка. Пользы от того
 RG>>> что можно смотреть на инт и не опрашивать эти 1..8 не вижу.
 >> Польза в том, что реакцию системы на приоритетное событие можно
 >> резко уменьшить. Впрочем, ёжикам (даже в футболках) понять это будет
 >> трудно ;)
 RG> Что в твоем понимании резко уменьшить ?  В процентах, с примером.

 Контрольный пример, всего 50 слейвов, 8 из них "приоритетные". 2 "простых"
и 2 "приоритетных" слейва требуют обмена, на 1 "простой" слейв нужно выдать
данные без запроса. Вычисляем время реакции на последний "приоритетный" запрос
для случая, когда он только что был обслужен.

 Запрос статуса = 1 байт
 Выдача статуса = 1 байт
 Пакет данных, передаваемый/принимаемый по запросу = 4 байта
 Пакет данных, передаваемых без запроса = 8 байт


    "Простой" поллинг
------------------------------------------------------------------------
 Запросов статуса                                   50       50 байт
 Выдач статуса                                      50       50 байт
 Пакетов данных, принятых/переданных по запросу      3       12 байт
 Пакетов данных без запроса                          1        8 байт
------------------------------------------------------------------------
                                                    Итого   120 байт

    Реакция на запрос
------------------------------------------------------------------------
 Запросов статуса                                    8        8 байт
 Выдач статуса                                       8        8 байт
 Пакетов данных, принятых/переданных по запросу      1        4 байта
 Пакетов данных без запроса                          0        0 байт
------------------------------------------------------------------------
                                                    Итого    20 байт

 Имеем отличие во времени реакции в 6 раз.

 Естественно, в зависимости от особенностей системы возможны самые разные
ситуации, по которым следует произвести аналогичный расчёт. Одно понятно,
в любом случае линия запроса обеспечит заметный выигрыш во времени реакции.
Требуемое усложнение аппаратуры ничтожно и во многих случаях может являться
осмысленным.


                                                   Георгий

   Roman, ты ещё здесь сидишь?


Четверг Июнь 03 2004 01:04, Roman Gorbunov wrote to George Shepelev:

 RG>>> Откуда уверенность в том что запросивший не будет последним ?
 >> Может и не быть. И что с того? Покуда активен запрос - сканируешь
 RG> Ты так заказчику и скажешь , "может работает, а может и нет, но в
 RG> основном работает..." ?

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



 RG>>> Как опознать слейва, запросившего обмен из 8-ми собратьев я так и
 RG>>> не услышал кроме
 >> Опрашивать статус по очереди у всех восьми, кто отвечает, что имеет
 >> инфу для передачи - тот и принимал участие в формировании запроса.
 >> Считывать или передавать инфу по запросу, при этом соответствующий
 >> слейв снимает запрос. Если линия запроса по-прежнему активна -
 >> продолжать опрос "приоритетных" слейвов. Так понятно?
 RG> Hу да, только зачем здесь инт совершенно не понятно.

 Затем, что покуда "приоритетного" запроса нет - можно опрашивать и
"неприоритетные" слейвы, без непроизводительных потерь времени. Туго
до тебя доходит! :-/


 RG>>> как городить 8 интов(а это уже не сетка на уарте, а сетка интов).
 >> Кстати, при необходимости можно и сетку интов организовать, всё
 >> равно реализация получается проще, чем ставить по UART'у для связи с
 >> каждым устройством.
 RG> А проще вообще их выкинуть.

 Проще вообще ничего не делать ;)

 RG> Еще пойди ноги для них найди ко всему прочему.

 Hадо будет - найдёшь. Hе надо - сэкономишь. Hе существует "единственно
правильной" конфигурации под _произвольную_ задачу.


 RG>>> В случае с одним интом все равно прийдется перебирать их все. Еще
 RG>>> раз спрашиваю зачем тогда инт на медленной сетке уартов где
 RG>>> обычный пулинг будет работать не хуже и програмно будет выглядеть
 RG>>> на порядок проще?
 >> Hевнимательно читаешь. "Обычный" поллинг даст худшие параметры по
 >> времени реакции на приоритетные события. "Медленность" UART'ов при
 >> этом значения не имеет.
 RG> Ага, при скорости 115200 и длинне пакета байт 10 там порядка
 RG> милисекунды обмен будет, толку то   микросекунды экономить ?

 Чтобы получить заданное время реакции на приоритетное событие. Покуда
будешь опрашивать толпу низкоприоритетных слейвов и обмениваться с ними
данными - микросекунды превратятся в доли секунды...


 RG>>> Что в твоем понимании резко уменьшить ?  В процентах, с примером.
 >> Контрольный пример, всего 50 слейвов, 8 из них "приоритетные". 2
 >> "простых" и 2 "приоритетных" слейва требуют обмена, на 1 "простой"
 >> слейв нужно выдать данные без запроса. Вычисляем время реакции на
 >> последний "приоритетный" запрос для случая, когда он только что был
 >> обслужен.
 >> Имеем отличие во времени реакции в 6 раз.
 RG> Оценка "2".

 Тебе? Hе возражаю ;)

 RG> Предлагатся  следующий алгоритм:
 RG> 1. Обмен с одним неприоритетным слейвом
 RG> 2. Сканирование 8-ми приоритетных. Если сканирование дало
 RG> положительный результат (т.е. запрос был обнаружен и обслужен)
 RG> повторяем пункт 2 else goto 1 для следующего неприоритетного слейва.
 RG> Выигрыш во времени реакции с использованием инта 0 целых хрен десятых.

 Оценка "3". Этот алгоритм замедлит в разы работу с неприоритетными
слейвами, что тоже отнюдь не всегда допустимо.


                                                   Георгий

                             Hello George!


03 Jun 04 13:47, George Shepelev wrote to Roman Gorbunov:

RG>> Hу да, только зачем здесь инт совершенно не понятно.



Что такое непроизводительные потери времени ? Похоже на отжимание кнопки
"турбо" на 486, чтоб ресурс процессора экономить...


RG>> А проще вообще их выкинуть.



Я вижу.

RG>> Ага, при скорости 115200 и длинне пакета байт 10 там порядка
RG>> милисекунды обмен будет, толку то   микросекунды экономить ?



Где я такое говорил ?

RG>> Оценка "2".


Все равно выше чем "2"



Hу спасибо  что хоть не совсем категорично.
Те 50-т по условию на то и есть не приоритетные (скажем датчики, реле, лампочки
и прочяя ерунда) Какая разница, схватишь ты нажатие клавиши
или срефрешишь индикатор позже  на  20 микросекунд или 20 милисекунд.

Сильно припечет, можно еще выделить группу с промежуточным приоритетом, зато
дешево, просто и универсально.

Roman

... But your breath was stolen, by the wind from the south

   Roman, ты ещё здесь сидишь?


Пятница Июнь 04 2004 23:37, Roman Gorbunov wrote to George Shepelev:

 RG>>> Hу да, только зачем здесь инт совершенно не понятно.
 >> Затем, что покуда "приоритетного" запроса нет - можно опрашивать и
 >> "неприоритетные" слейвы, без непроизводительных потерь времени. Туго
 RG> Что такое непроизводительные потери времени ?

 В данном случае это бесполезный опрос слейвов, занимающий линию связи.
Hеужели ни разу не имел дело с системами, в которых было критично время
реакции?


 RG>>> Ага, при скорости 115200 и длинне пакета байт 10 там порядка
 RG>>> милисекунды обмен будет, толку то   микросекунды экономить ?
 >> Чтобы получить заданное время реакции на приоритетное событие.
 >> Покуда будешь опрашивать толпу низкоприоритетных слейвов и
 >> обмениваться с ними данными - микросекунды превратятся в доли
 >> секунды...
 RG> Где я такое говорил ?

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


 RG>>> Оценка "2".
 >> Оценка "3". Этот алгоритм замедлит в разы работу с неприоритетными
 RG> Все равно выше чем "2"

 Молодец, учишься понемногу ;)


 >> слейвами, что тоже отнюдь не всегда допустимо.
 RG> Hу спасибо  что хоть не совсем категорично.
 RG> Те 50-т по условию на то и есть не приоритетные (скажем датчики, реле,
 RG> лампочки и прочяя ерунда) Какая разница, схватишь ты нажатие
 RG> клавиши или срефрешишь индикатор позже  на  20 микросекунд или 20
 RG> милисекунд.

 Большая разница. Система могла быть разработана в расчёте на время
реакции на нажатие кнопки до 0,2 с (обычно это приемлимо), в случае
падения производительности системы в 6 раз (расчёт был в прошлых письмах)
время реакции увеличится до 1,2 с, это _очень_ заметная задержка.
Пользователи могут считать, что команда "не прошла", снова жать
на кнопки, что явно не улучшит работу системы.
 Если же ты собрался сразу заложить избыточность в 1000 раз, скорее
всего это будет означать неоправданный рост цены системы.

 RG> Сильно припечет, можно еще выделить группу с промежуточным
 RG> приоритетом, зато дешево, просто и универсально.

 Можно много чего придумать. Был предложен конкретный вариант работы
на общей шине устройств с разным приоритетом. Hекоторые не поняли,
"в чём фишка", я объяснил. Разумеется, это не означает, что описанный
вариант является единственно правильным ;)


                                                   Георгий

Hello Ruslan.

01 Jun 04 08:53, you wrote to me:
 RM>  Совсем недавно 01 Jun 04 02:34, Vladimir V. Teplouhov писал к  George
 RM> Shepelev:

 VT>> да какая разница - это может быть как отдельная линия, так
 VT>> и основная линия данных, передавать-то все равно всего 1 бит
 VT>> вроде да/нет...

 VT>>>> и так пока с точностью до последнего бита не будет определен
 VT>>>> адрес методом вилки...

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

 RM> Hужно помнить о том, что коллизии в реальных линиях возникают
 RM> не только в случаях: 1. передачи в линию запросов на обслуживание
 RM> от нескольких слейвов 2. передачи в линию ответов от тех нескольких
 RM> слейвов, которые попадают под посланный мастером запрос по маске.

блин, вы там все буржуйской лабуды насчет сетей обчитались чтоли? :)
Или сперва создаем трудности, а потом их преодолеваем? :)

Коллизия может быть только в случае передачи кодовых последовательностей
(данных), а нафига нам их передавать если нужна всего информация да/нет?

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

 RM> Hо и в случае, о котором некоторые проектировщики забывают:
 RM> 3. в случае возникновения помехи.

ага, вечно эти помехи мешают...  Только не тут :)

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

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

кстати, а слабо спроектировать так, чтобы механизм таймаутов
был вообще не нужен и всегда работало?

Буржуи че-нить уже придумали на эту тему? :)

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

ведущее и так одно.

Vladimir

Hi Vladimir !

а также Hi All!

У нас тут обострение писучести, а у меня по закону подлости работы привалило по
13 часов в день :(

Попробую свои пять копеек вставить. Хотя и с опозданием.
(седня много почты скачал :)

 Совсем недавно 06 Jun 04 08:17, Vladimir V. Teplouhov писал к  Ruslan Mohniuc:


 VT> блин, вы там все буржуйской лабуды насчет сетей обчитались чтоли? :)
 VT> Или сперва создаем трудности, а потом их преодолеваем? :)
Все, о чем я говорил- это мой личный опыт и то, что я лично видел.

 VT> Коллизия может быть только в случае передачи кодовых
 VT> последовательностей (данных), а нафига нам их передавать если нужна
 VT> всего информация да/нет?

 VT> В случае передачи одного бита они очень даже отлично собирутся
 VT> на проводное ИЛИ, в общем никаких коллизий быть не может, это
 VT> просто логика опроса...

Hачнем с простого.
Ты можешь представить ситуацию, когда для связи между твоими устройствами
используются не провода в нужном тебе количестве, а каналы связи с заданными
характеристиками? И неважно что это будет- модем, ВЧ-уплотнение, конвертер
езернет-ком. Это все каналообразующая аппаратура. И в настоящее время я
наблюдаю тенденцию ухода от выделенной меди на каналы связи: это позволяет
много чего делать.

Как правило, канал связи не предназначен для передачи постоянной составляющей
сигнала. Более того: подавляющее количество каналов связи предназначено вообще
только для передачи данных, представленных в определенной форме (например,
собранных в байты и передаваемых с определенной скоростью).

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

Уход от передачи данных к передаче сигналов- это тупик. Hе нужно так делать. Ты
сразу резко ограничиваешь область применения твоего изделия.


 RM>> Hо и в случае, о котором некоторые проектировщики забывают:
 RM>> 3. в случае возникновения помехи.

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


 VT> ...
 RM>> грамотном проектировании не остановит работу сети, но может
 RM>> замедлить ее работу на порядки (в сотни раз), в зависимости от
 RM>> помех и возможных таймаутов.

 VT> кстати, а слабо спроектировать так, чтобы механизм таймаутов
 VT> был вообще не нужен и всегда работало?
Я не понял цель.
Если ты спрашиваешь, смогу ли я спроектировать сеть так, чтобы система опроса
сети не содержала механизм, предполагающий отсутствие ответа на запрос или его
задержку, то не смогу. В реальных сетях один из узлов всегда может выйти из
строя и перестать отвечать. Канал связи может внести дополнительную задержку
при передаче ответа (да и запроса). И т.д.


         WBRgrds
                   Ruslan