Трансляция ttyUSBx Linux в COMx Windows Опции

[Kirill_Good]

Здравствуйте!

Есть GUI программа под Windows, которая работает с COM портом. В ней есть окно где можно выбрать один из присутсвующих COM портов в Windows для записи и чтения. Эта программа нужна для установки значений регистров микросхемы на отладочной плате. Данные передаются по USB. На плате размещен MK Atmel для конвертации USB в SPI(интерфейс микросхемы для записи регистров).

Есть custom плата с FTDI чипом(USB<->SPI) для работы с микросхемой из предыдущего абзаца. Для работы c ним была написана программа под Linux(libftdi, libftdispi, libusb). Но оказалось, чтобы добиться такой же функциональности как у программы(произодителя) под Windows нужно много времени. И захотелось прикрутить Windows приложение к разработанному Linux приложению.

Встала задача как это сделать. Сначала я пробовал запуск с помощью Wine, создал бы файл в /dev/ и транслировал его в среду Wine. Не получилось. Затем пришла другая идея. Запуск на виртуальной машине Windows XP GUI программы. Создание с помощью сторонней программы виртуального COM порта. Программка создает на одном конце СОМ порт на другом клиентский сокет. На хостовой Linux Ubuntu я сделал сокет сервер, который транслировал в данные в ftdi. Это все работает, но с одним ограничением. Запись в регистры проходит на ура, но чтение, возможно из за задержек сокетов, сравается. Программа на Windows ждет запрошенных данных и по какому то таймауту говорит, что возможно пробемы в соединении кабеля, хоят данные приходят.

Как поступить? Как можно ещё извратиться? Или проще написать утилиту работы с FTDI под Windows и все, вроде у FTDI есть библиотеки, но это все время.

[sasamy]

получилось. Затем пришла другая идея. Запуск на виртуальной машине Windows XP GUI программы. Создание с помощью сторонней программы виртуального COM порта. Программка создает на одном конце СОМ порт на другом клиентский сокет. На хостовой Linux Ubuntu я сделал сокет сервер, который транслировал в данные в ftdi.

Тут QEMU так и напрашивается - он может эмулировать виртуальный последовательный порт для гостевой ОС и редиректить его на разнообразные устройства на хост-системе Linux - выбирай на любой вкус. Никакие сторонние утилиты тут не нужны.

http://wiki.qemu.org/download/qemu-doc.html

‘-serial dev’

Redirect the virtual serial port to host character device dev.
...

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

Сообщение отредактировал sasamy - Mar 1 2012, 18:32

[Kirill_Good]

Тут QEMU так и напрашивается - он может эмулировать виртуальный последовательный порт для гостевой ОС и редиректить его на разнообразные устройства на хост-системе Linux - выбирай на любой вкус. Никакие сторонние утилиты тут не нужны.

http://wiki.qemu.org/download/qemu-doc.html


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

Спасибо за ответ! Я часто встречал этот QEMU, но так и руки не доходили разобраться. Если там так легко перенаправлять, то тогда это способ должен помочь. То есть если в системе /dev присутствует ttyUSBx, и я сделаю трансляцию СОМx <-> ttyUSBx, то драйвер который будет непосредственно работать с физическим устройством, это драйвер Linux, а не гостевой? В VirtualBox этот номер не проходит просто, там гипервизор мультиплексирует доступ к аппаратуре между драйвером гостевой и хостовой ситемой.