Как драйвер линукса обрабатывает ввод из rs485?

Забыл еще вопрос, какой способ вычисления crc16 считается в линукс стандартным и есть его реализация в системной библиотеке?

man tcsetattr

не, нету

все это очень сильно зависит от реализации конкретной железяки. в общем случае, просто вычитывай по одному байту и используй poll/select для таймаутов

crc в библиотеке нет, т.к. контрольная сумма завязана на определенный полином, и реализуется в пару строк кода. примеров в сети валом

и используй poll/select для таймаутов

Можно поподробнее, это нужно делать в отдельном потоке?

нет

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

Что до CRC16, то это — мудачество и идиотизм.

Почему? А как проверить, что данные пришли без искажения?

Чтобы проверить, что данные пришли без искажений, просто посчитай checksum! XOR всех байтов. Но в реальной жизни на это просто забивают, т.к. по 485 особо быстро не попередаешь, так что вероятность получить ошибку там нулевая. А если ты вместо 485 будешь CAN использовать, так вообще не парься: проверку данных нижний уровень обеспечивает.

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

В общем, идиотизм чистой воды.

по 485 особо быстро не попередаешь

RS-485 can be used with data rates up to 10 Mbit/s or, at lower speeds, distances up to 1,200 m.

Under some conditions it can be used up to data transmission speeds of 64 Mbit/s.

Отцы то дураками не были и не зря ведь изобрели crc16?

Фу, какой тупак, еще и выдаётся за реальную жизнь

кстати, как хороший пример, можешь глянуть исходники libmodbus - https://github.com/stephane/libmodbus/blob/master/src/modbus-rtu.c

Спасибо

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

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

эдик, занимайся своей астрофизикой, и не лезь к нам в промышленные стандарты, ок?

Вредитель в треде. Зачем делать плохую контрольную сумму, если за то де время можно сделать хорошую, ещё и являющуюся стандартом в куче дочерних протоколов.

Там есть буферизация?

да, разумеется, емнип около 4кб по дефолту

Я в callback функции вычитываю этот буфер когда он полностью заполнился.

нет, так не надо - если у тебя модбас и прибор ругнётся на, например, номер регистра, то ты вместо условно 200 байт ответа с данными регистров получишь кроху байт с ошибкой, если два прибора шлют дату то ты попадёшь в дважды переполненный буфер, а если ты купишь переходник с эхо то ты всегда будешь попадать в переполнение либо будешь постоянно менять размер буфера под тип переходника :-)

формально, можно поискать событие «приход данных» а дальше выждать паузу, которая требуется для передачи пачки, но это событие в некоторых реализациях отсутствует а в некоторых работает через опу, зато везде можно запросить сколько сейчас байт лежит в буфере и соотв. просто почитывать это значение.

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

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

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

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

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

есть еще супер-быстрый режим :-) но он не совместим с модбасом и нужен когда приборов овер-дофига

Зачем вообще вычислять контрольную сумму в тех случаях, когда она не нужна совсем? Ну, получил ты неправильные данные - забей на них и жди правильные…

Я астрофизикой последний раз занимался лет 15 назад. А сейчас у меня как раз вся эта хрень «промышленностандартная». Поэтому я и негодую. Особо выражаю негодование в сторону сименсо-боше-севов, у которых все настолько плохо, что их железяки можно только из-под игровых приставок сконфигурировать.

Ну и совсем уж негодую по поводу мудаков, которые в 21 веке используют модбас. Поубивал бы!

Зачем вообще вычислять контрольную сумму в тех случаях, когда она не нужна совсем? Ну, получил ты неправильные данные - забей на них и жди правильные…

А как ты поймёшь что данные не правильные без контрольной суммы? Ну вот пришло тебе с твоего температурного датчика не 20+-2 градусов, а 200 - это ошибка или пожар? А если он после этого не отвечает, это обрыв (из-за которого данные и побились) или пожар?

Ну и совсем уж негодую по поводу мудаков, которые в 21 веке используют модбас. Поубивал бы!

Как хорошо, что мы даже не в курсе кто ты такой :-)

нужно 3 датчика и результат решать голосованием

ну Эдик как бы местная знаменитость, это ты в танке сидишь

он-да. А ты кто такой?

а ты

нужно 3 датчика и результат решать голосованием

О как, а пространственно-временное сравнение мы при этом шлем в нафиг и вычленять локальное повышение (возгорание) на фоне общего роста температуры мы видимо будем на пепелище

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

