Windows 11 тормозит обмены через СОМ-порт

@ay007 · Регистрация: 09.04.2020

Студворк — интернет-сервис помощи студентам

Добрый день, коллеги.

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

Есть приложение. написанное много лет назад на Delphi 7, и без вопросов работавшее на многих ПК с Windows XP и Windows 7. Приложение через СОМ порт (компонент BComPort) посылает запрос контроллеру, контроллер, приняв пакет, отвечает, приложение, приняв ответ, посылает новый запрос (или не приняв ответ, посылает запрос по таймеру). Все просто и отлажено в десятках приложений/устройств.

И вот эта отлаженная пара (приложение - контроллер) отказывается нормально работать по Windows 11 - существенно падает скорость обмена (со 120 до 40-50 обмен/с) и в обменах наблюдаются паузы до 0.5 с, что недопустимо. Причем сразу после запуска приложения показывает скорость 120 обмен/с, но через пару секунд скорость падает до 40, затем повышается до 60, снова падает и т.д.

Т.к. предположили, что проблема в новой (для нас) ОС, то отключили антивирусы, One Drive, пробовали режимы совместимости в разными ОС, устанавливали приоритет real_time, и пр. Существенного изменения скорости и непрерывности обмена получить не удалось.

Соответственно вопрос: как настроить Windows 11 под работу в режиме real_time?

Спасибо.

@ay007 · 11.05.2024, 19:35 **[ТС]**

Сообщение от Beltar

А как вы это сделаете без перманентного вызывания ElapsedTime, или как-там-этот-метод-называется? У вас поток будет на 100% загружен, или Sleep совать, но порт явно работает в главном потоке и вынести его не выйдет.

Это Вы предложили использовать StopWatch вместо Таймера в быстром обмене через СОМ-порт, вот и предлагайте.

@stalkernet · 11.05.2024, 20:51

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

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

ладно есть еще один вариант для проверки из разряда костыль. ускоритель игр - Razer Cortex.
пользуюсь ибо все лишнее из системы выкидывается. ядро на 7-ке занимает 1.2 гига.
при моих расчетах длительностью 12 -15 часов выйгрыш примерно чуть больше часа. по сравнению если без онной.
попробуй с ней.

@Beltar · 11.05.2024, 21:46

Я не предлагал TStopwatch, я лишь писал, что это инструмент для отсчета более точных временных интервалов, чем может GetTickCount.

@northener · 12.05.2024, 02:57

Сообщение от ay007

Никто не будет останавливать Установку на модернизацию системы управления только из-за того, что ПО не смогли адаптировать под Win 11

А придётся, имхо.
Windows чем дальше, тем больше позиционируется как ОС для кухарок. И все ваши потуги задать "максимальный" приоритет вашему процессу с каждой новой версией Windows всё более бесполезны. Да и на что вы изначально надеялись, если сразу было сказано, что Windows не есть ОС реального времени!

Добавлено через 12 минут

Сообщение от stalkernet

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

Порт не работает ни в каком отдельном потоке! Это бред! Порт это аппаратная сущность. Он работает сам по себе, даже в отсутствии какой либо ОС. А дальше работает его драйвер, который тоже не работает ни в каком потоке. RTFM.

@stalkernet · 12.05.2024, 06:33

northener, не правильно поняли друг друга. бывает. )))

Сообщение от northener

как ОС для кухарок

я бы сказал для поколения Я-ТЕЛЕФОНА. с характерным таким китаезным произношением.

посмотрим что райзер покажет.
Но на кастрацию винды в стиле по самую шею. все указывает. и это будут последние потуги перед смертью. хотя и так уже ситуация из анекдота - больной перед смертью потел? Потел. Это очень хорошо......

@AzAtom · 12.05.2024, 09:11

Сообщение от northener

драйвер, который тоже не работает ни в каком потоке.

Почему это "ни в каком потоке"? Всё работает в своих потоках.

@northener · 13.05.2024, 02:26

Хм. Драйверы вообще-то работают в нулевом кольце. Применимы ли там термины "потоки"?

@AzAtom · 14.05.2024, 02:14

northener, кольца это же про привилегии? Как они относятся к организации исполнения самого кода?

Кликните здесь для просмотра всего текста

Я на 100% не знаю, как именно оно там работает, но факт в том, что, например, когда открываешь звуковое устройство и передаёшь ему callback функцию, то эту функцию вызывает драйвер и функция срабатывает в другом потоке, не в потоке твоей программы.

