Can not use for ATMega16 and ATMega32?

General discussions about V-USB, our firmware-only implementation of a low speed USB device on Atmel's AVR microcontrollers
Post Reply
mohammadrezah
Posts: 2
Joined: Wed Nov 15, 2006 8:37 pm

Can not use for ATMega16 and ATMega32?

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?

christian
Objective Development
Objective Development
Posts: 1442
Joined: Thu Nov 09, 2006 11:46 am

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
Posts: 2
Joined: Wed Nov 15, 2006 8:37 pm

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

Can u help me how to use Atmega16 and Atmega32?

christian
Objective Development
Objective Development
Posts: 1442
Joined: Thu Nov 09, 2006 11:46 am

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.

christian
Objective Development
Objective Development
Posts: 1442
Joined: Thu Nov 09, 2006 11:46 am

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?

christian
Objective Development
Objective Development
Posts: 1442
Joined: Thu Nov 09, 2006 11:46 am

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.

Post Reply