Virtual DJ 5.0 (With Serial) Full Version
Savage Doherty
HW VSP is a software driver that adds a virtual serial port (e.g. COM5) to the operating system and redirects the data from this port via a TCP/IP network to another hardware interface, which is specified by its IP address and port number. HW VSP3 support even NT Services and 64 bit Windows 8 .
HW Virtual Serial Driver is intended primarily for devices produced by HW group, although it can be used for free as a universal driver that creates a virtual remote serial port, which redirects data to a predefined TCP/IP address and port.
In special applications (e.g. involving GPRS devices), the PC with the HW VSP driver can be set to operate in TCP Server mode, enabling the remote device to initialize the connection by sending any data to the remote port. Upon receiving RS-232 data, the converter establishes a connection with the PC and passes the data to the virtual COM port. Therefore, the scenario very closely resembles behavior of a real serial port.
When using HW VSP together with recommended devices produced by HW group, it is possible to change connection speed, parity, and other communication parameters (as well as to control any digital outputs and inputs) remotely on the fly via the RFC-2217 protocol, thus achieving a true remote serial port behavior.
Ability to run as a service has been the main reason for developing the new version. Running HW VSP as a standalone application requires starting it under a logged-in user and therefore prevents autonomous operation on Windows servers. (At this time, HW VSP fully supports Windows 2000 Server and Windows 2003 Server. Support for Windows 2008 Server is being tested.) In this mode, HW VSP consists of a client-side part (setup GUI) and a server-side part (the service itself). Parameters of a VSP running on a remote server can be easily changed from a local PC. However, in order to improve stability, only one user may access the service and change virtual port parameters at a time. Furthermore, since service administration requires administrator privileges, securing a VSP against misuse is as simple as not installing the client-side part.
Note: From the user point of view, using HW VSP in service mode has many advantages. However, on Windows XP SP2/Vista/2003 Server, it is necessary to manually configure the firewall to enable the appropriate communication ports or the entire application (by default Program Files\HW group\HW VSP3s\HW_VSP3s_srv.exe for the single-port version and Program Files\HW group\HW VSP3\HW_VSP3_srv.exe for the multi-port one). Firewall dialog control is currently under development.
In the previous version, HW VSP was fully transparent to the client software and did not restrict the communication flow in any way. Hence, the client SW had to send the data to the serial port using a defined communication speed, or use flow control (handshake). Otherwise, data were sent to the Ethernet / Internet with the maximum speed possible, often in the 10 Mbps range. When the buffers in VSP filled up, data started to be thrown away. Now, it is possible to enable the Strict Baudrate Emulation option in the Settings tab to ensure that VSP communicates with the client SW using the speed that is currently selected for the port.
The option allows to clear Ethernet receive and transmit buffers when the port is opened. This ensures that the client application does not receive any previously received data (e.g. sent in a previous session) that could cause problems.
This function allows connecting VSP to the port previously created and opened by the client application. This function is useful for servers, where it eliminates the need to close the corresponding virtual port before restarting server or the VSP service.
With the introduction of the multi-port version, VSP configuration is now stored in an INI file instead of the system registry. Therefore, configuration can be easily backed up or restored to another PC or server simply by copying the file and restarting the service. The INI file contains a complete VSP configuration, enabling the user to create a custom graphical interface to generate the INI file. Upon restarting the service, the INI file is loaded and the port parameters are changed - no need to study the complexities of controlling services. WC VSP for WirelesCOM is an example of such a customized application.
HW VSP 3 now fully supports the Windows 8. UAC (user switching) support is also fully functional now, including functionality in a domain. When HW VSP is run as a service, all users can control it.
HW VSP 3 is freeware; you can download it free of charge HERE. The software is available in a single-port and multi-port version (development is in the final stage now). Installation is straightforward, except for Windows Vista, where it is necessary to allow the installer to elevate its privileges.
Note: When installing HW VSP in Client/Server mode or using it in the Server mode on Windows XP SP2/Vista/2003 Server, it is necessary to manually configure the firewall to enable the appropriate communication ports or the entire service (by default Program Files\HW group\HW VSP3s\HW_VSP3s_srv.exe for the single-port version and Program Files\HW group\HW VSP3\HW_VSP3_srv.exe for the multi-port version). Firewall dialog control is currently under development.
Caution: These settings apply to the HW VSP utility only. They do NOT influence the remote device. Remote device properties are set according to its manual (e.g. via the Hercules utility in case of HW group products).
Updating Windows existing USB virtual serial COM ports version with either (usb_dev_serial.inf), (usb_dev_cserial.inf) or (usb_chidcdc_serial.inf) serial port driver will update the driver without error yet loose the ICDI USB virtual transport path to either COM ports.
We did the update after discovering ICDI USB is causing random bus faulting of TM4C1294NCPDTi3 MCU two different Launch Pads with or without a virtual terminal running on the desktop. This bus faulting has been occurring for a vey long time and who would ever suspect leaving ICDI plugged into the host USB port would do that. The GTO port has a USB bulk device client running and the ICDI reports slower debug status via virtual COM port dumb terminals.
The new Tivaware library (2.1.2.111) and earlier does not seem to have the Virtual COM driver as a separate install? The ICDI works great but if the USB virtual COM port are plugged in they random fault the EK-TM4C1294XL. That fault occurs even if a virtual COM client is not running. Leaving the ICDI USB unplugged after DFU removes the condition causing any such bus faults.
Hi Amit,
Yes that is what made both COM4/5 transport stop data flow after updating the COM ports drivers to the new Tivaware Serial CDC in device manager. The installer is not installing lmusb*64.dll's in System32 folder. I assume the amd64 device driver folder is for Win7/64bit and the 32bit USB drivers should not be there?
Will try to remove the ICID USB package completely and install the new version but how to make it select 64bit drivers?
Recall past having to monkey around with other packages to get the USB virtual serial COM to work. Windows drivers folder (usb_dev_serial.inf) device listing does not specify the Serial Port being Virtual like Stellaris driver past did. Not sure that is important but it is not being consistent with established naming conventions and confuses the situation. So it (Tiva COM driver) seems to be virtual but that is only a guess and everything is installed but the Virtual COM ports still don't work and have no Warnings of failure.
Windows System information shows both updated virtual serial ports present and functional. Virtual connection state (serial command or serial driver) toggles when the client terminal is connected/disconnected but no data is being passed from the ICDI driver into the USB virtual serial port.
Making calls to UARTprintf() with compile symbol (UART_BUFFERED) 2 launch pads. The ICDI virtual COM4/5 enumerate in the Windows client terminals yet no data will pass. They were passing data until and after updating newer Windows serial drivers. The enumerated serial ports vanish when ever the ICDI USB cable is unplugged, indicates the pipe is being created.
Are virtual serial drivers found in (USB_Dev_Serial.inf) -- the word (Virtual) is missing in the device list details for any single serial port driver name? The original working Stellaris virtual serial port drivers showed up in the device manager, made it unquestionable the driver installed was indeed a virtual COM port. Rolling back to the Stellaris virtual serial driver does not fix the problem.
Hi Petrei,
Had forgotten the hidden non persistent devices don't necessarily show up even when unhidden via pull down. Wish it were that simple in this case thanks for reminder. Now the WIN7 ports advanced choice dialog allow us to force in use COM ports as the current device. Perhaps MS got some complaints that issue and added ability.
This virtual serial COM was hard to get working as I recall 2 years ago fought similar issue. The Stellaris virtual COM driver once again matches the ICDI/DFU driver version & date 2012. There seemingly are no further ICID updates for CCS5 after 2012.
The syntax of posted command spaces between (devices = 1) was not showing the hidden devices. Every one previously removed INUSE status was still there in device manager. Thank Microsoft for lazy programming show hidden devices still is not working from a user perspective.
That was one issue and the other: 1 of the 2 connected EK-TM4C1294XL ICDI stopped working. There is UART0 data being sent to ICDI and it enumerates a COM port when USB is plugged in but does not pass the data to Windows.
That's just the point the ICDI was manually shut (radio button) from the terminal prior to disconnect and reconnect. The terminal emulator scans Windows for in use com ports and refuses to reconnect if it is in use so we know when that has occurred.
b1e95dc632