Objective Development Forums

Very interesting. Your effort should also be useful to someone learning how USB works hands-on, as it clears away all but the essentials. I've noticed that calling assembly routines frustrates the C optimizer, because it must assume the worst about registers preserved. Here was an attempt I made at ...

Your modifications are a good place to start. Does the stock firmware work? Is your hardware any different? What clock source are you using?

What problems are you having with using PB0 and PB1? If you don't also wire one to an interrupt pin, you'll need to be on a device that supports PCINT (pin change interrupt) that you can configure for one of those two pins.

I tried V-USB on the same chip recently. One change was having clock_prescale_set( clock_div_1 ); at the beginning of main, but you probably already have this since your other code isn't running in slow-motion. I used INT0 and had to reconfigure the interrupt: #define USB_INTR_CFG EICRA #define USB_...

Similar here. I've found the guides hopelessly disorganized, presenting random details and commentary before the reader even understands the overall structure. Along the lines of example code being a good teacher, I'd love to see a log of an actual USB session for say a keyboard, describing each USB...

My send reasoning could be wrong, since how could the 12.8MHz/16.5MHz versions work with RC sending? I'd also think that the receiver in the host would re-synchronize on every edge.

Well, I worked in this one-clock synchronization on the 12MHz version but it didn't improve the OSCCAL deviation allowed. With the original and this code only 0x46-0x48 worked. Full code linked: usbdrvasm12.inc waitForK1: inc YL sbic USBIN, USBMINUS brne waitForK1 ; just make sure we have ANY timeou...

16MHz osccal'd on an attiny85 seems to work here right out the box. I'm attempting to use the one-clock synchronization code idea from above in the 16MHz code, to make it more robust. I just had an insight that you really only need the two-clock-accuracy synchronization code done twice at a one-cloc...

I tried this on another chip, an attiny85 with a 16MHz crystal oscillator, and it fails when I omit one of the diodes, both on a hub and on a PC. So D1-D6 is necessary.

Sorry to revive this but I'd like to answer this hanging question: the voltage drop across the zener diode depends on the current going through it. http://i.imgur.com/kdMGUgp.gif As you go to the left (increasing reverse voltage across the zener), not much flows, until you reach a point where curren...

I think at the very least it doesn't do differential reception, where the voltages of the two data lines are compared (which increases noise immunity). I also don't think the CRC of packets is checked and errors reported to the host so it can re-send transparently.

I think that the 12.8 MHz and 16.5 MHz versions use real-time re-synchronization with the bit transitions, while the others synchronize only to the first transition and then rely on the clock accuracy, thus making them less tolerant of inaccuracy. Documentation for the clock rates is pretty scattere...

I noticed that you don't clear the interrupt flag before PCINT0_vect(). Did you determine that leaving the flag set won't bother usbdrv? I ask because I have seen places in the interrupt code where it checks the flag and acts on whether it's set.

So the .lss (from avr-objdump, not gcc) file doesn't show any occurrences of SEI? I wouldn't trust source code.

Anything mis-restoring the status register?

Oh, and you've changed RETI to RET in asmcommon.inc, right?

Interesting point. I might take a look at the levels for the special states where both are high. I also need to check the USB standard to see what the limits are and which count of diodes is best in the middle.