программа для связи по COM порту

Hi Alexandr !

Совсем недавно 28 Nov 05 15:22, Alexandr Kochmin писал к Ruslan Mohniuc:

AK>>> а интерфейс к нему.? AK>>> весь смысл не в классе, а в удобтсве работы в визуальной AK>>> оболочке.

RM>> Мне нравится. Я про билдеровский с++, использую компоненты "Async RM>> Professional from TurboPower Software Company".

AK> Hу их несколько. И все они это просто обернутые в класс вызовы winAPI AK> при этом оборачивать можно по-разному. Этим они и отличаются. Hу, я в таких умных словах, кто во что обернут и для чего, могу запутаться :) Просто беру компоненту, и далее использую предлагаемые свойства-методы-события для необходимой реакции на кликанье кнопки или еще на что. Оно работает, чего в большинстве случаем достаточно. Hасколько оптимально-эффективно внутри- не знаю, не интересовался. Hо например для нормальной работы в полудуплексе достаточно в нужном месте просто галочку поставить- и все, управляй своим RS485-м драйвером. Захотелось посмотреть что по порту бегает- два клика в билдере- и поставил окошко терминалки в свою программу. Hужно по xyz чего-то передать- опять же есть такое уже сделанное.

RM>> Там в компонентах много чего есть. Кстати, и по работе с факсами RM>> тоже есть, но я их не юзал, у меня ком-порт и свои протоколы.

AK> Hу факс тут нипричем это да. Да тут просто параллельно муссируют вопрос о подслушивании факсов, вот и упомянул я о них.

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

AK> Это понятно. Вот я делаю такую универсальную оболочку для отладки AK> своих протоколов обмена по COM порту.

Мне кажется, что достаточно много в этом направлении уже написано, хотя бы упомянутый мной комплект компонент. Если у тебя основной работой является именно отладка протоколов - то наверное такой самописный конструктор и нужен. Как там у классиков, "лучше день потерять, потом за пять минут долететь". Hо подозреваю, что подавляющее большинство тутошних обитателей тебя не поймет. За себя скажу, что отладка новых команд (не дай Бог новых протоколов, их-то вообще зачем часто менять!) занимает малую толику сил и времени, поэтому не удостоена чести написания индивидуальных спецпрограмм-конструкторов. Хватает написанных кем-то когда-то терминалок, ну в особо хитрых случаях есть с++Билдер. И если раз в полгода нужно запустить нечто старнинное-самописное-досовое, почему-то плохо бегающее под виндой, то мне проще загрузиться с дискетки, чем проводить исследования. То есть я бы просто не взялся за написание конструктора, незачем.

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

Однако и новый сабж, написанный кем-то (! :) может быть вполне интересен многим. Hапример, я так думаю, Редчук кормится не тем, что AVReal написал, хотя именно как написатель оного он нам и известен :)

WBRgrds Ruslan

Hello, Evgeny Kotsuba! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 29 Nov 2005 01:29:37

+0300:

VV>>>> Спрашивается, зачем плодить лишние сущности, когда VV>>>> какая-нибудь терминалка есть всегда и везде?

EK>>> йик. В голой венде тоже есть ? и шоб не глючила ? или в

DO>> Гипертерминал зовется. Есть в составе любой винды. Для связи DO>> с embedded по rs232 - достаточно вполне.

EK> и шо - оно не глючит ?

Чего ему глючить?

EK> и еще раз - я в принципе не на какие лавры не претендую, но EK> идею высказанную автором давно поддержал ;-) Есть/могут быть EK> заморочки с rts/sts и прочими вещами, есть необходимость

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

EK> отлаживать свои куски, и вставлять потом в боевую прогу, есть

Свои куски чего?

EK> потребность держать минимальный терминал в любом архиве, чтоб EK> он стартовал в любой позиции - и без гуя, и без dll'ек, с

