Не надо смешивать теплое с мягким. Обеспечение тишины 3,5 символьной тишины для разделения фреймов и односимвольной тишины, как длинного стопа, для обеспечения гарантированной отстройки любых валидных байтов от мусора в линии это разные вещи.

Не смотря на все выше написоннае Вами, НИКАКОГО наличия никакой паузы, если это не задуманый через анус модбас, просто НЕ требуется. Совсем не требуется.

А вот это уже ПРАВИЛЬНЫЕ слова.

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

http://electronix.ru/forum/index.php?showt...t&p=1383243

Да у миландра есть такие и мы применяем на волне импорта-замещения.
С импортными не сталкивался. Назовите одну-другую модельку, пожалуйста.

Ну и в продолжение темы, расскажу быль.
Не далее как пару месяцев назад столкнулись с необычным поведением драйвера ST S485EC.
Этот драйвер по нашему мнению - фейлсэйф и имеет растяжки >50К на линиях А и B к питанию и земле.
Так вот, если поставить терминатор 120 Ом, получается делитель из трёх резисторов и между линиями A и B оказывается потенциал менее 200мВ.
А напряжение менее 200мВ воспринимается, как неопределённое состояние, на ноге RO передатчика устанавливается логический 0 и мы ловим старт бит.
Вопрос - зачем так сделано (зачем ноль)?
Стоит убрать терминатор, ложные старт биты уходят.
Для себя сделали вывод, что терминатор без нормальных растяжек (~600 Ом) - зло.
С драйвером миландра со смещённым порогом таких косяков нет.

Сам прибор вместе с датчиками где-то 150 мА потребляет. К этому добавляются потребление приемопередатчиков, терминаторов, подтягивающих резисторов, USB-МК и ток через кабель. Кабель - 5-ти метровый USB. Пока потребление не мерял, но макет работает, правда пока без гальванической развязки.

Что касается Modbus и прочего, то дело в том, что у меня пакет данных от датчика составляет 12 байт плюс могу рассчитать контрольную сумму. Это траффик от датчика до МК1. Там чистый UART и скорость не хочется задирать, она там и так 350 кбит/с. Далее, к МК1 подсоединены несколько датчиков (8). То есть если приделывать к пакетам большие обрамления в МК1, то опять же придется повышать скорость передачи по RS-485 (передача на МК2).

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

Называется это "Fail-Safe". Из тех что у меня локально лежит (какбы недавно интересовался и еще не потер): SN65LBC184 (12 uA подтяжка), ADM4850–ADM4857бб ADM3483/ADM3485/ADM3488/ADM3490/ADM3491, LTC1480. Если гугл открою, то там конечно еще есть.
Но не вижу смысла специально искать и выбирать по наличию этой опции. Сам закладываю по сотне килоом в растяжку, чтобы не думать что за драйвер впаяют.

Предыдуший оратор http://electronix.ru/forum/index.php?showt...t&p=1383549 более чем четко объяснил почему "по сотне килоом" это буквально ни о чем. Эта припарка для терминированной линии просто фигня.

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

Ну это резко меняет дело.

При использовании COBS длина вашего (короткого) пакета увеличится на 1 байт. После преобразования COBS в вашем пакете не будет нулей. Для очистки грязи из приемного буфера надо дважды передать 0 до начала самого пакета. Первый 0 может оказаться испорченным, зато второй дойдет и очистит буфер. Для простоты можно еще раз передать 0 по завершению пакета. "Простота" заключается в том, что это позволяет не парсить приходящие байты "на лету", надо ловить только 0 и проверять валидность пакета целиком после прихода нуля. Итого, 4 байта накладных расходов.

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

А я смогу это преобразование выполнить на 8-битном процессоре с тактовой частотой 12 Мгц? Я имею ввиду по скорости, это преобразование много времени занимает?
И еще, после передачи от датчиков на МК мне надо как минимум добавить один байт - номер датчика (1,2,3..8). Можно ли это сделать без ущерба протоколу? Кроме того, нули то должен именно этот МК отправлять, потому что он передает по RS-485

