Об использовании JTAG_UART, Можно ли юзать в своих целях? Опции

[RHnd]

Ситуация: Есть плата альтеровская, CyclonII starter kit, на которой реализована типовая схема - USB-BLASTER на камне MAX. Т.е. плата подключается к компу одним только usb шнурком, через который идет и питание, и бластер делается. На плате собран проект демонстрационный, который решает свои задачи, внешнее оборудование дергает и т.п.. Для присмотра за всем этим хозяйством собран Nios, содержащий jtag_uart, по которому при отладке общался с Nios2-eds.

Возникло желание при эксплуатации платы передавать на комп в собственный софт некоторые сервисные данные - немного и небыстро. Что-то в духе по нажатию на кнопочку в софтине запрашивать и получать значение одного коэфициента. Обманувшись названием словом uart в названии jtag_uart, я надеялся общаться через этот интерфейс, представляя его на компе как обычный COM. Однако полез сегодня под вечер в мануалы, а там написано, что только nios2-terminal умеет общаться с jtag_uart.

Вопрос - так ли это? Можно ли как-то прикрутить сопсовский модуль и соединение jtag_uart к какому-то собственному софту? Какие можно предложить альтернативы? Безумно не хочется кидать дополнительный шнур.
Заранее всем большое спасибо за помощь!

[vetal]

собственно я там не увидел противоречий с тем, что писал выше. пляска с бубном в цигвине, грязные хаки с jtag_atlantic.dll(а лицензия позволяет?)

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

[vadimuzzz]

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

я в курсе насчет динамической линковки, но есть и сложности:

Upon attempting to work with a DLL that has been created in the Cygwin environment it becomes painfully clear that not all
DLLs are created equally. The Cygwin environment creates DLLs using an internal tool known as dlltool.exe. This tool is not
compatible with the export requirements for MS Visual Studio lib.exe tool when building an application which calls on member functions located
in the aforementioned DLL.

Explicit importing of the member functions using MS Visual Studio is not possible using function wrappers and/or ordinals. This can be
misleading due to the fact that no linker errors or warnings will be elicited. However, after attempting to run an
application which calls upon these member functions using the explicit method, there appears to be no linkage to the functions.
This is easily verifiable by inserting error checking code upon calling a member function and determining if it returns correctly.

One cannot use the *.a import library for the implicit calling method for the MSVC environment either. These import
libraries are created by Cygwin and are not compatible with the *.lib import libraries which MSVC expects. The *.def file created by
Cywin is also not compatible with MSVC.

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

Код

echo "что-то" > куда-то

что м.б. проще? но это уже личные предпочтения.