[k155la3 27]

Если не требуется переносимость-универсальгность, а также работа на физ. RS232 из серии 16550.

Можно попробовать "накрутить" FT2232, например, используя ихнюю (FTDI) библиотеку, позвляющую

работать напрямую, и с расширенным сервисом-API к функциям.

Но надо как следует прокурить даташиты и док на API

ps - оно еще и неплохо увязывается с RS485.

Изменено 8 сентября, 2016 пользователем k155la3

[Alex_2015 0]

Я не утверждаю, что MSDN врёт. Просто констатирую факты.

Возможно ошибка есть более глубоко в моём коде и я её пока не вижу. Поэтому пытаюсь освежить информацию по работе с портом, возможно пока та самая ошибка не проявлялась за несколько лет работы проги.

[zltigo 2]

ТСу нужно не опрашивать счётчики, а вести лог обмена по каналу UART. Причём с таймштампами точностью до десятков мкс.

Повторю еще раз - нет никакого смысла в "таймштампами точностью до десятков мкс", если само событие фиксируемое уже "драйвером" совершенно произвольгую задержку и сами события начинают склеиваться в одно уже на уровне FIFO UART.

Аппаратура UART 16550 позволяет определять наличие паузы...

Нет. Только выдает прерывании при заполнении FIFO и при межбайтовой паузе более 4x символов. При этом прием последующих символов продолжается в то же FIFO.

видим там слово "immediately", думаем.

Когда придумаете, где это "immediately" отнормированно в микросекундах и куда денутся байты пришедшие после 3,5 символьного интервала, причем UART будет еще тянуть собственый 4x символьный таймаут до того, как сгенерит прерывание, обязательно сообщите :).

 

 

 

ps - оно еще и неплохо увязывается с RS485.

Ослинные уши пакетного а НЕ БАЙТОВОГО интерфейса USB будут торчать по любому.

 

[DASM 0]

Я бы тоже решал по-другому. А именно: с открытия MSDN и прочтения всего, что касается работы с COM-портом. Чего автор как видно не сделал.

Иначе он знал бы о функции SetCommTimeouts() WinAPI и многих других полезных. А не строил пустые предположения.

Далее: установил-бы ReadIntervalTimeout and ReadTotalTimeoutMultiplier to MAXDWORD and sets ReadTotalTimeoutConstant to a value greater than zero and less than MAXDWORD

как советует MSDN, повысил приоритет принимающего потока, а также прочитал в MSDN про семейство функций QueryPerformanceFrequency()/QueryPerformanceCounter() и понял бы, что даже 95мкс - не есть проблема.

Другое дело что всё это лучше делать на железном RS-232 компа, а не USB-COM переходнике, времянки которого сомнительны.

 

Даже и с железным COM-портом и приоритетом потока ==REALTIME возможно будут проблемы из-за работы других драйверов винды (винта, видео и т.п.). Так что возможно лучше вынести такую работу на уровень драйверов.

 

 

Это вообще из другой оперы. Это для software flowcontrol.

 

 

Лучше откройте наконец-то MSDN, а не занимайтесь ерундой.

MSDN в именно в этой части читал лет 15 назад. Неифга оно так не работает (еще на тех -то компах, когда COM порт не был чудом). zltigo прав абсолютно. Точно вспоминать что именно не работает уже не смогу, помню что нужен был именно Modbus RTU и помню что эта возня с таймаутами в винде достала так, что ушел на SLIP протокол, благо не был ограничен

[jcxz 243]

Повторю еще раз - нет никакого смысла в "таймштампами точностью до десятков мкс", если само событие фиксируемое уже "драйвером" совершенно произвольгую задержку и сами события начинают склеиваться в одно уже на уровне FIFO UART.

Именно на уровне FIFO эти события никак не склеиваются. От UART есть прерывание заполнения всего FIFO и есть прерывание таймаута. Этих двух прерываний абсолютно достаточно для определения - была дырка между байтами или нет. И для ModBus эти таймштампы не нужны, но нужен факт наличия дырки.

Такой алгоритм работы UART есть во многих контроллерах, например LPC17xx. И он позволяет легко разделять кадры по дыркам между ними. И этот алгоритм - наследство от железного 16550.