На чем угодно. Хоть на брэйнфаке.


Мизер. Посмотрите сами на код в Википедии и не задавайте таких вопросов. Причем, там приведен "сложный" вариант кода, поскольку они обрабатывают сообщения произвольного размера, а потому перекладывают из одного буфера в другой, чтобы по ходу можно было вставлять дополнительные байты. В случае же коротких сообщений (меньше 255 байт) все гораздо проще, поскольку заранее все известно: один дополнительный байт появится в начале. Поэтому и перекладывать ничего не надо, одного буфера достаточно, просто незакодированное сообщение надо в него класть начиная не с 0-го байта, а 1-го. Потом просто пробегаете по буферу и заменяете нули.


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

А я вот не уверен.
ИМХО Fail-Safe - это не обязательно смещённый порог, а лишь наличие растяжек.
Хочется понять есть-ли специальный термин, определяющий, что есть именно смещение порога.
Хочу понять для собственного ЛИКБЕЗа.

Чтобы спать спокойно мы стали выводить четыре клеммы для RS485: VABC.
А задачу по установки растяжек и терминаторов перекладываем на плечи эксплуатантов.
Т.к. от слабых растяжек с терминатором один вред, а сильные ставить нельзя т.к.
при параллельной работе приборов в одной сети RS485 они суммируют проводимость и получаем другие грабли...

Я имел ввиду, что у меня есть данные 12 байт плюс считаю контрольную сумму = 13 байт. Преобразую все это дело по COBS-у, получается 14 байт. Это данные от одного датчика. Они поступают на МК через обычный UART, в обработчике DMA я добавляю номер датчика. Так вот эта добавка не будет противоречить COBS-у?
По идее, мне надо бы преобразовывать данные в этом МК, а не в датчике, но там у меня и так проблемы со временем, не хочется еще какие то преобразования там проводить.

Я не понимаю о чем вы говорите. Выражайте свои мысли яснее. Тот, кто отсылает сообщение, может добавить в сообщение что угодно, затем закодировать и переслать. Приемник раскодирует принятое сообщение обрабатывает как требуется, если надо - добавляет номер датчика. В чем проблема-то? Не играет роли кто является приемником, кто передатчиком. И что вы там в своем железе нагородили, кто у вас там "датчик", кто "МК", причем тут ДМА, и кто чего должен добавлять, то ли на передающем конце, то ли на приемном - так телепатов нет.

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

Конструкция такая: Датчики (8 штук) по UART подключаются к МК1, МК1 по RS-485 подключается к МК2, МК2 подключается по USB к ПК
То есть в Вашей концепции передатчик - это МК1, а приемник - МК2.
А мне удобнее COBS преобразование сделать в датчике, а в МК1 добавить байт - номер датчика.


почему? данных же мало, всего то 12 байт.

Извините, я не смогу ответить, не задумывался над этим.
Вы правы, это другое- если подать напряжение на вход, то эти подтяжки никак не перетянут вход в сторону от нуля. Но там начинает работать гистерезис на переключение (Input hysteresis voltage).


Почему Вы напрямую не подключаете шину RS-485 от MK1 к компьютеру? Или почему не подключаете компьютер к RS-485 просто как еще один узел сети RS-485, если уж MK2 действительно нужен?

У меня задание - сделать USB устройство. Видимо это связано с вопросами синхронизации прибора с другими устройствами.

Так подключите MAX485 прямо к FT232R или CP2103 или возьмите готовый переходник, а всю обработку делайте на компьютере. Зачам там еще МК?

А этот преобразователь, он же только данные отправляет? А счетчик USB фрейма?

А почему датчик не может сразу добавить свой номер и CRC, а потом закодировать сообщение?

