Habe die Firmware geflasht, und usbprog wird auch erkannt (winXp) hab dann den treiber installiert, aber HTerm meldet immer, das sämtlichen Baudraten angeblich nicht unterstüzt werde :( Gibt es da nen Trick wie ich USBProg zur mitarbeit überreden kann?
Hat niemand ne Idee oder sezt niemand ide RS232 Firmware ein? Hat shconmal jemand das an Windows zum laufen gekriegt?
Meiner Meinung nach, geht beim USBprog nur eine Baudrate, und zwar 9600 Baud. Du kannst aber mal Benedikt anschreiben, und dann macht er noch eine Funktion, dass man auch die Baudrate wechseln kann, hat er zumindest auf seiner Seite geschrieben. Ich hatte nämlich das selbe Problem, benötige aber kleinere Baudraten, also kann ich es auch nicht verwenden.... Bei mir erscheint nach dem Flashen der RS232- Firmware der USBprog im Gerätemanager mit so einem Fragezeichen, also er wurde irgendwie nicht korrekt installiert, keine Ahnung wieso. Normalerweiße sollte er ja als virueller Com- Port erscheinen. Wie hast du den installiert, bzw. welchen Treiber hast du da verwendet? Gruß, Steffen
AUf der Firmwareseite gibt eine eine inf Datei, die hab ich runtergeladen und dann mittels "Treiber aktualisieren" im Gerätemanager installiert. Oh man hab das voll überlesen! Mit 9600 geht es, wenn man da frei wählen könnte wäre das natürlich nett. Hab nur das Problem das er beim loop-Test Zeichen verschluckt :-\
So, jetzt hab ich es auch geschafft, der USbprog wird nun korrekt als COM5 erkannt. Welche der Stiftleisten ist eigentlich RX und TX? Ich hab das auf der Homepage von Benedikt irgendwie nicht verstanden, was da was ist. Gruß, Steffen
Jo... Das Projekt ist echt nett... aber leider alles SEHR konfus. Also laut Schaltplan ist die Reihenfolge: 1 = VCC 2 = PD0 = RXD 3 = PD1 = TXD 4 = GND Falls Benedikt mitliest: Nen Treiber für Win98 wäre auch nice, habe leider keine Ahnung was dafür nötig wäre :-\
Meinst du diese Pinbelegung an der Stifleiste, die man auch verwendet zum umflashen des USBprog? Ja, du hast recht, meiner Meinung nach gehören manche Sachen noch ein wenig besser dokumentiert. Gruß, Steffen
Angehängte Dateien:
-
usbprog3.jpg
120 KB
Laut Schaltplan(http://svn.berlios.de/svnroot/repos/usbprog/trunk/board/schematic_v31.pdf) sollte eine 4 Polige Buchse existieren, ich vermute mal das ist die welche relativ nah am Mega32 sizt (siehe Bild), das eckige Pad sollte Pin 1 sein (vorsichtshalber nachmessen). Habe mir gerade die USBSerial firmware mal runtergeladen, mal abgesehen von den Warnungen hab ichs sogar schon hinbekommen zu kompilieren :)
1 | main.c:16: warning: function declaration isn't a prototype |
2 | main.c:17: warning: function declaration isn't a prototype |
3 | main.c:277: warning: function declaration isn't a prototype |
4 | main.c:289: warning: function declaration isn't a prototype |
5 | main.c: In function 'main': |
6 | main.c:315: warning: passing argument 1 of 'USBNInit' discards qualifiers from pointer target type |
7 | main.c:315: warning: passing argument 2 of 'USBNInit' discards qualifiers from pointer target type |
8 | main.c: At top level: |
9 | usbn2mc.h:27: warning: inline function 'USBNBurstWrite' declared but never defined |
10 | usbn2mc.h:27: warning: inline function 'USBNBurstWrite' declared but never defined |
Bin nur zu "neu" und will da nirgends dran rumpfuschen, zumal es ein alter Stand ist (gut wäre es wenn Benedikt mal die aktuellen SOurcen als tar zur Verfügung stellen würde, hab leider kein SVN)
Ich bin am verzweilfeln: Wenn ich also die Firmware draufflashe, dann wird der USBprog ordentlich als COM5 erkannt. Nun verbinde ich an JP3 (der, der dem ATmega32 am nächsten ist) mit einem Jumper eben die zwei Pins, die man auch Verbinden muss, damit der USBprog in Bootloadermode geht. Dann müsste ich doch eigentlich RX mit TX verbunden haben, oder? Dann stelle im in HTerm COM5 und 9600 Baud ein, und sende ein Zeichen, dieses kommt jedoch nicht zurück.... Wieso klappt das nicht? Gruß, Steffen
1) Jumper für Firmwareupdaten 2) Firmware draufspieln 3) Gerät abstecken 4) Jumper abziehen (sosnt startest du wieder im Updatemodus) 5) Gerät anstecken 6) Verbinden (9600N1 Hardwareflußkontrolle aus) 7) ggf Jumper stecken Wie gesagt das funktioniert ÜBERHAUPT nicht zuverlässig, die Firmware scheint mir recht ungetestet, es gehen Zeichen verloren etc... Deshalb einfach mal ein paar mehr Zeichen senden, ich benutz zudem hterm weil Hyperterminal garnicht mit USB Prog zusammenarbeiten will. Werde mal Benedikt ne Mail schreiben, würde ja die Firmware auch weiteretnwickeln aber irgenwei steig ich bei dem Code nicht ganz durch...
Ja, du hast Recht, nun klappts auch! Aber auch bei mir das gleiche: Ich sende mit HTerm immer hallo, einmal kommt hlo zurück, ein anders mal halo, und wieder ein anderes mal klappts auch ganz. Scheint wirklich nicht gut getestet zu sein..... Gruß, Steffen
Habe mir den Source mal angesehen, das "Problem" scheint mir das jedes Zeichen ein eigener USB request ist ohne Buffer... dadurch geht natürlich durch die Latenz bei USB viel verloren. Ich würde ja die Firmware anpassen scheitere aber schon daran erstmal ein Zeichen zu senden, mir sind leider die Interna nicht ganz klar und auf der HP find ich auch keine gute Beschreibung wie das von staten geht den USBN als Serielle Schnittstelle zu verwenden :-\
> Ja, du hast Recht, nun klappts auch! Aber auch bei mir das gleiche: Ich > sende mit HTerm immer hallo, einmal kommt hlo zurück, ein anders mal > halo, und wieder ein anderes mal klappts auch ganz. > Scheint wirklich nicht gut getestet zu sein..... Bei mir war es so, dass vom gesendeten String "Hallo Welt" nur folgendes zurückgekommen ist (über Loop): "H". Nach Aus-/Einstecken funktioniert es dann wieder für genau ein Zeichen. Hat schonmal irgendjemand von euch die Logic-Analyzer-Firmware zum laufen gebracht? Hab selbst mittlerweile schon in Linux getestet - aber auch dort: keine Funktion. Grüße, gast
Also ich hab jetzt mal den GPS- Empfänger von hier (Beitrag "GPS - Empfänger günstig bei Ebay") und mit dem klappt der Empfang über die Firmware, ohne ein verlorenes Zeichen!! Warscheinlich liegt dieser Zeichenverlust daran, dass man eben RX und TX verbunden hat. Also, wenn ich das jetzt so teste, bin ich eigentlich echt zufrieden damit, bis auf das, dass man eben nur eine Baudrate hat. Gruß, Steffen
Naja, das geht aber vermutlich nur weil der Datenstrom bei so einem Modul doch recht einseitig ist, das sendet ja die meiste Zeit und empfängt nur alle jubeljahre mal einen kleinen Befehl von ein paar Bytes.
Hallo,
mit hat jemand eine Version vorkurzem zugesendet. Könnte für euch
interessant sein:
ich hab mal n bisschen mit der Firmware gespielt und versucht die tiny
Version noch kleiner zu machen. Die Descriptoren liegen jetzt im Flash
(werden nur bei Bedarf mit den pgm_space Befehlen geladen).
Außerdem habe ich eine generische USB-CDC Implementierung erstellt. HID
folgt vielleicht auch noch...
Eine minimale main.c würde so aussehen:
#include "usbn2mc.h"
#include "usbn2mc/class/CDC/usbcdc.h"
// reponse for requests on interface
void USBNInterfaceRequests(DeviceRequest *req, EPInfo* ep)
{
}
/* id need for live update of firmware */
void USBNDecodeVendorRequest(DeviceRequest *req)
{
switch(req->bRequest)
{
// case STARTAVRUPDATE:
// avrupdate_start();
break;
}
}
int main(void)
{
sei(); // activate global interrupts
USB_CDC_init(); // setup usbstack as CDC device
USBNAddStringDescriptor("USBprog EmbeddedProjects");
USBNAddStringDescriptor("USBprogRFM12");
USBNInitMC(); // start usb controller
USBNStart(); // start device stack
for(;;);
}
Hallo Benedikt, Dnake für die Dateien, das sieht auf den ersten Blick ja ganz gut aus, braucht man dafür spezielle Treiber wie bei der usbserial Version von dir wenn man das unter Win einsetzen möchte? Und kannst du vieleicht kurz erklären was man beim senden beachten muß? (hat es z.B. ne feste Baudrate? Ich seh jezt in den Files so direkt nix...) // EP0 in/out: USB (USBN: FIFO0 TXC0 RXC0) // EP3 interrupt in: CDC control (USBN: FIFO1 TXC1) // EP1 bulk out: CDC data (USBN: FIFO2 RXC1) // EP1 bulk in: CDC data (USBN: FIFO3 TXC2) EP0 --> Kann ich ignorieren? EP3 --> Muß man da was spezielles hinsenden (CTS...RTS....) EP1(out) --> Empfangen von Daten vom PC (müßte das nicht EP2 sein???) EP1(in) --> Senden von Daten an den PC Wollt das nur mal klären bevor ich jezt wieder stundenlang erfolglos rumwurschtel...
Wollts jezt mal kompilieren, aber:
1 | avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT usbozi.o -MF dep/usbozi.o.d -c ../usbozi.c |
2 | avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT usbn2mc.o -MF dep/usbn2mc.o.d -c ../usbn2mc.c |
3 | avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT usbnapi.o -MF dep/usbnapi.o.d -c ../usbn2mc/tiny/usbnapi.c |
4 | avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT usbn960x.o -MF dep/usbn960x.o.d -c ../usbn2mc/tiny/usbn960x.c |
5 | avr-gcc.exe -mmcu=atmega32 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT usbcdc.o -MF dep/usbcdc.o.d -c ../usbn2mc/class/CDC/usbcdc.c |
6 | ../usbn2mc/class/CDC/usbcdc.c:57: error: 'USB_CDC_CLASS_DESC_LENGTH' undeclared here (not in a function) |
7 | ../usbn2mc/class/CDC/usbcdc.c:131: error: empty scalar initializer |
8 | ../usbn2mc/class/CDC/usbcdc.c:131: error: (near initialization for 'cdc_config_desc.class_desc') |
9 | ../usbn2mc/class/CDC/usbcdc.c: In function 'USB_CDC_EP1_receive': |
10 | ../usbn2mc/class/CDC/usbcdc.c:176: warning: passing argument 1 of 'USB_CDC_rxCallback' from incompatible pointer type |
11 | make: *** [usbcdc.o] Error 1 |
Das einzige was ich geändert habe ist:
#include "usbn2mc/tiny/usbnapi.h"
in
#include "../../tiny/usbnapi.h"
Weil er sosnt bei mir die Headerfile nicht gefunden hat.
Und in der usbn2mc
//#include "UART/uart.h"
und
void USBNDebug(char *msg) {
//UARTWrite(msg);
}
(im zip gab es keinen Ordner mit den benötigten Dateien...)
Habs jezt doch hinbekommen durch ein zusätzliches Define, dafür läßt sich das "Gerät" aber laut WinXP nicht starten... :-\
Ich habe jetzt auch mal den USB-232 Wandler mit Usbprog ausprobiert (mit dem Source aus dem SVN). Gerät wird erkannt. COM Port wird eingerichtet. Senden von USB auf RS232 geht. Empfangen von RS232 und senden auf USB geht komplett nicht. Kein einziges Zeichen! Das empfangen von RS232 funktioniert nur bis in den ATMega. Hab da die rote LED im Receive Interrupt eingebaut. Bis da hin geht es gut. Aber über den USBN9604 wird irgendwie nichts weitergegeben. Aus lauter Verzweiflung habe ich dann den Takt für den ATMEga mal auf 8MHz geändert und die Baudrateneinstellung angepasst. Und schon kann ich auch Zeichen empfangen. Meine Vermutung ist jetzt das es bei 16MHz mit meinem Layout nicht so ganz hinhaut. Ist ein Nachbau mit ATMega im DIP Gehäuse. Die Leitungen sind aber sauber und kurz verlegt. Ich werde am Wochenende mal ein bißchen an USBNWrite() rumfummeln und versuchen es dort stabiler zum laufen zu bekommen. Ein Tip an Benedikt:
1 | sei(); // activate global interrupts |
2 | UARTInit(); // only for debugging |
3 | |
4 | // setup usbstack with your descriptors
|
5 | USBNInit(usbrs232,usbrs232Conf); |
6 | |
7 | _USBNAddStringDescriptor(""); //pseudo lang |
8 | _USBNAddStringDescriptor("USBprog EmbeddedProjects"); |
9 | _USBNAddStringDescriptor("usbprogRS232"); |
10 | _USBNCreateStringField(); |
11 | |
12 | |
13 | USBNInitMC(); // start usb controller |
14 | USBNStart(); // start device stack |
Der Receive Interrupt für den UART wird schon freigegeben bevor die Init für den USBN durch ist. Dort wird aber auch in den USBN geschrieben! Wenn an RxD etwas hängt was am senden ist könnte das Ärger geben. Ich würde den UART Receive Interrupt erst nach USBNStart(); aktivieren.
Also ich hab auch ein "selbstgebautes" bei 16Mhz sollte das unkritisch sein. Ich sende damit folgendermaßen ein Zeichen: Beitrag "Hilfe zu USB/CDC Implementierung (USBN9604)" Was aber leider recht lahm ist :-\
>Also ich hab auch ein "selbstgebautes" bei 16Mhz sollte das unkritisch >sein. Als mkII Clone arbeitet mein Selbstbau auch gut. Fehler in der Schaltung oder im Layout schliesse ich jetzt aus. Als USB->RS232 Sender funktioniert der usbprog. Das Problem liegt beim empfangen. Ich habe alles mögliche ausprobiert. Mit dem Programm aus dem Online-Pool programmiert, das usbserial aus dem SVN genommen, den Sourcecode selber kompiliert und an manchen Stellen in usbn2mc.c etwas konservativer programmiert. Den Receive Interrupt erst nach USBNStart() aktiviert. Alle UART Debug Meldungen aus dem Sourcecode entfernt. Ich kriege es einfach nicht hin :( Beim Empfang gibt es nur Probleme. Die Daten gehen per RS232 in den ATMega rein. Das zeigt mir eine toggelnde LED im Receive Interrupt. Jedesmal wenn ich eine Taste im Terminalprogramm drücke ändert sie den Zustand. Laut Osci werden dann auch Daten in den USBN geschrieben. CS,WR,A0 sieht alles gut aus. Am PC kommt aber nicht immer was an. Manchmal ja, manchmal nein. Ein Loopback mit Rx und Tx direkt am Usbprog funktioniert so gut wie gar nicht. Das kann man sich gleich sparen. Ich hab dann auch mal einen MAX232 an RX angeschlossen und Daten von einem echten COM Port gesendet. Auch da wieder: Mal geht ein bißchen was, meistens aber nur Stille auf dem Empfangsterminal. Obwohl das ist nicht ganz richtig. Die erste Taste wird gar nicht angezeigt. Die zweite Taste dann ja! Und dann kommt meist nichts mehr. Das bei allen drei Variationen, also Programm aus dem Online-Pool programmiert, das fertige Bin aus dem SVN und Sourcecode selber übersetzt. Ich gebs auf. Für CDC nehme ich doch lieber einen FT232 oder einen PIC18 mit USB.
Der Code, den Benedikt gepostet hat ist von mir. Funktioniert als USB<->RFM12 Wandler problemlos. Ich werd mal ne Version für USB<->RS232 incl. Baudrate fertig machen. Vielleicht klappts noch diese WE.
Manuel Stahl wrote: > Der Code, den Benedikt gepostet hat ist von mir. Funktioniert als > USB<->RFM12 Wandler problemlos. Ich werd mal ne Version für USB<->RS232 > incl. Baudrate fertig machen. Vielleicht klappts noch diese WE. Das wäre Klasse! Magst du vieleicht die USB<->RFM12 auch veröffentlichen?
Schon lange geschehen: http://www.mikrocontroller.net/articles/AVR_RFM12#USBprogRFM12 svn://mikrocontroller.net/rfm12
Manuel Stahl wrote: > Schon lange geschehen: > > http://www.mikrocontroller.net/articles/AVR_RFM12#USBprogRFM12 > > svn://mikrocontroller.net/rfm12 Kannst du die Sotware vieleicht hier hochladen? Ich hab leider kein Programm für SVN, und gibt es dafür auch nen Treiber für XP? Sorry wenns schon irgenwo steht aber ich kanns nicht entdecken, ggf könnte man das ja auch mal auf der FirmwareSeite vom USBProg hinpacken :)
Hier die Rev19. Die hab ich erfolgreich getestet, verwendet aber noch nicht meine überarbeitete USB-CDC Version.
Und hier noch ein aktueller Snapshot der Entwicklung. Bei beiden ist Eclipse mit CDT und AVR-Plugin zum Übersetzen nötig.
@Manuel Stahl Schonmal vielen Dank werde es mal heute Abend ausprobieren. Du sendest ja auch immer ein zeichen zur Zeit über die USB hast du schonmal versucht mehrer Zeichen gleichzeitig zu senden?
Die überarbeitete Bibliothek für den USBN9604 wird das auf jedenfall können! Ich mach mal ein neues Thema für den USBprogRFM12 auf, vielleicht gibts noch mehr Interesse... Beitrag "USBprogRFM12"
Mit dem Code aus USBprogRFM12_head.zip bekomme ich ein gelbes Ausrufezeichen für den COM-Port. Das Gerät kann nicht gestartet werden (Code 10)
@holger: ich weiß, deshalb hab ich ja auch den funktionierenden Code aus Rev19 hochgeladen. Falls aber jemand Basteln will, sollte er an der head-Version weitermachen, da diese dem aktuellen Stand entspricht.
Hallo zusammen, ich bin noch blutiger Anfänger und habe heute versucht den USBprog als RS232 Wandler zu nutzen ... mit mäßigem Erfolg. Wie schon beschrieben werden Zeichen teilweise verschluckt und ich muss auch die Baudrate ändern können. @manuel stahl Daher wollte ich Dich fragen, ob Du an dieser Stelle schon etwas gemacht hast? @Alle Ansonsten noch die allgemeine Frage, wenn ich an den Sourcen etwas ändere ... wie kann ich daraus eine neue Firmware kompilieren, die ich dann über das Flashtool ins UsbProg schreiben kann? Bisher nutzte ich für meine Projekte WinAVR + Ponyprog + Parallel Programmer Schon mal Vielen Dank! Gruß
Ja, bin weitergekommen. Baudrate einstellen geht aber leider immernoch nicht, da der entsprechende Wert seltsamerweise nicht richtig vom PC empfangen wird. Wer sich's anschauen will: usbcdc.c Zeile 226
So jetzt gehts. Baudrate ist auch implementiert! Nicht implementiert, aber prinzipiell kein Problem sind Character-Size, Parity, Stop-Bit und Hardware-Handshake.
Hallo Manuel! Toll, dass du dich so bemühst und die Firmware vorantreibst. Ich habe sie gerade bei mir ausprobiert mit einem kleinen Problem: Gerät kann nicht gestartet werden - Code 10 natürlich mit beiliegender inf-Datei. OS: WinXP Wäre nett, wenn du mir/uns da helfen könntest. mfg gast
Ich kann das unter Windows nachvollziehen, hab aber auch keine Idee an was es liegt. Vielleicht kann da jemand mir mehr Windows USB Erfahrung mal schauen... Unter Linux hab ich keine Fehler mehr.
"Gerät kann nicht gestartet werden" bekomme ich hier auch. usbview sagt folgendes: > Device Descriptor: > bcdUSB: 0x0110 > bDeviceClass: 0x02 > bDeviceSubClass: 0x00 > bDeviceProtocol: 0x00 > bMaxPacketSize0: 0x08 (8) > idVendor: 0x1781 > idProduct: 0x0C64 > bcdDevice: 0x0100 > iManufacturer: 0x01 > iProduct: 0x02 > iSerialNumber: 0x00 > bNumConfigurations: 0x01 > > ConnectionStatus: DeviceConnected > Current Config Value: 0x00 > Device Bus Speed: Low > Device Address: 0x00 > Open Pipes: 0 Die rote LED blinkt beim Einstecken 3 mal kurz... Die 2 Versionen im svn funktionieren auch nicht so richtig (USPprogRS232 und USBprogRS232_fix). Arbeitet da noch jmd daran?
ich hab da schon vergebens versucht eine email an Benedikt Sauter zu schreiben, da kommt aber nie eine antwort. es kümmert sich anscheinend niemand darum. bei anderen firmwares sieht das ähnlich aus. z.b. die logikanalyser firmware, da gibts noch nicht einmal einen download auf der embedded seite und im fimware pool ist diese auch nicht enthalten. von den 17 angepriesenen firmwares sind gerade einmal 8 über den firmwarepool erreichbar. ist schon irgendwo eine mogelpackung (und das für 32€).
Naja mir würde eine Mischung aus der "alten" RS232 ohne FIFO und der neuen schon reichen. Also mit FIFO, aber fix auf 9600 Baud. Passt nämlich zu meinem HR20 :) Komischerweise sind RX und TX beide high, sowohl am USBprog und am HR20, und dadurch versorgt sich der HR20 ohne Batterien...
Wenn mal jemand, der den USBprogRS232 unter Windows einsetzen will einen USB Logger installiert und den Trace schickt, könnte ich vielleicht mehr sagen. Da meine Linux-Version soweit geht, wüsste ich nicht in welche Richtung ich testen soll.
Das kam raus bei SnoopyPro, Firmware ist die aus deinem post vom
22.11.2008 19:00.
Die Formatierung ist etwas schlecht, ich hoffe du kannst erkennen was es
bedeutet.
packet 1
1 in down n/a 0.184 GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 1
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
---------------------------------------------------------------
packet 2
1 in up n/a 0.190 CONTROL_TRANSFER 12 01 10 01 02 00 00 08
0x00000000
URB Header (length: 80)
SequenceNumber: 1
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 89aa2a40
SetupPacket:
0000: 80 06 00 01 00 00 12 00
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
Descriptor Type: 0x0001
DEVICE
TransferBuffer: 0x00000012 (18) length
0000: 12 01 10 01 02 00 00 08 81 17 64 0c 00 01 01 02
0010: 00 01
bLength : 0x12 (18)
bDescriptorType : 0x01 (1)
bcdUSB : 0x0110 (272)
bDeviceClass : 0x02 (2)
bDeviceSubClass : 0x00 (0)
bDeviceProtocol : 0x00 (0)
bMaxPacketSize0 : 0x08 (8)
idVendor : 0x1781 (6017)
idProduct : 0x0c64 (3172)
bcdDevice : 0x0100 (256)
iManufacturer : 0x01 (1)
iProduct : 0x02 (2)
iSerialNumber : 0x00 (0)
bNumConfigurations : 0x01 (1)
---------------------------------------------------------------
packet 3
2 in down n/a 0.190 GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 2
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
---------------------------------------------------------------
packet 4
2 in up n/a 0.196 CONTROL_TRANSFER 09 02 43 00 02 01 00 a0
0x00000000
URB Header (length: 80)
SequenceNumber: 2
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 89aa2a40
SetupPacket:
0000: 80 06 00 02 00 00 09 01
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
Descriptor Type: 0x0002
CONFIGURATION
TransferBuffer: 0x00000009 (9) length
0000: 09 02 43 00 02 01 00 a0 1a
bLength : 0x09 (9)
bDescriptorType : 0x02 (2)
wTotalLength : 0x0043 (67)
bNumInterfaces : 0x02 (2)
bConfigurationValue: 0x01 (1)
iConfiguration : 0x00 (0)
bmAttributes : 0xa0 (160)
MaxPower : 0x1a (26)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.