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

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

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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

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

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

эту возможность я почти реализовал, но, поскольку лично мне она не очень нужна (меня и \x0А не напрягает), не сильно тороплюсь.
передача файлов реализована и у меня, но о том, чтобы данные файла преобразовывать в нужные пакеты - это надо делать фильтрами самостоятельно, если, конечно, в файле данные не в том формате, что надо передавать.
а вот с этим я чисто логически не понимаю, как делать. де-факто в винде и линухе поддерживается нативно UTF8, а все прочее, хоть и возможно, но требует усилий. соответственно, я пришел к мнению, что UTF8 по умолчанию устроит всех. и, хотя принципиально реализовать это не проблема (в виде фильтра для смены кодировки), делать не охота...что такое "распознавание"?
что такое "умение работать"? приходящий пакет протокола разобрать на части и показать их поотдельности или выборочно только нужные? если вы знаете формат пакета, это сделать можно уже сейчас. если вы не знаете формат пакета - кто за вас это будет делать?!
какая такая "эмуляция"? вы можете ввести данные, добавить к ним (автоматически, фильтрами!) необходимые сопроводительные поля (адрес, длину, CRC и т.п., что требует протокол) и выдать его в порт - это не эмуляция?у меня реализована возможность ЛЮБЫХ CRC в 8, 16 и 32 бита - подчеркиваю: ЛЮБЫХ. вам должен быть известен полином и другие параметры CRC - и все, моя программа поддержит этот алгоритм.

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

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

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

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


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

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

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

сойдет и так

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


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


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

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

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

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

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

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


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