CJoy / USB-DevName

Dir ist klar dass der String Unicode sein muss? Ich kann mir nicht 
vorstellen, das db Unicode erzeugt. Mehr kannst du dem List File 
entnehmen.

Ich habe die 4 Buchstaben -CJoy- durch -Joy1- ersetzt und im erzeugten 
Hex-File ist diese Änderung auch zu sehen, verstehe aber die Anmerkung 
auch nicht.

Dann kommt natürlich noch das Problem, dass Win diese Strings in aller 
Regel ignoriert, solange man keine spezialisierte inf Dateien 
präsentiert, was für Hid ziemlich unmöglich ist.

Warum WIN ? Mit Notepadd++ den SourceCode geändert und dann compiliert,
die HexWerte für "Joy1" sind im *.hex drin

Dann nimm mal bitte USB View und schau dir die Strings an was da drin 
steht, entspricht nicht so ganz dem was du dir vorstellst. Das ist 
definitiv kein Unicode der zur language id US oder DE passt.

Wie kann ich sicher sein, dass das geänderte hex-File auch sauber 
übertragen wird ?

Habe den flash-Vorgang so gestartet:
avrdude -c avrisp -p atmega8 -P COM17 -b 19200 -U 
flash:w:CJoy_0.03_neu.hex

Anbei noch die Anzeige in VICE64

1

avrdude: AVR device initialized and ready to accept instructions

2

3

Reading | ################################################## | 100% 0.07s

4

5

avrdude: Device signature = 0x1e9307 (probably m8)

6

avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed

7

         To disable this feature, specify the -D option.

8

avrdude: erasing chip

9

avrdude: reading input file "CJoy_0.03_neu.hex"

10

avrdude: input file CJoy_0.03_neu.hex auto detected as Intel Hex

11

avrdude: writing flash (2532 bytes):

12

13

Writing | ################################################## | 100% 4.07s

14

15

avrdude: 2532 bytes of flash written

16

avrdude: verifying flash memory against CJoy_0.03_neu.hex:

17

avrdude: load data flash data from input file CJoy_0.03_neu.hex:

18

avrdude: input file CJoy_0.03_neu.hex auto detected as Intel Hex

19

avrdude: input file CJoy_0.03_neu.hex contains 2532 bytes

20

avrdude: reading on-chip flash data:

21

22

Reading | ################################################## | 100% 1.88s

23

24

avrdude: verifying ...

25

avrdude: 2532 bytes of flash verified

26

27

avrdude: safemode: Fuses OK (E:FF, H:DF, L:3F)

28

29

avrdude done.  Thank you.

Rainer S. schrieb:
> Wie kann ich sicher sein, dass das geänderte hex-File auch sauber
> übertragen wird ?

Glaub mir das funktioniert einwandfrei sonst würdest du eine 
Fehlermeldung bekommen.
Nochmal:
USB erwartet Unicode Strings du definierst aber normly Byte Strings. Das 
funktioniert nur dann wenn der USB Code die Strings vor dem Senden auf 
Unicode umcodiert.
Ich hatte dir ja schon usbview empfohlen um die Strings mal anzuschauen. 
Deine C64 Optionen sind erst mal unwichtig.
Im Source sind ja schon Hinweise enthalten dass wohl was faul ist. Das 
Device wird erst dann neu eingelesen, wenn du neue ids vergibst.

Habe einen Namen UND eine ID vergeben, jetzt funktioniert's.
Aber warum erst bei Änderung der ID ? Dann muss Windoof irgendwo 
Treiber-Leichen zum USB-Adapter abgelegt haben, wo kann ich die finden ?

Bei dem ersten Anstecken legt Windows eine pnf Datei an. Das ist im 
Prinzip ein compilierter Teil der inf. Diese musst du löschen damit das 
Device neu erkannt wird. Das wird aus Performance Gründen so gemacht und 
ist seit W98 unverändert. Ohne diesen Mechanismus würde es wesentlich 
länger dauern bis ein Device nach dem Anstecken verfügbar wäre.
Alternativ kannst du das Device auch in der Registry entfernen wenn du 
weißt was du tust.