IT>У меня в ХР стоит "классический вид" и интерфейс твоей программы выглядит ужасающее. На скриншоте гораздо приятнее.
На скриншоте Виндоус 7. Интерфейс от 2000 виндов изначально не такой красивый а приложение просто следует основному интерфейсу в ОС.

IT>Вот если бы, я мог в гуе описать свой протокол (типа первый байт в пакете — ИД, и т.д.) и нужные мне пакеты выводило на экран или отправляло, то это было бы гораздо полезнее обычного терминала! Да и цену за такое можно было бы поднять. Подобное я видел в какой то утилите для CAN протокола.
Так о чём я и пишу! Моя прога позволяет описать практически ЛЮБОЙ протокол! И с ним работать. Обрати внимание: на сриншоте идёт работа с протоколом Модбас РТУ. Можно забить свой протокол и работать с ним.
Мало того, протоколами можно обмениваться, выкладывать их в интернете, т.к. они идут отдельными файлами и в ХМЛ.
Плюс к этому, для режима протоколов есть возможность включить автоответ. То есть, мой терминал может сам отвечать на запросы устройства! Причём, отвечать можно по-разному в зависимости от запроса устройства. При этом всём, можно работать не с байтами, а с параметрами, которые вшиты в протокол. Что гораздо удобнее. Я сам пользуюсь своей программой на основной работе, где отлаживаю жеоезки. Очень удобно.

IT>И такое вообще, стоит на форумах для DSP разработчиков пиарить
Не подскажете где лучше? Желательно международные, не рунетовские. Был на сахаре и ещё на одном форуме — посещаемость выросла, но с покупками в России хуже, сами знаете.

Здравствуйте, byterus, Вы писали:

B>А что делать? Программа работает с сетью.

Сделать это опцией и спрашивать у пользователя разрешения на проверку обновлений.

M>Если есть желание, могу накидать еще идеек .

А накидайте

Здравствуйте, mt_, Вы писали:

mt_>Мало того, протоколами можно обмениваться, выкладывать их в интернете, т.к. они идут отдельными файлами и в ХМЛ.

так не пойдёт. сделайте кнопки upload и download, чтобы была коллекция прям на вашем сайте с удобным доступом

Здравствуйте, mt_, Вы писали:

mt_>Два месяца назад впервые попробовал себя в шароварении.

welcome to the club

mt_>Был создан домен и выложена софтина. Программа очень нишевая — продвинутый терминал последовательного порта. Как я предполагаю, будет очень полезна всем,

скорее всего вот что (беда нишевых, да и не только) программ.
в мире полно идиотов. причем идиотов любопытных. сейчас они пришли в инет.
в силу любопытства они качают все подряд, даже то, что им нафиг не надо (за траффик то уже давно никто не платит).
И разумеется они не покупают. вот и все. Плюс еще одна проблема — в инете очень много роботов разного толка. Зачастую они умудряются не только по страницам шастать, но и программы тянуть — анализатор логов вполне их может считать нормальными скачками.
Надо убедиться что за публика идет к Вам на сайт.

Самый простой способ проверить настоящую конверсию — дать в адвордсах кампанию явно нацеленную на профессионлалов. и посмотреть какая там будет конверсия. ну а дальше воевать за целевой траффик.

Здравствуйте, prbasic /a-pora.ru/, Вы писали:

M>>Если есть желание, могу накидать еще идеек .
PAP>А накидайте

Кстати, Василий Васильев, а как вы продвигали свой терминал для коммерческого порта?

Здравствуйте, mt_, Вы писали:

mt_>Кстати, Василий Васильев, а как вы продвигали свой терминал для коммерческого порта?

Терминал мы потом прикрутили.

Я имею в виду, как вы продвигали hhd Serial Monitor?

Здравствуйте, prbasic /a-pora.ru/, Вы писали:

M>>Если есть желание, могу накидать еще идеек .

PAP>А накидайте

А пожалуйста!

