Can not use for ATMega16 and ATMega32?

mohammadrezah · Post by **mohammadrezah** » Wed Nov 15, 2006 8:41 pm

Hi,
I use obdev firmware for ATmega8 and all things be ok but when I use Atmega16 and Atmega32 windows show me Unkonw Device message.
why?

Post by **christian** » Thu Nov 16, 2006 12:01 am

AVR-USB works well with the ATMega16 and 32. However, the fuse bits differ from device to device. This means that you can't simply use fuse bit values from an example device for one of the bigger ATMegas.

mohammadrezah · Post by **mohammadrezah** » Thu Nov 16, 2006 7:35 am

Can u help me how to use Atmega16 and Atmega32?

Post by **christian** » Thu Nov 16, 2006 9:55 am

I can give you the hint to look at the fuse bits. But I'm afraid I can't help you more than that. Just have a look at the data sheet or use Atmel's AVR-Studio which represents the fuse bit meaning in clear text.

You must ensure that the AVR is clocked with an external 12 MHz crystal and no additional dividers.

Guest · Post by **Guest** » Sat Nov 18, 2006 1:41 am

I had to increase the delay between pulling D- Low and the call to usbInit()
(the part with the 10ms)

Using _delay_ms() to sleep for 12ms from avr-libc appears to help.

I have not found out how to coerce it into calling usbRead() but usbWrite() and Setup transfers work flawless.

Post by **christian** » Sat Nov 18, 2006 11:08 pm

The delay while pulling D+ and D- low has no effect when you first plug in the device. Since the hub or host detects the device by a high level on D- or D+ (for low or full speed respectively), the device is not detected until the delay is over.

The main purpose of this type of initialization is for watchdog resets. If you get a reset through the watchdog, the host sees a device disconnect and then re-connect. It will thus re-enumerate so that device and host agree on a device ID.

The re-enumeration SHOULD be initiated by removing the pull-up resistor from D- instead of pulling D+ and D- low, but the resistor is usually hard wired.

I have not found out how to coerce it into calling usbRead() but usbWrite() and Setup transfers work flawless.

Did you read the documentation for these functions in usbdrv.h?

Guest · Post by **Guest** » Sun Nov 19, 2006 11:52 pm

As far as I understand the comments i have just to return 0xff on Control-In transfers.
(Having enabled usbFunctionRead() in usbconfig.h of course)

Returning 0xff on Control-Out results in usbFunctionWrite getting called properly.

Setting usbMsgPtr to a valid location and returning a length < 0xff works too.

Commenting out usbFunctionRead results in the apropriate linker error.

Maybe i have missed something?

Post by **christian** » Mon Nov 20, 2006 12:46 pm

(This is getting off-topic -- please open a new topic for questions not directly related to the original topic.)

I assume that you want to implement a control-write transfer with a non-zero data block. In order to do that, you must:

Define USB_CFG_IMPLEMENT_FN_WRITE to 1 in usbconfig.h. This tells the driver that you intend to implement usbFunctionWrite().
Implement usbFunctionWrite() in your code. You will receive the data block of a control-write transfer there. If the block is more than 8 bytes, usbFunctionWrite() will be called multiple times. Return 0 in this function if you expect more data, 1 if the last block was received (see doc in usbdrv.h).
In usbFunctionSetup(), decode the request number. If you find your control-write transfer which involves a data block, store the number of bytes expected (so that you can return the right value in usbFunctionWrite()) and return 0xff. If another request was received, return the number of bytes you want to send.