Objective Development Forums

You can either send custom requests on endpoint 0 if your device decodes them as such and if Windows allows you to open the device. Or you can send configuration descriptors through the HID mechanism.

I've never tried the Microsoft DDK, only MinGW wich comes with a DDK compatible set of libraries. This worked for me.

You can buy V-USB Hobby licenses which come with a USB ID. It's more expensive than if somebody would sell USB IDs, but still viable.

Bulk endpoints with V-USB are really tricky. The USB polling consumes most if not all of the CPU time. If the interrupt service routine comes too late, you lose a packet. Since V-USB does not implement error handling (no CRC checks etc), you may lose packets.

Has anybody tested this?

If it's indeed a mass storage implementation, I'd like to add it to our products section.

The download via depositfiles.com is a pain. Long time to wait and full screen ads in the background...

rjburke377 wrote:DBG1() statement used before odDebugInit().

Thanks for this hint! It's indeed a bug!

Regarding the 16 MHz version: Have you checked with a simple non-USB program which blinks an LED that the clock rate is OK?

Still don't know why...

You can experiment with data toggling: Whether you start with a DATA0 or DATA1 packet. But this was not a solution for me.

It's the same as interrupt-in: You must call usbSetInterrupt() to send the data. The difference is only in the endpoint descriptor, not in the logic. [Except, of course, that bulk endpoints are polled MUCH faster than interrupt endpoints.]

I don't know how the fix works and I'm not an expert for descriptors either...

I would guess that it has something to do with the bulk endpoints.

I have not looked in to your descriptors in detail, but I read the comment that you use CDC. You DO know that Vista does not support CDC for low speed devices any more? The spec does not allow bulk endpoints for low speed USB and since Vista Windows enforces this limitation. It may work in a virtual...

I have read about this when doing support. Somebody found out that the program was executing normally, but the I/O registers were reset to their RESET state. I have not verified this myself, so it may have been some other unexpected behavior. On the other hand, I have seen lots of EMI problems with ...

OK. But it's still a kind of internal error: CreateProcess for gcc fails.

You probably need MinGW's bin directory in PATH, not the MinGW directory itself.

Then it's probably an issue with search paths (the environment variable PATH).

I've looked at the error message again. This is an internal error of your gcc. The compiler frontend can't create a process for the preprocessor or another stage of the compiler chain. Your gcc installation seems to be broken.