Diskussion:Hantek Protokoll
Prüfsumme der gesamten Daten
Ich konnte die Prüfsumme über alle Daten bei dem Bildschirm-Snapshot nicht nachvollziehen. Weder die reinen Nutzdaten, noch die einzelnen Pakete mit oder ohne Protokolldaten, die Summe war nie richtig. Jede mir sinnvoll erscheinende Kombination habe ich ausprobiert, ohne Erfolg.
Peter
Laut Hantek ist das protokol für screenshot empfang so aufgebaut:
53 SS SS A0 01 ZZ ZZ .. ZZ ZZ YY
53 SS SS A0 01 ZZ ZZ .. ZZ ZZ YY
.
.
53 SS SS A0 01 ZZ ZZ .. ZZ ZZ YY
53 SS SS A0 01 ZZ ZZ .. ZZ ZZ YY
53 04 00 A0 02 XX YY
53 - frame header
SS SS - frame size
A0 - master command (antwort auf 20)
01 oder 02 - sub control codes
ZZ - LCD Data
XX - ist summe aller ZZ bytes aus sämtlichen frames, genaue wortlaut
"XX is expressing LCD Data total cumulative and the end of the transmission"
YY - ist checksum für jeweiliges frame
Ich habe weder eine information ob die frames tatsächlich immer gleich sind,
noch über die anzahl der frames.
Fest steht das handheld es komplett
andere grösse versendet als bench. An sich ist es eh egal, jedes frame sendet
die grösse und solange
man die 53 04 00 A0 ...... nicht empfangen hat dauert
die übertragung weiterhin.
Thomas R.
Danke, die YY Prüfsumme ist klar, die stimmt auch, aber die berechnete XX Prüfsumme paßt nicht mit der gesendeten überein. Wie du sagst, es geht auch ohne, wer braucht ein Protokoll :-)
Peter
Die Prüfsumme über alle empfangenen Datenpakete stimmt bei dem Kommando 0x10 'Datei lesen', bei dem Bildschirm-Snapshot stimmt sie nicht. Obwohl die Daten mit derselben Prozedur eingelesen wurden.
Peter
Bildschirm-Snapshot - Protokoll
Es kommt oft vor das die Kommandos bei der Antwort vom DSO nicht stimmen bzw. eine Bedeutung haben die ich nicht kenne. Als Beispiel mitten in einer Übertragung ändert sich das Antwortkommando von 0xA0 auf 0x92, was die Antwort auf das Bedienfeld sperren ist:
53 E3 27 A0 01 00 00 00 .. .. Paket mit 10208 Bytes
53 E3 27 A0 01 00 00 00 .. .. Paket mit 10208 Bytes
53 E3 27 92 01 00 00 00 .. .. Paket mit 10208 Bytes
53 A3 18 92 01 00 00 00 .. .. Paket mit 6304 Bytes
53 04 00 92 02 ED D8 Paket mit Endenachricht und Prüfsumme
Das DSO wurde während der Übertragung nicht berührt und das Sperren-Kommando auch nicht gesendet. Alles sehr seltsam, zumindest stimmt die Prüfsumme pro Paket immer, auf das kann man sich verlassen.
Peter
Es wird auch direkt nach dem Start eines Bildschirm-Snapshots öfter mit 53 04 00 92 01 00 EA oder 53 04 00 92 02 ED D8, also den Antwort-Kommandos '92 01' und '92 02' vom DSO geantwortet. Mir kommt vor, die 0x92 bedeutet ungefähr "bin gerade beschäftigt, bitte probier's nochmal'. Wenn ich mich beim Abholen der Snapshots daran halte, und die 0x92 bei vorhandenen Daten in einem Paket wie eine 0xA0 behandle, noch dazu die Längenangaben in der Paketen ignoriere, dann lauft das Ding ohne Probleme.
An schlechten USB-Kabel liegt es nicht, habe alles mehrfach getauscht, das Protokoll ist so lausig oder ich kapier es nicht. Egal jetzt passt es vorerst.
Peter
Auf der suche nach dem seltsamen "92" habe die chinesischen dokumente von Hantek durchgeguckt und nur ein (abgesehen von den 2 schon bekannten) hinweis gefunden: Beim "waveform abholen" beispiel gibts ein 53 03 00 92 02 XX als antwort auf "do DSO suspend acq." -> 53 04 00 12 02 00 XX (wieder starten ist 53 04 00 12 02 01 XX.
In dem screenshot beispiel ist nix drin,auch die reihenfolge sehr sparsam beschrieben :
PC send DSO 53 02 00 20 XX, DSO answering 53 x0 x1 A0 01 .... and 53 x0 x1 A0 02 sum XX - kein wort zum sum oder sonst was.
Zur error handling beim screenshot abholen steht weiterhin folgendes:
Exception handling: if the DSO after a certain period of time is not responding the host computer will automatically repeat sending the command a certain number of times, if still no answer it will raise a communication timeout.
Alles in allem sind die infos die ich bekommena habe (nach massiven druck als beispiel dafür das die an die SDK denken) wenig brauchbar, den grossten teil muss man sowieso selber "entdecken". Andererseits auch die kleinen schritte bringen uns weiter.
Übrigens, auf deiner website schreibst du "geplannt start/stop acq.", dafür kannst du wunderbar das 53 04 00 12 00 00/01 benutzen. Klar geht auch über die Virtuellen tasten, die sind aber model abhängig - die kontrole über 0x12 0x00 befehl ist aber model unabhängig.
Thomas
DSO Start/Stop - Protokoll
Hallo Thomas,
bei meiner Firmware 120224.0 ist das Protokoll etwas anders. Start/Stop ist vertauscht und die Antwort ist anders:
PC an DSO -> Stop Akquisition ist "53 04 00 12 00 01 6A"
DSO an PC -> Antwort ist "53 04 00 92 01 00 EA"
PC an DSO -> Start Akquisition ist "53 04 00 12 00 00 69"
DSO an PC -> Antwort ist "53 03 00 92 00 E8"
Peter
Das Kommando übergeht nicht die Schaltfläche am DSO, wenn also am DSO auf STOP gedrückt wurde, kann man es mit diesem Kommando nicht aufheben, finde ich sinnvoll.
Peter
---
laut Hantek doku ist es richtig, entspricht aber nicht dem was alle meine DSOs machen - da ist genau wie du gemerkt hast umgedreht. Wird wohl also ein zahlendreher in der doku sein, das macht mich jetzt sehr "glücklich".
Interessant das ich hin und wieder auch andere seltsame "92" codes als antwort bekomme, z.b. 53 03 00 92 00 E8 FB BB 0E BC D1 59 36 beim stoppen der acq. Auch sowas wie 53 03 00 92 00 E8 ist eigentlich falsch.
Laut Hantek sollte die antwort 53 04 00 92 00 xx yy sein, wobei xx ist dann 00 oder 01 je nach status und yy checksum.
Anscheinend verstehen wir den sinn des ganzen nicht, diese kommandos sind anscheinend doch nur sinnvoll um kurz zu stoppen um die daten zu holen und fortführen und nicht als richtige "remote control" kommandos.
Habe jetzt auch die 92 02 00 kommandos getestet, obwohl die beschrieben sind tun die 0,nix auf den DSOs. Also etweder ist das noch nciht implementiert aber schon dokumentiert (von der sorte habe schon zwei kommandos für handheld - die fw kennt es nciht die doku von Hantek schon) oder nicht mehr implementiert.
Thomas
Hallo Thomas,
dein Text:
"Allerdings scheint diese funkton etwas buggy zu sein oder falsch verstanden (da die eigentlich gedacht ist? die acq. zu stoppen bevor Sample-Daten über USB übertragen werden)."
Das tut das Kommando doch. Ich lasse dem DSO im Programm noch kurz Zeit zum Stoppen, ansonst bleibt ein Streifen vom vorherigen Bild bei dem Bildschirm-Snapshot stehen.
Peter
Datei lesen - Protokoll
Es wird beim Senden des Kommandos noch ein Sub-Kommando bzw. ein Null-Byte vor dem Pfad benötigt. Das DSO entfernt ansonst das erste Zeichen vom Pfad.
Peter
---
sehr aufmerksam :)
da fehlt tatsächlich subkomando 00 in dem Artikel.
Wenn versucht wird eine Datei zu lesen die nicht vorhanden ist, antwortet das DSO nicht.
Betrifft auch den Text bei "0x01 DSO Einstellungen lesen: "Sollte die protocol.inf auf dem DSO nicht lesbar/vorhanden ist die Antwort leer. D.h. sie enthält kein Datenbyte:"
Peter (Pedre 07:44, 26. Mär. 2012 (UTC))
DSO Bedienfeld sperren - Protokoll
Als Antwort wird immer das gleiche gesendet, egal ob man sperrt oder entsperrt.
Anwort vom DSO -> "53 04 00 92 01 00 EA" - Das Datenbyte ist immer '0'.
Aber das Sperren ist nur von kurzer Dauer, das DSO entsperrt wieder automatisch nach ein paar Sekunden.
Peter
Sample-Daten lesen - Protokoll
Wenn das DSO angehalten wird, kann ich keine Sample-Daten lesen. Es ist egal ob das DSO mit dem Kommando 0x12 oder manuell gestoppt wurde.
Nachtrag: Habe es gerade mit der TTSope-Software probiert, die gibt auch die Meldung aus, dass man bitte doch das DSO starten möge.
Peter
Wenn das DSO angehalten ist, antwortet das DSO bei der Anfrage nach Sample-Daten sofort mit dem Fehler Sub-Kommando 0x03, z.B. für Kanal 1:
"53 04 00 82 03 00 DC"
Peter
stimmt, hab im Protokol ein vermerk dazu gemacht.
Thomas
Das DSO sendet manchmal die Daten vom anderen Kanal zurück, vorallem wenn mehr als 4k Speicher aktiviert sind. Sieht man auch bei TTscope, am DSO beide Kanäle aktivieren und den Speicher auf 40 k setzen, bei TTscope nur z.B. den Kanal 1 einschalten und etwas warten.
Es wird vom DSO nicht die gesendete Kanalnummer angepasst, es bleibt die vom abgefragten Kanal, also die Falsche!
Peter (Pedre 13:08, 7. Apr. 2012 (UTC))
das habe ich nie beobachten können, es ist aber schon eine weile her als ich TTScope richtig benutzt habe (mag sein das die aktuellen firmwares einfach schrott sind). Wenn das aber so ist dann muss es Hantek wieder fixen, das macht kein spass.
Thomas
USB-Treiber
Das Verhalten des DSO-USB-Treibers ist gleich wie vom Cypress EZ-USB-Treiber, den folgenden Text habe ich von deren Seite, den Link aber leider nicht gesichert:
Zitat:
----------8<--------
Knowledge Base Article
DeviceIoControl() to read data from my EZ-USB FX
Last Updated: 03/16/2009
Question: I've used the function "DeviceIoControl()" to read data from my EZ-USB FX device and if it doesn't have any data to transfer in the IN endpoint, my PC application hangs, What could be the problem? I am using your general purpose driver ezusb.sys.
Response: ezusb.sys is a synchronous driver, so any of the Bulk or Iso IOCTLs are blocking threads. Your PC application will sit there if the device has no data to return (for example in the case of a bulk read). The way to get out of that is to use a driver that supports overlapped I/o, commonly referred to as an asynchronous driver.
----------8<--------
Peter (Pedre 08:01, 26. Mär. 2012 (UTC))
Tastendruck auslösen - Protokoll
Im Text steht:
"- in den nächsten Zeilen folgen die Tastenkomandos (eigentlich deren Namen verwendet durch die firmware) und die Anzahl der Bytes die von jeweiligen Keycode benutzt sind."
Mir geht es um die "Anzahl der Bytes". Ist das eine interne Angabe oder missverständlich für den Wert des Bytes gedacht. Denn im beschriebenen Protokoll kommt die Anzahl ja nicht vor. Es deckt sich aber die '1' in der Datei mit den Wert der Bytes im Protokoll.
Peter (Pedre 10:46, 26. Mär. 2012 (UTC))
laut der info die ich bekommen habe soll die "1" in der keyprotocol.inf die anzahl der bytes bedeuten. Das passt aber nicht irgendwie zu den tastencodes (die dumped waren und in dem artikel stehen - EDIT : habs gerade atrikel angepasst damit jeder weisst das es code + anzahl der clicks ist) da die zweistellig sind. Das liegt daran das der erste byte in den tastencodes der eigentlich code ist, der zweite parameter die anzahl der clicks (angeblich), also z.b. 0x30 0x01 (vom probe check taste) ist der tastencode 0x30 (die 0x30 wiederum entspricht der keyprotocol.inf zeile-1). Diese angeblich anzahl der clicks, in der doku steht folgendes :
53 04 00 13 Key KeyCnt Checksum (Key: 表示键值, KeyCnt：表示写入的数量)
übersetzt Key ist key und KeyCnt key counter. Ich habe versucht z.b. utility taste 2 mal zu senden, hat nix gebracht es war immer nur "einmal" zu sehen gewesen (um ein schritt geändert).
Thomas
Init DSO - Protokoll
Bei mir tut sich nichts beim Senden, das DSO sendet nichts zurück und eine Reaktion sehe ich auch nicht.
Peter (Pedre 20:40, 26. Mär. 2012 (UTC))
---
also wenn ich 43 02 00 7F C4 sende kommt auch 43 02 00 FF 44 als antwort. Dazu habe es mit "0x41 DSO Selbstkalibrierung schreiben" und "0x40 DSO Firmware Variablen schreiben" getestet - ohne init waren die einstellungen nicht geladen, nach dem init schon. Man sieht auch LCD kurz blinken, es muss also auch bei dir funktionieren.
In deiner fw ist auch die 0x7F unterroutine vorhanden, wenn also nicht geht wird an deinen code liegen:
loc_7494C BL Main_RecallInit ; jumptable 0007455C case 127 BL SendToPcUartWriteOk B locret_74968
Thomas
---
habe mir dein DSO-USB-Tool_Code_20120326b angeguckt (mit USBLyzer), Du benutzt iDSOMessageStart (0x53) statt iDSOMessageStartDebug 0x43) in der DSOInitialise. Damit kann kein init funktionieren.
Thomas
Hallo Thomas,
danke, bin wohl schon 'betriebsblind'.
Peter (Pedre 05:53, 27. Mär. 2012 (UTC))
Datei senden - Protokoll
Mit dem Kommando 'Datei senden' kann man auch eine vorhandene Datei überschreiben. Mehr als 4,3 MB konnte ich in einem kurzen Test nicht schreiben, bei 4,9 MB gab's immer Fehler.
Peter (Pedre 21:23, 30. Mär. 2012 (UTC))
Wenn beim Überschreiben bzw. beim Senden ein Fehler auftritt, wird die ursprüngliche Datei nicht gelöscht, die bleibt erhalten. Mit 'Datei senden' kann man also alles machen, neue Datei speichern und vorhandene ersetzen.
Peter (Pedre 21:29, 30. Mär. 2012 (UTC))
Man darf oder soll nach dem Senden des letzten Pakets mit der Gesamtprüfsumme, nicht mehr vom DSO lesen. Das DSO sendet nichts mehr zurück, wenn man es trotzdem macht gibt es auf der Konsole die Meldung "usb_recv: RPC for non-existent buffer". Der USB-Treiber hängt dann für ein paar Sekunden, es geht aber alles ohne Fehler weiter.
Peter (Pedre 20:03, 10. Apr. 2012 (UTC))
das wundert mich etwas, ich sehe das SendToPcUartWriteOK oder SendToPcUartWriteError aufgerufen wird nach jedem block, damit sollte immer etwas in dem buffer stehen.
hier, bei jedem "datei speichern" paket wird die PcUartWriteObjFile aufgerufen:
<c> 00072f5c PcUartWriteObjFile: 00072f5c R12 = SP; 00072f60 /* push PC */ 00072f60 /* push LR */ 00072f60 /* push R12 */ 00072f60 /* push R11 */ 00072f60 /* push R4 */ 00072f64 R11 = R12 - 4; 00072f80 var_14 = * (4 + * pt_rec_buff); 00072f94 R3 = * (1 + * pt_rec_buff); 00072fa4 R2 = 2 + * pt_rec_buff; 00072fb0 R0 = UnitU16FromU8(R3, * R2, R2, R3); 00072fc4 size = (R0 << 0x10 >> 0x10) - 3; 00072fcc R2 = * pt_rec_buff; 00072fd4 ptr = R2 + 5; 00072fd8 R3 = var_14; 00072fdc Cond = R3 - 1; 00072fe0 if (Cond == 0) goto loc_7307C;
00072fe4 Cond = R3 - 1; 00072fe8 if (Cond > 0) goto loc_72FF8;
00072fec Cond = R3; 00072ff0 if (Cond == 0) goto loc_73004;
00072ff4 goto locret_73208;
00072ff8 loc_72FF8: 00072ff8 Cond = R3 - 2; 00072ffc if (Cond == 0) goto loc_730D4;
00073000 goto locret_73208;
00073004 loc_73004: 00073004 PausePthreadForTranFile(R0, R1, R2, R3); 0007300c Cond = size - 0x20; 00073010 if (Cond <= 0) goto loc_73020;
00073018 .printf("len>PC_UART_WRITE_FILENAME_LEN,error!\\n"); 0007301c goto locret_73208;
00073020 loc_73020: 0007302c .memset(s_filename.128, 0, 0x20); 0007303c R3 = .fopen("/tmpp", "wb"); 00073044 * s_fp1.126 = R3; 00073054 .memcpy(s_filename.128, ptr, size); 00073064 SendToPcUartWriteOk(.printf("start recving file,filename=%s...\\n"), s_filename.128, R2, R3); 00073074 * s_sum.127 = 0; 00073078 goto locret_73208;
0007307c loc_7307C: 0007307c PausePthreadForTranFile(R0, R1, R2, R3); 00073088 .printf("++ recving file,len=%d\\n"); 000730a0 .fwrite(ptr, size, 1, * s_fp1.126); 000730b0 R0 = GetSum(ptr, size, R2, R3); 000730bc R1 = * s_sum.127; 000730c0 R2 = R1 + R0; 000730c4 R3 = R2; 000730c8 * s_sum.127 = R3; 000730cc SendToPcUartWriteOk(R0, R1, R2, R3); 000730d0 goto locret_73208;
000730d4 loc_730D4: 000730d8 .printf("stop recving file and check ...\\n"); 000730e4 .fclose(* s_fp1.126); 000730f8 Cond = * s_sum.127 - * ptr; 000730fc if (Cond != 0) goto loc_73168;
00073108 command = * byte_105C1C; 0007311c .memset(R11 - s, 0, 0x29); 00073124 .printf("rec pc file and check OK...\\n"); 0007312c .system("chmod 777 /tmpp"); 0007313c .strcat(R11 - command, "mv -f /tmpp "); 0007314c .strcat(R11 - command, s_filename.128); 00073150 R3 = R11 - command; 0007315c R0 = SendToPcUartWriteOk(.system(R3), R1, R2, R3); 00073160 init_slave_usb_device(R0, R1, R2, R3); 00073164 goto loc_73194;
00073168 loc_73168: 0007316c .printf("rec file and check error...\\n"); 00073174 R3 = * s_sum.127; 00073188 .printf("sum=%d,rec sum=%d...\\n"); 00073190 SendToPcUartWriteError(1, R3, * ptr, R3);
00073194 loc_73194: 000731a0 * s_sum.127 = 0; 000731a4 R3 = s_fp1.126; 000731a8 R2 = 0; 000731ac * R3 = R2; 000731bc ContinuePthreadForTranFile(.printf("s_filename :%s\\n"), s_filename.128, R2, R3); 000731c0 goto locret_73208;
00073208 locret_73208:
ret
</c>
ja stimmt, es ist schon richtig wie im Protokoll beschrieben. Nur jedesmal wenn ich direkt nach dem Schreiben z.B. die DSO-Einstellungen lese, gibt es diesen Hänger und das DSO antwortet danach mit den "43 04 00 92 01 00 0A". Diese Antwort kommt öfters zwischendurch, breche die Kommunikation wegen dieser Antwort ab, weil sie eigentlich falsch ist, kommt irgendwie alles durcheinander. Ignoriere ich sie, bin ich wieder am Anfang mit den vielen Ausnahmen und das Protokoll ist dann nicht ernst zu nehmen.
Peter (Pedre 07:52, 12. Apr. 2012 (UTC))
Datei updaten - Protokoll
Das Kommando funktioniert irgendwie nicht richtig. Wenn eine Datei am DSO nicht vorhanden ist, aber überschrieben werden soll, wird keine neue Datei angelegt, passt. Wenn eine Datei vorhanden ist und überschrieben werden soll, funktioniert es nur wenn 1 Paket mit Daten gesendet wird, also die Datei < 10.000 Bytes ist. Sind es mehr, wird nur das zuletzt empfangene Paket in die Datei geschrieben.
Peter (Pedre 08:03, 31. Mär. 2012 (UTC))
Die Bedeutung des Fehlercodes 0x11 könnte man umkehren. Es gibt nämlich keinen Fehler wenn eine Datei nicht vorhanden ist, aber den Fehler 0x11 wenn eine vorhandene Datei überschrieben wurde.
Peter (Pedre 08:41, 31. Mär. 2012 (UTC))
Formelle Diskussion zum Artikel
Ich finde den Stil, wie man die Handlungsweise von Hantek kritisiert, nicht optimal. Allerdings begrüsse ich ausdrücklich den Artikel selber und die Arbeit, die sich manche damit manchen! Das ist sehr lobenswert. Engineer 13:10, 21. Dez. 2012 (UTC)