Форум РадиоКот

ARV, зачем дурацкие подозрительные файлообменники, когда есть сосфорж, гитхаб, битбакет, гитлаб и т.д., и т.п.?

подозрительность признак паранойи, "облако" Mail.ru тут совсем ни при чем

ARV, так где исходники-то? ☺

Может знаете какие-нибудь тренажеры

Eddy_Em писал(а):ARV, так где исходники-то? ☺

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

ARV, так мне они не нужны, я ж в линуксе работаю, там все нормально с этим делом. UNIX-way — классная штука!
А вот каким-нибудь вендузятникам эти исходники вполне могут пригодиться.
Да и исходники документации удобней хранить в VCS, чтобы если что легко было откатиться.

Eddy_Em писал(а):так мне они не нужны

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

ARV, в большинстве случаев хватает обычного текстового вывода. Но все равно, хоть и есть стандартный screen, я себе тоже терминальный клиент написал, чтобы повторные команды можно было просто клавишами курсора вытаскивать из истории readline. Ну и ncurses использую для разделения входных и выходных потоков.
Что до обработки, то обычно для этого использую пайпы в sed/grep/awk. Если нужно бинарный протокол глянуть, отправляю пайп в hexdump. Но бинарные протоколы крайне редко используются, поэтому простейшую автоматизацию вообще зачастую делаю на обычных баш-скриптах (скажем, нужно с одного компьютера включить аппаратуру, подключенную к другому, запускаю скрипт, который по ssh на другом компе отправляет нужные команды в /dev/ttySx или /dev/ttyUSBx и выполняет соответствующие действия).
Для анализа чужих протоколов я когда-то писал сниффер, который с одного канала читает Rx, с другого Tx и все пишет в один лог-файл, ставя временнЫе метки. Удобно подобный анализатор на STM'ке запилить, чтобы одно устройство было к USB подключено, а эмуляторов порта фактически несколько (на STM32F103 или STM32F0x2 можно сделать до семи каналов USB<>UART).

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

в частности, если бы вы прочли моё описание моей программы, вы бы неизбежно пришли к выводу, что писать о том, как при помощи своих скриптов вы решаете какие-то частные проблемки (не задумывась о том, кто еще способен подобное сотворить на питоне или баше) ни к чему, ибо едва ли не на первой странице моего текста я написал :

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

и, к слову, мне очень хотелось бы увидеть, как вы "стандартными для линуха" средствами (пайпами там или чем еще) реализуете то, что я описал на 30-й странице моего документа...

Добавлено after 5 minutes 33 seconds:

Eddy_Em писал(а):я когда-то писал сниффер, который с одного канала читает Rx, с другого Tx и все пишет в один лог-файл, ставя временнЫе метки.

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

обновил описание, добавил релиз проекта (в архиве - распаковать в любую папку, запускать configurator.exe): https://cloud.mail.ru/public/4tPD%2FuyfBDkHnH

в принципе, можно пользоваться...

снова обновил файлы: добавил последний важный блок для записи данных в файл и скорректировал описание.

еще одно обновление: исправил ошибки и заменил фильтр Digitizer на более универсальный Format. скорректировал описание.

И снова обновил файлы: исправил ошибки, сделал небольшие улучшения, скорректировал описание. Ссылка та же самая: https://cloud.mail.ru/public/4tPD%2FuyfBDkHnH

и снова обновление: https://cloud.mail.ru/public/4tPD/uyfBDkHnH
как обычно, исправление ошибок, уточнение описания...
но есть и новенькое: реализовал "библиотеку" пресетов, т.е. теперь можно удачно сделанные заготовки сохранять впрок. например, сделал настройки блока CRC для расчета CRC по алгоритму Modbus - для бинарного и текстового вариантов протокола, так что теперь можно пользоваться - архив с этой "библиотекой" прилагаю - желающим поиграться.

печально, что никого не удается заинтересовать...

пытаюсь тестировать, как моя программа может победить Modbus...
сделал тестовую конфигурацию:

посылаю команду 1-му устройству - прочесть 2 аналоговых входа, начиная с нулевогоо адреса:
\x01\x04\x00\x00\x00\x02\x71\xcb
вижу в консоли такое:


вроде работает...

Добавлено after 1 hour 31 minute 43 seconds:
а вот так можно изменить конфигурацию, чтобы видеть значения из ModBus-а в более привычном виде - в вольтах и амперах, например:

при этом в консоли будет такое:

а кроме того еще на дисплее будет и такое:

все обновляется каждые 0,5 сек, что видно по содержимому консоли

Добавлено after 2 hours 29 minutes 36 seconds:
вот и Modbus-TCP сделал:

сейчас пользую TerminalTMB_v2.25
удобен тем, что могу HEX сообщения посылать в таком формате:
FE 1C F5 01 01 1E 5B 59 00 00 5F C3 4F 3B 69 2E 0F BD DB 33 22 40 EF 8A 4A 3A 7A FF 74 B9 51 37 06 BA 33 67
без всяких "0x" и ";"

до этого пробовал:
HyperTerminal
Termit
PuTTY
Realterm
Встроенный терминал в ардуино...
Terminal v1.9b by Bray
КомПорт Толкин

