2012-03-13 04:04 PM
We are reading NMEA 0183 data from the USB port of our STM32 based product and our Windows PC Application has been written to use Overlapped IO to minimise performance issues when reading data from lots of COM ports.
The STM32 Virtual COM Port Driver returns an error code when we try to read data using the Overlapped IO functions in Windows, which makes us think that this mode is not supported in the driver. Can anyone confirm if this is true or better still can anyone confirm if they have managed to get the STM32 driver to work in Overlapped IO mode ? #stm32-virtual-com-overlapped-io2012-03-14 09:14 AM
> The STM32 Virtual COM Port Driver
ST supplies just INF file. The body of the device driver, usbser.sys, is built-in to Windows.> returns an error code when we try to read data using the Overlapped IO functions in Windows OVERLAPPED is supported on usbser.sys virtual COM port. There is no difference on coding from usual COM port. What does GetLastError() return just after ReadFile()? Tsuneo2012-03-16 04:58 PM
Success, the STM32 Virtual Com Port driver appears like a modem rather than a Com Port and returns a different set of capabilities when queried. It also appears to store and transfer strings of characters rather than individual characters like a Com Port does. We managed to change our application to work around this different way of operating and got it to work in Overlapped IO mode.
2012-03-16 06:02 PM
'' ... appears like a modem rather than a Com Port ... ''
A ''normal'' Windows modem can be accessed as a COM port, provided you know the COMx: number...
Here's how to find the COMx: number (on XP, at least):http://blog.antronics.co.uk/2011/09/15/identifying-a-modems-com-port-in-windows-xp/
2012-03-18 01:41 PM
It also appears to store and transfer strings of characters rather than individual characters like a Com Port does.
Yeah, I'm not sure what Win32 based COM port's you've been using, but in as long as I can remember you can use ReadData/WriteData to read/write large chunks of data to the COM port, I don't recall ever having to send/receive singular bytes*, with all the overhead that generates. You do have to pay particular attention to what Status, dwRead, and dwWrite return. * Beyond the obvious conditions where a protocol might only have a single byte to send, only one is pending. ie Dumping whole packets of an XModem-1K @ 460.8Kbaud, and waiting for a single ACK/NACK etc.