Objective Development Forums

Ah, sorry. Did not remember the context. Windows locks keyboards and mice, but not generic HIDs. If you have a keyboard or mouse, you probably need to send and receive a report.

Yes. That's the way how HID report descriptors work.

If you need a kind of RPC mechanism with only a couple of bytes sent to the device, consider raw setup requests with libusb-win32. This is an additional install, though.

usbSetReport() sends data to the device. Use usbGetReport() to read data.

I don't have the time to look through your code, but one comment: Debug mechanisms should be simple. They are there in order to debug problems, not in order to create new problems. The debug mechanism should work even if everything else breaks, just to debug this broken stuff. Debugging through USB ...

The AVR code needs nothing else than an edge triggered interrupt. This is configured in usbInit() in usbdrv.c.

The "P" stands for pico-power. Maybe you must enable something in an I/O register to turn on edge triggered interrupts. Just an idea...

To receive data, you must implement usbFunctionWrite(). If you want to send data, you can still use the message pointer mechanism. The result is the same, except that you need to have the data in a static buffer beforehand. If you decide to implement usbFunctionRead(), you can generate the data on t...

If you poll from the host, you don't need the interrupt endpoint at all. You can read chunks of 12 bytes at once (well, the driver splits it up into 8 byte chunks for you). And you could use a flag to indicate whether the current buffer has already been transferred. However, I really doubt that poll...

Q0: Why not use memory for REG_UARTFLAGS_B ? Because access to I/O registers is faster by 1 cycle. You can use a memory location instead, of course. Q1: Is uartScratch always mapped to R2 (and not used for some else variable by compiler ) ? Could we used it as storage instead of GPIOR1 ? In princip...

You may want to look at http://www.harbaum.org/till/i2c_tiny_usb/

This is not HID, I think, but an I2C interface with an 8 bit device.

I'm not sure I understand what you want to do. Do you send a CMD_POLL setup request after receipt of each interrupt packet from the host to acknowledge the receipt? And why should this be faster or better than using usbInterruptIsReady()?

There are two versions of libusb-win32. The filter version, which must be installed in any case, and the dll version which must be associated with your device by means of a .inf file. So I'm afraid you need some kind of installation in any case, contrary to the claim on the wiki.

I doubt that you can make this faster with this descriptor size...

You really should use some kind of regular calibration, something similar to the code in the libs-device directory of the driver. This may be very tight on the Tiny25, though.

I have not tested this particular chip myself, but since V-USB needs almost no hardware resources, it works on all AVRs which have at least 128 bytes RAM and 2 kBytes Flash. The Mega169 meets these criteria. You may have problems with devices with more than 64 kBytes of Flash when you use a boot loa...

This is exactly what my code is intended to do. If you do it this way, the assembler emits tons of push instructions before you can actually enable global interrupts. These probably take longer than the driver allows. The code I suggested uses a naked routine to do the interrupt magic before any pus...