Итак, что мы сделали у себя:
1. Возможность записи обмена в логфайл
2. 12 кнопок на которые можно "вешать" команды (прописываются в конфигурационном файле вместе с названиями кнопок).
3. Список команд (лист-бокс) с четыремя столбцами: название команды, коды команды, столбец для ввода параметров команды, столбец с кнопкой "послать" для каждой команды. Данный список прописывается в конфигурационном файле и позволяет задавать заранее все команды для прибора. В принципе это в некотором роде развитие кнопок описанных выше, но ими все-равно продолжаем пользоваться для часто повторяемых команд.
4. Макросы для возможности делать сложные действия: делать заданную задержку между посылками байтов в команде; ожидание приема заданного символа, перед посылкой следующего байта; передача параметра заданного в одном из полей в программе (очень полезно, если система команд имеет адресацию, т.е. в команде присутствует адрес прибора) в т.ч. с инкрементом/декрементом.
5. Возможность расшифровки полученного ответа на команду в виде битов статуса — эта возможность прописывается в конфигурационном файле, вместе с названиями каждого из битов и "вешается" на любую кнопку программы вместе с командой (при нажатии на эту кнопку в первый раз появляется немодальное окно с "лампочками" статуса, при этом они могут быть красного (ошибки) или зеленого (статусы) цветов).
6. Возможность записывать команды в файл и затем "проигрывать" его по-кругу: позволяет, например, выявлять какие-то очень редкие ошибки обмена
7. Отключение скролинга принятой информации: позволяет выводить ее в одном месте и при повторяющейся команде смотреть "мигание" каких-то символов в ответе.

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

И в заключении чего нам не хватает — логер СОМ-порта, которому мы могли бы безоговорочно верить , с более-менее удобним интерфейсом, работающий под Вистой и семёркой. Если бы он умел еще и разбирать пакеты по формируемым нами правилам, то это была бы фантастика. Конечно это не совсем терминал, но вполне может быть его частью или сопутствующей программой. Возможно мы как-нибуть сделаем его. Сейчас выкручиваемя исп. LG-логера под ХР и "прикручиванием" своего логера к каждой из настроечных/управляющих утилит, но это все-таки немного не то...

Здравствуйте, mt_, Вы писали:

mt_>Я имею в виду, как вы продвигали hhd Serial Monitor?

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

Здравствуйте, mject, Вы писали:

M>И в заключении чего нам не хватает — логер СОМ-порта, которому мы могли бы безоговорочно верить , с более-менее удобним интерфейсом, работающий под Вистой и семёркой. Если бы он умел еще и разбирать пакеты по формируемым нами правилам, то это была бы фантастика. Конечно это не совсем терминал, но вполне может быть его частью или сопутствующей программой. Возможно мы как-нибуть сделаем его. Сейчас выкручиваемя исп. LG-логера под ХР и "прикручиванием" своего логера к каждой из настроечных/управляющих утилит, но это все-таки немного не то...

А попробуйте STermPro? Он работает под Вистой и 7кой, умеет разбирать пакеты по тому протоколу, который Вы ему зададите. Всё автоматически логгируется в файл.

mt_>А попробуйте STermPro? Он работает под Вистой и 7кой, умеет разбирать пакеты по тому протоколу, который Вы ему зададите. Всё автоматически логгируется в файл.

А он может перехватывать трафик на КОМ-порту? Возможно я неправильно назвал его "логгером" — в общем нам нужена программа, которая прозрачно вешается на заданный компорт и пишет весь трафик, который идет по нему. Как пример: у нас есть какая-то программа, управляющая устройством и есть устройство. Иногда происходят сбои в обмене. Нужно выяснить кто виноват. Вот в таких случаях мы и используем "логгер".

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

Насколько видно по скришоту программа написана под .НЕТ. Возник вопрос: она использует .НЕТ-овский класс КОМ-порта (System.IO.Ports.SerialPort) или работает с ним через ВИН АПИ (CreateFile)?

Здравствуйте, mject, Вы писали:


M>А он может перехватывать трафик на КОМ-порту? Возможно я неправильно назвал его "логгером" — в общем нам нужена программа, которая прозрачно вешается на заданный компорт и пишет весь трафик, который идет по нему. Как пример: у нас есть какая-то программа, управляющая устройством и есть устройство. Иногда происходят сбои в обмене. Нужно выяснить кто виноват. Вот в таких случаях мы и используем "логгер".
Поддержка "прозрачного" режима появится в версии 2.0, которая выйдет в ближайшее время. С другой стороны, я бы хотел сначала хотя бы немного разобраться с продажами. Тратить месяцы жизни на бесплатные проекты, сами понимаете, приятного мало.

M>Вашу программу мы обязательно попробуем в "боевых условиях", когда возникнет потребность в терминале — может она нам и понравится . Из-за этого сейчас ее ставить не хочу — чтобы не сбить срок триала.
Буду рад ответить на любые вопросы по программе.
Ваши замечания внимательно изучаю. Часть пунктов совершенно точно войдёт в следующую версию.

M>Насколько видно по скришоту программа написана под .НЕТ. Возник вопрос: она использует .НЕТ-овский класс КОМ-порта (System.IO.Ports.SerialPort) или работает с ним через ВИН АПИ (CreateFile)?
Программа написана не под .НЕТ. Это родной бинарник, без виртуальных машин и прочего.
Кстати, линуксовая версия — тоже родной бинарник.
Работа с портом ведётся через Вин АПИ в Винде и стандартные либо в Линуксе.
Плюс к этому, набор оптимизаций отрисовки, за три года отработанный стабильный и эффективный подход к многопоточности. Соответственно, никаких тормозов. Даже на старом оборудовании и массе открытых одновременно портов.

Здравствуйте, mject, Вы писали:

M>А он может перехватывать трафик на КОМ-порту? Возможно я неправильно назвал его "логгером" — в общем нам нужена программа, которая прозрачно вешается на заданный компорт и пишет весь трафик, который идет по нему.

А это, как раз, и делает уже наш продукт: Serial Monitor (DMS). Причём, ни логгинг, ни разбор протоколов не влияет на производительность системы и ограничен только ёмкостью жесткого диска. Остальные продукты чаще всего делают это в оперативной памяти и на быстрых потоках отжирают у системы всю оперативную память и затем валятся.

Также мы специально тестировали логгинг, с последующим его проигрыванием, в жестком режиме, когда данные шли несколько суток. Работает.

Для России у нас специально снижены цены.

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

В планах:
В течении нескольких дней выходит новая версия с новыми возможностями и полностью новым визуализатором.
Далее
1. User Defined Prolocol Parsing (на базе structure view из Hex Editor Neo)
2. Scripting, Macros Recording
3. Event Tracker.
3. Интегрированный Packet Editor/Sender.

В случае, если купите и Lifetime Upgrades, то все последующие версии будете получать бесплатно.

Более подробную информацию можно увидеть на странице продукта Serial Monitor (DMS)

Если есть какие-то вопросы, с удовольствием отвечу.

Здравствуйте, mt_, Вы писали:

mt_>Поддержка "прозрачного" режима появится в версии 2.0, которая выйдет в ближайшее время. С другой стороны, я бы хотел сначала хотя бы немного разобраться с продажами.
Это будет замечательно, и, на мой взгляд востребовано. Тем более у Вашего "близкого" конкурента она уже есть в виде отдельной(?) программы. А по поводу продаж — Вам нужно пиарится на форумах где сидят разработчики железа и программисты микроконтроллеров. Такие терминалы их могут очень сильно заинтересовать.

mt_>Буду рад ответить на любые вопросы по программе.
Когда посмотрим, почти навярняка появятся вопросы/пожелания/замечания. В любом случае что-нибуть напишу.

mt_>Ваши замечания внимательно изучаю. Часть пунктов совершенно точно войдёт в следующую версию.
Рад помочь. Кроме того у меня есть интерес к Вашей программе. К сожалению пока резонов использовать ее вместо наших "велосипедов" я не вижу, но вдруг появятся? В любом случае Удачи!