Виндовый драйвер после чтения FIFO конечно может склеить, но как-бы описание SetCommTimeouts() говорит об обратном.

 

Нет. Только выдает прерывании при заполнении FIFO и при межбайтовой паузе более 4x символов. При этом прием последующих символов продолжается в то же FIFO.

А это не одно и то же? Прерывание по таймауту пришло - считали содержимое FIFO, запомнили что после этого содержимого была пауза. Всё.

Или Вы думаете, что вход в ISR может настолько запоздать, что придёт новый символ после 3.5-символьной паузы?

 

Когда придумаете, где это "immediately" отнормированно в микросекундах и куда денутся байты пришедшие после 3,5 символьного интервала, причем UART будет еще тянуть собственый 4x символьный таймаут до того, как сгенерит прерывание, обязательно сообщите :).

Какие 3.5 + 4 интервала?? Принят очередной байт - запускается счётчик таймаута - он отсчитывает 3.5 символьных интервала - генерится прерывание - ISR считывает содержимое UART, пишет в программный FIFO и пишет туда же признак наличия дырки.

А ещё можно в свойствах COM-порта выключить FIFO. Вот тогда будет: пришёл байт, сразу прерывание, ISR кладёт символ в программное FIFO и задача, вызвавшая ReadFile() и ждущая появления данных, тут же переходит из состояния wait в состояние run и получает управление от шедулера и выгребает данные из этого программного FIFO. Вот тогда след. символ точно успеет прийти до входа в ISR. И у драйвера есть все возможности выполнить обязательство "immediately".

 

MSDN в именно в этой части читал лет 15 назад. Неифга оно так не работает (еще на тех -то компах, когда COM порт не был чудом).

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

[zltigo 2]

Именно на уровне FIFO эти события никак не склеиваются. От UART есть прерывание заполнения всего FIFO и есть прерывание таймаута. Этих двух прерываний абсолютно достаточно для определения - была дырка между байтами или нет.

Разумеется нет.

1) таймаут отрабатывает на 4 символа паузу и приход следующего MODBUS фрейма приведет с склеиванию фреймов.

2) Если драйвера и система не успеет отработать прерывание до прихода следующего фрейма, то они опять склеятся или FIFO или уже в буферах драйвера.

3) Прерывания по таймауту и по заполнению FIFO не отличаются, так что приход прерывания, как такового не означает конца фрейма.

И для ModBus эти таймштампы не нужны,

О чем я Вам уже и писал.

но нужен факт наличия дырки.

к которому они никакого отношения не имеют, о чем уже тоже писал. Тау что помянуты они всуе.

Такой алгоритм работы UART есть во многих контроллерах, например LPC17xx. И он позволяет легко разделять кадры по дыркам между ними. И этот алгоритм - наследство от железного 16550.

Какой "такой"? В том же помянутом всуе LPC17XX есть еще навороты, типа CTI и самое главное, есть в отличие от WIN, жесткое реальное время и кучка аппаратных таймеров для организации поддержки таймаутов, как собственно UART, так и протоколов типа того же MODBUS-RTU (да гореть его недоучкам авторам в аду). Так что для микроконтролера, даже с минималистичным 55, проблем в реализации кривейшего MODBUS нет.

Виндовый драйвер после чтения FIFO конечно может склеить, но как-бы описание SetCommTimeouts() говорит об обратном.

Поворю, что для начала склеит уже аппаратное FIFO UART ну и "описание" ни о чем не говорит, кроме того, что не будет ДОБАВЛЯТЬ никаких ДОПОЛНИТЕЛЬНЫХ таймаутов к тем, которые так или иначе получатся в системе, которая НИКАК НЕ поддерживает реальное время.

А это не одно и то же? Прерывание по таймауту пришло - считали содержимое FIFO, запомнили что после этого содержимого была пауза. Всё.

Перечитайте неписанное выше.

Или Вы думаете, что вход в ISR может настолько запоздать, что придёт новый символ после 3.5-символьной паузы?

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

