Стандарт RS-485 и программное управление (RTS)

Нет, автоматическое выключение много позднее появилось rs485,это фича устройства.

Спасибо... Очень жаль, видимо отвертятся =(

Это следует теперь всегда прописывать в ТЗ черным по белому, чтобы не делали такую парашу, в то время как 99% другие делают автоматическое управление.

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

А вык лючать можно после приёма своей же передачи, достаточно надёжно работает.

В Linux, при любой загрузке процессора, без RT-патчей ? Не верю (С). В протоколах обмена есть конкретные указания для таймингов - в течении какого времени должно откликнуться slave-устройство и оно достаточно невелико. С софтовым переключением на прием всегда есть шанс не успеть переключиться до начала передачи от ведомого.

ilovewindows

В Linux, при любой загрузке процессора, без RT-патчей ? Не верю (С). В протоколах обмена есть конкретные указания для таймингов - в течении какого времени должно откликнуться slave-устройство и оно достаточно невелико. С софтовым переключением на прием всегда есть шанс не успеть переключиться до начала передачи от ведомого.

Именно так. Это источник проблемы. Много лет назад мне приходилось работать с этим несчастным RS-485 и там тоже был не-авто режим, но теперь производитель исправил эту проблему в биосе. И я тогда тоже мучился из-за того что ОС (тогда это была икспи, сейчас Linux) не всегда успевала переключать, выводя поток из слипа...

И чем всё заканчивалось?

Вообще, не силён в этих старых портах, но, по мне это всё мусор. Там не то что ретрансмита нет в случае потери синхронизации или если пакет побился. Там целая наука как вообще понять что данные побились. Причём, у разных контроллеров по-разному. Но это моё мнение, сильно в этом не ковырялся.

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

На уровне софта всё отслеживается, какая разница некорректный стоповый или ошибка четности в байте, не пришел пакет и всё .

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

Но суть в том что с платами других производителей, хост загружен до отказа, и при этом никаких потерь передач RS-485. Так что аппаратное авто-управление - не роскошь и не излишество.

Вообще, не силён в этих старых портах, но, по мне это всё мусор. Там не то что ретрансмита нет в случае потери синхронизации или если пакет побился. Там целая наука как вообще понять что данные побились.

Ник всё объясняет :) Не мусор, ибо всё еще миллиард возможных применений в тех местах, где не требуется даже мегабайты слать, а просто управляющие команды. Реализовать UART в FPGA или контроллере (готовый), и засунуть это через FTDI - проще пареной репы. Потому и живо до сих пор и будет наверное десятилетия еще.

Ретрансмит - софтово пишешь (у меня так). Данные побились? Добавляю CRC16. Ноль проблем :)

Ретрансмит - софтово пишешь (у меня так). Данные побились? Добавляю CRC16. Ноль проблем :)

Переизобретение велосипеда же :(.

слабенький одноплатник с нулевой нагрузкой

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

Не, ну кто же спорит то, сильно облегчает жизнь. Для каких-то частных случаев можно решить и так. Сделай четыре провода, если один ведомый, можно вообще не выключать. Доберись до прерываний - можно добавлять в конец один пакета лишний байт,по уходу первого бита получать прерывание и выключаться. Масса способов извратится и получить удовольствие. Железку в конце концов купить нормальную, стоит она от тысячи :).

Железку в конце концов купить нормальную, стоит она от тысячи :)

Думаем над таким вариантом, если субподрядчик упрётся. Но в моей специфике, придется металлический корпус изготавливать для этой маленькой какашки, хоть внутри и ширпотребовское гогно, ибо разъем надо винтовой.

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