mt_>Работа с портом ведётся через Вин АПИ в Винде и стандартные либо в Линуксе.

Это хорошо. Вопрос возник из-за того, что мы в свое время потеряли много нервов от работы с .НЕТовским стандартным классом порта. Потом переписали наш ВИН АПИшный С++ класс под С# и с тех пор проблем не знаем.

Здравствуйте, prbasic /a-pora.ru/, Вы писали:

PAP>А это, как раз, и делает уже наш продукт: Serial Monitor (DMS). Причём, ни логгинг, ни разбор протоколов не влияет на производительность системы и ограничен только ёмкостью жесткого диска. Остальные продукты чаще всего делают это в оперативной памяти и на быстрых потоках отжирают у системы всю оперативную память и затем валятся.

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

PAP>Также мы специально тестировали логгинг, с последующим его проигрыванием, в жестком режиме, когда данные шли несколько суток. Работает.

На какой скорости? 115200? Какова была загрузка канала?
Кстати а не может ли Ваша программа сначала сграбить обмен между железкой и программой, а потом проиграть его в "одну сторону", чтобы, например, без железки работала программа или наоборот? ... Только сейчас понял какая это может быть "мегафича" для нас! Так, детали нужно продумать... Спасибо, что натолкнули на очень интересную идею!

PAP>Для России у нас специально снижены цены.

Я не в России (хотя наше отделение в России также может заинтересоваться программой — я пошлю им ссылки). Цены в принципе нормальные.

PAP>Если предложение заинтересует, могу предоставить купон на скадку. Также у нас есть возможность продлевать trial на случай, если вам это необходимо.

Спасибо. Если мы решим что программа нам нужна, то я свяжусь с Вами, т.к. нам имеет смысл покупать сразу несколько копий.

PAP>В планах:
...
ОК. Подождем ее.

PAP>В случае, если купите и Lifetime Upgrades, то все последующие версии будете получать бесплатно.
А вот от этого скорее всего мы откажемся. Лицензия получается дороговата и учитывая несколько копий программы, вероятность отказа в покупке начинает сильно увеличиваться. Как это и не выглядит смешным, но проще подписать два раза заказ на покупку с интервалом в год, чем за один раз с полуторной суммой.
С другой стороны мы покупаем программу для работы и уже знаем, что она делает и как — и что именно это нам нужно. Если в какой-то новой версии появится что-то такое, что нам захочется использовать, то мы заплатим за Upgrade (это возможно?). Но, как подсказывает опыт, наиболее часто в обновлениях появляются "фичи" без которых и так нормально живется (например распарсивание протокола, который у нас не используется ну т.п.).

Здравствуйте, mject, Вы писали:

M>выдать заключение — подходит она нам или нет, и что в этом случае не устраивает.

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

PAP>>Также мы специально тестировали логгинг, с последующим его проигрыванием, в жестком режиме, когда данные шли несколько суток. Работает.

M>На какой скорости? 115200? Какова была загрузка канала?

На самом деле, там одинаковое ядро у Serial и USB модуля. Для Serial тестировали на 115200 про загрузку сейчас уже не вспомню. А USB тестили на 12Mb в секунду. Копирование данных в Win7 с 64Gb flash мониторится и пишется без критических для системы задержек. При суточном тестирование на постоянке работала Web камера. Сейчас тоже не вспомню какой был поток, но приличный. Модуль обработки один. так что Serial справляется тем более без проблем.

M>Кстати а не может ли Ваша программа сначала сграбить обмен между железкой и программой, а потом проиграть его в "одну сторону", чтобы, например, без железки работала программа или наоборот? ... Только сейчас понял какая это может быть "мегафича" для нас! Так, детали нужно продумать... Спасибо, что натолкнули на очень интересную идею!

Эта фича у нас в планах. Сейчас можно пока только ручками посылать данные в порт, файлы в порт и пользоваться встроенной утилитой ModBus send для modbus комманд.

PAP>>В планах:
M>ОК. Подождем ее.

