I have a FTD2xxx device, that how I understand, is a tool to work with USB device as with serial Com. I have a write and read operation to and from that device. After writing to a device the program waits until the device will finish his work with data we supplied and returns already converted data. How I can assign a callback procedure, that will activate, when the device is ready (finished to parse a data), or may be to assign an interrupt. All this must be in user mode. I think that data readiness is indicating with the signal in com. All functions for working with FTD are encapsulated in some DLL and I have only functions for interfacing with him, like a FT_Rread, FT_Write. The polling mechanism is not acceptable.
https://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer’s_Guide(FT_000071).pdf
You may want to take a look at 8 FT_SetEventNotification.
If you only care about Windows, then you can also take a look at various functions in FT-Win32 API Functions.
Thank You. May be FT_SetEventNotification will be useful.
Please remember that a USB device NEVER initiates communication. The device remains silent until the host controller asks it if it has anything to send, and it will only DO that if some driver has a read request outstanding. So, the usual way to do this is to issue a read, and leave that read pending until you receive something. Then, you process it and return it for another read.
FTDI USB to serial return once read or write are completed; or when the specified delay times out. The read and write specify a rx and tx buffer together with the amount of characters to be read or written respectively.
*to boot
FTDI have their own forum and you may get better help there.
Thank you for your responses. But if the USB device NEVER initiates communication, that means I have to work with it synchronously, the target thread that initiated the request will wait until the read is completed. In that time for what is FT_SetEventNotification function is intended for, as Mr. Xiaofan_Chen said. Thanks for the FTDI forum directions
Not at all. It just means you have to use overlapped I/O. Make sure you issue a read before you issue a write. As long as the read is pending, the hardware will keep asking, “do you have anything? Do you have anything? Do you have anything?” Sooner or later, it will reply. That’s the ONLY way to maximize throughput. Remember that USB is all scheduled in advance. If you don’t have a read request queued up while the host controller driver is scheduling the next frame, you’ll miss that whole frame. FT_SetNotificationCallback is too late.
Well, Mr. Tim_Roberts. I understand the difference between callback procedure(interrupt) und overlapped I/O. One realized in hardware level, the second in software level.
Resolve another question. When we create an NDIS filter driver using a template in Visual Studio, it uses two spinlocks. One use is FILTER_ACQUIRE_LOCK(&FilterListLock, bFalse), the other is FILTER_ACQUIRE_LOCK(&pFilter->Lock, bFalse); The first of these spinlocks is initialized in the DriverEntry subroutine, while the second is not initialized. How is it not initialized. But it works, I think it’s ok
I’m not sure what point you’re making, but hardware interrupts are not callback procedures. Callback procedures are a software concept, just like overlapped I/O, although the two are not otherwise related. Hardware interrupts are essentially irrelevant in USB.
The first of these spinlocks is initialized in the DriverEntry subroutine, while the second is not initialized. How is it not initialized. But it works, I think it’s ok
yeah that looks like a bug. It is pretty much irrelevant as it gets ‘initialized’ by zeroing it out, and it is in that sense initialized. But you should put a bug on it in github.
Thanks