Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
Т.е. порт может быть реальным или виртуальным — без разницы.
Если вопрос задан нечётко, то обрисую ситуацию:
Есть программа, которая берёт данные с порта. Есть железка, которая посылает данные в порт. Но формат этих данных надо преобразовавать, т.е. я пишу конвертилку. У портов, в общем случае, могут быть разные настройки (скорость и т.д.).
Сейчас просто кинули кабель СОМ1-СОМ2, но получается, что для отладки мне надо 4 порта, да и на этапе продажи какое-то некрасивое решение получится.
P.S. Если ошиблась форумом — отмодерируйте пожалуйста.
Здравствуйте, Red Cap, Вы писали:
RC>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же?
Скрепка во 2-3ю дырку Правда система двум программам СОМ-порт не даст
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, Red Cap, Вы писали:
RC>>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же? P>Скрепка во 2-3ю дырку Правда система двум программам СОМ-порт не даст
Здравствуйте, Red Cap, Вы писали:
RC>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же? RC>Т.е. порт может быть реальным или виртуальным — без разницы.
Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, wallaby, Вы писали:
W>Здравствуйте, Red Cap, Вы писали:
RC>>Как можно наименьшими усилиями сделать так, чтобы одна программа писала в СОМ-порт, а другая читала из него же? RC>>Т.е. порт может быть реальным или виртуальным — без разницы.
W>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ.
Это как? Хотя бы схематично расскажите.
Здравствуйте, Red Cap, Вы писали:
W>>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ. RC>Это как? Хотя бы схематично расскажите.
Ну например, для открытия порта приложения будут вызывать экспортируемую этой dll функцию OpenPort, которая при первом обращении будет вызывать CreateFile для физического открытия порта, а при последующих вызовах просто инкрементировать глобальный счётчик. Аналогично, ClosePort будет этот счётчик декрементировать и при обнулении вызывать CloseHandle. Ну и так далее.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, wallaby, Вы писали:
W>Здравствуйте, Red Cap, Вы писали:
W>>>Наверное, написать dll, которая и будет работать с портом на уровне winapi, и предоставлять свой API для пользовательских программ. RC>>Это как? Хотя бы схематично расскажите.
W>Ну например, для открытия порта приложения будут вызывать экспортируемую этой dll функцию OpenPort, которая при первом обращении будет вызывать CreateFile для физического открытия порта, а при последующих вызовах просто инкрементировать глобальный счётчик. Аналогично, ClosePort будет этот счётчик декрементировать и при обнулении вызывать CloseHandle. Ну и так далее.
Т.е. драйвер виртуального СОМ-порта, где вся обработка будет в драйвере? Или нет? Если так, то слишком сложно и трудоёмко
Приложение, читающее СОм-порт чужое, его менять нельзя