Objective Development Forums

Please see the thread "usb driver problem". You probably have not set the I/O ports used for USB as inputs without pull-up or other parts of your firmware still output data to these pins.

You may use ANY port, provided that USB D+ and D- are both on the same port AND D+ is also wired to hardware interrupt 0 (INT0). When you change usbconfig.h (or the Makefile or any other header file), do a "make clean" to ensure that all modules are compiled. Our Makefile does not contain ...

I think this is the best way to implement data streams on top of HID. I've done this in AVR-Doper. The first byte is the number of bytes available and the rest of the report is the payload.

Please look at Osamu Tamura's avrcdc: http://www.recursion.jp/avrcdc/. I think this is exactly what you want.

Implementing the CDC device class with AVR-USB is slightly outside the specs. It may therefore be unreliable on some computers. The driver you mentioned may change the USB timing and thus cause the CDC implementation to fail, although it's otherwise completely OK. If you have a choice, I would recom...

As Sarge pointed out, one of the FT232 chips is probably the best solution for this. However, if you want a solution with DIL chips (not SMD) and still small, you may want to look at Osamu Tamura's avrcdc: m. Implementing CDC based on AVR-USB is a bit demanding and I admit that a HID to serial conve...

There is no maximum clock vs. supply voltage specification directly available from Atmel. However, if you look at the diagrams in the electrical specification of the ATMega8, especially "Active Supply Current vs. Frequency", parametrized by supply voltage (Figure 119), you see that the sup...

The device descriptor you quote is of class 9 which means "USB Hub". This is probably the root hub in the USB controller chip. If Windows identifies the device by name ("PowerSwitch"), then it must have read the descriptors correctly. This rules out voltage level problems. I can'...

I have not tested this approach, but I think it should work.

Yes, this is rather dirty coding, but that's what I meant with "The driver is not really prepared to handle interrupt-IN transfers of more than 7 bytes".

10DE/00E7 is the PCI identification of your USB controller, not a USB ID pair. If nothing else is listed for the bus, no USB devices have been found.

I doubt that the supply voltage has any influence. Yes, it's true that the ATMega8 is not specified for 3.3V operation. However, parts of the data sheet (such as figure 121 "Active Supply Current vs Vcc" in section "ATMega8 Typical Characteristics") suggest that the same parts ca...

Are you referring to a CDC-ACM device and you use VisualBasic on the host side to read data from a serial-to-USB converter?

In this case you may be out of luck. Using AVR-USB to implement CDC-ACM devices is outside the specification. It may not work on some hosts or with some drivers.

The driver is not really prepared to handle interrupt-IN transfers of more than 7 bytes (one USB transaction indicating End Of Transfer). Larger (interrupt-) transfers are built from multiple transactions. You should be able to simulate a 16 byte interrupt transfer with the following procedure: &sdo...

If you want to create your own driver, then yes. If you want to use existing drivers and implement a CDC ACM device (a modem), then no. There are not enough endpoints available.

What do you mean with "there is no hub"? The firmware on the USB-OTG [yes, "On The Go" is the correct term] is usually limited in the support of devices. Maybe it's usual that these OTG devices don't support hubs. The low level protocol between cameras and printers is definitely ...