AVR Freaks

before releasing the code their is a couple things bothering me in the original VUSB code that I noticed today when proof-reading everything, maybe bugs in VUSB and I want to fix them beforehand....

see the below code, this is the usbdrvasm15.inc file... something looks wrong at se0Delay, it is going to delay 9 cycles, not 6 as the code documents.

"ldi  x4, 3" I think should actually be "ldi x4, 2" (currently I think I will fix the loop delay before releasing)

makeSE0:
    cbr     x1, USBMASK     	;1 [06] 	prepare SE0 [spec says EOP may be 19 to 23 cycles]
    lds     x2, usbNewDeviceAddr;2 [07+08]
    lsl     x2                  ;1 [09] we compare with left shifted address
;2006-03-06: moved transfer of new address to usbDeviceAddr from C-Code to asm:
;set address only after data packet was sent, not after handshake
    out     USBOUT, x1      	;1 [00] [10] <-- out SE0-- from now 2 bits==20 cycl. until bus idle
    subi    YL, 20 + 2          ;1 [01] Only assign address on data packets, not ACK/NAK in x3
    sbci    YH, 0           	;1 [02]
    breq    skipAddrAssign  	;1 [03]
    sts     usbDeviceAddr, x2	;2 [04+05] if not skipped: SE0 is one cycle longer
;----------------------------------------------------------------------------
;end of usbDeviceAddress transfer
skipAddrAssign:				;- [03/04]
    ldi     x2, 1<<USB_INTR_PENDING_BIT	;1 [05] int0 occurred during TX -- clear pending flag
    USB_STORE_PENDING(x2)           ;1 [06]
    ori     x1, USBIDLE     		;1 [07]
    in      x2, USBDDR      		;1 [08]
    cbr     x2, USBMASK     		;1 [09] set both pins to input
    mov     x3, x1          		;1 [10]
    cbr     x3, USBMASK     		;1 [11] configure no pullup on both pins
    ldi     x4, 3           		;1 [12]
se0Delay:				;- [12] [15]
    dec     x4              		;1 [13] [16]
    brne    se0Delay        		;1 [14] [17]
    nop2				;2      [18+19]
    out     USBOUT, x1      		;1      [20] <--out J (idle) -- end of SE0 (EOP sig.)
    out     USBDDR, x2      		;1      [21] <--release bus now
    out     USBOUT, x3      		;1      [22] <--ensure no pull-up resistors are active
    rjmp    doReturn			;1	[23]

Another thing bothering me, below is the code from usbdrvasm20.inc... The "st" operation "st y+, shift" uses 2 cycles, NOT 1 cycle, but the code below is written assuming st uses 2 cycles. The driver still works, but I assume the timing is not exactly as intended because of that, or maybe it was just a documentation error. I am investigating. (currently I think this will have no ill effect, and will probably release as is)

;----------------------------------------------------------------------------
; Process bit7. However, bit 6 still may need unstuffing.
;----------------------------------------------------------------------------

b6checkUnstuff:
    dec     bitcnt              ;[9]
    breq    unstuff6            ;[10]
bit7:
    subi    cnt, 1              ;[11] cannot use dec becaus it does not affect the carry flag
    brcs    overflow            ;[12] Too many bytes received. Ignore packet
    in      x1, USBIN           ;[0] sample line state
    andi    x1, USBMASK         ;[1] filter only D+ and D- bits
    cpse    x1, x2              ;[2] when previous line state equals current line state, handle "1"
    rjmp    b7handle0           ;[3] when line state differs, handle "0"
    sec                         ;[4]
    ror     shift               ;[5] shift "1" into the data
    st      y+, shift           ;[6] store the data into the buffer
    ldi     shift, 0x40         ;[7] reset data for receiving the next byte
    subi    leap, 0x55          ;[9] trick to introduce a leap cycle every 3 bytes
    brcc    nextInst            ;[10 or 11] it will fail after 85 bytes. However low speed can only receive 11
    dec     bitcnt              ;[11 or 12]
    brne    bit0                ;[12 or 13]
    ldi     x1, 1               ;[13 or 14] unstuffing bit 7
    in      bitcnt, USBIN       ;[0] sample stuff bit
    rjmp    unstuff             ;[1]

Very interesting.., and I also noticed the cycle count documentation being different was kind of odd... I did write an oscal tuner for the TinyAvr0/1 series that will be included with the source, as well as an HID working example. It works for both 12.8 and 16.5 Mhz. The TinyAvr0/1 internal oscillators are different, but a welcome change as they are more accurate and more stable. very reliable for V-USB so far during my testing. And have no issue reaching 12.8 or 16.5 MHz. The oscal tuner can solve oscal for 16.5Mhz in about 3 loop iterations.

Standard avr 2 cycles (attiny, atmega as vusb was originally written for). TinyAvr0/1 is 1 cycle... from the file I described above, only the 20 megahertz oscillator file has the discrepancy. I am mindful of cycles per architecture that's how I found the discrepancy during the code port to TinyAvr0/1. The discrepancy or bug seems inconsequential to the functionality but is bothersome to me.