Так что надежно работающий снифер выделяющий MODBUS-RTU фреймы из 485 под Win нереален. Для низких скоростой и медленнннннооо отвечающих перeферийных устройств, да, частные реализации оаботающие на конкретной машине, возможны.

 

 

 

И проверять надо под современной виндой.

Будет только хуже :(. Все обещания, которые Вы захотели увидеть в описании драйверов на самом деле тянутся от тех самых Win 3.1/85, котрые еще были как то похожи на "микроконтроллер". В "современных" байтовые интерфесы вообще похоронены де-факто.

[jcxz 243]

Разумеется нет.

1) таймаут отрабатывает на 4 символа паузу и приход следующего MODBUS фрейма приведет с склеиванию фреймов.

2) Если драйвера и система не успеет отработать прерывание до прихода следующего фрейма, то они опять склеятся или FIFO или уже в буферах драйвера.

Кто-ж спорит что в этом случае склеятся. Только:

1) ТС нужна не рабочая система сбора данных, а система для мониторинга в целях отладки. Значит к этой системе можно предъявить спец. требования (отсутствие посторонних задач, достаточная мощность и др., которые обеспечат достаточную реалтаймовость системы и скорость реакции на прерывания железа).

2) рассмотрим как работает ПО в сети обмена ModBus и начинаем думать какие будут минимальные дырки:

а) предположим мы наблюдаем обмен двух устройств - устройство А передаёт кадр, устройство Б - принимает, обрабатывает и отвечает (режим запрос-ответ), а наше устройство (комп) мониторит этот обмен со стороны:

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

Когда в FIFO устройства-монитора появится этот первый байт ответа? Правильно, через: 4 символа таймаута + время обработки в Б + 1 символ ответа. Даже если предположить, что устройство Б обрабатывает запросы мгновенно, всё равно имеем в устройстве-мониторе паузу в 5 символов! Т.е. - устройство-монитор сгенерит прерывание таймаута как минимум за один символ до прихода 1го символа ответа.

А теперь ещё немного подумаем и поймём, что после того как устройство Б переключило свой драйвер RS-485 в режим передачи, то после этого и до начала выдвигания бит первого слова ответа, оно должно обеспечить некую паузу для того, чтобы и устройство А принимающее его ответ заведомо успело переключить свой драйвер RS-485 в режим приёма. А ведь и устройство Б может иметь драйвер RS-485 с гальванической развязкой, которому нужно время на переключение RX->TX и у устройства А тоже может быть такой драйвер, требующий доп. задержки. И ПО ModBus-драйвера, написанное прямыми руками, должно учитывать, что у устройств с которыми оно будет работать, могут быть медленные опторазвязки RS-485, а значит давать возможность или конфигурировать минимальное время переключения себя RX->TX или просто хотя-бы выдерживать это время с большим запасом.

Это всё приводит нас к мысли, что паузы запрос-ответ будут заведомо больше чем 5 символьных интервалов.

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

 

3) Прерывания по таймауту и по заполнению FIFO не отличаются, так что приход прерывания, как такового не означает конца фрейма.

Да ладно?

Открываем даташит на LPC17xx содержащий UART с, как в нём утверждается: Register locations conform to 16C550 industry standard. Читаем описание регистра IIR и видим две разные причины прерывания: RDA и CTI. И даже если размер принимаемого кадра равен FIFO trigger level, то всё равно можно обнаружить границу кадра: после получения RDA считать (FIFO trigger level - 1) символов и через некоторое время получить ещё и CTI, сигнализирующее о границе кадра.

Даташит на прародитель 16C550 найти конечно сейчас трудно, но вот эта ссылка например http://www.lookrs232.com/rs232/iir.htm говорит, что и в нём дело обстояло так же.

 

Какой "такой"? В том же помянутом всуе LPC17XX есть еще навороты, типа CTI и самое главное, есть в отличие от WIN, жесткое реальное время и кучка аппаратных таймеров для организации поддержки таймаутов,

Для "поддержки таймаутов" в LPC17xx таймера не нужны, вполне достаточно RDA и CTI. Это на приём. Только на передачу нужен таймер, чтобы отследить момент опустошения сдвигового регистра передатчика и переключения драйвера RS-485 с TX на RX.

 

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

