Терминал моей мечты (COM-порт)

[Gudd-Head↑↓]

Отпуск закончился

[ARV↑↓]

тут были пожелания на счет "нормального" ввода значений в HEX-формате...
ну, вот набросал такой блок: https://cloud.mail.ru/public/uGth%2F95nVdPsQs - так нормально будет?

HEX-ввод позволяет вводить с разделением на байты или без оного, т.е. можно FF3E2A, но можно и FF 3E 2A - это будет то же самое. при этом F F 3 это то же самое, что и три байта 0F 0F 03, а FF3 - это то же самое, что FF 03

текст сохранен так же, как и был, но в этом поле можно вводить и так: "Текст с переносом\nстроки" или "Текст с 2 байтами данных \xFF\xFE"

история ввода - в выпадающих списках.

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

[ARV↑↓]

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

попробую пояснить примером.

многим знаком протокол Wake, который достаточно широко применялся для создания "сетей" измерительных приборов, например.
предположим, есть нужда отправлять пакеты по этому протоколу. сложность заключается в том, что этот протокол подразумевает две далеко не тривиальные вещи: байтстаффинг данных и вычисление CRC пакета. сделать это вручную не так-то просто, если вы не пользуетесь моим пакетом OBSERVER

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

показываю пример решения задачи:


поясняю рисунок:
1. Большинство блоков просто переименованы, далее описываю как и что.
2. Ввод ADR-CMD-DATA - это блок ввода данных. По названию понятно, что вводить нужно байт адреса "кому пакет", байт "команды" и произвольное количество байтов "данных" пакета (может отсутствовать).
3. Байтстаффинг - это блок замены списком, далее поясню подробнее.
4. Начало пакета+ - это блок ДОПОЛНЕНИЕ, т.е. блок, который добавит к началу данных байт "начало пакета" (это фиксированный протоколом байт, и вводить вручную его смысла нет, пусть добавляется автоматически)
5. CRC - это блок восьмибитной CRC, настроен на полином протокола Wake 0x31, начальное значение 0xDE, остальное 0.
6. AND - это блок, который делает единый пакет из двух частей
7. Последовательный порт в комментариях не нуждается - это транспорт для доставки пакета.

теперь немного подробностей, почему так, а не иначе.

пользователь вводит нужные байты адреса, команды и данных. ввод может быть в различном виде, это понятно. в итоге получается строка байтов, которая попадает на блок байтстаффинга, т.е. замены некоторых байтов на пары:
DB ---> DBDD
C0 ---> DBDC
то есть получается уже другая строка, к которой добавляется байт C0 в самое начало - это признак начала пакета. но этот байт не должен заменяться байтстаффингом, поэтому он добавляется после того, как введенные пользователем данные обработаны.
теперь нужно дополнить пакет контрольной суммой, и тут небольшая проблемка: с одной стороны CRC должна считаться для пакета с байтстаффингом, с другой - сама должна пройти через байтстаффинг. и эта проблема решается "раздвоением" обработки: считается для подготовленного пакета CRC, подвергается байтстаффингу, а затем "приделывается" к подготовленному пакету - вуаля! все готово к отправке.

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

Разумеется, похожим образом можно наладить формирование пакета для различных протоколов и посложнее. Более того, можно реализовать еще более "гуманный" интерфейс, например, сделав дополнительный блок замены списком, при помощи которого заменять СИМВОЛЬНЫЕ КОМАНДЫ и/или НАЗВАНИЯ УСТРОЙСТВ на их байтовые коды, чтобы в итоге отправка данных делалась в таком виде: VOLTMETER:READ: или DIMMER:BRIGHT:12% (блок замены списком заменит VOLTMETER: на адрес вольтметра, DIMMER: на адрес диммера, READ: на код команды чтения значения, BRIGHT: на код команды установки яркости, знак процента заменит на "ничего", ну а 12 так и останется 12)

Добавлено after 3 minutes 29 seconds:
само собой, аналогичным использованием блоков замены списком, CRC и т.п. можно "расшифровывать" и пакеты, возвращаемые устройствами по протоколу Wake, чтобы показывать в консоли (или где там хочется - на стрелочных приборах, возможно) уже "человекочитаемые" результаты.

