Objective Development Forums

This is just for debugging. Disable the TWI initialization, disconnect TWI SCL and wire INT7 to INT0. If the device enumerates on the USB, then you have a working example to start with. If it does not, we know that the cause is probably something else, not the interrupt. I assume you have checked th...

A similar documentation patch will be in the next release. Thanks for the hint! Regarding the original problem: We really recommend a high priority interrupt because USB processing does not tolerate any delays. INT0 is the highest priority interrupt. Please solder a wire from INT0 to INT7 and use th...

Hmmm... You should be able to capture a USB snoop this time....

Thanks for your feedback about the current status of IAR compatibility! I have added your .macro and .endm fix for the next release. Please define USB_INTR_PENDING to the appropriate register or memory address in usbconfig.h. The default is EIFR or GIFR in usbdrv.h, but these constants may not be de...

You can use the hex file as is, but the fuse values are NOT included. They must be flashed with a separate command, see the respective Makefile target. Setting fuses is only required for the ATTiny2313, not for the AT90S2313.

It looks as if the host does not understand the data sent by the device. I have re-arranged the instructions a bit to give a more evenly distribution of leap bits. I'll send you the modified driver to your e-mail address. Please check this one out...

Yes, this is very likely a timing problem in the code. Since I have not been able to reproduce the problem here, it's very hard to figure out what it is and how to fix it. The 16 MHz timing is a bit critical since 16 is not a multiple of 1.5. We have to insert leap cycles every now and then. To debu...

The hex file has been built with the makefile which ships with the project. The target device there is the at90s2313. However, since the Tiny2313 is binary compatible with the at90s2313, you can use the same hex file for the Tiny2313. But be sure to run "make fuse_tiny2313" to set the fuse...

This limit is not in the USB spec and it would be possible to extend AVR-USB for bigger message sizes. However, since this requires 16 bit arithmetics, it would bloat the driver size. Another #ifdef would make it harder to maintain. We have done some transfer speed measurements and found that increa...

Since your function name is sendUSBVendorCmdIn(), I guess you transfer 100 bytes from the device to the host. In and Out are defined from the host's point of view. But you are right, this should transfer 100 bytes unless an error occurs. A possible error would be that the host and the device don't a...

If your sendUSBVendorCmdIn() is defined analogous to sendUSBVendorCmdOut(), you receive one byte in the first case and two in the second. Please note that you actually transfer many more bytes, that's the overhead of control transfers. For efficient transfers, send or receive at least 100 bytes (if ...

PowerSwitch is a good example because, if you compile it with TEST_DRIVER_SIZE defined, it generates the minimum USB devices which is recognized by the host. Please note that you need to disconnect and reconnect it manually after flashing the firmware because the disconnect code is not compiled in.

Please look at example applications. Automator, for example, sends blocks of 128 bytes to the devices and stores them in the EEPROM. Or, if you take USBasp, Thomas Fischl's AVR programmer, it sends and receives variable sized blocks of data.

Send a couple of kB to the device and measure the time it takes. The quotient gives the transfer rate, the more kB, the more precise it will be.

So you confused the operating system with a report which did not match the Report Descriptor.

In any case: I'm glad you found the cause!