Objective Development Forums

That looks like something that would break arbitrarily with new compiler versions

Oh, I agree, that could work. You'd need to activate the pull-up resistors because otherwise the zener diodes may pull the inputs low.

The debounce interval is covered by the code is posted up here: viewtopic.php?f=8&t=8801&sid=166e80c1207f99a9e917f28d23023b3e#p26452

It is not necessary to take care of debouncing in the reset code. The code does exactly what I mentioned.

Whenever I tried that, the compiler would also initialize the variables, which took up more space than it saved.

I think for reliable detection of the presence of a USB host you'd have to do this: 0) For enumeration 1) Wait for reset (long SE0). If reset times out, quit bootloader 2) After that, wait for n keepalive pulses (short SE0). If reset times out, quit bootloader All of this will take at least 500ms if...

Actually not so much call overhead, but richer information to the optimizer about exactly what registers are modified. It could probably also be written to let the compiler assign all the registers it uses. I wish I have not found a way to define variables in the assemblercode without having the co...

That is where it is right now. The idea was that inlining saves code space.

Maybe the image below helps. It shows the USB traffic during device enumeration. "Int active" is high while the interrupt routine is executed, tx during set. If you want to understand the usb protocol, i would recommend you get a logic analyzer with USB protocol support. The saleae support...

I tried inlining the crc routine. Unfortunately it only saved two bytes.

It can be a good idea to simulate a device disconnect after program start to force a bus reset. This removes all ambiguity after startup. usbDeviceDisconnect(); /* do this while interrupts are disabled */ _delay_ms(500); usbDeviceConnect(); Otherwise you should be more clear about what you actually ...

The AVR-LIBC erases the the bss section before entering main. You can actually see it when disassembling: This is just an arbitrary example: >avr-objdump -d -S main.bin >main.lss 000017fa <__do_clear_bss>: 17fa: 20 e0 ldi r18, 0x00 ; 0 17fc: a0 e6 ldi r26, 0x60 ; 96 17fe: b0 e0 ldi r27, 0x00 ; 0 180...

Update: I managed to get it to work on a meager ATtiny10!

>Here was an attempt I made at inlining the CRC routine and communicating what registers it trashed
Excellent idea. In fact I can onto a lot of trouble with registers on the ATiny10. I will look into this.

>it uses the USB 5V and a low threshold 3.3V regulator Can the Attiny 85 do 12 MHz at 3.3V? I am certain this is out of spec. > is there enough time for usbPoll() to complete execution for the first time before control goes to the ISR? If you clear pending interrupts before the SEI there may be. Oth...

To understand how to optimize the memory footprint of V-USB, I created a small ATtiny85 based device that controls a single WS2812 RGB LED via USB. This is very similar to the Blink[1] and other devices. Current functionality * Enumeration. * Only SETUP-request can be received. * Responses are limit...

I wonder whether it's the send timing that's the problem. The original OSCCAL for 16MHz was 0xA2, and 0x47 was the optimal 12MHz value. Assuming roughly linear steps, that's about 0.044MHz/step (the way OSCCAL overlaps around 0x80 means that the step is larger than this). Two steps break it, which ...