@northener · 14.05.2024, 03:05

Сообщение от AzAtom

northener, кольца это же про привилегии?

Да про привилегии. Но не только.

Сообщение от AzAtom

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

Вот только СОМ-порт работает по очень старым стандартам. У него нет никаких callbackов.

@stalkernet · 14.05.2024, 08:22

ну наконец то. через 5 дней добрались и до колец....

инфа из первых рук (друг в Израиле работал в конторе которая писала для мелкософта). В свое время страдал CNC STEP-DIR на основе винды. даже из матричников сделал свой. платы сверлил и фрезеровал. правда ОЧЕНЬ медленно. вобщем при попытке переезда на вЫсту естественно словил крупный геморрой на голову. В ходе попыток решения, друг выяснял и подкидывал инфу. Чтото как то решил, но результат больше напоминал презерватив на кирзовом сапогу.

итак то что помню достоверно. Колец всего 5.

0-1 RTS. обработка железа CPU, MEM, DMA, IDE, FDD таймеры счетчики железа
2 обработка PCI-E VIDIO, SATA, PCI, USBHAB, LPT, COM, BIOS, PS\2
3 вот тути начинается виндовое - где хочу пописаю, где хочу покакаю.
PCI-E, USB, потоки, stream, WINAPI, ДРАЙВЕРА для PCI-E USB, службы, аудио
4 юзверевские программы.

в 7 думаю также. хотя с приходом в винду политики похеру bios я сама знаю что у меня стоит и блокировку записей в порты. куда передвинули обработку портов хер поймеш. судя по глюкам похоже в 3 кольцо.

@ay007 · 14.05.2024, 17:15 **[ТС]**

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

После последовательной отработки нескольких тупиковых идей (замена типового таймера Delphi на Real Time таймер, проверки времени выполнения подпрограмм формирования пакетов, контроля длительности реакции на прием ответа контроль исправности соединительных кабелей, наличия заземления и пр.), вырулил на вроде как перспективный путь.

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

Также обратил внимание, что два контроллера с проблемами обмена обмениваются короткими пакетами (9 байт (запрос) - 13 байт (ответ) и 3 байт (запрос) - 9 байт (ответ) байт) в отличии от третьего контроллера (21 байт (запрос) и 17 байт (ответ)). Соответственно, время на формирование запроса третьего контроллера существенно больше (в десятки раз) по сравнению с временем формирования запросов первых двух контроллеров.

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

Теперь осталось понять, что это было.

@Beltar · 14.05.2024, 18:43

Предположение. Нужна задержка м/у сменой четности при отправке адреса и собственно посылки.

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

@AzAtom · 14.05.2024, 20:15

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

@Rius · 14.05.2024, 22:19

Сообщение от ay007

с помощью вульгарных Sleep(1)

Это может аукнуться.

@northener · 15.05.2024, 02:13

Сообщение от Beltar

Предположение. Нужна задержка м/у сменой четности при отправке адреса и собственно посылки.

Есть более надежный и грамотный вариант. Но он требует наличия злектронщика.

Не по теме:

Когда мы в стрёмных 90-х начинали делать свои системы охранки и потом и СКУД на контроллерах с 51-м процессором (в котором как раз и была впервые придуман этот способ адресации посылки) нам было поставлено условие, что система должна уметь работать на уже проложенных кабельных линиях. Которые могли быть выполнены простой "лапшой". Поскольку полнодуплексность нам была нифиг не нужна, наш электронщик разработал простой блочок, который параллелил Rx и Tx так, что СОМ-порт читал и то, что ему присылали контроллеры, так и то что он сам посылал контроллерам. И тут гарантировано не нужны никакие задержки!

@stalkernet · 15.05.2024, 08:34

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

может всетаки посмотреть в сторону ModBus.

@AzAtom · 15.05.2024, 09:38

Сообщение от ay007

с помощью вульгарных Sleep(1)

Если не подготовить таймер, то это будет зависеть от других запущенных программ.
Можно при старте своей программы делать

Delphi
1
  TimeBeginPeriod(1); // Разрешение 1 мс

Далее в программе использовать Sleep(1), и на выходе из программы

Delphi
1
  TimeEndPeriod(1); //В конце завершить эту запрошенную точность

@ay007 · 15.05.2024, 11:15 **[ТС]**

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

