vesago (26.03.2025 14:09, просмотров: 6875)-
- Так, что это за такое! А робота спросить забыли!... POV(6 знак., 28.03.2025 13:39, картинка, картинка)
- Спасибо. Действительно - 25 год на дворе. Эпоха ИИ. - vesago(28.03.2025 18:49)
- Dmx512 RDM и его процедура Discovery , всё давно украли до вас - DMX512(27.03.2025 00:53,
)
- Излишне усложненный вариант метода половинного деления. Попытка ускорить поиск для варианта когда устройств мало. Если устраивает быстродействие при простом поиске тогда нет смысла реализовывать все эти навороты. В худшем варианте по этому методу время поиска будет раза в два больше простого метода половинного деления, из-за большего размера пакетов с информацией и более длинных времен ожидания ответа. - AlexBi(27.03.2025 08:20)
- Обычно в таком случае сначала по-одиночке назначают устройствам адрес: подключаем его единственным к отдельной шине и широковещательной командой назначаем. А если прямо уже в готовой сети, выше отличный вариант уже предложили: давать широковещательную команду "серийник ХХХ, теперь твой адрес ЙЙЙ"… А потом уже по этому адресу проверять - вняла ли железка. Правда, как-то это буторно - по серийнику задавать адрес. Eddy_Em(326 знак., 26.03.2025 18:08)
- Странное сочетание "RS485" и "серийный номер". Казалось бы, что
общего? Может, желаемый протокол озвучите? - max(26.03.2025 17:33)
- Подозреваю, что Tyмблep(106 знак., 26.03.2025 17:38)
- Есть конторка Доза, дозиметры какие-то лабает... у них свой протокольчик DiBus (открытый? .. но файло с описанием у меня было откуда-то) по RS-485 искать девайсы с проописанными адресами. - POV(26.03.2025 17:22)
- Можно попробовать так: Tyмблep(215 знак., 26.03.2025 17:18)
- Обычно такое нужно, когда адрес еще не задан вообще и мастер хочет
определить топологию и назначить адреса. Серийник длинный и
уникальный, а адрес обычно короткий. - Andreas(26.03.2025 17:22)
- И всё то же самое. Tyмблep(635 знак., 26.03.2025 17:37)
- Обычно такое нужно, когда адрес еще не задан вообще и мастер хочет
определить топологию и назначить адреса. Серийник длинный и
уникальный, а адрес обычно короткий. - Andreas(26.03.2025 17:22)
- напрашивается что-то типа LordN(154 знак., 26.03.2025 15:20)
- Метод половинного деления. Например ищем минимальный номер,
спрашиваем всех "есть кто с номером меньше N/2?" Кто есть передает
ноль. Если ответы наложатся, все равно что-то примется, и мы узнаем
что есть кто-то. Если ни кто не ответит, узнаем, что ни кого нет. И
так пока не останется один. Его как-то исключаем, что бы в
следующей итерации он не отвечал, и опять ищем минимальный номер по
той же схеме. Если устройств много ищем сперва минимальный, потом
максимальный, с учетом AlexBi(114 знак., 26.03.2025 15:11)
- если делать по уму, то одиночные запросы/ответы не годятся. Нужен
пакетный обмен с контрольными суммами, а это кратно увеличит время
(банально, более длинные пакеты, если приходить к какому-то
стандартуобщему, более-менее универсальному синтаксису, то навскидку это минимум 5-6 байт. соответсвенно время транзакции Adept(728 знак., 26.03.2025 17:40)- придумался метод исключения коллизий ответов на броадкаст запрос адреса по методу дихотомии: - устройства начинают ответ не сразу, а в соответствии с таймаутом, который равен интервалу передачи байта, помноженному на "константа минус две последних цифры DevID". Все клиенты слушают шину, и видя, что кто-то даёт ответ, - лезть со своими пакетами на шину нe будут. Adept(850 знак., 27.03.2025 17:18)
- А ответы не наложатся потому как на этот запрос есть задержка
ответа, зависящая от номера - General(26.03.2025 15:46)
- Если вариантов номеров много, например 1млн, тогда для выделения
каждому своего слота во времени потребуется очень долго ждать. А
еще из-за разности частот у разных устройств такое количество
просто не разойдется по времени и наложения все равно будут.
Поэтому лучше что бы ответы просто совпали, тогда их наложение
будет даже не заметно. - AlexBi(26.03.2025 16:23)
- RS-485 речь об адресах которых 245 типа - General(27.03.2025 06:11)
- Если вариантов номеров много, например 1млн, тогда для выделения
каждому своего слота во времени потребуется очень долго ждать. А
еще из-за разности частот у разных устройств такое количество
просто не разойдется по времени и наложения все равно будут.
Поэтому лучше что бы ответы просто совпали, тогда их наложение
будет даже не заметно. - AlexBi(26.03.2025 16:23)
- Спасибо. Я имел дело с алгоритмом похожим. Но со стороны
подчиненного устройства. Хост два числа высылал. Если серийник
больше или равен одному числу и с другой стороны меньше или равен
другому числу, мое устройство на шину посылало ноль. Работало
шустро, но я не знаю по какому принципу софт на хосте формировал
эти два числа. И команды, чтобы такой-то серийник освободил шину не
было. - vesago(26.03.2025 15:19)
- Тот же метод половинного деления. Только интервал задается в явном
виде, а не с одной границей задаваемой в неявном виде (при поиске
минимума это ноль). Может так даже быстрее получится, с учетом
отсутствия отдельной команды для исключения из поиска. Первого ищем
установив нижнюю границу в ноль и двигая верхнюю. Потом ставим
нижнюю границу на найденный номер +1 и опять ищем двигая верхнюю. И
так пока всех не найдем. - AlexBi(26.03.2025 15:27)
- Спасибо, надо переварить в целом про алгоритм половинного деления.
Оптимальнее наверное вряд ли выйдет. - vesago(26.03.2025 15:30)
- метод дихотомии. ищет на заданном отрезке. что-нить наверняка
найдёт. не факт, что всё, но что-нибудь - точно. - LordN(26.03.2025 15:35)
- Дихотоми́я - раздвоенность, последовательное деление на две части, более связанные внутри, чем между собой. (Вики) bnb62(363 знак., 26.03.2025 16:12)
- метод дихотомии. ищет на заданном отрезке. что-нить наверняка
найдёт. не факт, что всё, но что-нибудь - точно. - LordN(26.03.2025 15:35)
- Спасибо, надо переварить в целом про алгоритм половинного деления.
Оптимальнее наверное вряд ли выйдет. - vesago(26.03.2025 15:30)
- Тот же метод половинного деления. Только интервал задается в явном
виде, а не с одной границей задаваемой в неявном виде (при поиске
минимума это ноль). Может так даже быстрее получится, с учетом
отсутствия отдельной команды для исключения из поиска. Первого ищем
установив нижнюю границу в ноль и двигая верхнюю. Потом ставим
нижнюю границу на найденный номер +1 и опять ищем двигая верхнюю. И
так пока всех не найдем. - AlexBi(26.03.2025 15:27)
- если делать по уму, то одиночные запросы/ответы не годятся. Нужен
пакетный обмен с контрольными суммами, а это кратно увеличит время
(банально, более длинные пакеты, если приходить к какому-то
- Это не CAN конечно, но оттуда можно идеи дернуть. Andreas(2 знак., 26.03.2025 14:34, ссылка, ссылка)
- А посвежее редакции нет ? К тому же LSS Fastscan не работает без допиливания. - 3m(26.03.2025 16:44)
- Благодарю - почитаю. - vesago(26.03.2025 15:00)
- Если драйверы выдержат коллизию - то можно взять идейки от Dallas
One Wire. - LightElf(26.03.2025 14:27)
- Вопрос в том что примет приемник при коллизии. Может там получатся
сплошные 1 и не примется ничего вообще. Даже если что то и примется
то с большой вероятностью с Framing Error или вовсе как Break. У
оборудования с обработкой Break в большинстве случаев все очень
плохо а framing error типовые обработчики прерываний тоже не очень
обрабатывают. В общем не заточен 485-й на коллизии и в целом на
мультимастер. Поэтому в XXI веке место ему как говорится
"фтопке"!!! - 3m(26.03.2025 16:53)
- Достаточно того, чтобы при коллизии хоть что-то принялось. То есть
после запроса есть три варианта: 1) никто не ответил 2) ответил
один слейв нормальным пакетом 3) в линии мусор, что означает
коллизию и наличие более одного устройства в данной маске - LightElf(27.03.2025 11:35)
- Если драйвер одного слева гораздо сильнее драйвера второго слейва,
то мастер не заметит коллизии, несмотря на то, что второй слейв
тоже что-то отвечает. - Ale3000(27.03.2025 11:57)
- Не верю что совсем не заметит, какой-нибудь бит да сбойнет. CRC не
сойдется. Но согласен, что на LIN это работает лучше. - LightElf(27.03.2025 16:21)
- Если один слэйв на расстоянии 5м от мастера а другой за 250м и они отвечают одновременно то будьте уверены что мастер услышит только близкого и без каких либо искажений. - 3m(28.03.2025 13:29)
- Не верю что совсем не заметит, какой-нибудь бит да сбойнет. CRC не
сойдется. Но согласен, что на LIN это работает лучше. - LightElf(27.03.2025 16:21)
- Если драйвер одного слева гораздо сильнее драйвера второго слейва,
то мастер не заметит коллизии, несмотря на то, что второй слейв
тоже что-то отвечает. - Ale3000(27.03.2025 11:57)
- Достаточно того, чтобы при коллизии хоть что-то принялось. То есть
после запроса есть три варианта: 1) никто не ответил 2) ответил
один слейв нормальным пакетом 3) в линии мусор, что означает
коллизию и наличие более одного устройства в данной маске - LightElf(27.03.2025 11:35)
- Спасибо, припоминаю - было такое. Почитаю алгоритм. - vesago(26.03.2025 14:34)
- Вопрос в том что примет приемник при коллизии. Может там получатся
сплошные 1 и не примется ничего вообще. Даже если что то и примется
то с большой вероятностью с Framing Error или вовсе как Break. У
оборудования с обработкой Break в большинстве случаев все очень
плохо а framing error типовые обработчики прерываний тоже не очень
обрабатывают. В общем не заточен 485-й на коллизии и в целом на
мультимастер. Поэтому в XXI веке место ему как говорится
"фтопке"!!! - 3m(26.03.2025 16:53)
- Так, что это за такое! А робота спросить забыли!... POV(6 знак., 28.03.2025 13:39, картинка, картинка)
