Gast
#1269348
Hallo Johannes, hier kurz der Link: http://apps.sourceforge.net/trac/welecw2000a/ Gruß, branadic
@Guido Im Datenblatt, dass im Wiki mit dem Flash verlinkt ist, steht was von "Minimum 1 million erase cycle guarantee per sector". Hast also noch ein paar Versuche
Also heute geht es ja richtig ab hier oder? Fortschritte an allen Ecken und Enden, so macht das echt Spaß! Da kann ich auch gleich noch einen nachschieben - Trigger geht wieder. Dann werde ich mal auf Guido und Stefan warten und dann eine schöne runde 0.63 beta zum langen Wochenende rausschieben bevor ich mit dem Rollmode/Shiftmode anfange. Hayo
Gast
#1269355
Hallo, der Streifen bleibt. :-( Ich dachte dir Ursache wäre dieselbe wie mit dem Pixelfheler. Der resulierte daher, dass die Menü-Plane über das Grid kopiert wurde (UI_Plane2). Abhhilfe: Am Anfang von TransferPlanes ändern:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Und in TransferDataPlane_asm_persistant die Loop-Variable von 1460 auf 1000 reduzieren. Der Upload ins Ram hat aber nicht geklappt, da das Oszi immer eine Microsofz-Behandlung gewünscht hat. :-( Falls es sich jemand anschauen möchte, Anhang. @ Stefan: Dann muss ich mir wohl doch keine Gedanken machen, ich war von einem Hundertstel ausgegangen. Gruß, Guido
So Hayo, hier die abgeänderte Datei. Geändert hat sich nur etwas in der READADC_ALL. Zweimal hatte ich den fall, dass sich ein Kanal beim Verschieben vom Nullpunkt vom Nullpunktpfeil proportional verschoben hat. Ein erneutes ADC und DAC-Kalibrieren hat das dann behoben. Denke, dass muss woanderst liegen. Das Rauschen nimmt jedenfalls jetzt nicht mehr zu beim Invertieren.
Alles klar Ihr Beiden. Vielen Dank für die schnelle Lösung. Ich werde das dann mal einfließen lassen. Zum Flash - da gibt es keinen Grund zur Sorge, bis da das Ende der Schreibzyklen erreicht ist sind die Leuchtkathoden vom Bildschirm schon in den ewigen Jagdgründen und es gibt nur noch einen Blackscreen. Das Wegspeichern ist deshalb so häufig nötig, damit das Oszi beim nächsten Start wieder mit den alten Einstellungen starten kann. Gruß Hayo
och eine Erfolgsmeldung - es reißt nicht ab - ich hab den Fehler mit dem Triggercursor am oberen Gridrand beseitigt. Da blieb ja beim Drücken des Default Setup immer eine Leiche irgendwo links oder rechts neben der neuen Position zurück. Ist erledigt - nicht zuletzt dank der jetzt so kurzen Upload Zeiten ins RAM. Hayo
Ach ja zu guter Letzt - kaum noch auszuhalten - der Fehler 139 beim Erzeugen des Objektdumps ist auch Geschichte. So jetzt ist aber gut. Bis morgen also Hayo
Hab jetzt das Perlscriptchen (hoffentlich) OS-unabhängig gemacht. Bei mir unter Linux geht es noch, jetzt müsste nur mal einer unter Windows testen, ob es auch mit ActivePerl und dem Module Win32::SerialPort klappt. Zum Benutzen muss man wie gesagt je nach Betriebssystem das Modul Win32|Device::Serialport installieren. Das geht unter Linux am einfachsten mit dem distributionseigenen Paketmanager (das Paket heisst üblicherweise in der Art wie perl-Device-Serialport oder etwas in der Preislage), und wenn man es da nicht findet, dann in einem Terminal via CPAN (Archiv von Perlmodulen):
1 | |
2 | |
Alle darauf folgenden Fragen immer nur mit Enter bestätigen, dann sollten benötigte Module gleich mit installiert werden. Wie man das unter Windows macht, ist mir gerade nicht klar, da gibt's aber IIRC auch so ein Archiv bei Activestate. Wenn das dann geklärt ist, kann man im Terminal folgendes ausführen (vorausgesetzt, das Script befindet sich in einem Verzeichnis zusammen mit der Tomcat-Datei und man befindet sich auch in diesem Verzeichnis ;-):
1 | |
Portbezeichnung und Dateiname sind natürlich entsprechend anzupassen. /Hannes
Gast
#1269657
Moin Leute, nachdem ich mir gestern beim ersten Versuch des Flashens gleich mal alles geschossen habe, habe ich am Skript noch ein bisschen rumgefummelt. Es sendet nun nicht erfolgreich übertragene Zeilen nochmals zu senden. Da meine serielle Schnittstelle etwas flaky ist und gern mal alle zigtausend Zeichen eines verschluckt, war das auch absolut notwendig, um das Gerät wieder zum Laufen zu bekommen ;) Da ich aber mit der Version weitergebastelt hab, die ich gestern Nachmittag irgendwann geladen habe, sind natürlich die neuesten Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird sich dem noch annehmen. Wichtig: Das Skript enthält KEINE sleeps mehr. Die sollten aber nicht nötig sein, da im Fehlerfalle ja erneut gesendet wird. Ansonsten nochmal mein Aufruf: So viel wie hier aktuell los ist, würde ich es sehr begrüßen, wenn auch der Hayo-Branch der Firmware sowie die tollen Tools die hier entstehen, versioniert werden würden. Ihr seid alle herzlich eingeladen, die vorhandenen Ressourcen des welecw2000a Projekts bei Sourceforge zu nutzen ;) Dann gäbe es (endlich) eine zentrale Anlaufstelle für alle Neulinge (und alten Hasen) und vorallem einen Platz für dauerhafte Dokumentation! Viele Grüße Daniel
Gast
#1269665
Nachtrag: Ok, ein sleep(1) im Fehlerfall ist doch noch drin, das könnte auch noch raus, war nur zu Testzwecken.
Crazor schrieb: > Da ich aber mit der Version weitergebastelt hab, die ich gestern > Nachmittag irgendwann geladen habe, sind natürlich die neuesten > Änderungen noch nicht drin, aber ich schätze, einer der Perl-Profis wird > sich dem noch annehmen. Ok, das werd ich dann mal mergen... /Hannes
Wie sich mein Skript verselbstständigt ist echt cool ;-)
Das endgültige Skript werd ich dann heute oder morgen mit zu der 0.63 beta packen. Hayo
Das wird aber auch unter Windows laufen und zusammen mit einer passenden tomcat.ram ausgeliefert? ;-)
Kurt Bohnen schrieb: > Das wird aber auch unter Windows laufen und zusammen mit einer passenden > tomcat.ram ausgeliefert? ;-) Das ist das Ziel. Je praktikabler das Ganze wird, desto mehr werden es ausprobieren und sich anstecken lassen... Hayo
Gast
#1270408
Hallo Hayo, habe noch den hässlichen Balken beseitigt. Dazu muss in tc_vars.h BOT_PLANE_MIN von 8480 auf 8600 vergrößert werden. Das wird afaik eh nur benutzt um eine Init aus dem Flash zu laden. Gruß, Guido
Gast
#1270524
@ Hayo: Oder noch besser, den teil erst garnicht aus dem Flash laden. Dazu auskommentieren:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
Das Bottom-Area. Gruß, Guido
Aufgemerkt! Es gibt die 0.63 beta. So viele Fixes habe ich noch in keinem Release auf einmal gemacht. Nicht übel. Das komplette Build gibt es ebenso wie die Firmware bei Google Groups http://groups.google.com/group/welec-dso/files Ich habe das beigelegte Perlskript nochmal umbenannt und noch zwei Shellskripte für den Flash und den RAM-Upload dazugetan. Es gibt auch eine neue How to. @Guido Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr dazu gekommen bin mir das anzusehen. Gruß Hayo
Hab jetzt diesen Schreibwiederholversuch da eingepflegt und es unter Linux getestet, das klappt einwandfrei. Will mal sehen, ob ich jetzt fix noch ein Activeperl mit Win32::SerialPort in die VM geballert bekomme und es dort noch schnell testen kann. Oder fühlt sich ein Windowsbenutzer berufen, das mal fix auszuprobieren? /Hannes
Unter WinXP-SP3 überträgt das Script ca. 1 Zeile pro Sekunde am echten RS232. Wird das noch schneller?
@Kurt: welche Variante des Scripts hast du versucht? Die aus dem FW-Archiv? Das Problem mit dem Schreiben von nur einer Zeile pro Sekunbde hatte ich auch schon, das lag am falschen Zeilenende. Muss ich also offenbar für Windows anpassen. Fixe ich schnell, keine Angst, ich bin nur grade noch am Windows-Perl-Installieren ;)
Deine letzte und die von Hayo zuletzt gepostete.
Gast
#1270716
Hallo Hayo, einfach Klasse! Das Triggern geht wieder auf Ch1 am 2012a funktioniert wieder auf positive und negative Flanke auf dem Probe-Ausgang! Gruß Jürgen
Sodele, bei mir klappt das jetzt unter Windows (in einer VM allerdings) und unter Linux mit vollem Tempo. Bitte um Test. /Hannes
Gast
#1270726
Hallo, >@Guido >Deine letzte Änderung hab ich noch nicht eingebaut, da ich nicht mehr >dazu gekommen bin mir das anzusehen. Falls es sich trotzdem jemand ansehehn möchte: auf Basis 0.63. Hoffentlich klappt es bald auch für die Windowsuser mit dem Ramupload. Habe gearde gesehen, dass die Änderungen das Quickmeasure stören, da muss ich wohl noch nachlegen. Als Nächstes schau ich mir aber erst mal die Softbuttons an, die sollten einheitlich aussehen. Gruß, Guido
Hi, ich sehe es regt sich noch was. Bin schon an der 0.64 zugange und baue gerade den Ultra Slow Timebase Modus ein (Shift und Roll). Mal sehen wann ich einen ersten Prototyp zur Verfügung stellen kann. @Jürgen Jupp. So soll es sein. Hayo
Geht immer noch nicht schneller.
Kurt Bohnen schrieb:
> Geht immer noch nicht schneller.
Dann bin ich erstmal ratlos. Muss mir mal nen Rechner mit
Hardware-Serial und Windows besorgen, dann schau ich dort mal.
Wie viele Punkte (oder gar X) siehst du vor dem OK am Ende der Zeile?
/Hannes
2 Punkte
Angehängte Dateien:
-
cmd.jpg
(24 KB)
@Guido Hab mal Deine Demo eingespielt. Ich finde eigentlich die Version mit unterlegtem Balken besser, weil es den UI-Bereich klarer abgrenzt. Hayo
Gast
#1270757
@ Hayo: hmmh, ist natürlich Geschmackssache, mich hat der Balken immer gestört. Nundenn ... Gruß, Guido
Mit Balken finde ich auch schöner. Unter OpenSuse 11.1 in der VirtualBox läuft das Skript rasend schnell durch. ;-)
Ist es normal, dass sich beide Signale exakt in der Schirm Mitte befinden müssen damit die Mathefunktionen korrekt arbeiten? Das Problem gibt es in der 0.62 und der 0.63.
Seit ich den Zero-Shift wieder eingebaut habe (DAC-Offsetverschiebung) ist die Mathfunktion davon betroffen. Hier muß ich noch den neuen variablen Zerolevel einbauen. da ich aber gerade in höheren Programmiersphären schwebe (Shift und Rollmode) muß das erstmal warten ;-) Hayo
@ Hannes Ich hatte das selbe problem wie Kurt unter Windows.
Um den download zu beschleunigen habe ich folgende zeilen geaendert:
53 $serial->read_const_time(1);
83 if ($readcount++ > 1000) {
es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer
read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen
wurden!
Gemessen Zeiten download der version 0.64 mit echter UART:
download ins RAM: 2 min. 40 sek.
download ins FLASH: 2 min. 45 sek.
Martin
Gast
#1270991
beim testen der .63 ist mir ein etwas im delayed modus aufgefallen. gerät: w2024 signal: 1mhz rechteck 10vpp an ch1 main timebase: 100ns/div bei einer delaed timebase von 50ns ist der auswahlbereich um ca 1div nach rechts verschoben im vergleich zu dem was im delayed fenster angezeigt wird. ab einer delayed timebase von 20ns wird im delayed fenster ein völlig anderer bereich des signales dargestellt. hat man die signalaufzeichnung gestoppt und ändert den delayed auswahlbereich, wird das aktuell angezeigte signal gelöscht und eine erneute aufzeichnung gestartet. es ist also nicht möglich, den zoombereich auf ein einmaliges event zu vergrößern oder zu verkleinern.
Martin H. schrieb: > es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer > read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen > wurden! Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut, danke. /Hannes
Gast
#1271155
was mir bei der .63 noch aufgefallen ist, das die messwerte der cursor nicht mehr angezeigt werden.
Gast
#1271219
Moin Moin! Ich weiß net, ob's hier erlaubt ist. Aber ich würde mein Oszi gerne Verkaufen, ist ein W2022A mit 200 MHz / 2 Kanal. Daher erstmal die vorsichtige Anfrage, ob das hier möglich ist.
Dafür gibts in diesem Forum einen Markt! http://www.mikrocontroller.net/forum/markt gruß, brunowe
Hallo, ich habe mir erlaubt, das svn-repository http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/welec/improved/src/ auf den aktuellen Quellcode zu aktualisieren. Können wir uns darauf verständigen, alle Änderungen dort zu hinterlegen? Gruß, Stefan
Johannes Studt schrieb: > Martin H. schrieb: >> es scheint das unter windows (ich verwende ActivePerl 5.8.8) immer >> read_const_time(x) gewartet wird auch wenn genuegend zeichen empfangen >> wurden! > > Nö, dann wäre es bei mir nicht gegangen. Aber der Hinweis ist gut, > danke. Hab da jetzt nochmal bissl rumgegraben. Das Windows-Modul arbeitet auf jeden Fall irgendwie anders als der Linux-Nachbau, es werden (zumindestens hier) nicht bei jedem Leseaufruf die "geforderte" Anzahl Bytes zurückgeliefert. Unter Linux steht bei mir vor dem OK immer genau ein Punkt (ergo genau ein Leseversuch), unter Windows sind es unterschiedlich viele, meist jedoch 2-3. Der ganze Unsinn, den ich da mit Linebreaks verzapft hatte, war völlig unnötig. Hab's jetzt so ungefähr wie Martin gemacht, und das führt auf meinem System zu folgenden Zeiten für das Flashen der 0.63: Linux nativ: 3m15s WinXP in VM: 5m01s Dauert zwar unter Windows immer noch deutlich länger, aber verschmerzbar, denke ich. Die Zeit wird hier bei mir übrigens auch davon beeinflusst, ob ich das cmd-Fenster sichtbar oder minimiert habe. Die Ausgabe der Zeilen scheint ein durchaus erheblicher Faktor zu sein, und offenbar ist da irgendetwas[TM] schlau genug, bei minimiertem Fenster die Ausgabe einfach zu unterdrücken. /Hannes
Jetzt läuft er auch unter Windows super!
Was ist los? Keiner mehr auf? Rollmode läuft, feile aber noch am Timing. Shiftmode ist in Vorbereitung. Hayo
Klar bin ich noch wach. Warte ja auf die nexte Version... :D
Gast
#1271576
@ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der Einzige, bei dem bei Invertierung der Signale auch die ADC und DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir etwas knifflig vor. Gruß, Guido
@Guido Das hab ich mir noch nicht so im Detail angesehen. Bist Du sicher, dass die Werte invertiert werden müssen? Das wäre dann ja Stefans Baustelle oder? Hayo
Guido schrieb: > @ Hayo: Also gut, du hast es so gewollt. Bin ich eigentlich der > Einzige, bei dem bei Invertierung der Signale auch die ADC und > DAC Kalibrierwerte invertiert werden müssten? Stelle ich mir > etwas knifflig vor. > > Gruß, Guido Hallo, kannst du das etwas genauer erklären? Meinst du vielleicht die leichte Verschiebung des Signals um den Nullpunkt, wenn der Eingang kurzgeschlossen ist? Die Invertierung läuft folgendermaßen ab: - Abzug des (AD-spezifischen) DAC-Korrekturwertes vom Eingangswert - Berechnung der Differenz zum ZeroLevel - Fallweise Addition oder Subtraktion der Differenz zum Zerolevel (jenachdem ob davor drunter oder drüber) Vielleicht stimmt der Offsetabgleich noch nicht ganz, Vielleicht kann Hayo testweise eine zusätzlichen iterativen Abgleich einführen, der den Offset solange verändert, bis das normale und invertierte Signal die "gleichen" Werte haben. Ich kann erst wieder ab Montag oder Dienstag testen. Deshalb kann ich es nicht selber ausprobieren. Gibt es eigentlich die Möglichkeit eine Zeitmessung über einen der Timer einzubauen? Mich würde interessieren, welche Routine welche Zeit braucht. Evtl. lässt sich die Geschwindigkeit an der Stelle dann ja erhöhen. z.B müssen ja nicht immer alle 4000 Werte umkopiert werden, wenn das Gerät läuft. Erst wenn auf Stop gedrückt ist, werden z.B alle Daten aufbereitet. Gruß, Stefan
@ Hannes: Habe deine abgeanderters script ausprobiert bei mir benötigt es ca. 5 min. 20 sek. und ich sehe immer zwei Punkte vor dem OK (bei meiner Version waren es drei!) Um das besser zu verstehen habe ich mir die DOC von Win32::SerialPort angesehen, di inizialisiert immer auch zwei weitere Parameter (read_interval(x) und read_char_time(x)). Ich habe diese versuchsweise in deinem Script ergaenzt, und siehe da: nur noch ein Punkt vor dem OK! Des weiteren ist es so möglich zu deine original Werten zurueck zu gehen. (read_const_time(1000) und 10 versuche). Download ins RAM der 0.63 in ca. 2 min. 5 sec. Download ins Flash der 0.63 in ca. 2 min. 12 sec. Im Anhang meine Version (nur unter Windows getestet) Martin
Martin H. schrieb:
> Im Anhang meine Version (nur unter Windows getestet)
Super Sache. Ich werde das dann später mal unter Linux testen, hab heute
leider keinen Brückentag.
/Hannes
Bei mir gehts unter Linux (debian) nicht wegen read_interval:
1 | |
Entweder ist das unter Linux nicht dabei (Paket libdevice-serialport-perl), oder noch in einem anderen Paket... Vielleicht liegts auch daran: "Write timeouts and read_interval timeouts are not currently supported." aus http://www.justanotherperlhacker.com:8911/cpan/Device::SerialPort/Device::SerialPort_-_Linux_POSIX_emulation_of_Win32::SerialPort_functions..html Leider habe ich nur rudimentäre Perl-Kenntnisse....
Noch ein Nachtrag: Der GERMSloader.pl braucht bei mir für TomCat.ram (0.63) 2:48, also unter 3 Minuten. Das ganze unter Debian Linux mit USB-RS232 Konverter.... Dabei kommen 3-4 mal mehr als ein Punkt vor dem OK (bis zu 4)...
Gast
#1271867
Hallo Hayo und Stefan, ein Bild sagt mehr ... Der ADC- und DAC-Abgleich funktionieren bei mir sehr gut. Invertiere ich das Signal (Kanal 2) wird es unschön. Wenn ich damit neu kalibriere, sieht Kanal 2 so gut aus wie Kanal 1. Dann die Invertierung wieder aus, sieht wieder aus wie im Bild. Ich vermute, dass da die Abgleichwerte invertiert werden müssen, was eigentlich in der UI-Funktion erfolgen sollte. Bin ich wirklich der Einzige, bei dem das so stark ist? Gruß, Guido
Angehängte Dateien:
-
rausch_inv2.jpg
(55 KB)
Guido schrieb:
> Bin ich wirklich der Einzige, bei dem das so stark ist?
Definitiv ja! Bei mir ist das Signal immer gleich egal ob invertiert
oder nicht. Stefan hat hier also ganze Arbeit geleistet.
Aber deine Teilung der Bottom Plane sieht interessant aus.
Hayo
@Hannes + Martin Ich möchte zusätzlich zu Linux auch unter Win XP Firmware laden. Was brauche ich außer dem neuen Perlskript noch zusätzlich? (irgendeine favourisierte Perlversion, Module?) Hayo
Gast
#1272108
>Aber deine Teilung der Bottom Plane sieht interessant aus.
Hmmh, ist die unveränderte FW 0.63. Ich sage ja, dass ich damit
irgendwie noch nicht zufrieden bin. ;-)
Muss mir später mal die Abgleichwerte der ADC anschauen.
Gruß, Guido
@ hayo Ich verwende ActivePerl 5.8.8 (habe ich von http://www.oldapps.com/Perl.php geladen). Zusaetzlich benoetigst du das Modul Win32:SerialPort Am einfachsten ist die Installierung via Perl Package Manager (PPM): 1. Neues Repository eintragen via Edit -> Preferences und den Reiter Repositories Name: Bribes Location: http://www.bribes.org/perl/ppm (ein ausfuerliches help findest du unter http://www.bribes.org/perl/ppmdir.html) 2. Jezt kannst du das Modul Win32-SerialPort installieren: Zeile mit Win32-SerialPort suchen und an klicken Action -> Install Win32-Serialport 0.19 Das sollte alles sein. Martin
Ich habe mal zwei Batchdateien geschrieben. Dann kann man z.B. eine Verknüpfung auf dem Desktop anlegen und den Flashvorgang per doppelklick starten.
Ramloader
@ Hayo Ups habe vergessen zu erwähnen das du am Ende den grünen Pfeil auswählen musst sonst wird das Modul nicht installiert!! Martin
Packagemanager für Windows??? Hab ich das korrekt verstanden? Hayo
Ich hatte zuerst ActivPerl installiert: http://www.activestate.com/activeperl/ Und anschließend diese Datei mit WinRar enpackt und das Readme befolgt: http://search.cpan.org/CPAN/authors/id/B/BB/BBIRTH/Win32-SerialPort-0.19.tar.gz
@ Hayo Ja einfach vom dos prompt aus "ppm<enter>" eingeben oder ueber START usw. auswählen. (nach dem du ActivePerl installiert hast) Martin
Hallo Guido, dein Phänomen ist mir neu. Und ich kann es mir auch noch nicht erklären. Hast du probiert, nochmal alle Einstellungen zurückzu setzen und den kompletten Abgleich neu gemacht? Poste mal die DAC-Korrekturwerte für beide Kanäle und ohne Invertierung und mit Invertierung. Was passiert bei Averaging? Und warum schaut deine Bottom-Plane so komisch aus? Gruß, Stefan
Gast
#1272286
Hallo Stefan, die ADC-Korrekturwerte: Kan1, 3110; Kan2. 3140; DAC-Korrekturwerte: Kan1.77/94/70; Kan2. 15/96/76. Die bleiben bei Invertierung gleich. Averaging summiert die Störungen auf, sonst ändert sich nichts. Was habt ihr nur mit meiner Bottom-Plane? Ich hab da nichts geändert (noch!!!). Wie sieht die denn bei euch aus? Gruß, Guido
Vielleicht solltest Du mal ein komplettes Backup einspielen. Mir scheint da ist was vergurkt. Hayo
Gast
#1272332
Hallo Guido, die Bottom-Plane sollte in etwa so aussehen: http://www.welec.de/graphics/images/W2_100u_50mV.gif Zumindest scheint die bei allen anderen so auszusehen. Beste Grüße, branadic
Gast
#1272346
Hallo branadic, besten Dank, jo, ist bei mir anders. @ Hayo: Gute Idee! Die 1.3 von welec hat nichts geändert, probier jetzt mal mein Backup, sonst muss ich mal den alten Thread durchwühlen. Btw.: Das Flashen über USB ist schnarchlangsam ;-). Gruß, Guido
Gast
#1272426
Hallo, habe jetzt die Alpha 1.4 geflasht und damit eine saubere Bottom-Plane. Anschließend die Beta 0.63 geflasht und jetzt klappt es. Kann ich mir zwar nicht erklären aber man muss ja nicht alles verstehen. Danke Hayo für den Tip, sorry Stefan, ich hoffe ich habe dir nicht allzuviel Arbeit gemacht. Gruß, Guido
Gast
#1272428
Hallo zusammen, fühlt sich einer der Perl-Terroristen im Stande die Vorgehensweise zum Flashen des Gerätes unter Windows noch mal genau aufzuführen? Also was muss installiert werden, wie geht man vor. Ich habe dafür einen extra Bereich im Trac unter Firmware eingerichtet: http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload Ich würde das gern wieder für alle festhalten wollen. Beste Grüße, branadic
Guido schrieb: > Die bleiben bei Invertierung gleich. Averaging summiert die > Störungen auf, sonst ändert sich nichts. Meinst du damit, dass sie gleich bleiben, auch wenn du im invertierten Zustand den Abgleich neu ausführst? Wenn nicht, dann mach das mal bitte. Also erst normal die Werte, dann invertieren, wieder abgleichen und nochmal die Werte notieren. Ich könnte mich täuschen, aber deine DAC-Werte erscheinen ungewöhnlich hoch zu sein. Gruß, Stefan
War wohl zu langsam beim tippen ;-)
Bernhard M. schrieb:
>1 | |
2 | |
Hab diese beiden Parameter jetzt OS-abhängig gemacht. So geht es hier unter Linux und in der XP-VM auch einwandfrei. Vielleicht ist das ja jetzt ein Stand, der möglichst vielen Hardwarevarianten gerecht wird. :D Linux: 3:14 Win-VM: 3:42 /Hannes
Gast
#1272483
Hallo, nochmal ausdrücklich: Sorry Stefan! Wäre der Fehler mit der Bottom-Plane nicht gewesen, hätte ich ewig suchen können. Damit tauchen aber neue Probleme auf: Ich weiß jetzt, warum ihr den Balken (der jetzt ja keiner mehr ist) besser findet. Die Menü-Routinen sind völlig buggy und dieses wird durch einen Flashload einfach überbraten. Resultat (irgendwer hatte es schon gemeldet, ich sehe es erst jetzt) ist, dass für Cursor oder QuickMeasure die Messwerte nicht mehr angezeigt werden. Das habe ich schnell per Fallunterscheidung gelöst, jetzt habe ich die Pixelfehler wieder. Da muss mal grundsätzlich aufgeräumt werden, ich kümmere mich darum. Gruß, Guido
@Guido Alles klar, super dass Du Dich drum kümmerst. @Hannes Klasse mit dem Perl Skript. Bin noch nicht zum Testen gekommen da wir dieses Wochenende Besuch haben, aber die neueste Version wird mit aktualisierter How to in der nächsten Beta dabei sein. Ansonsten auch noch Dank an alle die wie Branadic zur Dokumentation beitragen, denn das Thema wird langsam so vielschichtig dass man leicht den Überblick verliert, insbesondere als Neuankömmling. Zur aktuellen Entwicklung: Bin immer noch am Rollmode zugange, ist schon ganz nett anzusehen, aber das Timing ist etwas widerborstig. Vorabdemo gibt es in Kürze. Das Konzept und die aufgetretenen Probleme werde ich dann dem Wiki zuführen. Guats Nächtle Hayo
Hi, Ihr Perlen, Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die Meldung, dass das DSO nicht antwortet... :-( Sowohl realer Port am PC als auch Konverter am Laptop bringt nichts. Für einen Tipp wäre ich dankbar. (Bei den Porttests bekomme ich auch nur ein durchwachsenens Protokoll - ärgerlich...) Michel
Gast
#1272613
Hallo Michel, ich habe bisher zwar nur mit dem WelecUploader geflasht, aber bei mir hat es bisher auch maximal 25min gedauert, bis das neue FlashFile im Gerät war. Zum Germsmonitor: Es ist notwendig die beiden Softbuttons einen Moment lang gedrückt zu halten (so etwa 2-3sec. mach ich das immer, um sicher zu gehen, dass die Übertragung richtig initialisiert wird), nachdem man den WelecUpdater zum Upload bewegt hat. Einfach nur kurzes Drücken wird dich nicht zum Erfolg bringen. Wie das bei der neuen Uploadmoglichkeit ist kann ich dir nicht sagen. Gruß, branadic
Gast
#1272643
Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide Tasten drückt und dann die Rechte eher los lässt als die Linke... Da reicht es dann auch nur etwa eine Sekunde zu drücken.
Michael W. schrieb: > Ich bekomme den Germsloader einfach nicht zum laufen - jedesmal die > Meldung, dass das DSO nicht antwortet... :-( Das Problem hatte ich allerdings auch schon. Das Win32::SerialPort-Modul scheint den Port nicht korrekt zu initialisieren (bzw. ich tu es nicht richtig mit dem Modul, je nachdem, wie man es sehen möchte :D). Ich musste bisher schon ab und zu erst mit der WelecUpdater.exe einfach einen Upload beginnen, nach ein paar Zeilen abbrechen und dann den Script starten. Habe das bisher auf die Kombination aus XP in einer VM und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist, werde ich das nochmal untersuchen. michaelk schrieb: > Bei mir klappt der Start des Germsmonitor ganz gut, wenn man beide > Tasten drückt und dann die Rechte eher los lässt als die Linke... Da > reicht es dann auch nur etwa eine Sekunde zu drücken. Klasse. Klappt hier auch einwandfrei. /Hannes
Auch bei mir scheint der Port nicht richtig initialisiert zu werden. Dann stelle ich kurz mit Hyperterminal eine Verbindung her und beende sie direkt wieder. Danach funktioniert auch das Skript wieder. PS: Mein 2024 ist immer noch nicht da. Ich hatte das verfusselte Gerät am 9.5 zurückgeschickt. Seit dem 14.5. sollte das neue unterwegs sein. Zwei Anfragen wegen der Trackingnummer blieben unbeantwortet. Montag werde ich bei ebay den Artikel als nicht erhalten melden.
Johannes Studt schrieb: > Script starten. Habe das bisher auf die Kombination aus XP in einer VM > und USB->RS232-Adapter geschoben. Falls das eher generischer Natur ist, > werde ich das nochmal untersuchen. Man sollte sich wirklich mal mit Dokumentationen befassen. Ich glaube, dass da bisher was fehlte. ;) @Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es auf jeden Fall hingehauen. /Hannes
Leider nicht besser.
Tse, elende Computertechnik. :D Dann bleibt halt, bis da mal einer den wirklichen Fehler erkannt hat, nur der Umweg über die Initialisierung mit Hyperterminal. Wenn diese Krücke in der Dokumentaion mit auftaucht, wird sich sicher schnell ein betroffener Perlkundiger finden, der das dann mal wirklich repariert. /Hannes
Ganz so schlimm ist es ja auch nicht. Die initialisierung muss man ja immer nur jeweils ein einziges mal nach dem start des PCs machen.
... Satatn Ziege !
Das ist ja wirklich schnell - Junge-Junge! Gefühlt keine 2 Minuten!
Bei mir hat's jetzt hingehauen. Besten Dank nochmal. So macht ein Flash
doch mal Spaß.
Werde ich mir also den Updaten vornehmen und mal sehen, ob ich das mit
dem auch hinbekomme...
Kann mir jemand diese Zeilen erklären:
- if ($line =~ /^#.*/) {
- while ($buffer !~ /\+/) {
Ich würde gerne den Updater umschreiben/aktualisieren. War in Lazarus,
oder?
Michel
Gast
#1272931
@ Johannes Studt : Perl kenne ich zwar nicht, aber unter Windows muss man meist die Flags des DCB noch auf 0 setzen. Z.B. $serial->flags(0) oder so ähnlich. Die Flags sind hierbei LongInt. Gruß, Guido
>- if ($line =~ /^#.*/) { >- while ($buffer !~ /\+/) { 1.Zeile: Klammer ausführen, falls keine #-Zeichen am Anfang der Zeile vorkommt 2.Zeile: Schleife solange ausführen bis ein +-Zeichen zurück kam. Perl ist schon eine geile Sprache ;-)
Stefan E. schrieb:
> Perl ist schon eine geile Sprache ;-)
ACK!
Johannes Studt schrieb: > @Kurt bzw. $ANY_WIN_USER: bitte probier das jetzt mal, ohne vorher mit > HyperTerminal die Schnittstelle zu initialisieren. In meiner VM hat es > auf jeden Fall hingehauen. Hallo Hannes, Bei mir ist nun auch die Initialisierung in Ordnung. Der unterschied laesst sich leicht testen. 1. COM Port mit einem Terminal program (z.b. Teraterm) auf eine andere Baudrate stellen (z.b 1200 Baud). 2. Download mit GERRMSLoader.pl versuchen: --> das alte script scheitert --> mit dem neuen get's! Martin
Gast
#1274414
Moin, der aktuelle GERMSloader ist echt super! Funktioniert immernoch mit meiner gammeligen Schnittstelle perfekt (drei oder vier retries, geht eigentlich). Einzig das letzte Datum in der Flash-Datei (S804852AFC50) funktioniert nicht. Eventuell sollte noch eine speziellere Behandlung für S8-Records eingebaut werden? ;Daniel
>Einzig das letzte Datum in der Flash-Datei (S804852AFC50) >funktioniert nicht. Das Oszi schickt hier nichts mehr zurück. Deshalb wartet das Skript. Gehen tut es aber trotzdem. Kann man aber abfangen, wenn man will. Habe nur gerade keine Zeit, dass anzupassen. Ist im Prinzip sogar schon drinnen, nur wurde es im Laufe der Entwicklung an die falsche Position geschoben ;-) Stefan
So, jetzt wieder mit Enderkennung. Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine Versionsnummer verpasst. Stefan
Stefan E. schrieb: > So, > jetzt wieder mit Enderkennung. > Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine > Versionsnummer verpasst. > Hallo Stefan, Meiner meinung nach war die end Erkennung vorher besser platziert (so wird sichergestellt das auch die letzte Zeile richtig übertragen wurde). Was fehlte ist eine Behandlung des S8 records (S8 bedeutet "Start programm with 3 Byte Address" das bedeutet dass der GERMS Monitor verlassen wird) Ich habe das ergaenzt (V1.0.1) Martin
Ups habe den Anhang vergessen! Martin
Letzten Endes ist die Zeilennummer als Endkriterium eh Käse, weil nie mehr kommen kann als der Inhalt der Flashdatei. Darum ist die Behandlung des S8-Befehls als Abbruch-Kriterium sicher das Sinnvollste. Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder anderweitig an der Antwort hindern? /Hannes
Johannes Studt schrieb: > Gibt es noch mehr Befehle als nur S8, die das DSO rebooten oder > anderweitig an der Antwort hindern? Tja GERMS steht für G (go) E (erase) R (relocate) M (memory) S (srec) ==> G ist auch ein Kandidat ohne Rückkehr und natürlich S7 (4 Byte Startadresse) und S9 (2 Byte Startadresse) Gruß, Günter
Hallo, ich spiele gerade am Kantentrigger rum. Habe den Kanal 1 mal umgestellt. Kanal 2-4 sind unverändert. Ich finde, das Einstellen des Triggerpegels funktioniert schon deutlich besser. Dazu ist zu beachten, dass bei aufsteigend getriggerter Flanke, der obere Rand eines Signal gut erkannt wird und der untere nicht. Bei negativer Flanke verhält es sich genau umgekehrt. Außerdem trifft die Flanke noch nicht den eingestellten Zeitpunkt. Das kommt auch noch ;-) Bitte mal rückmelden, ob es bei euch auch besser ist. Ich habe es bis jetzt nur mit dem internen Signalgenerator getestet. Vielleicht kann jemand mal andere Signalformen testen.
Hi Leute, um keine Langeweile aufkommen zu lassen hier schon mal die versprochene Rollmode-Demo. Der Rollmode setzt automatisch bei Timebases >= 5 S/Div ein. Wenn Ihr kein geignetes langsames Signal habt könnt Ihr durch Drehen am Zerolevel eine quasi Flanke erzeugen die dann den Verlauf des Signals zeigt. leider ist das Timing immer noch etwas widerborstig wie Ihr evtl. sehen werdet. Der Shiftmode ist in Arbeit und kommt demnächst. Trigger und Memoryscrolling stehen in diesen Betriebsmodi nicht zur Verfügung und sind meines Erachtens auch eher überflüssig. Gruß Hayo
Gast
#1275641
Moin, hab's gerade runtergeladen und der Downloadzähler ist immer noch bei 0 ? hmmm
Ich sehe eine 4! Hayo
@Stefan wenn Du mit der Triggererkennung weiterkommst, poste mal das Coding, dann kann ich das in die nächste Beta mit einbauen. Wie Du sicher gesehen hast, hab ich an den Stellen auch schon meine Duftmarke gesetzt... Hayo
Ach ja, die Verschiebung des Triggerzeitpunkts findest Du unter "TOC" (TriggerOffsetCalc), wie der Programmierer das genannt hat. Gruß Hayo
Gast
#1276226
Hallo Hayo, ich schicke dir bei Gelegenheit mal meine Änderungen. Hast du es mal probiert, ob es bei dir auch besser funktioniert? Ich habe die Berechnung für das Triggerschwellenregister mal neu formuliert. Hier muss doch der Schwellwert in der Größenordnung, wie der ADC im eingestellten Spannungsbereich Werte liefert, gespeichert werden (also z.B. zwischen einen Wert zwischen 100 und 160)
@Sefan Da bist Du auf dem richtigen Weg. Das stand bei mir auch noch auf der Liste, aber man kommt ja zu nichts. Und zwar wollte ich statt des festen Wertes, der definitiv falsch ist, mal die Berechnung des Zerolevels verwenden so wie ich ihn in Hardware::ReadOut_Signal() zur Berechnung des Ground-Coupling verwendet habe: Virtual_Zero = ADC_ZERO + int((float)Virtual_ZeroLevelCH1 / scale_factor[Selected_Voltage_CH1]); Zum Vergleich sinngemäß die nicht funktionierende Originalroutine die ich ersetzt habe: Virtual_Zero = (ZeroLevelCH1 + 64) >> 1 So ähnlich sieht das ja auch beim Triggerlevel aus. Daher vermute ich mal das es damit schon getan sein sollte. Bin allerdings noch nicht zum Testen Deiner Source gekommen, da ich in den letzten Tagen etwas eingespannt war und nur gestern abend schnell mal die Demo rausgehauen habe. Gruß Hayo
Bin heute erst recht spät wieder zu hause, vielleicht hast Du bis dahin ja schon ein Ergebnis. Werd mich dann mal melden. Hayo
Sodala Hayo, habe meine hardware_t.cpp in SourceForge hochgeladen. Änderungen sind in UpdateTrigger, Handle_ADC, und in FindTrigger zufinden. Man könnte die Werte, die in FindTrigger und UpdateTrigger jetzt berechnet werden auch global zwischenspeichern. Bin mir aber nicht sicher, ob sich das für die Geschwindigkeit her lohnt. Ich bin jedenfalls ganz zufrieden. Er triggert sauber, auch auf den Überschwinger den der interne Rechteckgenerator an der Flanke liefert. By the way, ich habe in SourceForge mal in die tc_vars.h eine Reihe defines für MenuStatus eingefügt. Kannst du die per Suchen/Ersetzen in die Dateien einfügen? Ich werde sonst verrückt ;-) Und wenn ich das mache gibts nur ein Versionschaos, weil ich nicht weiß, wo du gerade werkelst. Gruß, Stefan
Gast
#1276750
hallo @stefan ich habe deine änderung mal getestet. sieht gut aus. jetzt passt die triggerung auch zu den triggermarken. es ist mir jedoch etwas aufgefallen. getestet mit dem calib. rechteck. mit aktivem autotrigger lässt sich nur bis zu einer zeitbasis von 200us triggern. bei schnelleren zeitbasen funktioniert die triggerung nich mehr. es ist also nicht möglich, sich die steigende oder fallende flanke eines rechtecks genauer anzuschauen. im normalmodus des triggers funktioniert es. @hayo und guido ich hatte es weiter oben schon mal geschrieben als die .63 rausgekommen ist. glaub aber es ist damals in der diskusion um das perl script untergegangen. es ging um die, seit der .63 fehlenden, werte der readout cursor und um die merkwürdige verschiebung im delayed modus. bis 50ns wird das delayed signal, in bezug auf den auswahlbereich, etwas verschoben dargestellt. ab 20ns wird offenbar ein komplett falscher speicherbereich ausgelesen. das delayed signal passt dann gar nicht zum auswahlbereich und wenn man den auswahlbereich weiter nach links verschiebt, werden irgendwelche konstanten daten aus dem ram im delayed fenster angezeigt. übrigens zzt. lässt sich der build aus dem svn nicht compilieren weil in tc_vars.h die deklaration von iScale_Factor auskommentiert ist. das array wird aber in der InterpretUART-funktion benötigt. gruß sunny
@ sunny sorry, mein Fehler. Hab eine alte Datei verarbeitet. Etz müsste es wieder passen. Ich habe bis jetzt nur mit dem normalen Trigger getestet. Auto muss ich dann morgen mal probieren. Gruß, Stefan
Gast
#1276786
Hallo, @ sunny: habe oben schon geschrieben, dass es bei mir jetzt auch sichtbar ist und bin dran (Flash läuft gerade). Falls ich es hinbekomme, muss ich erst nocht testen, welche Änderungen nötig sind. @ stefan: ah, dann probiere ich ev. später auch noch mal, ich habe mit den Syntaxfehlern kapituliert. Gruß, Guido
Hi Jungs, bin grad zu hause eingetrudelt. Hier tut sich ja in letzter Zeit geradezu erschreckend viel. Bin ich aus den letzten Monaten gar nicht gewöhnt. @Stefan Ich werd mir Deine Änderungen morgen mal zu Gemüte führen und einbauen. Evtl. werd ich schon früher eine neue Beta raushauen, damit die Änderungen für alle verfügbar sind und wir auf der gleichen Basis weitermachen. Die Perlskriptecke war ja auch recht aktiv. Da kommt wieder eine Menge zusammen im nächsten Release. @Sunny Nein die Anmerkungen sind nicht untergegangen. Hatte nur noch keine Zeit. Ich denke an den fehlenden Cursorwerten ist Guido dran, da das wohl direkt mit den Änderungen an der Plane-Größe zusammenhängt. Die Zeitverschiebung des Delayed-Signals hab ich schon länger im Auge, hab dem aber keine so hohe Priorität zugeordnet. Gruß Hayo
Gast
#1276933
Hallo, hab die Probleme bis auf eine Pixelzeile reduziert und die kriege ich auch noch hin. Dann fange ich noch mal mit einer sauberen Beta 0.63 an, um die Änderungen auf das notwendige Maß einzuschränken. Also, morgen oder übermorgen. Gruß, Guido
@all Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger Kommentar dazu gekommen ist. Liegt es daran dass - die Funktion eher uninteressant ist? - Ihr kein geeignetes Testsignal habt? - Ihr nicht so richtig wißt um was es geht? - Ihr mit anderen Themen beschäftigt seid? Gruß Hayo
>Ich bin etwas erstaunt, dass seit der Rollmodedemo kein einziger >Kommentar dazu gekommen ist. Liegt es daran dass >- die Funktion eher uninteressant ist? >- Ihr kein geeignetes Testsignal habt? >- Ihr nicht so richtig wißt um was es geht? >- Ihr mit anderen Themen beschäftigt seid? Habs sogar gestern noch ausprobiert, dann aber wohl vergessen zu erwähnen. Hat bei mir gut geklappt. Was noch abgefangen werden muss ist, dass man nicht den Trigger-Modus auf "normal" stellen können darf. Gruß, Stefan
Hayo W. schrieb: > - Ihr kein geeignetes Testsignal habt? > - Ihr mit anderen Themen beschäftigt seid? Sorry. ;-) Aber am Wochenende komm ich sicher dazu, mal wieder was zu machen. /Hannes
ich frag nur weil ich gerade die Shift-Funktion eingebaut habe und es ja sein könnte dass es da Änderungsvorschläge gibt oder so. Hayo
@Stefan Ja Du hast recht, mit dem Triggermode muß ich mir was einfallen lassen - und genau das meinte ich, das war mir nämlich noch gar nicht aufgefallen. Danke Hayo
Hi, mal ein paar simple Fragen zum Scope, bzw. Messen: Gestern Nacht habe ich mal ein wenig die höheren Frequenzen an dem W2024A getestet. Ich hatte eine Schaltung mit 20 MHz Quarz am Oszi (Pic Brenner für USB von Sprut): - Das Signal am Quarz war beinahe sinusförmig, erwartet hätte ich eher ein Rechtecksignal. Allerdings habe ich keinerlei Erfahrungen und vorher nie ein Signal am Schwingquarz gemessen. Außerdem war die Amplitude sehr niedrig, 500 oder 600 mV, bei 10:1 Tastkopfeinstellung sind das dann ja nur 50 bzw. 60mV. Erwartet hatte ich TTL-Pegel oder wenigsten die Pegel für 3V Logik. Liegt die Sinusform an den kleinen Kerkos am Quarz? - Das Signal hatte ich mit der Tastkopfeinstellung 10:1 gemessen. Als ich auf 1:1 umgestellt hatte und die Empfindlichkeit am Scope entsprechend in die andere Richtung geändert hatte, bekam ich kein Signal auf den Schirm. Erwartet hatte ich das gleiche Signal oder höchstens in der Amplitude unterschiedlich... Auch hier muss ich sagen: vorher kaum/keine Erfahrungen mit dem Messen und dem Ändern der Tastkopfeinstellungen. Habe ich irgendwo Denkfehler? Wenn ich heute Abend wieder zu Hause bin, könnte ich einen Screenshot posten. Michel
Gast
#1278614
Hallo Michael, du hast tatsächlich einen Denkfehler. Der Tastkopf hat keinen Verstärker, sondern einen "Abschwächer". Wenn man den Tastkopf auf 10:1 stellt, dann wird dein gemessenes Signal bei 1:1 Einstellung im Gerät um den Faktor 10 kleiner dargestellt. Abhilfe schafft hier die Umstellung des betreffenden Kanals auf 10:1, dann wird dein Signal wieder umgerechnet und mit "realer" Amplitude dargestellt. Aus einem Quarz kommt vereinfacht angenommen ein sinusförmiges Signal. Tatsächlich besteht das Signal jedoch aus einem komplexen Frequenzspektrum. Was du zu meinen scheinst ist ein Quarzoszillator. Hier befindet sich noch eine aktive Schaltung unter dem Gehäuse, die für das rechteckförmige Signal bestimmter Amplitude sorgt. Gruß, branadic
Gast
#1278674
Hallo Michael, als Ergänzung zu branadics Erläuterung noch: Im 1.1 Betrieb hat der Tastkopf ca. 40 pF Eingangskapazität. Wenn du das direkt an den Quarz legst, reißt die Schwingung wahrscheinlich ab. Gruß, Guido
@Stefan Bin gerade dabei Deine Änderungen zu sichten und einzubauen. Sehe ich das richtig, dass Du bei ReadOut_Signal() einen Parameter gelöscht hast weil er überflüssig war? Hayo
Gast
#1278919
Hallo Hayo, siehst du richtig. Der Parameter kam in der ganzen Funktion nicht vor. Kommt auch kein Compilerfehler und es geht immernoch. Also weg mit den Altlasten ;-) Stefan
Alles klar! Wie verwurstet das Coding war kann man auch daran sehen, dass trotz zahlreicher Neuerungen von mir das Coding immer kleiner geworden ist durch die ganzen Löschungen und Redesigns. Trotz einiger Aufräumaktionen gibt es immer noch zig nicht benutzte Variablen und Funktionen. Ein weiterer Kandidat sind die Routinen für Timer 1 mit dem eigentlich der Autotrigger-Timout gesteuert werden sollte. Nach meinen derzeitigen Erkenntnissen wird das aber überhaupt nicht genutzt. Ich werde da noch mal weiter prüfen und gegebenenfalls deaktivieren. Gruß Hayo
Jo, da gibts noch eine ganze Menge Sachen, die einfach krank sind. Auch die ganzen einzelnen Konstanten, die für alle Kanäle einzeln angelegt sind. Wie blöd ist das eigentlich. Der Code würde sich mindestens auf die Hälfte reduzieren, wenn der Kerl an der einen oder anderen Stelle ein Array verwenden würde. Am besten finde ich ja den Kommentar in der ursprünglichen Source: >TMW: "Some bugs found, not easy to understand software structure" >TMW: "All to be improved!!!" Stefan (THW ist das Kürzel des Namensgebers der Firma)
Ich denke die Aussage "Some bugs found" trifft das Ausmaß der Sache nicht so ganz... Das mit den nicht verwendeten Arrays hat mich auch schon genervt. An einigen Stellen hab ich das auch schon geändert im Rahmen der DAC und ADC-Kalibrierung. Aber es sind zu viele solcher Baustellen um es auf einmal zu machen. Also weiter Stück für Stück. Gruß Hayo
Gast
#1279153
Hallo Leute, ich möchte gern noch mal nachfragen, ob jemand noch einmal das genaue Vorgehen für den Flash/RAM-Upload unter Windows und Linux zusammenfassen kann. 1. Was für Tools werden benötigt? 2. Wie ist die Reihenfolge beim Upload? Ich würde es natürlich begrüßen, wenn der- oder diejenige dies direkt auf SF erledigen würde, damit alle Leute international etwas davon haben und es auf der Projekthomepage gebannt ist. Wir sind nach wie vor bestrebt mehr und mehr Übersichtlichkeit in die Projekthomepage zu bekommen und ich denke wir sind da auf einem recht guten Weg. Ihr könnt euch ja selbst davon überzeugen und seid herzlich eingeladen dabei auch mitzuwirken, sei es durch Beiträge oder Verbesserungsvorschläge. Vielen Dank, branadic
Gast
#1279165
Hallo Hayo, ich hoffe, dass die Pixelfehler jetzt endgültig behoben sind. Es sind nur kleien Änderungen nötig, wie du dem Anhang entnehmen kannst (sieht nur so lang aus, weil ich einfach Codeteile kopiert habe um Suchbegriffe zu liefern). Alle Änderungen in hardware_t. Gruß, Guido
Ich werde für die nächste Beta meine "Beipackzettel" dahingehend erweitern. Dann braucht nur noch einer den Text der englishen Fassung ins SFN zu kopieren. Ist das ok? Apropo, mein letzter Stand bezüglich GERMSloader-Skript war 1.0.2 - ist das der aktuelle Stand? Hayo
Gast
#1279175
Hallo Hayo, das wäre in jedem Fall sehr hilfreich. Ich würde das dann einpflegen. Nebenbei bemerkt hat die Projektseite ein etwas anderes Gesicht: http://apps.sourceforge.net/trac/welecw2000a/ Gruß, branadic
Ja ich hab mich da heute auch schon getummelt um Stefans Sourcen runterzuladen. Macht wirklich einen netten Eindruck. Ich werde den Link mal mit in mein Package aufnehmen. Was ich vermisse ist eine Downloadecke wie bei Google Groops in der man ganze Softwarepakete für den Download hinterlegen kann. Zudem mußte ich etwas nach unseren Sourcen suchen, da ich sie nicht unter "FPGA" vermutet hätte. Alles in allem aber schon sehr ansprechend und auch sehr hilfreich für Neueinsteiger. Die Online-Versionsverwaltung ist auch nicht übel, aber hier muß sich jeder seine Source selbst zusammenstellen aus den verschiedenen Versionen. Da wären zusätzliche Komplettpakete ganz hilfreich (oder hab ich die Ecke übersehen?). Hayo
Gast
#1279267
Hallo Hayo, für den Upload/Download steht das Repository zu Verfügung. Hintergrund ist einfach, dass die Sachen halbwegs geordnet sind und nicht einfach wild upgeloadet werden und durcheinander in einem einzigen Ordner liegen, wie es bei GoogleGroup der Fall ist. Dies ist die Downloadecke für SF. Eine Übersicht zur Repository Struktur ist auf der Startseite vom Trac zu finden: http://apps.sourceforge.net/trac/welecw2000a/wiki/Repository Das die Sourcen zur FW ausgerechnet unter FPGA liegen ist auch bei uns noch ein kleiner Diskussionspunkt. Prinzipiell hat man recht zu sagen, dass die FW im FPGA läuft. Auf der anderen Seite kann man aber wieder argumentieren, dass unter FPGA eher das Design und der Softcore-Entwurf zu verstehen sei und die FW nur zur Ansteuerung des Softcores da ist. Man kann argumentieren wie man will und jeweils für und wider finden. Vielleicht ist es ja schon hilfreich das Repository als Downloadecke besser kenntlich zu machen? Beste Grüße, André
Gast
#1279353
Hallo Leute, wie gerade schon mit André geklärt, ist das Repository nicht wirklich für Release-Downloads zuständig. Sourcen gehören da rein zwecks Versionierung, klar. Aber so ganze Zips, wie Hayo sie veröffentlicht, gehören in die Sourceforge-Download-Ecke. Die ist allerdings etwas ätzend zu verwalten, man muss die Sachen irgendwie erst per SFTP hochladen, um sie dann per Webinterface aus diesem Staging-Server auf die Seite zu bringen. Dafür kann man aber Kategorien und sowas alles anlegen für die Downloads und auch direkt Versionen anzeigen usw. Können das gern mal zusammen erproben, wie dort was hochgeladen wird. Ich hatte das schonmal testweise für den USB-Blaster-Treiber gemacht, und ich denke, wenn man das ein paarmal gemacht hat, geht das auch recht fix von der Hand. Am Besten wäre, wenn Hayo oder jemand anderes, der die Releases machen will, mal im Skype-Chatroom vorbeischaut, dann können wir die Probleme zeitnah klären. Grüße ;Daniel
Gast
#1279376
Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV stellen und den Finger an die Messspitze halten ;) Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern, also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande
Crazor schrieb: > Nachtrag: Der Rollmode hat was meditatives an sich. Einfach auf 200mV > stellen und den Finger an die Messspitze halten ;) Hier ist das Motto eile mit Weile. Man sollte schon etwas Zeit mitbringen. Ich hätte das natürlich auch Zeitlupenmodus nennen können ;-) > Was ich aber sagen wollte ist, dass die Indikatoren bei mir flackern, > also Trigger- und Ground-Level und der AC-Indikator. Nur mal so am Rande Das flackert deshalb, weil zwischen zwei Meßwerten die Graphikroutine (anders als im Normalmodus) mehrfach durchlaufen wird (bis der Timer einen Interrupt auslöst) und bei jedem Durchlauf die Markierungen gelöscht und dann neu geschrieben werden. Hayo
Gast
#1279614
Hallo zusammen, für alle die genauso fit mit Perl sind wie ich hier mal schnell eine kleine Anleitung für die Windows-User. Ich hab mir Active Perl installiert. Anschließend hab ich mir noch Win32-SerialPort-0.19 aus dem Netz geladen und unter C:\Perl\lib\ entpackt. Nun über Start-->Ausführen-->cmd die Windows-Console starten und in das Verzeichnis mit der .ram bzw. .flash Datei wechseln. Dort sollte sich auch die GERMSloader_1.0.2.pl befinden. Mit cd und cd.. sollte man vertraut sein. Um die TomCat.ram in das Gerät über den Port COM1 zu laden muss in die Console folgende Zeile eingetippt werden: perl GERMSloader.pl COM1 TomCat.ram @ Hayo: Mir ist beim Verstellen der Zeitbasis ohne vorherige Kalibrierung ausgefallen, dass Kanal3 ab 10µs wieder dutzende von Spikes bei mir anzeigt, die bei 5µs und kleiner jedoch nicht auftreten. Nach der Kalibrierung sind sie dann plötzlich weg. Falls also jemand mit ähnlichen Symptomen zu kämpfen hat wei0 er wo er dran drehen kann. Beste Grüße, branadic
Prima Anleitung - werd ich mal direkt übernehmen und auch ins Englische übersetzen. Hayo
Gast
#1279782
Hallo Hayo, vielleicht noch ein kleiner Nachtrag, bevor man die Console aufruft muss der GERMSmonitor noch gestartet werden. Ansonsten findet sich eine aktuelle (englische) Beschreibung zum Umgang mit dem WelecUpdater und dem Upload via Perl unter Windows im SF-Wiki: http://apps.sourceforge.net/trac/welecw2000a/wiki/FWupload Beste Grüße, branadic
Gast
#1279924
Hallo, mal ganz naiv gefragt: konnten wir nicht eine der Testfunktionen verwenden um direkt in den GermsMonitor zu springen? Damit könnten wir den Upload weiter automatisieren (nicht dass jemand langweilig wird ;-)). Gruß, Guido
So, hier zum langen Wochenende was zum spielen. Die neue 0.65 beta enthält im Wesentlichen den neuen Roll und den Shiftmodus. Die Umschaltung findet Ihr im Timebasemenü (Main/Delayed). Weiterhin habe ich die Änderungen von Stefan für die Triggerung eingebaut. Allerdings klappte das trotz der eigentlich korrekten Formel noch nicht so ganz 100 prozentig. Da die Ursache nicht offensichtlich ist habe ich erstmal mit harten Korrekturen das Triggerverhalten so hingebogen dass es ganz passabel läuft. Der Fehler mit den fehlenden Cursorwerten ist noch nicht gefixt, da ist Guido wohl dran, so dass der Fix erst in die nächste Beta einfließt. Zur Source: Die Ersetzungen mit den neuen #defines für die Menüs ist noch nicht nicht ganz komplett, kommt aber noch. Viel Spaß Hayo
Hi, hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell Adapter zum Laufen bekommen? Mit dem realen Port meines Rechners geht's ohne Probleme, mit dem Adapter an meinem Laptop nicht :-( Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem Script wirklich häßlich :-/ Michel
Michael W. schrieb: > hat jemand das Perl-Script schon unter Windows mit einem USB <-> Seriell > Adapter zum Laufen bekommen? Ja. > Mit dem realen Port meines Rechners geht's ohne Probleme, mit dem Adapter > an meinem Laptop nicht :-( Was heißt "geht nicht"? Wenn du das genauer ausführen kannst, kann man vllt was "löten" ;) > Hab angefangen mich in den Updater einzuarbeiten - im Vergleich zu dem > Script wirklich häßlich :-/ Das werd ich mir jetzt auch mal ansehen, kann ja schliesslich kaum eine große Änderung sein, die den WelecUpdater dann genauso beschleunigt wie das Perlscript. Sind sicher nur irgendwelche Parameter des Ports bzw. der Serial-Dingsda-Unit. /Hannes
...bei der Gelegenheit auch gleich für die Dateiendung .ram freischalten! Gruß Hayo
Gast
#1280679
Hallo, @ Hayo: den Fix zu den Cursorwerten habe ich gestern schon gepostet. Hast du wohl übersehen. @ all: Habt ihr auch Zeichenfehler im ganz linken Button? Falls nötig mache ich noch Bilder. Ich suche seit 2 Tagen nach dem Grund und habe schon Drawsoftbutton und Pixelp komplett neu geschrieben. Ich glaube fast, dass ich da ein Hardwareproblem habe. Gruß, Guido
Mach mal Bilder, damit man sich was drunter vorstellen kann. Bei mir spackt der linke Button auch hin und wieder etwas rum. Deinen Fix hatte ich tatsächlich übersehen. Pflege ich schnell nach, dann gibt es morgen eine neue Beta. Hayo
Gast
#1280693
Bei mir schaut der linke Soft-Button auch mal komisch aus. Er ist nur ein normales gelbes Rechteck. Kein abgerundetes.
Gast
#1280706
Hallo, erstmal ein Bild. Die Buttons sehen komisch aus, weil die Ecken noch fehlen. Die Fehler sind aber die weißen Linien im linken Button, sowohl im Menu als auch in den Cursordaten. Mit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
habe ich noch drei Linien gezeichnet, wobei die graue (UI_Plane5) und die gelbe (UI_Plane4) korrekt gezeichnet werden. Die weiße (UI_Plane1) jedoch nicht. Ich hänge im nächsten Post noch das Tomcat.ram an, dann könnt ihr das auch mal probieren. Gruß zum Ersten, Guido
Angehängte Dateien:
-
pixelf1.jpg
(61 KB)
Gast
#1280710
Und noch das Tomcat.ram! Gruß zum zweiten, Guido
Jupp, linker Softbutton ist bei ir auch defekt (Überlagerung?). @Jo In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich bekomme. Zum Updater: Im Vergleich zum Script wirklich unübersichtlich. 1500 Codezeilen gegen 120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht, jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich umständlich. Michel
Gast
#1280718
Hallo Michael W., jo Überlauf um 1 LW, das würde aber bedeuten, dass die Plane falsch definiert ist, was ich mir kaum vorstellen kann. Mit dem Updater habe ich mich auch schon rumgeplagt. Ist wirklich sehr unübersichtlich. Ich habe nur unter Linux das Schreiben in die Edit-Komponente rauskommentiert und direkt in ein File geschrieben. Damit habe ich mein Original-Backup in akzeptabler Zeit hinbekommen. Schon das war aber ganzschön langwierig, also viel Spaß ;-). Gruß, Guido
@Guido sieht bei mir alles exakt genauso aus wie bei Dir. Hardware scheint also in Ordnung zu sein. Hayo
Michael W. schrieb: > In dem Script bekomme ich keine Antwort vom DSO (timeout). Ziehe einen > Stecker ab und starte es, dann hast Du eine Fehlermeldung, die ich > bekomme. Wenn ich den Stecker ziehe, kommt die Meldung, dass es den Port nicht gibt. Wenn es die Timeout-Meldung wirft, sollte er vorher auch einige Punkte ans erste Zeilenende gemalert haben. > 120 Scriptzeilen - das ist schon ein Unterschied - Naja, der Updater > kann ja auch Backup machen... Es wird wirklich alles von Hand gmacht, Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein großer Akt. > jedes Zeichen wird analysiert, einen Timer gibt's noch - wirklich > umständlich. Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der Nebel. /Hannes
@Hayo, die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche Kommentare. Am besten nochmal die hier ins Archiv packen: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die beiden Softkeys ausgegraut. (W2022A)
So hier die 0.66 Beta mit dem Bugfix von Guido. @Kurt > die ramloader.bat in deinem Archiv hat aus irgendeinem Grund falsche > Kommentare. Ist erledigt. > Was muss man tun, um in den Roll/Shift Mode zu kommen? Bei mir sind die > beiden Softkeys ausgegraut. (W2022A) Tja da hast Du wohl die Homeedition. Dann must Du auf Professional upgraden, wird nicht billig... ;-) Im Ernst: Der USTB-Modus (Ultra Slow TimeBase) wird automatisch ab 5S/Div aufwärts aktiv. Dann stehen auch die beiden Menüpunkte zu Verfügung. Gleichzeitig wird das Delayed Menü deaktiviert und die Triggerung zwangsweise auf AutoFreeRun geschaltet. Hayo
Ach ja, XY-Modus hab ich vergessen abzuschalten, kommt in der 0.67 Hayo
Johannes Studt schrieb: > Jo, hab auch gerade Knoten im Hirn. :D Aber langsam lichtet sich der > Nebel. Ich geb's erstmal auf, das werd ich demnext mal komplett leerlöschen und neu schreiben. > Backup müsste man halt ins Perlscript auch einbauen, ist sicher kein > großer Akt. Und darum hab ich das erstmal fix gemacht. Stell ich dann oder morgen noch hier rein, wenn es wirklich fertig ist. /Hannes
Super! Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute reinstellen wollte, aber da warte ich noch bis Dein Skript kommt. Hab noch einige Detailverbesserungen eingebaut und wieder mal überflüssiges Zeugs über Bord gekippt (wie schon vermutet war alles zum Thema Timer 1 so überflüssig wie ein Kropf - wer also für seine eigenen Routinen einen Timer braucht...) Für den USTB-Modus habe ich die Timersteuerung umgestellt, läuft jetzt gleichmäßiger ohne Ruckler und ohne "Warmlaufphase". Der XY-Modus wird jetzt im Menu deaktiviert wenn ultra slow gemessen wird. Gruß Hayo
Hayo W. schrieb: > Dann werd ich das mal in die 0.67 mergen die ich eigentlich schon heute > reinstellen wollte, aber da warte ich noch bis Dein Skript kommt. Wird wirklich erst heute im Laufe des Tages, hatte grade noch Besuch. Sry. /Hannes
Hm, habs vorsichtshalber schon mal angehängt, falls ich heute Morgen doch nicht dazu komme. Es funktioniert auf jeden Fall, aber die neue Fortschrittsanzeige muss ich noch in den Schreibmodus übernehmen, und sicher auch noch ein paar andere Kleinigkeiten fixen, die meine Bettschwere jetzt verdeckt. Es ist ein neuer Parameter dazugekommen, der den Modus bestimmt:
1 | |
Also zum Schreiben der Firmware z.B.
1 | |
und zum Lesen
1 | |
Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder Schrägstrich nehmen, "/R" ginge also auch. Wenn man die Adressen weglässt, verwendet das Script beim Auslesen defaultmässig 0x040000 und 0x7fffff. /Hannes
Kein Problem, hab auch noch ein paar Stellen gefunden die ich fixen muß. Dann kriegen wir auf jeden Fall ein schönes rundes Pfingst-Release hin. Hayo
Sodele, ich denke, so kann man's erstmal nehmen. Wär schön, wenn es dieser oder jener zeitnah testet. Bei mir läuft das Komplettbackup von 0x40000 bis 0x7FFFFF in 0:40h durch, mit dem WelecUpdater hab ich das (nach Löschen aller Bildschirmausgaben im Code) in 1:42h geschafft. Ist also durchaus etwas schneller. Schreiben geht nach wie vor wie bisher auch, nur die Fortschrittsanzeige ist etwas hübscher. Bedienung:
1 | |
> > Also zum Schreiben der Firmware z.B. >
1 | |
> > und zum Lesen >
1 | |
> > Als Modus-Parameter kann man Klein- wie Großbuchstaben mit Binde- oder > Schrägstrich nehmen, "/R" ginge also auch. > > Wenn man die Adressen weglässt, verwendet das Script beim Auslesen > defaultmässig 0x040000 und 0x7fffff. Fehler werden fast gar nicht abgefangen, mal abgesehen von nicht les- oder schreibbaren Dateien oder fehlenden Parametern. Insbesondere wird NICHT gewarnt, wenn beim Auslesen der Firmware eine bestehende Datei überschrieben würde. Also immer Augen auf beim Eierkauf. /Hannes
Super! Ich werde das mal wieder schön in Shellskripte (bzw. in Batchdateien) verpacken. Dann ist das schön komfortabel Hayo
Ich habe eben ein BackUp mit dem Script gemacht. Dauer 42 Minuten. Im Vergleich dazu ein Backup mit dem Updater. Dauer 45 Minuten. Allerdings liest das Script eine Zeile mehr ein. Die letzten Zeilen vom Script: S315007F0480050000000000803F266F420050FE9F005F S315007F049077004000E9CA9944871A443663D64200FA S315007F04A064000000000C9200000000002323232339 S313007FFFF0FFFFFFFFFFFFFFFFFFFFFFFFFFFF8C r0 Die letzten Zeilen vom Updater: S315007F0480050000000000803F266F420050FE9F005F S315007F049077004000E9CA9944871A443663D64200FA S315007F04A064000000000C9200000000002323232339 r0
Jo, ist aber nicht schlimm. Der Updater lässt Zeilen, die ausschliesslich 0xFFFF enthalten, weg. Das mache ich auch, aber nicht ganz so akkurat (ich suche nur nach kompletten Zeilen, und da die Zeile nicht komplett ist, landet sie doch im Backup). Interessant ist, das der WU bei dir fast genauso schnell ist wie das Perlscript. Ist das beim Schreiben auch so? /Hannes
Der WU braucht ca. 12 Minuten zum schreiben ins Flash glaube ich, das Script nur 128 Sekunden.
Interessant... Hab grade noch gesehen, dass das Schreiben unter Windows in einem standardmässigen CMD-Fenster räudig aussieht, weil ich glatt über die 80 Zeichen Breite wegschreibe. Kommt zwar eigtl nicht drauf an, aber ich habs trotzdem noch geändert. /Hannes
Gast
#1282002
[OT] Hallo, vorab entschuldige ich mich schonmal dafür, euren Thread zu "missbrauchen". Ich mach's auch kurz. Versprochen ;-) Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für 380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand bessere / günstigere Anbieter? Grüße, ein-vielleicht-baldiger-W2024A-Besitzer [/OT]
Gast
#1282015
Mir ist ueberhaupt kein anderer Anbieter bekannt. Bei dem Ebay Verkaeufer handelt es sich auch um irgendwen der Fa. Wittig. Kurzum: Wenn nicht jemand die Nase voll von seinem Oszi hat und es dir verkauft, ist Ebay der einzige Weg. Gruessle
Interessent schrieb: > Ich würde mir gerne ein W2024A kaufen. Bei eBay werden die Scopes für > 380 Euro - 450 Euro gehandelt. Kann man da zuschlagen oder kennt jemand > bessere / günstigere Anbieter? Wenn Du ein W2014 günstiger kriegen kannst nimm es! So wie es momentan aussieht unterscheiden sich die 100MHz Geräte und die 200MHz Geräte wohl nur durch das Label. Ich selbst habe auch beide Varianten und effektiv nutzen kann man beide ohnehin nur bis 25MHz (zumindest im Originalzustand). Hayo
Gast
#1282118
Danke für die Hinweise. Darf man denn Fragen, was ihr so für die Geräte hingelegt habt?
Gast
#1282128
Die bei Ebay ueblichen Preise natuerlich. Ich hab mein 2024 fuer 350,65 bekommen. Nu schluss mit OT. Entweder ists dir den normalen Preis wert oder eben nicht. Mehr Oszi fuer weniger Geld gibts ohnehin nirgends und Dank der Spitzenarbeit von Bruno, Guido, Hayo & Co (alphabetische Reihenfolge ;)) wirds wahrscheinlich irgendwann sogar noch zu einem ganz gut brauchbaren Geraet. Gruessle
@Interessent Ich habe die Wittig Electronics GmbH direkt über info@welec.de kontaktiert. Funktioniert ebenfalls. Beste Grüße, odic
Gast
#1282877
Hallo, ich bin erst jetzt dazu gekommen die neue Beta zu testen. Das sieht ja klasse aus. Die Triggerung funktioniert wirklich gut und auch der Rollmode macht Spaß. Ich messe zwar selten soo langsame Signale, aber der "Gummibandeffekt" durch den Linienalgorithmus ist echt toll. Warum setzt der Rollmode erst so spät ein? Das könnte doch ruhig schon bei 200 ms/div so losgehen. Es geht sichtbar voran, das liefert genau die nötige Motivation um weiße Pixelfehler zu analysieren. Gruß, Guido
Erstmal vielen Dank für die vielen Infos welche hier schon zusammengetragen wurden. Ich habe mich heute mal mit der USB-Problematik beschäftigt, mit dem Ziel das Firmware-flashen etwas einfacher und vielleicht auch schneller zu machen. Nachdem mein Programm nun, zumindest im im groben erstmal funktioniert ist mir allerdings klar geworden, das das zweite Ziel (schneller) mit der derzeitigen Implementation leider nicht zu erreichen ist. Was interessantes habe ich nebenbei trotzdem herausgefunden, nachdem ich im Welec W2000Update ein bischen geschnüffelt habe. Gebt mal, nachdem das Programm gestartet ist "89174" ein, dann erscheinen einige weitere Buttons, mit denen man vielleicht irgendetwas sinnvolles anstellen kann? Soviel habe ich schon rausgefunden: - c:\workfiles muß existieren dort werden die ausgelesenen Dateien abgelegt. - "USB-Reset" löscht den EEPROM vom USB-Controller also besser ! NICHT ! probieren - Receive Flash liest irgendwelche Speicherbereiche aus und schreibt sie in Files in o.a. Directory, Achtung dauert ewig wie oben schon geschrieben. Gruß
Hi Guido, ich hätte den Rollmode auch gerne schon früher eingesetzt, aber hier sind uns leider natürliche Grenzen gesetzt. Wenn ich den Timer auf Null setze komme ich auf eine minimale Zeitbasis von 2,5 S/Div - für 2 S/Div reicht es also gerade nicht mehr und die nächste ist dann 5 S/Div. Ich habe den ADC-Count schon auf 128 runtergesetzt, aber das wirkt sich nur auf das Auslesen aus, der Wandler wandelt trotzdem alle 16385 Werte bevor er den Interrupt auslöst. Falls Du eine Möglichkeit findest das zu ändern, könnte ich hier natürlich noch was machen. Anbei mal der generelle Ablauf im Rollmode -> kann auch gerne zu Dokumentationszwecken ins SFN-Wiki. Im Übrigen bin ich schon die ganze Zeit dabei lauter kleine Unstimmigkeiten zu beseitigen und den Rollmode für den XY-Betrieb einzurichten. Mit dieser Funktion dürfte unser DSO wohl auf dem Markt ein Unikum sein schätze ich... Hayo
Angehängte Dateien:
-
Rollmode_Schematik_1024.jpg
(140 KB)
Gast
#1283358
Hallo Hayo, das wird schon ein riesiger Aufwand, weil in alle benutzte Funktionen Fallunterscheidungen bzgl. USTB eingebaut werden müssen. Meine Überlegung ist, die ADC sehr schnell laufen zu lassen und das Timing über den Timer(2?) zu realisieren, wobei dessen eigentliche Funktion in der ISR über einen Zähler mimikriert wird. Es kommt aber auch noch eine vernünftige Realisierung der Funktionen für Start/Stop und Single hinzu. D.h.: Wenn dir Anderes wichtiger ist, lass es als Skelett erstmal wie es ist. Im Vergleich zum Original zeigt es immerhin, wie es aussehen sollte. Wenn ich den verdammten Zeichenfehler gefunden habe, fange ich mal an die ADC-Routinen in C umzusetzen (ich bin dann Disassembler ;-)). Das könnte wirklich ganz interessant werden und die Rolle rückwärts wäre bei zu langsamen Lauf leicht zu bewerkstelligen. Gruß, Guido
Gast
#1283360
Uups, ganz vergessen: @ Fritz Richter: Das ist echt nett, die Postleitzahl von Herrn Wittig? Die Flashdownloads betreffen wohl die zu ladenden Hintergründe der Grafik. JTAG sieht ganz interessant aus. Ich habe mich aber nicht getraut einen Button zu drücken, vllt. probier ich noch. Wäre ja schön, wenn es mir mitteilt welche Datei nicht gefunden wurde. Gruß, Guido
Guido schrieb: > Meine Überlegung ist, die ADC sehr schnell laufen zu lassen und das > Timing über den Timer(2?) zu realisieren, Genauso funktioniert das ja jetzt auch -> siehe Schematik. Hayo
So hier die Pfingst-Edition mit dem neuen Skript von Hannes. An dieser Stelle noch mal meinen Dank an die Skriptschreiber, da die Entwicklungszeit sich dadurch drastisch verkürzt hat. So schnell wie jetzt bin ich vorher nie vorangekommen. Die neue Version ist im Wesentlichen stabiler, fehlerbereinigter und hat eine etwas geänderte Menüstruktur Grid und Draw Switch sind jetzt im Displaymenü, der Browsebutton ist jetzt im Timebasemenü. An Bord ist natürlich das neue Perlskript von Hannes und angepasste Shellskripte. Die Batchdateien für's Backup und Restore hab ich nicht mehr geschafft, haben aber die gleiche Syntax wie die Shellskripte. Gruß Hayo
Hier die angepassten batch Dateien.
Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF. Also nur das reine Programm ohne Config/Protected flash.
Gast
#1283420
Hallo Hayo, die Schematik habe ich schon angeschaut. Wenn sich Timer2 nicht feiner granulieren lässt (timerperiodh/l), müsste man das ev. in den Timer1 einbauen, der ja ganz offensichtlich schneller kann. Aber wie schon gemeint, es handelt sich doch um eine eher seltener benutzte Funktion. Gruß, Guido
Gast
#1283438
Hallo Kurt,
> Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF.
aha, dein Ersatzgerät ist wohl angekommen! Mach noch einen
einen Download mit Config-Bereich, kann man manchmal brauchen,
wie ich gelernt habe. ;-)
Gruß, Guido
Hallo Guido, ja, das Ersatzgerät ist angekommen. Zwei mal ;-) Das erste hatte auch Staub, ein klapperndes Metallteil und einen Kurzschluss zwischen der Main/Delayed Taste und Mode/Coupling. Das zweite hat nur noch Staub. Aber so wenig, dass es nicht mehr stört. Hier noch der Config von 0x000E0000 bis 0x007FFFFF
So ein Komplettbackup hab ich auch noch hier rumliegen vom W2024. Wenn wir jetzt einmal beim Hochladen sind... ;) /Hannes
@Guido Das Problem ist nicht der Timer. Der läuft wie er soll und läßt sich auch prima einstellen - übrigens sind alle drei Timer gleich aufgebaut - das Problem ist, dass man mit der Timerperiode nicht kürzer werden darf als die Wandlungszeit des ADC - und die ist leider so lang weil man immer warten muß bis alle Werte gesampled sind. Einzige Möglichkeit wäre rauszufinden wie man den ADC dazu bringt weniger Werte zu holen. Hayo
Gast
#1283773
@ Hayo: Das habe ich mir gedacht, aber ist es nicht möglich die Samplerate von der Timenase zu entkoppeln? Die ADC können ja nun mal rasend schnell. Ich frage so doof, weil ich denke du hast da einiges parat, während ich erst die ganzen Menüs durchwühlen müsste. Gruß, Guido
@Guido Ja hab ich gemacht, der ADC läuft im USTB-Mode mit vollen 1Gsa/S (Timebaseregister mit 0xFFFFFFFF laden -> siehe tc_vars.cpp Zeile 353). Davon werden dann 128 Werte genommen und zur Glättung das arithmetische Mittel berechnet. Das ADC-Set hat aber wenn es den Interrupt auslöst trotz allem 4 x 4096 Werte gesampled. Diese Ansteuerung ist im FPGA realisiert und ich weiß nicht, ob es im Design vorgesehen ist auch weniger Werte zu holen. Das hieße nämlich das irgendwo ein Counterregister anders gesetzt werden müßte. Wenn wir allerdings die hardwarenahen Routinen umsetzen stoßen wir ja vielleicht darauf. Hayo
Gast
#1284204
@ Hayo: Sorry, ich kapiere es immer noch nicht. Für die 4096 (*4) Sample benotigt der ADC doch nur rund 16 µs. Das kann doch bei 100 ms/div nicht ausbremsen? Gruß, Guido
Ja, das hatte ich auch so ausgerechnet. Dazu kommen natürlich noch die Ausleseroutinen. Ich hatte rein rechnerisch auch mit einem etwas schnelleren Zugriff gerechnet. Ich habe allerdings auch den Verdacht, dass evtl. der Trigger da mitmischt und eine Verzögerung bewirkt, obwohl eigentlich nicht getriggert werden sollte. Hayo
Die Timersteuerung läuft allerdings jetzt auch etwas anders als bei meinen Tests, evtl. läßt sich da jetzt noch was rausholen, muß ich mal prüfen. Hayo
@Guido Durch Dein hartnäckiges Nachfragen hab ich nochmal diverse Tests durchgeführt und festgestellt, dass ich auf dem Holzweg war... Das begrenzende Element ist tatsächlich nicht die ADC-Routine (hatte mich auch gewundert aber nicht gleich zum Nachdenken gebracht) sondern (hätte ich auch gleich drauf kommen können) die Graphikausgabe. Ich habe jetzt mal testweise mehrere Ausgaben pro Durchlauf ausgelassen und - oh Wunder - die machbaren Zeitbasen wandern weiter nach unten. Werde also noch ein wenig tricksen und mal sehen was so geht. Danke für die Anregung Hayo
Gast
#1285667
@ Hayo, hört sich gut an. Ich habe gestern mal mit der Umsetzung der Assemblerroutinen in C angefangen. Bei dem Transfer der Daten kann man wohl nicht sparen, da es sich um eine FIFO-Struktur handelt. Es müssen daher immer alle Samples ausgelesen werden, damit der FIFO wieder leer ist. Andererseits konnte man doch mit einer der Testfunktionen sich ADC-Daten aufs Terminal holen. Könnte man mal schauen, was da gemacht wird. Gruß, Guido
@Guido Prima, dass Du Dich da reinhängst. Ich denke es wird heute eine neue Beta geben mit erweitertem USTB-Support. Ich würfel gerade das Timing neu aus. Bis jetzt geht es bis 500mS - mehr wird auch schon etwas anstrengend für die Augen. @Hannes Nochmal eine kleine Rückmeldung zum GERMSloader 1.1.2 - läuft super stabil unter Windows und Linux. Bislang hab ich schon ca. 20 - 30 Uploads gemacht. - Linux RAMload 180 S - Linux Flashload 200 S - Windows Flashload 136 S Alles mit echter RS232. Linux auf Athlon 2000 PC, Windows auf Intel Dualcore Lappy. Hayo
Gast
#1285760
@ Hayo: Ich habe jetzt READADC_ALL2 und EXTRACTADCVAL umgeschrieben. Wird schön kompakt und von der Geschwindigkeit her merke ich bisher keinen Unterschied (bei EXTRACT... hatte ich schon Bedebnnken). Sagt dir der Stil zu? Noch kann ich mich umgewöhnen. Klar, die Grafik braucht ja über 0,1 s, hätte ich auch dran denken können. Wunder sind damit wohl nicht möglich. Gruß, Guido
Gast
#1285761
Hm ich haette 2 Sachen, die mir an der Benutzeroberflaeche aufgefallen sind: Ist nur ein Kanal aktiv, so laesst sich dieser nicht abschalten,sondern erst nachdem man einen andern eingeschaltet hat. Ich meine aber mich erinnern zu koennen, dass das nicht immer so war. Wenn das eine Verbesserung sein sollte, so finde ich sie eher unpraktisch, da dem Benutzer so die Reihenfolge der notwendigen Tastendruecke zum Wechseln eines Kanals vorgegeben wird. Klar ist es logisch sinnlos, jedoch druecke ich z.B. meist auf die Taste, die dem Finger grad am naechsten ist :D Mein Oszi will nach jedem Einschalten auf Pusweite triggern, auch wenn ich vorm dem letzten Abschalten auf Edge gestellt hatte. Das war bis vor 2-3 Versionen auch noch nicht so. Allgemeines Problem oder spinnt mein Config-Bereich auch? Gruessle und danke fuer die tolle Arbeit André
Hallo, ich hab mal (im Anhang ein Bild davon) die Flanke vom Rechteckgenerator in 10ns /div aufgelöst. Ein Sample dürften also ca. 5 Pixel sein? Jedenfalls, schaut es sehr hässlich aus. Wenn man sich jetzt die Zacken, die so stark nach unten ausreißen, gedanklich um eine Zacke nach links verschiebt, würde es scheinbar perfekt passen! ADC und DAC-Abgleich habe ich frisch davor gemacht. Werden die Kanäle vielleicht verkehrt ausgelesen?
Angehängte Dateien:
-
bild0515.jpg
(2 MB)
Gast
#1285779
Hallo Stefan, mach das doch bitte gleich noch mit Kanal 2, damit man sieht ob es kanalabhängig ist. Bruno W. hatte das auch schon mal gezeigt, aber ich kapiere erst jetzt die Zusammenhänge. Gruß, Guido
Gast
#1285784
Ich hab jetzt ein Weilchen mit dem Trigger herum gespielt. Speziell fiel mir auf, dass bei mir bei Zeitaufloesungen <= 100µs der Trigger auf Kanal 2 nicht funktioniert. Fuer die Tests habe ich den internen Signalgenerator benutzt. Nach langem Herumspielen bemerkte ich dann auch noch, dass das Oszi gelegentlich die Triggerquelle "vergisst" und kurzerhand auf Kanal 1 zurueck stellt. Gruessle André
Nach einer kleinen Firmware-Änderung sieht es jetzt schon viel besser aus. Zumindest auf Kanal 1. Auf Kanal 2 hat sich die Situation dadurch verschlechtert, weil der scheinbar woanderst vertauscht ist. Werde gleich mal noch weng testen.
Angehängte Dateien:
-
bild0517.jpg
(110 KB)
Gast
#1285816
Hallo Hayo In FW1.2.BF.0.68_beta funktioniert der RollMode nicht mehr. In 0.66 schon... Ist das bei Euch auch so? Habe das TomCat.flash verwendet. l.G. Roberto
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.