Также необходимо учитывать, что Установка работает 12-24/7 и доступ к ее телу у меня есть в технологические, а также обед/ужин перерывы. Соответственно предложения, требующие фундаментальной модернизации Установки (или существенного расширения моих знаний и умений) прекрасны, но на практике нереализуемы.

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

Событие OnTxEmpty происходит когда выходной буфер порта становится пустым
Описание
Информирует о том, что все данные из выходного буфера переданы в линию.

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

Delphi
1
2
Procedure TForm0.Port0TxEmpty(Sender:TObject);
  Begin If TimeForTx then Begin Port0.Parity:=paMark; Port0.Write(ByteTx,NumTx); TimeForTx:=false; End; End;

Если же вставить Sleep(1), то сбоев нет.

Delphi
1
2
Procedure TForm0.Port0TxEmpty(Sender:TObject);
  Begin If TimeForTx then Begin Sleep(1); Port0.Parity:=paMark; Port0.Write(ByteTx,NumTx); TimeForTx:=false; End; End;

И да, Sleep(1) - это только, чтобы быстро проверить идею.

П.С. Win 11 пока реабилитирована.

П.П.С. Контроллер (писал сам, поэтому верю) все же быстрее, чем СОМ порт, поэтому быстрота нового компа, компенсируется медленной (хоть и 115200) скоростью обмена.

Добавлено через 1 час 25 минут
П.П.С. Т.к. не верю никому проверил длительность задержки Sleep(n);

Delphi
1
2
3
 QueryPerformanceFrequency(Fr); QueryPerformanceCounter(T1);/////
  Sleep(n);////
  QueryPerformanceCounter(T2);/////

Задержка, в мс, вычисляется по формуле: Delay=1000*(T2-T1)/Fr
При n=1, Delay=0.161 - 1.091 мс;
При n=2, Delay=1.194 - 2.025 мс;
При n=3, Delay=2.182 - 3.050 мс;
Delphi 7, Win 7. Вроде почти все честно.

@ay007 · 15.05.2024, 19:25 **[ТС]**

Убрал Sleep-ы.

Delphi
1
2
3
4
5
Procedure TForm0.Timer0Timer(Sender:TObject);
     {...}
    QueryPerformanceFrequency(Fr); QueryPerformanceCounter(T1); T2:=T1; {Вставил фиксацию момента записи в буфер СОМ порта байта адреса}
    Port0.Parity:=paSpace; Port0.Write(ByteTx,1);
    {...}

Delphi
1
2
3
4
Procedure TForm0.Port0TxEmpty(Sender:TObject);
    {...} 
    If Fr>0 then while 1000*(T2-T1)/Fr>Tmin do QueryPerformanceCounter(T2); {Вставил проверку интервала времени от записи  в буфер СОМ порта байта адреса}
  If TimeForTx then Begin Port0.Parity:=paMark; Port0.Write(ByteTx,NumTx); TimeForTx:=false; End; End;

При Tmin=0.1 мс количество сбоев не уменьшилось, при Tmin=0.2 мс, сбои практически исчезли, поэтому поставил 0.3 мс (типа, технологический запас).

Сейчас скорость обмена главного контроллера от около 100 до 142 об/с, что вполне удовлетворительно для работы Установки. Максимальная теоретическая скорость (типа обмены идут без перерыва на работу ОС, формирование запросов, переключение паритетов, обработку ответов, вывод на экран и пр.) - около 205 об/с, т.е. типа КПД = 50-70 % под мало освоенной Win 11. Пока доволен.

Добавлено через 3 минуты
2 AzAtom Сейчас посмотрел, оказалось, что у меня используется связка TimeBeginPeriod(1); TimeEndPeriod(1); Давно писал, сразу и не вспомнил, а программа большая. Спасибо.

@stalkernet · 15.05.2024, 19:57

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

Добавлено через 22 минуты
если уж на то пошло - взять микроконтроллер с двумя UART. по одному опрашивать железо и складывать в буфер. по второму забирать на комп данные сразу о трех. минимум затрат. установку не курочить. просто вставить еще одну железку между установкой и компом....