и ничего из этого не понравилось
в основном пользовался КомПорт Толкин, но и он не хотел воспринимать HEX в том формате, что я выше привел.
приходилось что то править ручками

В TerminalTMB_v2.25 - есть ограничение на количество символов в строке ввода
Может конечно там есть какая то функция, что бы подключать фалы - но я пока не разобрался..

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

Обязательным вижу возможность юзать все доступные кодировки
и в любом формате ( каком душе угодно )

---------------------------------------------

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

различные CRC тоже не помешало бы...

uwrtey писал(а):HEX сообщения посылать в таком формате:
FE 1C F5 01 01 1E 5B 59

эту возможность я почти реализовал, но, поскольку лично мне она не очень нужна (меня и \x0А не напрягает), не сильно тороплюсь.

uwrtey писал(а):подключение txt-файла, в котором можно без ограничения ( ну или очень большого объема )
записывать пакеты для передачи ( дабы имитировать поток данных )

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

uwrtey писал(а):возможность юзать все доступные кодировки
и в любом формате ( каком душе угодно )

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

uwrtey писал(а): распознавание некоторых протоколов

что такое "распознавание"?

uwrtey писал(а):умение с ними работать

что такое "умение работать"? приходящий пакет протокола разобрать на части и показать их поотдельности или выборочно только нужные? если вы знаете формат пакета, это сделать можно уже сейчас. если вы не знаете формат пакета - кто за вас это будет делать?!

uwrtey писал(а):эмуляция каких то протоколов

какая такая "эмуляция"? вы можете ввести данные, добавить к ним (автоматически, фильтрами!) необходимые сопроводительные поля (адрес, длину, CRC и т.п., что требует протокол) и выдать его в порт - это не эмуляция?

uwrtey писал(а):различные CRC тоже не помешало бы

у меня реализована возможность ЛЮБЫХ CRC в 8, 16 и 32 бита - подчеркиваю: ЛЮБЫХ. вам должен быть известен полином и другие параметры CRC - и все, моя программа поддержит этот алгоритм.

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

Добавлено after 17 minutes 52 seconds:
бегло почитал о программе TerminalTMB_v2.25, и могу сказать, что по функционалу она не дотягивает даже до предыдущего моего терминала FTerm (в этой ветке ранее есть ссылка). кстати, в FTerm ввод данных в виде "0f ff" реализован был

ARV писал(а):эту возможность я почти реализовал, но, поскольку лично мне она не очень нужна (меня и \x0А не напрягает), не сильно тороплюсь.

это сейчас для меня на первом месте. ( требует текущий проект )

ARV писал(а):это надо делать фильтрами самостоятельно

не буду повторяться

ARV писал(а):а вот с этим я чисто логически не понимаю, как делать

В прошлом моем проекте очень надо было. ну прям очень.. Тогда решил вопрос одним из перечисленных мною терминалов - увы не помню каким.

ARV писал(а):что такое "распознавание"?

Ну знаете - на подобии логического анализатора. Подслушивает поток и сам! определяет (предполагает) на какое скорости идет обмен и что за формат данных

ARV писал(а):если вы знаете формат пакета, это сделать можно уже сейчас. если вы не знаете формат пакета - кто за вас это будет делать?!

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

ARV писал(а):и выдать его в порт - это не эмуляция?

сойдет и так

ARV писал(а):у меня реализована возможность ЛЮБЫХ CRC

и так сойдет, но удобнее выбрать из списка ( и потом видеть именно выбрано, и это исключит возможность ошибки )

ARV писал(а):похоже, вы не читали описание моей программы... а жаль. потому что ваши вопросы-предложения оказываются неконструктивными от незнания уже готовых функций и возможностей программы...

Каюсь, читал очень бегло...

ARV писал(а):бегло почитал о программе TerminalTMB_v2.25,

На данный момент меня удовлетворяет только она...

ПС: я вовсе не настаиваю. Автор - Вы. Возможно мои предложения вовсе бессмыслены или узконаправлены...

Ваши пожелания просты: вы хотите, чтобы вам был предоставлен инструмент, который бы все делал за вас. Я же стараюсь сделать швейцарский армейский нож, с помощью которого каждый может сам сделать, что угодно. Т.е. я делаю конструктор, а вам нужен робот.

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

Что касается смены кодировок, то мне даже тестировать не на чем, в моем распоряжении только utf8 и все... Потому я и не понимаю, что нужно и как нужно. Дайте примеры, что ли...

Я наконец-то утянул домой терминал, который активно используется у нас на работе. Может, понравятся какие-нить идеи.
Итак, весь функционал настраивается через .ini-файл (хотя .xml наверное было бы нагляднее):
— параметры обмена;
— приём;
— передача.
С параметрами, думаю, понятно: скорость, чётность, бит данных, стоповых бит.
Приём: можно настроить в каком формате выводить и как интерпретировать принятые байты (int, single, double...), какой длины сообщение ожидать, хидер, трейлер.
Передача: можно добавить кнопки, по нажатию на которые будут отсылаться какие-то данные. В том числе переменные данные, которые каждый раз запрашиваются у пользователя.
По желанию вся история обмена пишется в лог-файл.


Также планирую утянуть терминал для вывода графиков, который писался чисто под мои хотелки