Новая версия уже прошла предрелизное тестирование. Сегодня дописываем документацию. Осталось поправить 3 незначительных ошибки, прогнать оптимизацию и будем выкладывать. Думаю успеем в пятницу.

Если хотите следить за обновлениями — это очень просто посредством нашего RSS канала по анонсам новых версий Serial Monitor.

M>Если в какой-то новой версии появится что-то такое, что нам захочется использовать, то мы заплатим за Upgrade (это возможно?).

Да, конечно. На каждого покупателя автоматически заводится Account где он сам в онлайне может полностью управлять всеми данными, менеджить продукты, лицензии, апгрейдится и много чего ещё.

Здравствуйте, prbasic /a-pora.ru/, Вы писали:

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

Обязательно напишу.

PAP>На самом деле, там одинаковое ядро у Serial и USB модуля. Для Serial тестировали на 115200 про загрузку сейчас уже не вспомню. А USB тестили на 12Mb в секунду. Копирование данных в Win7 с 64Gb flash мониторится и пишется без критических для системы задержек. При суточном тестирование на постоянке работала Web камера. Сейчас тоже не вспомню какой был поток, но приличный. Модуль обработки один. так что Serial справляется тем более без проблем.

Это не может не радовать!

M>>Кстати а не может ли Ваша программа сначала сграбить обмен между железкой и программой, а потом проиграть его в "одну сторону", чтобы, например, без железки работала программа или наоборот? ... Только сейчас понял какая это может быть "мегафича" для нас! Так, детали нужно продумать... Спасибо, что натолкнули на очень интересную идею!

PAP>Эта фича у нас в планах. Сейчас можно пока только ручками посылать данные в порт, файлы в порт и пользоваться встроенной утилитой ModBus send для modbus комманд.

Модбас мы не используем. У нас свой протокол, можно сказать даже несколько.
Как правильно иногда на этом форуме подмечают — пользователям не интересна программа сама по себе, а нужно решение их проблемы. Так вот у нас есть проблемы, которые я хочу озвучить — возможно Вы или кого-то еще сможет предложить их решения, которые нас устроят.
Итак проблема 1: тестирование прошивок микроконтроллера. У нас идет разработка/доработка программ для микроконтроллеров наших приборов. Команд бывает от пары десятков до нескольких сотен (речь идет о серийном интерфейсе). Пока все тестируется в ручном режиме т.к. ответы могут сильно отличаться от последовательности команд и их параметров. Хотелось бы этот момент как можно сильнее автоматизировать. Так вот, нам нужна программа/система в которой можно было бы достаточно наглядно/просто прописать набор команд прибора, задать какие-то правила его тестирования, критериев оценки и после этого запустить программу тестирования с выдачей финального лога.
Проблема 2: Все тоже самое, но для настроечных утилит. Т.е. без наличия "физического" прибора устроить тестирование программы.

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

PAP>Новая версия уже прошла предрелизное тестирование. Сегодня дописываем документацию. Осталось поправить 3 незначительных ошибки, прогнать оптимизацию и будем выкладывать. Думаю успеем в пятницу.

Это хорошо! Я уже послал ссылку на Вашу программу в Российский офис; там также возникла заинтересованность и обещали ее "пощупать" на следующей неделе.

Здравствуйте, mject, Вы писали:

M>пользователям не интересна программа сама по себе, а нужно решение их проблемы.

Это мы отчётливо понимаем.

M>Так вот у нас есть проблемы, которые я хочу озвучить — возможно Вы или кого-то еще сможет предложить их решения, которые нас устроят. Итак проблема 1: [skip] Проблема 2: [skip].
M>Это описание проблем в двух словах. На самом деле там все несколько сложнее получится но идея примерно такая. Конечно, рано или поздно мы сами напишем себе подобное средство — но если можно было бы использовать готовое — было бы лучше.

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

Здравствуйте, prbasic /a-pora.ru/, Вы писали:

M>>пользователям не интересна программа сама по себе, а нужно решение их проблемы.

PAP>Это мы отчётливо понимаем.

А вот это я уже понял

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

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