Вложения

wake-1.png

(9.02 KiB) Скачиваний: 2970

[ARV↑↓]

Завел тему на ELECTRONIX.RU - раз тут интересу тема не вызвала, буду там пытать счастья. тут больше не пишу.

[Мурик↑↓]

Завел тему на ELECTRONIX.RU - раз тут интересу тема не вызвала

Судя по этому

У вас нет прав для просмотра этой публикации.

Там интерес вероятно будет еще меньше.

[ARV↑↓]

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

[ARV↑↓]

Если вдруг кому интересно, то проект обновлен https://cloud.mail.ru/public/4tPD%2FuyfBDkHnH
Теперь там есть и блок для графического отображения данных.
Переключение на electronix.ru дало значительный эффект: количество найденных и исправленных, благодаря тамошним посетителям, багов просто поразило моё воображение!

[ARV↑↓]

Загрузил в облако https://cloud.mail.ru/public/4tPD%2FuyfBDkHnH последний релиз проекта. Присвоил версию 1.1.0

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

Некоторые изменения по мелочи, как всегда, описаны в файле history.txt

Там же в облаке тестовая конфигурация для "поиграться" с графическим отображением данных.

Теперь буду заниматься только устранением багов, на которые укажет почтенная публика, новшеств не планируется до 100% уверенности в качестве уже сделанного.

[nickjust↑↓]

Хай
А можно продублировать ваш проект на github или на гугл диск
С Украины проблематично качать файло без ВПН

[ARV↑↓]

С гитхабом я не дружу, а на диск загружу завтра

[ARV↑↓]

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

[Gudd-Head↑↓]

Понадобился мне на неделе терминал на Windows Embedded, и я с удивлением и огорчением обноружил, что все мои терминалки там не работают (не запускаются) даже в режиме совместимости. Стал побираться по друзьям-соседям, и наткнулся на это:

Что понравилось:
— минимализм;
— быстрая и удобная настройка параметров обмена;
— сразу видно доступные СОМ-порты;
— возможность отправки нескольких байт данных по клику (до 12 макросов внизу);
— не требуется установка, мало весит.
Что не понравилось:
— отправляемые данные отображаются в ASCII (ну или я не нашёл как переключить их в hex);
— только старшие 10 СОМ-портов.

Вложения

Terminal2.zip

(320.95 KiB) Скачиваний: 143

[ARV↑↓]

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

я сейчас об этом варианте: https://cloud.mail.ru/public/Audn/95Vd3Xz1j потому как OBSERVER не так уж минималистичен и прост в настройках.

[electroget↑↓]

ARV писал(а):

показываю пример решения задачи:

Есть какая-то программа для рисования таких блок-схем или это нарисовано в Ворде?

[ARV↑↓]

ну как бы эта "блок-схема" и нарисована в моём "терминале" OBSERVER
а программ для этого куча - от MS Visio до Inkscape

[electroget↑↓]

ARV писал(а):

программ для этого куча - от MS Visio до Inkscape

Я собственно поэтому и спросил. Использовать специализированные графические редакторы для рисования блок-схем это ЕЩЁ ХУЖЕ чем использовать для этого Ворд. Даже Ворд это как на тракторе за хлебом ездить.

[ARV↑↓]

Использовать специализированные графические редакторы для рисования блок-схем это ЕЩЁ ХУЖЕ чем использовать для этого Ворд

ну а как же тогда ХОРОШО создавать блок-схемы? специализированными редакторами плохо, вордом - плохо... а хорошо-то как?!

[electroget↑↓]

ARV писал(а):

а как же тогда ХОРОШО создавать блок-схемы?

Да никак, наверно. Это задача у которой нет ХОРОШЕГО решения.

[Eddy_Em↑↓]

Я как-то давным-давно в Tikz блок-схемы рисовал. В принципе, для несложных схем - нормально. Но сложные лучше таки в чем-нибудь более визивигном - типа Dia…

[electroget↑↓]

Eddy_Em,
Понял.