-
- если делать по уму, то одиночные запросы/ответы не годятся. Нужен
пакетный обмен с контрольными суммами, а это кратно увеличит время
(банально, более длинные пакеты, если приходить к какому-то
стандартуобщему, более-менее универсальному синтаксису, то навскидку это минимум 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)
- если делать по уму, то одиночные запросы/ответы не годятся. Нужен
пакетный обмен с контрольными суммами, а это кратно увеличит время
(банально, более длинные пакеты, если приходить к какому-то