USB I/O

[Dinosaur]

Hi all

Well I am pleased to say, that the callback problems are behind us. phew.

there might be a limited number of RM callbacks that you can allocate from the DPMI host.

Yes that's true, 16 actually is the minimum that should be provided. And I guess the best way is as suggested an array with the number of copies depending on the number of boards installed.
That way they all use he same code.
I dont think I am confused about the interupts, I have always thought of them as Close Interupts & Start Interupts. The doc's on dpmi definitely state that there is danger of the Int staying disabled if you dont specifically enable them when you are finished with the callback.

You don't need to restore the DS passed to you.....

Actually the final result is even better, the register struc has all the details I need. Although because it gets filled in as a result of an Int, I cant rely on it being the info from the Interface I want,
if another interface uses the same CallBack. So, by looking at the UserPktID, I will know which I/F but it is possible to miss an event completely,
if 2 Interfaces cause a CallBack within micro-Sec's.
I have noticed that when sending a command to an I/F the return registers (from usbuhcil) indicate "all OK", but a second or two later, the Host Controller will create the callback with a problem.
So if during that delay (which will more then likely happen) I comm with another I/F, then the danger of loosing a callback is real.

Once I get all the functions working correctly, I will then think about the best program logic to handle multiple I/F's.

Regards

[Bret]

The best way to handle those kinds of issues is to have at least a small amount of code and filtering in the IRQ call-back procedure. For instance, it could filter out the "unnecessary" ownership notifications, and just pass through the ones you care about (like Disconnects and maybe a few others). You may also need to set up some sort of "notification stack", that can store several notifications that happen before you have a chance to process them. Multiple asynchronous interrupts can definitely happen faster than you can process them by polling, so if you don't process them in the IRQ call-back or save them in a stack, the only one you know about is the last one. Doing some pre-filtering in the IRQ call-back code can reduce the size of the notification stack and increase the overall speed.

Like you said, sorting this all out will come later after (and as) you get the wrinkles ironed out and get the first device working efficiently and reliably. Just some thoughts to keep in the back of your mind as you are progressing.

[c.m]

Only one thing left to note for me :-)

I dont think I am confused about the interupts, I have always thought of them as Close Interupts & Start Interupts. The doc's on dpmi definitely state that there is danger of the Int staying disabled if you dont specifically enable them when you are finished with the callback.

Actually the docs state not to enable interrupts (if you aren't doing anything which takes long). If you are to enable interrupts, you have to copy the register structure to a dynamically allocated buffer first, and set es:edi to point to the new structure before enabling interrupts.

Since the real mode call structure and the selector used for the real mode SS are static, care must be taken when writing DPMI client callback procedures that may be reentered (for example, by a real mode program that services hardware interrupt). The simplest method of avoiding reentrancy is to leave interrupts disabled throughout the entire callback procedure. However, if the amount of code executed by the callback is large, the client may find it more desirable to copy the real mode register data structure into a dynamically allocated buffer and then re-enable interrupts and not use the incoming DS any more. The real mode register data structure pointed to by ES:(E)DI upon return from the callback procedure is not required to be at the same address as the original real mode register data structure.

[wsseet]

It looks like the only external interface to the Device that could be used for configuration is the USB connector.

[Bret]

It looks like the only external interface to the Device that could be used for configuration is the USB connector.

Either I'm not understanding what you're trying to say, or you're very confused. Interfaces and configurations having nothing at all to do with the physical USB connector.