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. по одному опрашивать железо и складывать в буфер. по второму забирать на комп данные сразу о трех. минимум затрат. установку не курочить. просто вставить еще одну железку между установкой и компом....

Новые блоги и статьи Все статьи Все блоги /
Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .
Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .

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

	Windows 11 тормозит обмены через СОМ-порт 06.05.2024, 13:36. Показов 6043. Ответов 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 1074 / 514 / 41 Регистрация: 05.05.2022 Сообщений: 3,655
	11.05.2024, 21:46
	Я не предлагал TStopwatch, я лишь писал, что это инструмент для отсчета более точных временных интервалов, чем может GetTickCount. 0

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

@AzAtom Модератор 4153 / 2362 / 814 Регистрация: 15.11.2015 Сообщений: 9,496
	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 1074 / 514 / 41 Регистрация: 05.05.2022 Сообщений: 3,655
	14.05.2024, 18:43
	Предположение. Нужна задержка м/у сменой четности при отправке адреса и собственно посылки. Статистику ответов и ошибок CRC надо было делать сразу, как без этого можно жить, я не понимаю. 0

@AzAtom Модератор 4153 / 2362 / 814 Регистрация: 15.11.2015 Сообщений: 9,496
	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