Минимальный терминал уже есть в виндах. Есть программа teraterm, которая во многих отношениях удобней. Никаких dll ей не надо. Зачем подоконный терминал без ГУЯ я не знаю, но можно любой ДОСовский запустить.

EK> дискеты и т.п.. Впрочем, я уже повторяюсь.

EK>>> каком-нибудь однодискетном ембедизме ?

DO>> Какая там ОС? И какая связь с subj?

EK> какой фиг разница, какая ос, если oc правильная ;-)

Такая, что subj - под windows.

EK> и getch() с printf'ом работает.

И какое это к ком порту отношение имеет?

dima

Hi Alexandr Kochmin!

On Mon, 28 Nov 2005 12:08:55 +0000 (UTC); Alexandr Kochmin snipped-for-privacy@danomsk.ru wrote about 'Re: программа для связи по COM порту':

AZ> начал писать подобное на python (чтобы не только windows), но AZ> пришлось забросить из-за недостатка времени.

AZ> А у вас на чём? Насколько легко дописывать нужную финкциональность?

adr> Delphi. А какая может быть дописываемая нужная функциональность?

Delphi эх ...

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

RM> Hу, я в таких умных словах, кто во что обернут и для чего, могу RM> запутаться :) Просто беру компоненту, и далее использую предлагаемые RM> свойства-методы-события для необходимой реакции на кликанье кнопки или RM> еще на что. Оно работает, чего в большинстве случаем достаточно.

Да, это понятно. тут главное "беру билдер\дельфи". Для кого-то пустяк, а для кого-то нет.

RM> И если раз в RM> полгода нужно запустить нечто старнинное-самописное-досовое, почему-то RM> плохо бегающее под виндой, то мне проще загрузиться с дискетки, чем RM> проводить исследования. То есть я бы просто не взялся за написание RM> конструктора, незачем.

Тоже понятно. Аргументы приняты.

RM> Да и у тебя может так статься, что написание своего инструмента станет RM> самоцелью, что неверно будет истолковано любым начальством, ибо RM> начальству главное- итоговое изделие, а каким молотком его собирали- не RM> его дело.

Ну начальства как бы и нетуть. :)

RM> Однако и новый сабж, написанный кем-то (! :) может быть вполне RM> интересен многим. Hапример, я так думаю, Редчук кормится не тем, что RM> AVReal написал, хотя именно как написатель оного он нам и известен RM> :)

Вот и я так думаю. P.S. Вот, к взаимопонимаю пришли.

AZ> Delphi эх ...

комментарии?

AZ> А функциональность, например некоторая обработка полученных данных AZ> и представление их в виде графиков.

хм... идея неплохая. Надо подумать. Вот идеи и принимаются. Я ж в первую очередь сюда и обратился с просьбой. Давайте ваши пожелания, и они по мере возможности будут реализованы. По-моему неплохой шанс получить то что хочется нахаляву.

Mon Nov 28 2005 11:20, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

VV>> Спрашивается, зачем плодить лишние сущности, когда какая-нибудь VV>> терминалка есть всегда и везде? EK> йик. В голой венде тоже есть ? и шоб не глючила ? или в каком-нибудь EK> однодискетном ембедизме ?

hyperterminal?

Mon Nov 28 2005 14:22, Alexandr Kochmin wrote to Evgeny Kotsuba:

AK> И нет истории команд, и нет толкового редактирования и прочего.

Это должно быть встроено в управляемый прибор. Я так считаю.

AK> И нет толком управления RTS, CTS, DTR, DCR и прочими.

И нефиг, ибо это зависимые от реализации сигнала канального уровня. В TCP их не завернёшь и на компутер в соседней комнате не пошлёшь.

Mon Nov 28 2005 17:43, Vladimir Vassilevsky wrote to Evgeny Kotsuba:

VV> Какие проблемы. getch() с клавиатуры, putch() в компорт и наоборот.

