Трансляция 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 есть библиотеки, но это все время.

[Olej]

Встала задача как это сделать. Сначала я пробовал запуск с помощью Wine, создал бы файл в /dev/ и транслировал его в среду Wine. Не получилось. Затем пришла другая идея. Запуск на виртуальной машине Windows XP GUI программы.

сэр понимает вкус в извращениях

а какую конкретно виртуальную машину (tools) вы используете?
от этого может многое меняться.

мне почему-то кажется, что самыми адекватными (приближающимися к реальным) здесь были бы VirtualBox, а ещё более QEMU (хотя VirtualBox и написан на базе QEMU).