Objective Development Forums

christian wrote:The report-ID must also be the first byte of the report data. The reports sizes all increase by one byte.

Hello Christian,

thanks for your answer. I already had that in mind. So it should work with the posted code or are there any other modifications neccessary?

Hi all, it's me with a stupid question again I was wondering how to handle a HID descriptor with multiple report ids correctly? For example, if I had a device with a HID descriptor containing two reports (report id(1) and report id(2)), would it be sufficient to modify the function "usbFunction...

Update: Grendel, your hint was right. After inserting a sei() at the beginning of the ADC ISR the device ran as expected. Thank you very much - you saved my day

@Grendel: thanks for the hint - I must have overlooked this ... That would mean that I must ensure that there are no ISR blocking situations which last longer than ~2µs (25/12MHz) - is that correct? In the code there's a section where I copy several 100 bytes of data with interrupts disabled - so I ...

I forgot something to mention: sometimes (1 out of 10 tries or so), the device gets recognized by windows and is shown in the game controller panel. But then it seems, that the communication broke down, because no matter what I do, the shown values of the analog axis don't change any more. If I chan...

Finally I found the issue: as in most cases, it's located behind the screen The trouble was caused by the pull-up which has been placed between VCC and D+ instead of VCC and D-, so the device always registered as full-speed instead of low-speed. I've looked several times at the pull-up, but due to s...

If I remember correctly, it does not work regardless of the interrupt in your case. Right Let's concentrate on the debug output. You get the startup message and you see USB Reset, but you don't get any data. This can be because the interrupt never occurs or because the data is identified as garbage...

Here are the latest results (there's still no change ): The interrupttable looks good for INT0 and INT1: INT0: Disassembly of section .text: 00000000 <__vectors>: 0: 0c 94 7f 00 jmp 0xfe ; 0xfe <__ctors_end> 4: 0c 94 f6 02 jmp 0x5ec ; 0x5ec <__vector_1> 8: 0c 94 9c 00 jmp 0x138 ; 0x138 <__bad_interr...

Did you check the disassembler output to see whether the interrupt table has been compiled correctly? Can you please give me a hint where I have to look and what it should look like? And did you try a different interrupt? I tried INT1 instead of INT0 - I connected D+ to INT1 (pin 17) and made follo...

Finaly I was able to log some data via uart: after plug-in of the device, I receive 1 time "00" (1st message) and 15 times "ff" -- that's all. I guess, this isn't a good sign Next, I will test if port D works as expected on my ATmega32 - maybe the micro itself has some errors.......

The ATMega32 should work without any changes, at least at the first glance. I have never used this chip myself, though. It definitely needs other fuse values than the ATMega8. What fuse values do you use? The lfuse is programmed to 0x9F, the hfuse to 0x09 -- these are the same settings as on the at...