Проблемы в том, что типичный libc отвратительно, а скорей вообще никак, работает в неблокируемом режиме ввода-вывода. Всё писать своё жутко утомительно будет.

EK>> или в каком-нибудь EK>> однодискетном ембедизме ? VV> У линуксанутых свои проблемы...

У них tcl и expect есть.

Tue Nov 29 2005 00:29, Evgeny Kotsuba wrote to Dmitry Orlov:

EK> терминал в любом архиве, чтоб он стартовал в любой позиции - и без гуя, и EK> без dll'ек, с дискеты и т.п..

kermit? Вот на 386 нотебуке с 1МБайт памяти запускается. Без всяких win32 и прочих линухов.

DO>> Какая там ОС? И какая связь с subj? EK> какой фиг разница, какая ос, если oc правильная ;-) EK> и getch() с printf'ом работает.

Как через printf послать BREAK? Или как через getch() узнать состояние DCD? И наконец, как в "правильной ос" системо-независимым образом сделать fopen() порта в нужном режиме? И не надо мне про cygwin.

Tue Nov 29 2005 14:19, Alexander Zholtkovsky wrote to Alexandr Kochmin:

AZ> Delphi эх ...

AZ> А функциональность, например некоторая обработка полученных данных AZ> и представление их в виде графиков.

Hi Alexandr !

Совсем недавно 29 Nov 05 15:23, Alexandr Kochmin писал к Ruslan Mohniuc:

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

AK> Да, это понятно. тут главное "беру билдер\дельфи". AK> Для кого-то пустяк, а для кого-то нет. Hо согласись, все ж придется когда-нибудь осваивать. Мне хватило пары советов от знатоков, в том числе и совета купить книгу Архангельского по 5-му Билдеру и применить вышеуказанную мной библиотеку компонент. А дальше- вполне себе дело техники, была бы задача. Правда, очень трудно удержать себя и не превратить написание отладочной софтинки из однодневной работы в самоцель. Уж явно красочнее и эффектнее, чем корябанье в каком-то MCU, можно не только собрату-ембиддеру показать. :)

RM>> Да и у тебя может так статься, что написание своего инструмента RM>> станет самоцелью, что неверно будет истолковано любым RM>> начальством, ибо начальству главное- итоговое изделие, а каким RM>> молотком его собирали- не его дело.

AK> Hу начальства как бы и нетуть. :) Так уж и нету. А родители-жена....итд :) Их тоже только результат интересует, правда для них результат в денежном исчислении надо предоставлять. Так сказать, показатель деньги/затраченное время тоже обосновывать нужно. :)

RM>> Однако и новый сабж, написанный кем-то (! :) может быть вполне RM>> интересен многим.

AK> Вот и я так думаю. AK> P.S. Вот, к взаимопонимаю пришли. Так и не спорили. Чего-то просто работать уже лениво, а спать еще неохота, вот я и расписался.

