Ну и отстой же этот Realterm
Сделан на AsyncPro десятилетней давности. Да еще на ActiveX технологии.

Пока работал у меня раз 10 исключения выкинул. Строки да, режет.
На AsyncPro вы сами за 10 мин сделаете свой терминал , AsyncPro же теперь бесплатно лежит и даже поддерживается до последних версий RAD Studio.

Я практически во все свои программы вставляю этот терминал. Работает без нареканий. Тот же ANSI, VT100 и проч. поддерживает, протоколы X-Y-Zmodem и т.д. Сокеты опять же.

Рискну предложить сообществу свое творение...
Две версии - с инcталяшкой - внутри 32-бит, отдельный exe - 64 bit. Исходники доступны.

Экран настроек - Alt+F3, там внизу кратенько все написано. Изменение настроек как в старых bios.
Handshake никакого нет, просто пункты в настройках.

Сообщение отредактировал Genadi Zawidowski - Dec 28 2016, 10:39

А Clear at [ ] - это не то?

Хорошая тема у Segger-а
15 независимых терминалов в одном окне через один SWD интерфейс!
Поддерживается скорость что-то около 4 Mbit



А вот кто либо знает драйвер под Windows поддерживающий композитный дивайс с двумя виртуальными COM портами?

Да я тоже поддерживаю. И даже начинал писать. Но времени всё время нету на это (((


Нет. Это как раз самое нужное. Надо было на первое место поставить.
У меня обычно в ПО бывает много встроенной отладки (в различных компонентах ПО и службах), которая управляется через свои команды, порой довольно сложные.
И когда отлаживаешь работу такой службы или взаимодействие с ней, очень много раз приходится набирать порой довольно длинные команды.


Что значит ворованное/купленное? Я имею в виду - наше собственное ПО, написанное давным-давно одним коллегой.... но вот к сожалению немного криворуким


Ну мало-ли почему Putty не теряет. Может несколько по-другому с портом работает и поэтому просто повезло, что не наступает на баги чипа USB-UART.
У меня с некоторых пор интенсивной работы с USB-UART переходниками предубеждение против всех их вариантов, кроме FT232x и CP210x.
На других (всяких PL2303 и пр.) я тоже сталкивался с потерями на больших скоростях. Потом заменял на FT232 или CP2102 и под тем же терминалом всё начинало прекрасно работать вплоть до 921600 - без каких-либо проблем.

Для 95 случаев из 100 так и делаю. Есть давно отработанные кубики из которых собираются специализированные терминалы с нужными наворотами включающими в том числе и загргузчики. Но как универсальный с возможностью некоторого программирования через скрипты и профили - ZOC. Просто вне конкуренции.

Тут для ясности картины следовало бы указать какими чипами USB-UART при этом пользовались и на каких скоростях. Потери от этого зависят.

Есть возможность написать скрипт разворачивающий принимаемую информацию.

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


А программируемые юзером кнопки там есть?

Да, конечно.

Тогда поставлю себе на заметку посмотреть его.

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

(конечно, предварительно настроив порт при помощи minicom'а). Все достаточно элементарно — и никакие "кнопочки" не нужны, тем более что "кнопочки" потребуют рисования сложного GUI — нафиг оно нужно, когда проще сразу в терминале запускать?

Ну так и писали бы: "наше собственное".

А проприетарщина отличается закрытым кодом и прочим огораживанием. Не надо ее поддерживать, лучше поддерживайте GNU.

Насчет потерь, я сильно сомневаюсь, что программист, который пишет терминальный клиент, настолько криворук, что поставит большие задержки в select/poll/epoll (или что он там будет использовать), чтобы на больших скоростях терять информацию. Скорее всего, в потере информации виновата сама железяка. Скажем, вместо того, чтобы в буфер копить и по 64 байта слать по USB посылки, она каждый байт индивидуальной посылкой отсылает — вот и кирдык данным...

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




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

Я без понятия, что это такое.

Посмотрите Terminal v1.9b
тут немного про него есть.
Мне очень нравится. Пользуюсь уже не помню сколько лет.
Кстати, содержит и функцию параллельной записи в файл- очень удобно для долговременных логов.
И свои метки времени вставлять может для строк, и еще много чего еще.

Есть важное ограничение- не видит порты в винде начиная кажется с COM65. приходится выкручиваться, но в остальном претензий никаких. А, еще в момент запуска пишет "I/O error 103", но на его работоспособности это никак не отражается.