Добавить байт (т.е номер датчика) к уже закодированному COBS сообщению - вообще-то проблема, даже если этот номер не равен 0. Потому что в корректной реализации при раскодировании сообщения на месте этого байта должен быть или 0 (это значит, что сообщение закончено), или число последующих ненулевых байт в сообщении. Конечно, можно наставить костылей, например, если длина сообщения фиксирована, то последний байт обрабатывать не так, как остальные. Только нехорошо это.


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


SOF-ы автоматически считаются "на нижнем уровне". А накой вам этот счетчик?

а как? датчик же не знает какой у него номер. все датчики одинаковые, воткнул в 1-е гнездо, значит датчик №1, если в о 2-е, то №2


Для синхронизации. У меня в USB МК отправляется сначала счетчик фрейма (2 байта), потом данные

Тогда пусть все датчики ставят в нужное место номер 1, кодируют и отправляют. А ваш МК1 просто заменит номер 1 в этом месте на действительный номер датчика. Если он не будет равен 0, то на COBS это никак не повлияет.

Однако при этом придется обойтись без CRC на все сообщение, поскольку CRC надо добавлять до того, как кодировать по COBS. Можно, конечно, CRC считать в датчике, а "1" добавлять потом, но при этом номер датчика не будет охвачен CRC. Это не очень хорошо, но работать будет.


Какой счетчик? Взятый в тот момент, когда вы получили сообщение, или в тот момент когда вы его сформировали в буфере для отправки? Неужто вы думаете, что он будет отправлен в том же фрейме? Ведь вы же BULK используете, а он асинхронный.

Специфиkация USB:

5.12.4.1.1 Asynchronous
Asynchronous endpoints cannot synchronize to SOF or any other clock in the USB domain.

Хорошая идея, я подумаю...
Нет смысла охватывать номер датчика CRC, он же все равно будет переписан. Хотя может быть испорчен дальше, но дальше все таки дифф пара RS-485.


я использую изохронный

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

Понятно, спасибо.
А еще Вы писали, что в Википедии "сложный" вариант перекодировки COBS. Где тогда можно простой посмотреть?

Опять товарища =AK= куда-то понесло - предложил для RS485 с шумами в паузах протокол канального уровня, позволяющий отловить конец пакета, но не его начало после шума. А потом еще предложил всунуть между канальным и физическим уровнями кусок транспортного (номер пакета). Аплодисменты.

Atlantis-, почитайте про сетевую модель OSI. У вас есть физический уровень - RS485. Поверх него вы строите канальный, отвечающий за разбивание потока вашей информации на пакеты и контрольную сумму. COBS тут не подходит по указанной выше причине - малейший шум в паузе и пакет вы потеряли. Посмотрите на SLIP, реализуйте что-то похожее, но с отметкой не только конца, но и начала пакета. Далее строите сетевой уровень - добавляете в протокол адреса ваших датчиков. Если у вас каждый датчик воткнут в свой отдельный интерфейс - сетевой уровень на этом участке вам не нужен. Далее сверху накладываете транспортный уровень - добавляете в протокол номер пакета. И сверху водружаете прикладной уровень - собственно ваши данные.

При передаче идете по модели сверху вниз: берете данные (прикладной уровень), добавляете к ним номер пакета(транспортный уровень), добавляете адрес(сетевой уровень), считаете контрольную сумму и обкладываете все это байт-стаффингом (канальный уровень, SLIP-подобные протоколы позволяют делать это побайтно, прямо в процессе передачи, не видя пакета целиком) и в конце передаете получившийся пакет данных через UART в RS-485 (физический уровень).
На приемной стороне вы двигаетесь по модели снизу вверх: принимаете байты из RS-485 (физический уровень), обрабатывая SLIP-подобный протокол убираете байт-стаффинг и выделяете начало/конец пакета, считаете контрольную сумму (канальный уровень), далее отделяете и обрабатываете адрес (сетевой уровень), следом номер пакета (транспортный уровень) и в результате получаете ваши исходные данные очищенные от всей этой шелухи, т.е. в том виде, в котором эти данные поступили из прикладного уровня на передающей стороне.

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

