[Arlleex 284]

1 час назад, jcxz сказал:

Я в своё время перепробовал множество терминалок. Искал самую безглючную. Не нашёл.  Во всех встречались те или иные баги. Пришлось писать свою.

Что с putty не так?

[makc 322]

2 минуты назад, Arlleex сказал:

Что с putty не так?

Почти всё не так. До удобного терминала для отладки ему (ей?) очень очень далеко. Нет ни меню, ни возможности быстрого подключения/отключения к порту и т.д. Сравните хотя бы с gtkterm (если под Linux).

[Arlleex 284]

15 минут назад, makc сказал:

Почти всё не так. До удобного терминала для отладки ему (ей?) очень очень далеко. Нет ни меню, ни возможности быстрого подключения/отключения к порту и т.д. Сравните хотя бы с gtkterm (если под Linux).

Речь не об удобствах, это дело вкуса и личных хотелок. Речь о багах программы как терминала. Уж чего чего, так терминал лично мне не доводилось переписывать...

[makc 322]

28 минут назад, Arlleex сказал:

Речь не об удобствах, это дело вкуса и личных хотелок. Речь о багах программы как терминала.

Ну как сказать... Инструменты должны быть удобными, чтобы быть эффективными. Попробуйте резать помидоры тупым ножом. 🫢

[mantech 105]

3 часа назад, jcxz сказал:

Я у себя все переходники на PL23xx уже давно повыкидывал. Чего и вам советую.

3 года назад повыкидывал все вообще, перешел на эзернет))

[jcxz 313]

4 часа назад, Arlleex сказал:

Что с putty не так?

Уже не помню всех деталей. Но putty сам по себе неудобен в качестве отладочного терминала. Я использую его, когда нужно интерактивное взаимодействие с программой: пользовательский интерфейс, меню, конфигурирование и т.п. Но для отладки он неудобен. Для отладки нужен терминал примерно такого типа:

В верхнем поле можно вводить команды. Которые отправляются как строка только после полного ввода и нажатия Enter. В нижнем - весь лог обмена: отправляемые данные, принимаемые. И чтобы лог мог быть длинным - хоть во много мегабайт длиной. Вот уже это Putty не умеет - у него короткая история. И построчного ввода нет, только интерактивно. Также Putty сильно тормозит: на моём не самом слабом i5 - отправляю с МК поток данных в UART со скоростью = 921600 бод -> загрузка CPU=~25%!   Для такого ПК это слишком много. Моя терминалка в таком случае вообще практически не грузит CPU (есть передача или нет - загрузка CPU на глаз никак не меняется).

У многих терминалок баги проявлялись только при хорошей нагрузке: Отправляешь с МК скажем файл: base64-кодированный двоичный поток случайных данных с CRC. И записываешь его терминалкой. Если размер файла небольшой - почти все справляются. Но как только размер файла становится хотя-бы = несколько МБ - начинаются проблемы: выпадения кусков текста, "замораживание" окна терминалки, высокая загрузка CPU (до 100% у некоторых бывало). Уже не помню - тестил ли так putty, но она сама по себе не подходит для отладочной терминалки.

4 часа назад, makc сказал:

Почти всё не так. До удобного терминала для отладки ему (ей?) очень очень далеко. Нет ни меню, ни возможности быстрого подключения/отключения к порту и т.д. Сравните хотя бы с gtkterm (если под Linux).

Да - речь именно об отладочном терминале. Не совсем о таком как Putty.

Вот ещё какой баг наблюдал у некоторых терминалок: Если устройство (МК) отправляет данные с какой-то определённой частотой - скажем одну строку каждые 50мсек, то встречал такие терминалки, которые при этом вообще переставали обновлять своё окно. Как будто на вход вообще ничего не поступает. Если отправляет чаще или реже - всё Ок. Но если с определённой частотой - устройство может хоть час так сообщения отправлять - в окне терминалки чисто, как будто на вход ничего не поступает.    Нужно было остановить работу МК - и тогда сразу все тысячи принятых сообщений появлялись на экране.

Многие баги у терминалок проявляются только при определённых условиях. Не всегда они сразу заметны. Но очень бесят.

4 часа назад, makc сказал:

ни возможности быстрого подключения/отключения к порту и т.д.

Точно. Согласен. Почему-то такая нужная вещь редко кем из терминалкописателей предусматривается.

3 часа назад, Arlleex сказал:

Речь не об удобствах, это дело вкуса и личных хотелок. Речь о багах программы как терминала. Уж чего чего, так терминал лично мне не доводилось переписывать...

Я тоже долго не хотел этим заниматься. Но потом совсем допекло.    Это всё-таки - один из самых главных инструментов в моей работе. Используемый каждый день.

[sasamy 14]

1 hour ago, jcxz said:

Для отладки нужен терминал примерно такого типа

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

https://www.com-port-monitoring.com/serial-port-terminal/

[Arlleex 284]

Ясно. Просто я сразу рисую гуй с кнопками и лампочками.

1 час назад, jcxz сказал:

Я тоже долго не хотел этим заниматься. Но потом совсем допекло.    Это всё-таки - один из самых главных инструментов в моей работе. Используемый каждый день.

 

[tonyk_av 65]

9 hours ago, mantech said:

3 года назад повыкидывал все вообще, перешел на эзернет))

Аналогично. Правда не буквально, а фигурально. Хотя нынешние ноутбуки стали лишать Эзернета, оставляя только USB, в который приходится втыкать USB-Ethernet.

[_pv 101]

16 hours ago, jcxz said:

О недостатках его - тоже писал в самом начале. И я его давно использую.

 

  int n = 1000000;
  QueryPerformanceCounter(&t0);
  while(n--) ret = QueryDosDevice("COM6", buff, sizeof(buff));
  QueryPerformanceCounter(&t1);

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

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

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

 

Перед отправкой/приёмом каждого байта проверять наличие порта, не отвалился ли он, это пожалуй немного через чур, но и то работать будет (возможно не очень на 3Мбитах скорости), а вот перед каждым "пакетом" - вполне.

[jcxz 313]

47 минут назад, _pv сказал:

  int n = 1000000;
  QueryPerformanceCounter(&t0);
  while(n--) ret = QueryDosDevice("COM6", buff, sizeof(buff));
  QueryPerformanceCounter(&t1);

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

А вы уверены, что таким способом вы обнаружите все COM-порты в системе?

Я сейчас использую для получения списка портов RegOpenKeyEx()/RegQueryInfoKey()/RegEnumValue() и ещё ряд функций. И сканирую ими ветку реестра "Hardware\\DeviceMap\\SerialComm". И код - во много раз больше.

А про упрощённые методы задания имени COM-портов слышал, что они не все порты обнаруживают.

47 минут назад, _pv сказал:

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

Это вы видите задержку их отображения. Которая основана на частоте обновления той программы, которой смотрите. Реальная скорость появления порта в реестре думаю - во много раз больше. По логу энумерации своего USB CDC устройства, вижу, что вся энумерация занимает максимум ~200 мс (насколько помню; пишу по памяти).

У меня часто открыто сразу несколько программ, работающих с COM. Если скажем все станут сканить реестр с периодом ~100мс (со всеми его открытиями, блокировками, etc.) - думаю это будет не очень хорошо.

47 минут назад, _pv сказал:

Перед отправкой/приёмом каждого байта проверять наличие порта, не отвалился ли он, это пожалуй немного через чур, но и то работать будет (возможно не очень на 3Мбитах скорости), а вот перед каждым "пакетом" - вполне.

Это не работает. Если бы это работало, то и темы этой бы не создавал. Я в самом начале писал - что все читающие операции с дескриптором или возвращающие его состояние - продолжают нормально работать если порт пропал из системы. Не чувствуют его пропадания. Или я не нашёл такой функции, которая чувствует. Если знаете такую - напишите.

[mantech 105]

7 часов назад, tonyk_av сказал:

Правда не буквально, а фигурально. Хотя нынешние ноутбуки стали лишать Эзернета,

Это "неправильные" ноутбуки, я пользуюсь правильными, с эзернетом)))

[_pv 101]

4 hours ago, jcxz said:

А вы уверены, что таким способом вы обнаружите все COM-порты в системе?

ну у меня сейчас сом1 - железный и сом6 - usb->serial из какого-то китайского ch552, обои два вроде обнаруживает, вне зависимости от того открыты они в другой программе или нет.

при выдергивании переходника из usb порта

while(1) printf("%d\r", QueryDosDevice("COM6", buff, sizeof(buff)));

сразу же начинает показывать 0, если воткнуть обратно - оживает через несколько секунд.

4 hours ago, jcxz said:

У меня часто открыто сразу несколько программ, работающих с COM. Если скажем все станут сканить реестр с периодом ~100мс (со всеми его открытиями, блокировками, etc.) - думаю это будет не очень хорошо.

QueryDosDevice отрабатывает за 3мкс. отправка/приём байта на 115200 - 85мкс, то есть его можно натурально дёргать перед отправкой/приёмом каждого байта.

[girts 22]

3 hours ago, jcxz said:

Это не работает. Если бы это работало, то и темы этой бы не создавал. Я в самом начале писал - что все читающие операции с дескриптором или возвращающие его состояние - продолжают нормально работать если порт пропал из системы. Не чувствуют его пропадания. Или я не нашёл такой функции, которая чувствует. Если знаете такую - напишите.

Работает, но чуть не так и только исходя из обратного.
Если тот же COM при попытке его открыть == FALSE, значит есть все основания считать его уже открытым и пытатся работать дальше.
Если открылся - значит он был отвалившимся.
Другие варианты не находились.
Некоторое веселье добавляется если был выход из программы не закрывая порт - замечено, что некоторые терминалки в этом грешат.

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

[Arlleex 284]

7 минут назад, girts сказал:

Если тот же COM при попытке его открыть == FALSE, значит...

...он, скорее всего, пропал из системы.