Rigol DS1052E Speichertiefe

Am 25.05.2010 21:13, schrieb Christian Zietz:

Oha - das ist interessant. Könntest du mir deinen Dump vom USB schicken, damit ich genau vergleichen kann, wenn ich meinen Kern ändere?

Hmmm, ok.

Der usbtmc-Treiber ist auch von Agilent geschrieben und wohl nur mit deren Scopes getestet :-)

Zu deinem Patch aus der anderen Antwort: Das führt leider dazu, dass das Scope schon beim *IDN? abstürzt. Das Rigol ist was Kommunikationsfehler auf dem USB angeht wohl nicht sonderlich robust.

Was ich aber gemacht habe, ist die Buffersize gleich gelassen (für kalloc auf 2k), allerdings in den Bulk Requests die Größe so verändert (auf 1k + 15), dass die remaining_size genau 0x400 wird, wenn die Headergröße subtrahiert wird. Das hat dann den Effekt, dass beim Ersten Senden im dmesg

auftaucht, aber beim zweiten Absetzten des Kommandos kommen die ganzen Daten reingerauscht! Juhuuu! Werde diese Erkenntnis morgen mal in LKML einkippen und sehen was die dazu sagen. Wenn du mir dein Dump schicken würdest könnte ichs auch genau so verändert, dass die Datagramme exakt identisch sind. Wäre interessant was der -75er bedeuted.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Leider kann ich unter Windows nicht mit pcap/Wireshare "capturen", sondern nur mit der Trialversion eines kommerziellen USB-Analyzers. Hier ist der Dump als HTML exportiert: . Paket 1 ist das ":WAV:DATA?", danach folgen immer abwechselnd die Pakete mit der Anforderung neuer Daten (Länge 12 Bytes) und die Antworten des Scopes (Länge 1036 Bytes). Im letzten Paket ist korrekterweise das EOM-Flag gesetzt. (Da die Trialversion in der Menge der Daten begrenzt ist, habe ich hier nur die

Nachtrag: Ich habe Windows gerade dazu gebracht, auch TransferSize=0x7f1 zu verwenden. Seltsamerweise klappt das da auch. Das Scope stürzt nicht ab, die Daten kommen an und korrupte Pakete logge ich auch keine... Dump dazu kann ich gerne nachreichen, aber nicht mehr heute.

Laut include/asm-generic/errno.h wäre das EOVERFLOW.

Christian

Am 25.05.2010 23:39, schrieb Christian Zietz:

...

Wenn Windows unter VirtualBox unter Linux läuft, leistet usbmon gute Dienste. BTDT.

Viel Erfolg, Falk

Am 25.05.2010 23:39, schrieb Christian Zietz:

Ok, vielen Dank. Ich habe deinen Dump mit Hilfe von ein Paar Zeilen Python ins selbe Format gebracht wie meins und dann noch einen kleinen Python-TMC-Parser geschrieben. Die Ausgabe deines Dumps ist hier:

und die meines Dumps:

Was mich dabei sehr wundert, ist dass das Rigol bei mir direkt nach der ersten Nachricht das Byte an Array-Position 9 auf 0x0a setzt (laut Standard ist das reserviert und muss immer 0 sein).

Wäre wirklich interessant!

Hmmm...

Viele Grüße, Johannes

Am 26.05.2010 07:29, schrieb Falk Willberg:

Werd ich mir vielleicht eins installieren müssen, um das auszuprobieren

- jetzt will ich's schon gern wissen.

Wenn man allerdings kein usbtmc im Kern hat, claimed usbfs das Device, mal schaun wie man das umschippert.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Ich muss mich korrigieren, mittlerweile bekomme ich das Scope auch unter Windows zum Absturz und zwar, sobald ich zwei "Read"-Befehle [1] mit einer TransferSize, die nicht durch 4 teilbar ist, direkt in Folge sende. Also zweimal 0x400 geht, zweimal 0x404 auch, zweimal 0x401 führt zum Crash.

Der entsprechende Dump ist in . Paket 10 ist das ":WAV:DATA?", Paket 13 der erste "Read"-Befehl, Paket 18 die Antwort darauf, Paket 19 der zweite "Read"-Befehl. Dann stürzt das Scope ab.

Das bedeutet dann wohl, dass es tatsächlich ein Bug im Scope und nicht im Linux-Treiber ist. Das der unter Windows nicht auffällt, liegt daran, dass dort standardmäßig runde TransferSize-Werte (0x400, 0x100 etc.) zum Einsatz kommen.

Christian

Am 26.05.2010 22:51, schrieb Christian Zietz:

Könntest du mir beschreiben, was du unter Windows konfigurieren musstest, um das Scope zum Absturz zu bringen? Der Rigol-Typ glaubt mir das nach zig Mails hin und her nicht. Erst hat er gesagt, mit Linux testen sie nicht, dann hat er gesagt, mit Windows gehts. Gerade eben flog herein:

Ich glaube nicht dass er das Problem versteht oder sich die Logs angesehen hat bzw etwas damit anfangen kann :-/

Viele Grüße, Johannes

Johannes Bauer schrieb:

Unter Windows nutzt man ja in der Regel das VISA-Framework, um mit dem Scope zu kommunizieren. Zumindest bei Agilents und NIs VISA-Implementierungen ist es nun so, dass ein Aufruf der viRead-Funktion direkt in ein "Read"-Kommando über USBTMC übersetzt wird, wobei die der viRead-Funktion übergebene Buffergröße (genannt "cnt") als TransferSize verwendet wird. Somit ist es also einfach, dem Scope beliebige TransferSize-Werte zu senden. Zwei viRead-Aufrufe mit einem cnt (=TransferSize) von z.B. 0x401 direkt hintereinander (nach dem Senden von ":WAV:DATA?") führen zum Crash des Scopes.

Ich poste heute abend noch ein Demoprogramm, das mein Scope zum Absturz bringt.

Immerhin antwortet man Dir zügig. Darf ich fragen, an welche Adresse Du Dich gewandt hast? Im rcgroups-Forum las man eine Zeit lang von Leuten, die deutliche länger auf eine Antwort von Rigols Support warteten.

Christian

Am 27.05.2010 11:29, schrieb Christian Zietz:

Hm, also irgendwie glaube ich nicht, dass das mit "durch 4 teilbar" zusammenhängt, sondern eher "ist eine Zweierpotenz" - bei einem Puffer von 1024 + 15 stürzt er bei mir ab, bei 1024 + 15 + 1/2/3/4/5 jedoch nicht.

Super, das wäre klasse! Dann können die von Rigol das auch nachvollziehen und fixen es evtl.

snipped-for-privacy@rigol.com - Antwort in weniger als 12 Stunden.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Also, hier ist das Demoprogramm, das mein Scope abstürzen lässt, sowohl im Sourcecode als auch als Executable:

Hinweise:

- VISA wird benötigt, wie für Rigols Ultrascope-Software auch.

- Das Scope muss das erste (oder einzige) über VISA angesteuerte Gerät sein.

- Das Scope muss auf "Long Memory" und "Single Shot" eingestellt sein, damit bei ":WAV:DATA?" genug Daten zusammen kommen. (":WAVEFORM:POINTS:MODE MAXIMUM" ist nicht nötig.)

Die Weitergabe dieses Programms ist natürlich ausdrücklich erlaubt.

Christian

Ich schrieb:

Gerade noch mal aktualisiert, in der alten Version standen in den Kommentaren im Quelltext noch falsche Angaben. (Das hatte natürlich keinen Einfluss auf die Funktion, nun sind aber auch die Kommentare richtig.)

Christian

Ich schrieb:

Nochmal aktualisiert. Jetzt lässt der Code das Scope noch zuverlässiger abstürzen, d.h. auch bei normalen (nicht-single-shot) Trigger und unabhängig von der Wahl der Speichertiefe.

Christian

Am 28.05.2010 21:52, schrieb Christian Zietz:

OK, habe mal wieder eine Antwort erhalten, offenbar hat er dein Programm gar nicht benutzt. Das scheint mit dem nichts zu bringen. Ich versuchs jetzt selbst effizient zu Debuggen.

Hab dafür meine ganze Abneigung versucht zu unterdrücken und mir im Qemu ein XP installiert, damit ich den USB genau überwachen kann (auch als pcap um einen Diff zu machen). Und was soll ich sagen? Ich weiß warum ich das so ungern benutze. Erstmal die Ultrascope Software installiert, ok. Dann den Rigol Treiber für USBTMC. Ging nicht, wird nur als gelb mit schwarzem Ausrufezeichen erkannt. Ins INF geschaut, aha, ist nur für 95 und NT. Also woher krieg ich einen VISA Treiber? Aha, Agilent und NI haben welche. Funktioneiren die auch? Keine Ahnung, ausprobieren. Kann ja nicht so groß sein, der Linux Source ist 28kB.

Agilents Treiber ist knapp 100 MB, NI hat 53. Was zur Hölle?! Oh Mann und immer das ewige gesuche, das macht ja mürbe. Wenn ich das dauerhaft benutzen müsste würd ich das mit den Computern sein lassen, glaube ich. Ist ja eine Zumutung. Das erzähl ich dem nächsten, der mir mit "Windows ist so einfach zu bedienen" kommt.

So, jetzt weiter im Marathon - hoffentlich krieg ich das heute noch zum rennen!

Viele Grüße, Johannes

Am 29.05.2010 20:48, schrieb Johannes Bauer:

AAAARGH. Ich hasse Windows. Und jetzt weiß ich wieder genau, weshalb.

Der Treiber ist installiert, das Rigol wird vom Windows erkannt, auch als DS1000er Serie. Aber Ultrascope sagt "Ne, find ich net".

Hmtja. Da braucht man echt ne verdammte Glaskugel, Logs sind ja völlig überbewertet. Damit kann ein Benutzer ja eh nichts anfangen. Jetzt trink ich ein kühles blondes und versuchs später oder morgen nochmal, sonst schlag ich hier alles kurz und klein.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Windows XP *ist* Windows NT 5.1. Der Rigol-Treiber ist schon für XP geeignet, nur nicht für Scopes der DS1000E/D-Serie sondern nur für ältere Scopes von Rigol. Musste ich aber auch erst herausfinden:

Ja. Beide.

Ich habe mir unterdessen mal die Kernelsources für mein Linuxsystem besorgt, um mit dem usbtmc-Treiber zu experimentieren. Welches Programm nutzt Du unter Linux, um mit dem Scope zu kommunizieren?

Christian

Johannes Bauer schrieb:

Welche Version von Ultrascope verwendest Du. Ich habe mit Version

Christian

Johannes Bauer schrieb:

...

Siehst Du, so war das doch nicht umsonst...

Wenn Du auch nicht auf "Problembehandlung" klicken willst ;-)

Falk

Dave Jones (der den 100MHz Hack publizierte) aus Australien hatte das DS1052 m.W. mit XP in Betrieb.

Johannes: Schreibe ihn doch mal an, er ist normalerweise sehr hilfsbereit.

Joerg schrieb:

Geht ja auch, wie ich bereits schrieb. Ich habe es hier unter Vista und XP am Laufen. Man darf halt nur nicht den Treiber von der Rigol-Webseite nehmen sondern man benötigt VISA (z.B. von Agilent oder National Instruments).

Christian