• нет смысла направлять три пирометра в одну точку - они все три сложнят если будет повод
• на волоконных в принципе не получится организовать измерение четко в одной точке не переплатив овердофига или не убив точность
• инвазивные термопары … трижды сверлиться ради отсутствия црц?

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

стандарты не дураки придумали

*смотрит на FTP*

негодуешь ты на уровне водителя такси. конкретика будет? а 21 век оставь для тредов всяких-разных ангулярщиков

Там есть буферизация?

485 ничем не оличается от 232, програмный буфер tty - 4 килобайта

Как указать драйверу, что мне нужен буфер размером 259 байт?

никак

И как привязать эту функцию к событю «буфер заполнен»?

в SoC на arm используют DMA для UART и он сам режет принимаемый поток данных на куски, т.е. если тебе предали 259 байт то ровно столько ты и прочитаешь в юзерспейс - очень удобно на полудупоексных каналах с пакетной передачей.

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

Протокол должен быть простым и удобным. Лучше всего - обычный текстовый протокол, чтобы, подключившись простым терминалом, ты мог видеть, что в линии происходит и команды всякие разные подавать. В случае с CAN идеал - гольные посылки по 0..8 байт (даже CANopen позволяет такое, если работать на уровне PDO или SDO).

У нас, вон, 6-метровый и 1-метровый телескопы уже много лет работают на простейшем протоколе. Без этих ваших хипстерских модбасов. А задумали делать модернизацию, как вдруг оказалось, что мудачье-производители застряли в прошлом веке и многие пускатели на модбасе! Договариваемся об изменении протокола. Либо сами будем делать кое-какие вещи. Это лучше, чем уподобляться идиотам, которые в 21 веке гоняют протокол, разработанный еще для медленных аналоговых телефонных линий!

Ну вот пришло тебе с твоего температурного датчика не 20+-2 градусов, а 200

Если в следующий раз пришло опять 200, значит, кирдык датчику или пожар. Если потом ничего не пришло - ахтунг по причине «кирдык датчику или пожар». Что тут сложного-то?

Протокол должен быть простым и удобным.

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

уставки, отбраковка… нет, не слышал

Очень даже прекрасно слышал и использую в работе. Или ты тут так толсто троллить пытаешься?

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

Если потом ничего не пришло - ахтунг по причине «кирдык датчику или пожар». Что тут сложного-то?

Сложного тут то, что ты не понимаешь кирдык линии (плохое црц = 200 градусов игнорируется) или пожар (црц корректное = пожар) это разные события, и во многих случаях, ошибочный «пожар» стоит очень много денег из-за стартующего пожаротушения (а оно бывает и на одноразовых капсулах) которое топит оборудование (вода) или ставит раком все производство (газ/пена) надолго

И это мы ещё про простые датчики температуры, я вообще не прожаркой а вибрационкой занимаюсь, там в ВЧ спектре в принципе многие сигналы не повторяются (перекус прутка забора это один единственный всплеск на 200+Гц) который нельзя ни проигнорировать ни пропустить ни переспросить - если ты его провафлил, приняв за ошибку передачи, то привет привет, а многие штуки реализуются на подсчете таких всплесков - пропустил один из трёх - пролюбил тревогу, насчитал лишний - получит рапорт о ложняке от сб

Зачем нужно ловить всплески: http://npfpol.ru/upload/medialibrary/b0e/b0ea33d2e70337649ee66d87fcc7e2c5.png
На фоне просто шума: http://npfpol.ru/upload/medialibrary/c87/c873dfd144934d4bdd98d40bccdbd381.png

Ну или зачем их считать: http://npfpol.ru/upload/medialibrary/e06/e0602c7b9c762d5733ea5c88aa5145c1.png

Ну и главное - а в чем прикол от црц то отказываться? Нулевой кортекс или тинька бомжатская их тыщи раз в секунду могут посчитать, трафик 1-2 байта при условии что 115200 сейчас ну очень дешевый на километр, а из поприличней так там мегабиты уже идут

П.с. вот примерно так выглядит длинный сигнал четырех ударов рукой (левый график) - красный график это 100-200Гц и там всего по 1-2 точке на фоне длинных сигналов у НЧ: https://www.linux.org.ru/images/19207/original.png а перекус это 1-2 всплеска всего в частотах ещё выше (200/400/800Гц) у которых огибающая выше (40/80/160Гц) частоты обмена (33Гц) и соотв если точка обломилась передаться то это реально проблема ибо именно вч позволяет проводить половину всякой аналитики

смотрит на FTP

Фтп, насколько помню, очень хороший протокол:

• ты можешь за день написать на любых счётах хоть ручкой и сервер и клиент
• ты можешь использовать его без клиента вообще (притом с текстовыми файлами это будет полностью осмысленно)
• он не ест ресурсы от слова вообще в базовом варианте, пень 200 мог обслужить весь завод не напрягаясь на вполне себе лихих скоростях под 10 мегабит :-)
• он легко расширяется (тот же многопоток, или мд5 по требованию) ибо прост как валенок

Вообщем свою задачу транспорта файлов он вполне себе обеспечивает, а вот безопасность или супер эффективное использование канала или убер стабильность ты должен уже накрутить на этот транспортный уровень сам, либо использовать что-то более специализированное.

Надо датчики разных типов! ИК, ёмкостные, микроволновые. Чтоб сразу несколько на нарушителя срабатывали, и тогда можно исключать ложную тревогу от отдельного датчика.

Если мне нужна надежность, я пользуюсь CAN-шиной (а там CRC считается аппаратно, как и разруливание многих других проблем). А если тупо побаловаться, так и тупой USART сойдет с текстовым протоколом безо всяких CRC.

Причем, построенные по второму способу железяки у меня уже несколько лет верой-правдой работают. Если вдруг будут замечены косяки по причине проблем в линии связи, тогда и буду думать, как их решить. Нулевой этап - избавиться от источников помех. Первый - заменить USART или RS-232 на RS-485, дифференциальный сигнал уже лучше защищен от помех. Ну, а если уж совсем жопа, то переходим на CAN.

это еще хорошо, если посторонних шумов нет

Обычно для определения «ахтунг, пожар» ставят простой пирометрический датчик. Термометрами никто пожар не определяет. А вот в системах охлаждения термометры используются. Но там они через АЦП подключаются, и как-то проблем в CRC никаких нет. А трех- или четырехпроводной интерфейс защищает от помех. У меня на платиновых термодатчиках с трехпроводным интерфейсом в диапазоне от жидкого азота до комнатной температуры воспроизводимость температуры была не хуже 0.1К! Но обычно рабочий диапазон намного меньше, как и предъявляемые требования к точности и воспроизводимости. Поэтому за глаза хватает подключения непосредственно к АЦП МК. А в качестве термодатчиков для чиллера использую обычные рублевые NTC с алиэкспресса. У них такая же говеная точность, как у DS18B20 (около полуградуса в районе от нуля до +30℃), но зато более-менее нормальня относительная воспроизводимость (что, собственно, и нужно для поддержания температуры охлаждающей жидкости на одном уровне с точностью в один-два градуса).

Мне просто смысл спора не очевиден - в Кан црц считает драйвер и приклёпывает к довольно жестко определенному пакету, в 485 у тебя нет определения пакета и соотв ты сам выбираешь логику его состава и драйвер тебе посчитать црц не может (ибо ты можешь туда что угодно накрутить), но ты можешь это сделать сам в 4 строчки и приложить к пачке так-же как и драйвер кана дополняет пакет.
Бонус - ты можешь сам решать нужно ли тебе црц и какое именно
Текстовый протокол не совсем аналогия ибо если побилось твоё hello в какое-нить hel&o то оно, возможно (если протокол простой), отрыгнется само собой как неизвестная команда, а битая цифра просто не распарсится в инт, но один фиг если можно прикрыть парой строк кучу потенциальных проблем то чтоб и нет?
В тсп вон есть аппаратное црц но один фиг на ответственную инфу не стесняются ещё мд5 приложить ибо ну все наверное напарывались на битые Файлы, хотя он «гарантирует целостность» :-)

Термометрами никто пожар не определяет.

Чой-то?
Возгорание угля на конвейере подачи ловят пирометрами именно по температуре (ну или в икеевских пиццериях, где они есть :-) ), возгорание кабельных трасс ловят оптическими распределенными термометрами (и они же стоят на подлодках вторым рубежом), возгорание на спецтехнике (белазы и тп) ловят точечными кабельными измерителями.

Проблем аппаратно посчитать ЦИК нет (даже STM32F0 такое умеют аппаратно). Проблема в том, как это реализовать в протоколе: вот открыл я терминал и пишу команду. И что же, мне для железяки специальный терминал разрабатывать? Да нафиг оно нужно, у меня уйма железяк на баш-скриптах работает, где тупо команда дается как echo commands > /dev/ttyUSB0, а ответ парсится из cat /dev/ttyUSB0.

Не стоит усложнять то, что можно реализовать просто.