>> The above measures will allow you to build the project, but manual
>> inspection of the code generated for usb.c, l.309 revealed that
>> there is severe bug in the code generator: instead of just reading
>> SetupPacket.wValue1 (offset 3), the generated code overwrites
>> SetupPacket.bmRequestType (offset 0). There seems to be lack of
>> scratch register allocation. I'll have to investigate this
>> further... Just thought you might want to now.
> can we return to this problem ? I tried to get newest SDCC-20080905
> and compile the project again.
> Downloaded the PICHID package -
Did that as well.
> Made necessary changes in usb.c and Makefile - see diffs. In compile
> log there are missing some lines about --optimmize-goto and modified
> dog caaled EVELYN.
Hmm. I spent the evening (after your post) compiling and inspecting the
USB/PICHID/* stuff and updated the source to compile without warnings
"the right way" (except for EVELYN, which is harmless: it removed empty
if-blocks). Find attached a more generally applicable Makefile, a patch
to move sdcc keywords into the __-namespace (just recommended,
cosmetic.patch) and another patch to remove all warnings (take address
of proper object instead of casting blindly). However, they yield no
difference in the output.
> But device is not detected at all.
You mean that the PIC-USB-Device is not detected by some host system
with confirmed working USB support, right? Gee, that makes it difficult...
> Did you find something for these problems you mentioned ?
They are gone, the generated code is correct as far as I can see (well,
I can only check some 100 LOCs, but the above problem is definitely no
longer there; didn't bother to find out since when, though...). Your
problem lies elsewhere I fear. Might be another compiler bug, or maybe
your setup? Can you confirm your setup using the distributed USBHID.hex
is related to and can solve your problem, though I do not quite why
recompiling the libraries (solution proposed there) did help at all...
You might try using SDCC 2.5.6 (r4161, to be obtained from svn directly).
Could *anyone* who has already run the given USB code on a PIC confirm
that the code generated by the current SDCC 2.8.3, r5228, snapshot from
2008-09-05 is broken (or alternatively check that it works just fine)?
Or post the version/revision of *any* (preferably the last ;-) ) working
SDCC version so that I can generate reference .asm output?
I do not even have a PIC nor a testbed to try, so I am quite lost here.
How shall I debug this?!? I even tried to diff the disassembled versions
of the packaged and the newly built USBHID.hex, but that diff is ...