[MrBearManul 0]

Уважаемые коллеги, возможно поможет сей документ. Там реализованы рецессивный и доминантный уровень  с помощью приёмопередатчика RS-485.

[_3m 4]

4 часа назад, MrBearManul сказал:

Уважаемые коллеги, возможно поможет сей документ. Там реализованы рецессивный и доминантный уровень  с помощью приёмопередатчика RS-485.

Это отступление от стандартного включения драйвера RS485. Тем более что ТС явно указал что у него "ну и чтобы было веселее RE и DE на драйвере 485 закорочены вместе,.."
Если не соблюдать стандарт то удобнее сразу применить CAN трансиверы вместо RS-485

[MrBearManul 0]

20 минут назад, _3m сказал:

Если не соблюдать стандарт то удобнее сразу применить CAN трансиверы вместо RS-485

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

[vladec 7]

Если у Вас на шине RS-485 может быть много устройств, то в процессе присвоения адресов лучше использовать "древовидный" алгоритм. Из готовых стандартных, посмотрите реализацию процедуры Дискавери в протоколе RDM (E1.20 - 2006), широко используемом в сетях DMX.

[jcxz 184]

8 часов назад, _pv сказал:

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

Я думаю - Вы ошибаетесь. Имхо - вероятность коллизии будет высокой. А чтобы её снизить до минимально приемлемой, придётся сильно увеличивать время поиска.

Цитата

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

В смысле? Вы что - собираетесь сделать выход на передачу только что включившихся слэйвов сразу, в любой момент времени, а не в определённые задаваемые мастером окна времени???

Тогда если у вас там ходит какой-то протокол обмена типа "запрос/ответ", это будет прямым его нарушением. Система изначально будет кривой в целом. Это не решение, это - кривой костыль.

8 часов назад, _pv сказал:

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

У вас и драйвера RS-485 стоят с большим временем переключения TX<->RX? Тогда да - тут будет трудно придумать что-то более-менее вменяемо работающее....  

Я думал: у вас время переключения TX<->RX - единицы мкс....

1 час назад, _3m сказал:

Если не соблюдать стандарт то удобнее сразу применить CAN трансиверы вместо RS-485

Кстати - здравая мысль! 

У меня в текущем проекте как раз так и сделано для одного из интерфейсов. 1Мбод стабильно.

[jcxz 184]

Пришёл в голову ещё один вариант ускорения моего алгоритма:

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

Мастер посылает соответствующий кадр старта такого цикла. Слэйвы подчитывают некую контрольную информацию по своему длинному адресу (ID). Например - CRC16 от ID. Это всего 16 бит, а не 64. Посылает точно также как я описывал для 64 бит. В конце посылки с большой вероятностью останется только один слэйв выигравший арбитраж на этой отправке. Он об этом знает сам. И он отправляет свой ID (с некоей контрольной информацией). Отправляет обычным образом. Мастер принимает и проверяет контрольную информацию. Если всё ок - он знает ID этого слэйва и назначает ему короткий адрес. Иногда эти CRC от двух разных слэйвов могут совпасть. В таких случаях мастер обнаруживает это по нарушению контрольной информации. И тогда для этих редких случаев только выполняется отдельный цикл сканирования полного 64-битного ID.

Можно и ещё более короткий CRC использовать - надо подбирать.

[_pv 52]

1 hour ago, jcxz said:

Я думаю - Вы ошибаетесь. Имхо - вероятность коллизии будет высокой. А чтобы её снизить до минимально приемлемой, придётся сильно увеличивать время поиска.

да вот, вроде даже численно проверил, для коллизии надо чтобы два передатчика попали в "окно" 0.5мкс.

 

сверху гистограммы 256 устройств для задержек 100,200,500,1000, и шириной бина 0.5 мкс, снизу график сколько столбцов выше 1 в процентах от 256, в зависимости от задержки.

1 hour ago, jcxz said:

В смысле? Вы что - собираетесь сделать выход на передачу только что включившихся слэйвов сразу, в любой момент времени, а не в определённые задаваемые мастером окна времени???

Тогда если у вас там ходит какой-то протокол обмена типа "запрос/ответ", это будет прямым его нарушением. Система изначально будет кривой в целом. Это не решение, это - кривой костыль.

этот кривой костыль должен отработать один раз при включении, а появление/исчезновение слэйвов по ходу работы - это уже некая авария.

1 hour ago, jcxz said:

У вас и драйвера RS-485 стоят с большим временем переключения TX<->RX? Тогда да - тут будет трудно придумать что-то более-менее вменяемо работающее....  

Я думал: у вас время переключения TX<->RX - единицы мкс....

время переключения 0.5мкс: десяток тактов или сколько там тактов у msp430 на запись в порт, в течении которых он ещё не переключился и начал передавать, а передачу от соседа уже не увидит.

получившиеся 500мкс это время на то что вы называете циклом, принять от одного слэйва ID и отправить ему обратно адрес.

1 hour ago, jcxz said:

2 hours ago, _3m said:

Если не соблюдать стандарт то удобнее сразу применить CAN трансиверы вместо RS-485

У меня в текущем проекте как раз так и сделано для одного из интерфейсов. 1Мбод стабильно.

тоже думал над применением физики CAN вместо 485, но не до конца понятно как оно будет жить вместе с нормальными rs485 если их в эту же сеть воткнуть понадобится.

 

30 minutes ago, jcxz said:

Пришёл в голову ещё один вариант ускорения моего алгоритма:

можно пойти дальше и просто собрать отдельно ID и попробовать подобрать хэш функцию которая ID в однобайтный адрес преобразует более менее без коллизий, ну и потом отдельно проверить/поменять несколько штук у которых адреса всё-таки совпали.

[_3m 4]

Кстати если передавать break то конфликта на шине можно избежать.
Только его надо передавать управляя входом DE трансивера.

Остается вопрос сможет ли мастер уверенно ловить break - во многих уарт с этим не хорошо.

[vladec 7]

Еще раз, зачем изобретать велосипед, когда все уже придумано до нас и даже стандартизировано. Посмотрите же Discovery Method протокола RDM, там решается ровно та же задача -- поиск устройств на шине и присвоение им адресов с использованием Binary Search Tree.