Новые блоги и статьи Все статьи Все блоги /
Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .	Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники). Hrethgir 04.08.2026 Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .	Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .
Создание формы заимствованного документа Maks 03.08.2026 Задача: Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также табличная часть со следующими реквизитами: - Расчетный счет покупателя. . .	Задача предоставления скидок покупателям Maks 03.08.2026 Задача: В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .	Почему SEO не начинается с ключевых слов: что проверить до написания текстов Neotwalker 01.08.2026 Когда владельцу сайта предлагают заняться SEO, первым шагом часто становится сбор запросов и написание текстов. Логика кажется понятной: 1. Находим ключевые слова. 2. Добавляем их на. . .	Знание — сила: Доктрина интенциональности знаний, углубление в формулу Hrethgir 01.08.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11957&stc=1&d=1785567302 Знаменитый афоризм Фрэнсиса Бэкона «Знание — сила» (Scientia potentia est) в массовой культуре принято понимать. . .

@ay007 0 / 0 / 0 Регистрация: 09.04.2020 Сообщений: 35

	Windows 11 тормозит обмены через СОМ-порт 06.05.2024, 13:36. Показов 5953. Ответов 85 Метки нет (Все метки) Добрый день, коллеги. Столкнулся с проблемкой, вынесенной в название темы. Есть приложение. написанное много лет назад на Delphi 7, и без вопросов работавшее на многих ПК с Windows XP и Windows 7. Приложение через СОМ порт (компонент BComPort) посылает запрос контроллеру, контроллер, приняв пакет, отвечает, приложение, приняв ответ, посылает новый запрос (или не приняв ответ, посылает запрос по таймеру). Все просто и отлажено в десятках приложений/устройств. И вот эта отлаженная пара (приложение - контроллер) отказывается нормально работать по Windows 11 - существенно падает скорость обмена (со 120 до 40-50 обмен/с) и в обменах наблюдаются паузы до 0.5 с, что недопустимо. Причем сразу после запуска приложения показывает скорость 120 обмен/с, но через пару секунд скорость падает до 40, затем повышается до 60, снова падает и т.д. Т.к. предположили, что проблема в новой (для нас) ОС, то отключили антивирусы, One Drive, пробовали режимы совместимости в разными ОС, устанавливали приоритет real_time, и пр. Существенного изменения скорости и непрерывности обмена получить не удалось. Соответственно вопрос: как настроить Windows 11 под работу в режиме real_time? Спасибо. 0

@stalkernet 62 / 42 / 3 Регистрация: 04.01.2019 Сообщений: 278
	11.05.2024, 20:51
	Порт работает в отдельном потоке и из него плюет евенты о том что в буфер чтото упало. авот через скока времени евент доползет до программы это ...... TStopWatch я использовал для более точного замера времени между событиями. просто запустите программу и увидите насколько все тонко шатко и глючно..... со списком обработки евентов и мессажей. а если учесть еще и таймауты для списка то ....... ладно есть еще один вариант для проверки из разряда костыль. ускоритель игр - Razer Cortex. пользуюсь ибо все лишнее из системы выкидывается. ядро на 7-ке занимает 1.2 гига. при моих расчетах длительностью 12 -15 часов выйгрыш примерно чуть больше часа. по сравнению если без онной. попробуй с ней. 0

@Beltar 1069 / 510 / 41 Регистрация: 05.05.2022 Сообщений: 3,595
	11.05.2024, 21:46
	Я не предлагал TStopwatch, я лишь писал, что это инструмент для отсчета более точных временных интервалов, чем может GetTickCount. 0

@northener пофигист широкого профиля 4770 / 3206 / 862 Регистрация: 15.07.2013 Сообщений: 18,613
	13.05.2024, 02:26
	Хм. Драйверы вообще-то работают в нулевом кольце. Применимы ли там термины "потоки"? 0

@AzAtom Модератор 4153 / 2362 / 814 Регистрация: 15.11.2015 Сообщений: 9,495
	14.05.2024, 02:14
	northener, кольца это же про привилегии? Как они относятся к организации исполнения самого кода? Кликните здесь для просмотра всего текста Я на 100% не знаю, как именно оно там работает, но факт в том, что, например, когда открываешь звуковое устройство и передаёшь ему callback функцию, то эту функцию вызывает драйвер и функция срабатывает в другом потоке, не в потоке твоей программы. 0