"а это уж вы сами" © Щербаков



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

Никакой шум в паузе не повлияет на прием пакета из-за того, что передатчик передает два 0 до начала пакета. После паузы приемник гарантировано получит хотя бы один 0, после чего "шумовой" пакет будет проверен и отвергнут из-за несовпадения CRC, а также из-за несоответствия правилам COBS. А следующий сразу же вслед за этим истинный пакет будет принят без искажений.

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




Совет неверный. Нужен один 0xFF.

Что-то мне эта тема напомнила... Ага, вот эту тему.
Там долго выясняли способ гарантированно восстановить битовую синхронизацию при непрерывной передаче потока. =AK= описал применяемый им способ посылки двух подряд символов 0x0F, при котором второй символ гарантированно ловится. Потом выяснилось, что это не так, по крайней мере, не со всеми контроллерами UART.
Символ же 0xFF, переданный перед началом пакета, гарантированно восстановит битовую синхронизацию:
Нажмите для просмотра прикрепленного файла

Байтовую Битовая, если надо, захватывается по 0x55.

Как-то неразумно называть признак начала кадра именем "END".

RFC 1055:
Про признак начала ничего не сказано.

Это не ко мне . В реальные реализации протокола ПРАВИЛЬНО отрабатывают и одиночные разделители и начало-конец и любое количество "END" в качестве разделителей. Что совершенно ествественно и соответственно никаких "реализуйте что-то похожее, но с отметкой не только конца, но и начала пакета" не требуется.


Из этого-же RFC:

Предлагаю конец теме — передаём, после получения TC=1 отключаем драйвер, делаем задержку, устанавливаем RE=1, немного попринимали, далее сразу устанавливаем RE=0, включаем драйвер, делаем задержку и снова передаём.

Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF.


Варианты с задержками (в частности, Modbus RTU) обсуждались ранее. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера.

Избыточное кодирование — та же задержка, плюс ещё сколько писанины, в сравнении хотя бы с тупо NOP'ами — автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница.

Не наводите тень на плетень. Никакая и ничья кривизна здесь совершено ни причем. Абсолютно незавтсимое и естественое решение.


Да уж "трясти надо"(с)

А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку.

Суть в том, что последовательность 0xF0, 0xF0 "прочистит" приёмник не всегда, поскольку она опирается на framing error, который обрабатывается разными контроллерами по-разному.
То же самое и с последовательностью 0x00, 0x00.
А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое.

Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере.

Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF.

Что же касается 0xF0 в том топике, то там мой (радио)канал требовал, чтобы количество 0 и 1 в последовательности было равно. Поэтому я использовал именно 0xF0 как специальный символ для байт-синхронизации и взвешенное кодирование 6b8b для данных, и все прекрасно работало с обычным микроконтроллерным UART-ом.

не совсем понял, придется делать XOR всех байт пакета?


с чего это? USB наиболее удален от помех будет. и длина RS-485 будет 5 метров кабеля, а USB меньше 1 см на плате

Поясните пожалуйста поподробней, что не так, если передавать 0x00, 0x00 вначале? Первый 0x00 вызовет ошибку фрейма, второй 0x00 будет принят
Если 0xFF передавать, то возможно, что стартовый бит 0xFF попадет на стоповый бит "байта помехи". И тоже будет ошибка фрейма.

Не всегда. Существуют контроллеры, которые считают бит, на котором случился FE, стартовым для следующего фрейма. В случае такого контроллера второй байт 0x00 тоже вызовет FE. Вот тут я рисовал картинку. (Там для 0xF0, но суть та же).

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

Я надеюсь, к "таким" контроллерам не относятся STM32 ? У них есть флаг Frame Error.
А вот в Silabs (C8051F320) я такого флага не нашел, вообще ничего про это не написано...

Ага. А вас по каким-то причинам напрягает операция XOR? Религия не позволяет, или типа того? Ну тогда не делайте, посылайте как есть, на практике результат будет одинаковый.


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