я время от времени получаю в ЛС вопросы и предложения по "терминалу"... поэтому хочу немного пролить свет на тему, чтобы, возможно, дать часть ответов на часть вопросов и/или сделать задаваемые вопросы более конкретными.
итак,
что задумано1. программа, которая предназначена для наблюдения за потоком данных между внешними устройствами и/или компьютером.
2. безусловной привязки только к СОМ-портам нет, но, как самое простое, это будет сделано в первую очередь. вообще же задумка такая, что можно будет смотреть на любые потоки - CAN, LIN, UDP, TCP и т.п.
3. нет привязки к конкретному способу вывода информации. большинство программ выводит либо в виде таблицы, либо в виде графика, ну или в виде текста. я же предполагаю сделать так, чтобы можно было выводить что угодно как угодно. разумеется, в определенных рамках. в частности, спрашивали: можно ли видеть ВЕС с промышленных весов, зная протокол обмена? большинство терминалов позволяет увидеть ПАКЕТ, и в одном из его полей увидеть нужный вес - это понятно. моя программа сможет ВЫРЕЗАТЬ из пакета ТОЛЬКО ВЕС и показать его, например, НА СТРЕЛОЧНОМ ИНДИКАТОРЕ. и больше ничего пользователь не увидит!
как это планируется реализовыватьоснова уже была заложена в программе
FTerm - это система фильтров данных. т.е. поступающие из наблюдаемого источника данные проходят через систему фильтров, которые оставляют на выходе только нужную информацию в нужном виде.
теперь эта система фильтров дополняется новыми возможностями, количество фильтров будет больше, появится возможность использовать не единственный источник/приемник данных, а произвольное их количество.
основная фишка нового проекта - графический визуальный интерфейс - вы могли видеть выше скриншот.
на скриншоте была показана простая система автонагрузки моей программы (для тестирования): данные с клавиатуры поступают (стрелки показывают направление движения данных) через блок ИЛИ на вход RX СОМ-порта, а то, что из СОМ-порта придет - поступает снова ему на вход через тот же блок ИЛИ. таким образом, стоит один раз ткнуть пальцем в клавиатуру, как СОМ-порт начинает сам себе флудить с предельно возможной интенсивностью (если его физические контакты RX-TX замкнуты, естественно).
аналогичным образом можно нарисовать систему изучения обмена любого количества любых девайсов: нарисовал стрелочку в нужном месте к блоку "консоли" - и смотри, что там передается.
само собой, вместо (или вместе с нею) клавиатуры предусматривается возможность использования других источников данных, например, таймера (чтобы посылать данные периодически без ручного вмешательства), или файла, или другого порта... да хоть с микрофона (не думал, но можно сделать). в любом месте прохождения данных можно вставить любое количество фильтров, чтобы изменять поток данных, как угодно. например, бинарный обмен нет смысла наблюдать в режиме "1 к 1", т.к. половина кодов будет соответствовать кракозябрам полностью бессмысленным. но можно выделить из этого бинарного потока важные данные, и преобразовать их в читаемый вид (например, если в пакете данных есть важное поле "адрес отправителя", можно его выделить, и не просто вывести число в любом формате, но вывести вместо этого числа обычное текстовое название отправителя, если оно известно). можно встрять в поток и заменить того же отправителя на другого, чтобы принимающее устройство думало, что получило данные от другого... ну и так далее.
короче, я хочу сделать ЛЕГО для изучения потоков данных, а что из моих блоков вы построите - зависит от вашей фантазии и потребностей.
что уже реализованопока не так много:
1. графический интерфейс построения диаграммы потоков данных, рабочее название - конфигурация.
2. блок последовательного порта (СОМ).
3. блок текстовой консоли (точнее, только текстового визуализатора, ввод данных в этом блоке невозможен - это концептуальное условие)
4. блок текстового ввода (рабочее название - клавиатура).
то есть уже сейчас можно иметь почти тот же функционал, что и средний терминал.
что планируется в ближайшее время1. блоки типичных фильтров (поиск-замена, преобразование форматов, выделение пакета по шаблону, буфферизация, детектор пауз)
2. блоки таймера, сигнализатора, записи в файл, счетчика
3. блок источника данных "файл"
4. блок табличного отображения пакетных данных
5. блок графического визуализатора (по времени) входных числовых данных
6. блок графического визуализатора в виде стрелочного прибора (а-ля спидометр)
(в порядке предполагаемой очередности)
в настоящее время я занимаюсь отладкой, тестированием и доводкой всего этого добра. и мне, как я уже не раз писал, не хватает обратной связи.
надеюсь, я ответил на все заданные и еще не заданные вопросы... но готов продолжить разговор