@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
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:
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
su -
2
perl -MCPAN -e 'install Device::SerialPort'
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
perl flashloader.pl /dev/ttyUSB0 TomCat.flash
Portbezeichnung und Dateiname sind natürlich entsprechend anzupassen.
/Hannes
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
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
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
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
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
@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 ;)
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
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
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
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
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
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.
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
@ 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
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)...
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
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
>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
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
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
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
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
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
Can't locate object method "read_interval" via package
2
> "Device::SerialPort" at ../GERMSloader-win.pl line 51.
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
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
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
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
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
... 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
@ 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 ;-)
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
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
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
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
@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
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
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
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
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
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
@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
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
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
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
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
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
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
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é
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
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
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
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
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
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
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
//Testlines
2
y=300;
3
4
for((x=0);(x<640);x++)
5
{
6
PIXELP(x,y,1,UI_Plane1);
7
}
8
y+=20;
9
10
for((x=0);(x<640);x++)
11
{
12
PIXELP(x,y,1,UI_Plane4);
13
}
14
y+=20;
15
16
for((x=0);(x<640);x++)
17
{
18
PIXELP(x,y,1,UI_Plane5);
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
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
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
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
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:
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
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:
>> 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
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
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
[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]
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
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
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
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
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
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
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
@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
@ 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
@ 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
@ 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
@ 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
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?
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
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.
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
Thread beobachten
Seitenaufteilung abschalten