Кстати, я тут пользую нечто немного напоминающее то, что ты хочешь, но заточенное под Modbus (Modscan32,

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

WBRgrds Ruslan

Очень рад вас видеть, Vladimir!

AK>>>>> Для собственных нужд написал программу, позволяющую AK>>>>> обмениваться данными по COM порту. VV>>> Гениальный изобретатель, наверное, никогда не слышал о PC Anywhere, VV>>> линках по компорту в Norton-е и Volkov-е, FastWire...

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

EK>> вы слегка путаете - попробуйте пообщаться через PC Anywhere с EK>> дивайсом, EK>> сидящем на COM-порту. Hапример, эзернетовский свитч или миниАТС.

VV> Эзернетовский свич, с которым нужно общаться по компорту? Оригинально.

да вроде как банально... у меня есть несколько таких. например малоизвестная фирма "три-ком" делает...

AVL

Tue Nov 29 2005 14:59, Kirill Frolov wrote to Vladimir Vassilevsky:

VV>> Какие проблемы. getch() с клавиатуры, putch() в компорт и наоборот.

KF> Проблемы в том, что типичный libc отвратительно, а скорей вообще никак, KF> работает в неблокируемом режиме ввода-вывода.

????

if(kbdhit()) getch();

VLV

"Я добрый, и это единственный мой недостаток" (Достоевский)

KF> Mon Nov 28 2005 14:22, Alexandr Kochmin wrote to Evgeny Kotsuba:

AK>> И нет истории команд, и нет толкового редактирования и прочего.

KF> Это должно быть встроено в управляемый прибор. Я так считаю.

хм... так у него ж память не резиновая. И нафиг оно там ненадо. Гораздо проще когда это реализовано на другом конце.

AK>> И нет толком управления RTS, CTS, DTR, DCR и прочими.

KF> И нефиг, ибо это зависимые от реализации сигнала канального уровня. KF> В TCP их не завернёшь и на компутер в соседней комнате не пошлёшь.

согласен. Пока эти сигналы для питания например не испрользуют. Или как сигнал факта подключения устройства.

Hello Vladimir!

30 Nov 05 02:49, you wrote to Kirill Frolov:

VV> if(kbdhit()) getch();

$ man kbhit No manual entry for kbhit $ man kbdhit No manual entry for kbdhit $

Anatoly

Hi Alexandr Kochmin!

AZ> Delphi эх ...

adr> комментарии?

Я хочу от него избавиться. Вписать пару строк в скриптовую прогу гораздо легче и быстрее чем лезть в делфю. А если отладка и настройка железки производится в другом месте, то обновление этой рулилки напрягает :(

AZ> А функциональность, например некоторая обработка полученных данных AZ> и представление их в виде графиков.

adr> хм... идея неплохая. Надо подумать. adr> Вот идеи и принимаются. adr> Я ж в первую очередь сюда и обратился с просьбой. Давайте ваши adr> пожелания, adr> и они по мере возможности будут реализованы. adr> По-моему неплохой шанс получить то что хочется нахаляву.

Я думаю что пожелания будут очень специфические. Например потом вдруг понадобиться по тем же данным посчитать FFT. Всё нереализуешь.

Пpивет, Kirill!

Давеча Вт Hоя. 29 2005, писал(а) Kirill Frolov для Alexandr Kochmin:

AK>> И нет истории команд, и нет толкового редактирования и прочего. KF> Это должно быть встроено в управляемый прибор. Я так считаю. AK>> И нет толком управления RTS, CTS, DTR, DCR и прочими. KF> И нефиг, ибо это зависимые от реализации сигнала канального уровня. KF> В TCP их не завернёшь и на компутер в соседней комнате не пошлёшь.

Как всё запyщено ;) Каким боком тyт IP затесался, если надо с компа общаться с подключенным по RS232 yстройством? ;))) Hо если так yж хочется распределённости - выделяем часть проги, которая занимается обменом с последовательным портом в отдельный сервер, а всё остальное делаем клиентом.

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

Wed Nov 30 2005 05:48, Alexandr Kochmin wrote to Kirill Frolov:

KF>> Это должно быть встроено в управляемый прибор. Я так считаю. AK> хм... так у него ж память не резиновая. И нафиг оно там ненадо. AK> Гораздо проще когда это реализовано на другом конце.

Сотню-другую байт из нескольких килобайт иногда можно и выделить.

AK>>> И нет толком управления RTS, CTS, DTR, DCR и прочими. KF>> И нефиг, ибо это зависимые от реализации сигнала канального уровня. KF>> В TCP их не завернёшь и на компутер в соседней комнате не пошлёшь. AK> согласен. Пока эти сигналы для питания например не испрользуют. AK> Или как сигнал факта подключения устройства.

Используй стандартное состояние сигналов. Или не используй вовсе. Ибо потом будет -- версию виндов (COM-порт на USB-переходник, что угодно ешё) в очередной раз сменили -- и пошло всё прахом.