Это всего лишь слова и предположения. Тут может рассудить только эксперимент(-ы).

Я не вижу никаких причин в современной системе, не загруженной тяжёлой работой, имеющей как правило несколько процессорных ядер с ГГц-выми тактовыми частотами, которые почти всё время просто тупо простаивают, не отреагировать на событие почти мгновенно, обработав например прерывание одним ядром и тут же переключить другое ядро на выполнение высокоприоритетного thread-а драйвера сис. уровня UART, а третьим ядром выполнить пользовательский высокоприоритетный код с ReadFile.

 

к которому они никакого отношения не имеют, о чем уже тоже писал. Тау что помянуты они всуе.

Таймштампы нужны пользовательскому процессу, вызывающему ReadFile(), особенно с выключенным FIFO, чтобы обнаружить дырки:

LARGE_INTEGER t1, t2;
while () ReadFile(); //опустошаем RX-поток UART
for (QueryPerformanceCounter(&t2);; t2 = t1) {
  ReadFile();
  QueryPerformanceCounter(&t1);
  t2.QuadPart = t1.QuadPart - t2.QuadPart;
  //вот здесь t2 будет или примерно равно 1-му символьному интервалу, если чтение идёт внутри кадра; или больше 4-х символьных кадров, если последняя ReadFile() считала 1-й символ ModBus-кадра
  //т.е. - поставив пороговое сравнение скажем на сравнение t2 < 3-х символьных интервалов или t2 >= 3 символьным интервалам можно с запасом обнаружить дырку
  //временем выполнения этого кода на мощном незагруженном процессоре и высокоприоритетном thread-е можно пренебречь
}

[Alex_2015 0]

Я всё-таки внесу некоторые дополнения.

Использую преобразователь USB-RS485. Провёл несколько экспериментов и выяснил, что данные из порта читаются пачками по 4-16 байт. Причём начало запроса всегда читается с начала, начало ответа читается вместе с хвостом запроса.

Эксперименты с таймаутами мало что меняют. Здесь, я думаю, большую роль играет характер устройства (виртуальный порт).

Так случилось, что преобразователь построен на основе FTDI микросхемы. У неё есть возможность работы через D2XX драйвер, который, если верить описанию, в большей степени позволяет мониторить события железки. Если кто работал с ним, насколько это так.

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

[zltigo 2]

Т.е. - устройство-монитор сгенерит прерывание таймаута как минимум за один символ до прихода 1го символа ответа.

Сколько много слов было написано выше, но результат неизменный - прерывание должно быть обработано драйвером, который должен дернуть операционную систему, которая должна запустить ожидающую сигнала задачу, котороая должна вычитать принятую информацию, за время прихода ОДНОГО символа. О скорсти передачи здесь, кажется не говорилось, но при, например, 115200 это очень мало :( для монстральных операционок типа WIN/LIN.

А теперь ещё немного подумаем и поймём....

Неправильно написано, правильно "еще придумаем" :).

Проблема в том, что на любую Вашу фантазию, можно нафантазировать противоположную :(

, что после того как устройство Б переключило свой драйвер RS-485 в режим передачи, то после этого и до начала выдвигания бит первого слова ответа, оно должно обеспечить некую паузу для того, чтобы и устройство А принимающее его ответ заведомо успело переключить свой драйвер RS-485 в режим приёма.

Для этого у устройства передатчика есть вагон времени:

1) тот самый 3.5 таймаут (да, да я знаю, что так делать не надо, но знаю, что делают)

2) 0.5 символьный таймаут до срабатывания прерывания.

А ведь и устройство Б может иметь драйвер RS-485 с гальванической развязкой, которому нужно время на переключение RX->TX и у устройства

Может, но быстродействие развязки должно быть таким, что бы обеспечивать передачу одиносного БИТА без существенных искажений, так что мимо.

А тоже может быть такой драйвер, требующий доп. задержки. И ПО ModBus-драйвера, написанное прямыми руками, должно учитывать, что у устройств с которыми оно будет работать, могут быть медленные опторазвязки RS-485, а значит давать возможность или конфигурировать минимальное время переключения себя RX->TX или просто хотя-бы выдерживать это время с большим запасом.