@stalkernet 62 / 42 / 3 Регистрация: 04.01.2019 Сообщений: 278
	14.05.2024, 08:22
	ну наконец то. через 5 дней добрались и до колец.... инфа из первых рук (друг в Израиле работал в конторе которая писала для мелкософта). В свое время страдал CNC STEP-DIR на основе винды. даже из матричников сделал свой. платы сверлил и фрезеровал. правда ОЧЕНЬ медленно. вобщем при попытке переезда на вЫсту естественно словил крупный геморрой на голову. В ходе попыток решения, друг выяснял и подкидывал инфу. Чтото как то решил, но результат больше напоминал презерватив на кирзовом сапогу. итак то что помню достоверно. Колец всего 5. 0-1 RTS. обработка железа CPU, MEM, DMA, IDE, FDD таймеры счетчики железа 2 обработка PCI-E VIDIO, SATA, PCI, USBHAB, LPT, COM, BIOS, PS\2 3 вот тути начинается виндовое - где хочу пописаю, где хочу покакаю. PCI-E, USB, потоки, stream, WINAPI, ДРАЙВЕРА для PCI-E USB, службы, аудио 4 юзверевские программы. в 7 думаю также. хотя с приходом в винду политики похеру bios я сама знаю что у меня стоит и блокировку записей в порты. куда передвинули обработку портов хер поймеш. судя по глюкам похоже в 3 кольцо. 0

@ay007 0 / 0 / 0 Регистрация: 09.04.2020 Сообщений: 35
	14.05.2024, 17:15 [ТС]
	Если вернуться к теме, то сформулирую промежуточные результаты. После последовательной отработки нескольких тупиковых идей (замена типового таймера Delphi на Real Time таймер, проверки времени выполнения подпрограмм формирования пакетов, контроля длительности реакции на прием ответа контроль исправности соединительных кабелей, наличия заземления и пр.), вырулил на вроде как перспективный путь. Для начала поставил счетчики для каждого из контроллеров (их три), которые инкрементировались при формировании каждого запроса к контроллеру и декрементировались при приеме каждого ответа от этого контроллера. При этом каждую секунду значения счетчиков выводилось на экран, а содержимое счетчиков обнулялось. В итоге с изумлением увидел, что два из трех контроллеров не отвечали на 4 - 10 запросов в секунду, что приводило к запуску формирования следующего запроса не по приему ответа, а по срабатыванию таймера, что, в свою очередь, приводило к существенному снижению скорости обмена. И т.к. число пропущенных запросов постоянно изменялось (в зависимости от работы самопроизвольной ОС), то также постоянно изменялась скорость обмена, заставляя грешить на ОС, а не на собственное ПО. Также обратил внимание, что два контроллера с проблемами обмена обмениваются короткими пакетами (9 байт (запрос) - 13 байт (ответ) и 3 байт (запрос) - 9 байт (ответ) байт) в отличии от третьего контроллера (21 байт (запрос) и 17 байт (ответ)). Соответственно, время на формирование запроса третьего контроллера существенно больше (в десятки раз) по сравнению с временем формирования запросов первых двух контроллеров. Соответственно, для проверки увеличил время формирования запросов контроллеров, в обмене с которыми наблюдались частые пропуски ответов с помощью вульгарных Sleep(1) и увидел, что ошибки снизились до околонулевых значений, скорость перестала катастрофически снижаться. Типа все хорошо. Теперь осталось понять, что это было. 0

@Beltar 1069 / 510 / 41 Регистрация: 05.05.2022 Сообщений: 3,595
	14.05.2024, 18:43
	Предположение. Нужна задержка м/у сменой четности при отправке адреса и собственно посылки. Статистику ответов и ошибок CRC надо было делать сразу, как без этого можно жить, я не понимаю. 0

@AzAtom Модератор 4153 / 2362 / 814 Регистрация: 15.11.2015 Сообщений: 9,495
	14.05.2024, 20:15
	Новый быстрый комп стал выдавать новые запросы раньше, чем контроллер успеет перейти в режим приёма? 0

@stalkernet 62 / 42 / 3 Регистрация: 04.01.2019 Сообщений: 278
	15.05.2024, 08:34
	Вам же предлагали для начала соеденить порты кабелем, повесить два терминала и на одном передавать а на другом принимать. и посмотреть что доежает а что нет. если все в порядке. имитировать протокол обмена...... может всетаки посмотреть в сторону ModBus. 0

@stalkernet 62 / 42 / 3 Регистрация: 04.01.2019 Сообщений: 278
	15.05.2024, 19:57
	О чем вам и говорили. события еще должны доползти до железа и обратно. вот через сколько рук они пройдут - это ..... отсюда и sleep и плавать он будет как система захочет.... Добавлено через 22 минуты если уж на то пошло - взять микроконтроллер с двумя UART. по одному опрашивать железо и складывать в буфер. по второму забирать на комп данные сразу о трех. минимум затрат. установку не курочить. просто вставить еще одну железку между установкой и компом.... 0