Ох уж это "должно" прежде всего оно должно обеспечить собственную работоспостобность, а не возможность подключения неприспособленного для этого железа, типа PC c Windows.

Это всё приводит нас к мысли, что паузы запрос-ответ будут заведомо больше чем 5 символьных интервалов.

Не нас, а Вас :). И не будут заведомо, а могут быть :(. Об желаемых "огромных" 5 символьных интервалах тоже можно поговорить. FIFO в UART появилость в PC не сразу и по одной простой причине - операционые системы тупо не успевали обрабатывать потоки байтов уже на скростях 9600 :(.

Открываем даташит на LPC17xx содержащий UART с, как в нём утверждается: Register locations conform to 16C550 industry standard. Читаем описание регистра IIR и видим две разные причины прерывания: RDA и CTI. И даже если размер принимаемого кадра равен FIFO trigger level, то всё равно можно обнаружить границу кадра: после получения RDA считать (FIFO trigger level - 1) символов и через некоторое время получить ещё и CTI, сигнализирующее о границе кадра.

Даташит на прародитель 16C550 найти конечно сейчас трудно, но вот эта ссылка например http://www.lookrs232.com/rs232/iir.htm говорит, что и в нём дело обстояло так же.

Открывать 17xx не надо. Это НЕ PC. И найти 550 очень легко. Только искать нужно вообще-то не его, а 450. FIFO начиналось 82450 чипе, где дополнительных идентификаторов нет. А драйвера PC обслуживают и вобще 8250. Так что появившиеся инентификаторы прерывания драйверам PC по барабану - не обрабатывабтся и ПРИЛОЖЕНИЮ НЕ ПЕРЕДАЮТСЯ.

Для "поддержки таймаутов" в LPC17xx таймера не нужны, вполне достаточно RDA и CTI. Это на приём. Только на передачу нужен таймер, чтобы отследить момент опустошения сдвигового регистра передатчика и переключения драйвера RS-485 с TX на RX.

Еще раз - причем тут 17xx к PC? Вообше формально 17xx и помянутый Вами таймер не нужен, но это уже другая тема.

Это всего лишь слова и предположения. Тут может рассудить только эксперимент(-ы).

c 1984 года и поныне занимаюсь "экспериментами" с PC и UART на них.

Результаты не радуют отсутствием гарантированой стабильности. Причина одна - НЕ УСПЕВАЕТ гарантированно отработать операционная система и приложение за время прихода одного байта по UART.

 

Последние "эксперименты" были по весне - дабы не отсылать кучу железа, вместо железа написал эмулятор для PC некоего протокола у которого в стиле MODBUS признаком конца фрейма пауза длительностью более 64 бит на 115200. Казалось-бы :(, должно было проскочить. У немцев на их стендовой писишке не заработало, причем абсолютно стабильно не заработало. Пришлось живое железо таки посылать. Хотя, конечно, можно было и DOS приблуду написать :).

[Ruslan1 17]

Мне кажется, изначально вопрос некорректно поставлен: из " данные преобразовать в удобоваримый вид, удобный для отладки работы сети устройств" вовсе не следует что "Надо написать свою".

Берите китайский логический анализатор за 10 баксов, там уже все написано. Для " отладки работы сети устройств" - самое оно. И писать ничего не нужно (если очень хочется, то конечно можно и свое дописать).

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

 

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

[jcxz 243]

Может, но быстродействие развязки должно быть таким, что бы обеспечивать передачу одиносного БИТА без существенных искажений, так что мимо.

Вы путаете скорость передачи (от входа до выхода) и время переключения TX/RX. Скорость передачи может быть достаточной для передачах в МГц, а вот время переключения будут сотни мксек или даже миллисекунды.

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

Соответственно - любой вменяемый передатчик RS-485 должен это учитывать и позволять увеличить время своего переключения RX на TX.

 

Ох уж это "должно" прежде всего оно должно обеспечить собственную работоспостобность, а не возможность подключения неприспособленного для этого железа, типа PC c Windows.

Всё это только Ваше личное мнение.

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

 

Берите китайский логический анализатор за 10 баксов, там уже все написано. Для " отладки работы сети устройств" - самое оно. И писать ничего не нужно (если очень хочется, то конечно можно и свое дописать).

Кстати - тоже хотел это с самого начала предложить. В этих лог.анализаторах как правило стоит CY7C68013A. Можно даже отключить внутреннюю EEPROM и написать свою прошивку для CY7C68013A и ПО на PC, разбирающее пакеты от CY7C68013A - тоже несложно своё написать.

[zltigo 2]

Вы путаете скорость передачи (от входа до выхода) и время переключения TX/RX. Скорость передачи может быть достаточной для передачах в МГц, а вот время переключения будут сотни мксек или даже миллисекунды.

Я все понял и ничего не путаю. Давайте пример, а не фантазии называемые "убедительными доводами", такого дивного приемопередатчика на бочку!

[juvf 17]

2ТС Тут только аппаратный снифер поможет. Можно сделать MODBUS-RS485 to MODBUS-TCP. А вот тсп-модбас уже акулой смотреть, она знает модбас и может его парсить.

 

2jcxz Утопия. Ни фига не сможет вин/лин по таймаутам работать. Если только на скорости 100 бод. У нас MODBUS на 921600 работает, ОСи скромно отдыхают в сторонке.

 

Бред какой-то вы пишите.... Теоретически лошадь, практически упала. Я эти теоретические сказки про возможность реализации чистого модбаса на ПК слышу много лет. Все они разбиваются о попытки практической реализации модбаса на ПК. Попробуйте написать консольную программку, без гуи... которая просто бы принимала и считала кол-во пакетов с правильным црц? и в студию.

 

ps Ну если говорить про совсем чистый модбас, то по спецификации пакет, у которого внутри между байтами больше 1,5 символьного интервала считается не годным.

 

pps

Я не вижу никаких причин в современной системе, не загруженной тяжёлой работой, имеющей как правило несколько процессорных ядер с ГГц-выми тактовыми частотами, которые почти всё время просто тупо простаивают, не отреагировать на событие почти мгновенно, обработав например прерывание одним ядром и тут же переключить другое ядро на выполнение высокоприоритетного thread-а драйвера сис. уровня UART, а третьим ядром выполнить пользовательский высокоприоритетный код с ReadFile.

ВНЕЗАПНО в Qt 5.6 появился класс для работы с модбасом. Покопался в дебрях документации и нашел, что этот класс не может распознавать фреймы в 3.5 символа. В документации Qt5.7 не могу это ограничение найти. В libmodbus тоже не сказано, что у них не чистый модбас.... Гдето же были оговорки по таймаутам.... не могу найти..... может и вправду эти сказки реализовали и финты с RDA и CTI запилили? Кто пользовал эти либы? Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

[Lagman 1]

Сможет QtModbus или libmodbus распознать(разделить) 2 пакета RTU, идущих подряд и разделённых 3.5 символами тишины, на скорости 921600, на каком нить стареньком одноядерном компе, на котором еле-еле гуи ворочится и процессор занят кучей увесистых задач?

В рекомендациях modbus сказано (MODBUS over Serial Line Specification and Implementation Guide V1.02, стр. 13)

The implementation of RTU reception driver may imply the management of a lot of interruptions due to the t1.5 and t3.5 timers. With

high communication baud rates, this leads to a heavy CPU load. Consequently these two timers must be strictly respected when the

baud rate is equal or lower than 19200 Bps. For baud rates greater than 19200 Bps, fixed values for the 2 timers should be used: it is

recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

 

Но наверно даже с этими значениями без ОСРВ не поймать эти моменты, и если T1.5 почти никто не проверяет, то с T3.5 главное не начинать передачу пакета (запрос или ответ) раньше этого момента и можно "терпеть" с передачей вплоть до истечения времени ожидания ответа.

[juvf 17]

it is recommended to use a value of 750μs for the inter-character time-out (t1.5) and a value of 1.750ms for inter-frame delay (t3.5).

ЗАПЕЙСАЛ.