Wittig(welec) DSO W20xxA Open Source Firmware

[branadic (Gast)]

Hallo Johannes,

hier kurz der Link: http://apps.sourceforge.net/trac/welecw2000a/

Gruß, branadic

[Stefan E. (stefan_e)]

@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

[Blue F. (blueflash)]

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

[Guido (Gast)]

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:

if (UpdateMenuTextPlane)
    {
  /* Gudo test:change
        TransferDataPlane_asm_persistant(0x008DBB24, 0x00970F30);  */  
  TransferDataPlane_asm_persistant(0x008DC254, 0x00971660);
    }

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

[Stefan E. (stefan_e)]

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.

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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):

su -
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 
;-):

perl flashloader.pl /dev/ttyUSB0 TomCat.flash

Portbezeichnung und Dateiname sind natürlich entsprechend anzupassen.

/Hannes

[Crazor (Gast)]

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 (Gast)]

Nachtrag: Ok, ein sleep(1) im Fehlerfall ist doch noch drin, das könnte 
auch noch raus, war nur zu Testzwecken.

[Johannes S. (demofreak)]

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

[Stefan E. (stefan_e)]

Wie sich mein Skript verselbstständigt ist echt cool ;-)

[Blue F. (blueflash)]

Das endgültige Skript werd ich dann heute oder morgen mit zu der 0.63 
beta packen.

Hayo

[Kurt B. (kurt)]

Das wird aber auch unter Windows laufen und zusammen mit einer passenden 
tomcat.ram ausgeliefert? ;-)

[Blue F. (blueflash)]

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

[Guido (Gast)]

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

[Guido (Gast)]

@ Hayo: Oder noch besser, den teil erst garnicht aus dem Flash
laden. Dazu auskommentieren:

void Display::DrawStartScreen(void)
{
  unsigned long lX;
  //Top area above the grid
  for (lX = TOP_PLANE_MIN; lX < TOP_PLANE_MAX; lX++)
  {
    Buffer_UI2Plane[lX] = *(UI_Plane2_Flash + lX);
    UI_Plane3[lX] = *(UI_Plane3_Flash + lX);
  }
/* BF del for the new grid
  //Grid area
  for (lX = GRID_PLANE_MIN; lX < GRID_PLANE_MAX; lX++)
  {
    Grid_Plane[lX] = *(Grid_Plane_Flash + lX);
    
    if (tc_hw_version < 0x4c7) {if ((lX % 20) == 0) Grid_Plane[lX] = Grid_Plane[lX] << 2;} // Gap
  }  
 BF end  */   
  //Bottom area
  /*for (lX = BOTT_PLANE_MIN; lX < BOTT_PLANE_MAX; lX++)
  {
    UI_Plane1[lX] = *(UI_Plane1_Flash + lX);
    Buffer_UI2Plane[lX] = *(UI_Plane2_Flash + lX);    
    UI_Plane3[lX] = *(UI_Plane3_Flash + lX);
    UI_Plane4[lX] = *(UI_Plane4_Flash + lX);
    UI_Plane5[lX] = *(UI_Plane5_Flash + lX);
  }*/

Das Bottom-Area.

Gruß, Guido

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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 B. (kurt)]

Unter WinXP-SP3 überträgt das Script ca. 1 Zeile pro Sekunde am echten 
RS232. Wird das noch schneller?

[Johannes S. (demofreak)]

@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 ;)

[Kurt B. (kurt)]

Deine letzte und die von Hayo zuletzt gepostete.

[Jürgen (Gast)]

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

[Johannes S. (demofreak)]

Sodele,

bei mir klappt das jetzt unter Windows (in einer VM allerdings) und 
unter Linux mit vollem Tempo. Bitte um Test.

/Hannes

[Guido (Gast)]

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

[Blue F. (blueflash)]

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 B. (kurt)]

Geht immer noch nicht schneller.

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

2 Punkte

[Blue F. (blueflash)]

@Guido

Hab mal Deine Demo eingespielt.

Ich finde eigentlich die Version mit unterlegtem Balken besser, weil es 
den UI-Bereich klarer abgrenzt.

Hayo

[Guido (Gast)]

@ Hayo: hmmh, ist natürlich Geschmackssache, mich hat der Balken
immer gestört. Nundenn ...

Gruß, Guido

[Kurt B. (kurt)]

Mit Balken finde ich auch schöner.

Unter OpenSuse 11.1 in der VirtualBox läuft das Skript rasend schnell 
durch. ;-)

[Kurt B. (kurt)]

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.

[Blue F. (blueflash)]

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

[Martin H. (martinh)]

@ 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

[sunny (Gast)]

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.

[Johannes S. (demofreak)]

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

[sunny (Gast)]

was mir bei der .63 noch aufgefallen ist, das die messwerte der cursor 
nicht mehr angezeigt werden.

[Michael (Gast)]

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.

[Bruno W. (brunowe)]

Dafür gibts in diesem  Forum einen Markt!
http://www.mikrocontroller.net/forum/markt

gruß, brunowe

[Stefan E. (stefan_e)]

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 S. (demofreak)]

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

[Kurt B. (kurt)]

Jetzt läuft er auch unter Windows super!

[Blue F. (blueflash)]

Was ist los? Keiner mehr auf? Rollmode läuft, feile aber noch am Timing. 
Shiftmode ist in Vorbereitung.

Hayo

[Johannes S. (demofreak)]

Klar bin ich noch wach. Warte ja auf die nexte Version... :D

[Guido (Gast)]

@ 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

[Blue F. (blueflash)]

@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

[Stefan E. (stefan_e)]

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

[Martin H. (martinh)]

@ 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

[Johannes S. (demofreak)]

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

[Bernhard M. (boregard)]

Bei mir gehts unter Linux (debian) nicht wegen read_interval:

Can't locate object method "read_interval" via package "Device::SerialPort" at ../GERMSloader-win.pl line 51.

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....

[Bernhard M. (boregard)]

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)...

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Guido (Gast)]

>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

[Martin H. (martinh)]

@ 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

[Kurt B. (kurt)]

Ich habe mal zwei Batchdateien geschrieben. Dann kann man z.B. eine 
Verknüpfung auf dem Desktop anlegen und den Flashvorgang per doppelklick 
starten.

[Kurt B. (kurt)]

Ramloader

[Martin H. (martinh)]

@ 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

[Blue F. (blueflash)]

Packagemanager für Windows???

Hab ich das korrekt verstanden?

Hayo

[Kurt B. (kurt)]

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

[Martin H. (martinh)]

@ Hayo

Ja einfach vom dos prompt aus "ppm<enter>" eingeben oder ueber START 
usw. auswählen. (nach dem du ActivePerl installiert hast)

Martin

[Stefan E. (stefan_e)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

Vielleicht solltest Du mal ein komplettes Backup einspielen. Mir scheint 
da ist was vergurkt.

Hayo

[branadic (Gast)]

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

[Guido (Gast)]

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

[Guido (Gast)]

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

[branadic (Gast)]

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

[Stefan E. (stefan_e)]

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

[Stefan E. (stefan_e)]

War wohl zu langsam beim tippen ;-)

[Johannes S. (demofreak)]

Bernhard M. schrieb:
>

Can't locate object method "read_interval" via package
> "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

[Guido (Gast)]

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

[Blue F. (blueflash)]

@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

[Michael W. (slackman)]

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

[branadic (Gast)]

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

[michaelk (Gast)]

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.

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

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 S. (demofreak)]

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

[Kurt B. (kurt)]

Leider nicht besser.

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

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.

[Michael W. (slackman)]

... 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

[Guido (Gast)]

@ 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

[Stefan E. (stefan_e)]

>-  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 S. (demofreak)]

Stefan E. schrieb:
> Perl ist schon eine geile Sprache ;-)

ACK!

[Martin H. (martinh)]

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

[Crazor (Gast)]

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

[Stefan E. (stefan_e)]

>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. (stefan_e)]

So,
jetzt wieder mit Enderkennung.
Hab dem Skript, nachdem es jetzt soweit ja ganz brauchbar ist, mal eine 
Versionsnummer verpasst.

Stefan

[Martin H. (martinh)]

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

[Martin H. (martinh)]

Ups habe den Anhang vergessen!

Martin

[Johannes S. (demofreak)]

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

[Günter J. (gjung)]

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

[Stefan E. (stefan_e)]

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.

[Blue F. (blueflash)]

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

[nur mal so (Gast)]

Moin,

hab's gerade runtergeladen und der Downloadzähler ist immer noch bei 0 ?

hmmm

[Blue F. (blueflash)]

Ich sehe eine 4!

Hayo

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

Ach ja,

die Verschiebung des Triggerzeitpunkts findest Du unter "TOC" 
(TriggerOffsetCalc), wie der Programmierer das genannt hat.

Gruß Hayo

[Stefan (Gast)]

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)

[Blue F. (blueflash)]

@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

[Blue F. (blueflash)]

Bin heute erst recht spät wieder zu hause, vielleicht hast Du bis dahin 
ja schon ein Ergebnis. Werd mich dann mal melden.

Hayo

[Stefan E. (stefan_e)]

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

[sunny (Gast)]

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

[Stefan E. (stefan_e)]

@ 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

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

@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

[Stefan E. (stefan_e)]

>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

[Johannes S. (demofreak)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Michael W. (slackman)]

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

[branadic (Gast)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

@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

[Stefan (Gast)]

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

[Blue F. (blueflash)]

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

[Stefan E. (stefan_e)]

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)

[Blue F. (blueflash)]

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

[branadic (Gast)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[branadic (Gast)]

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

[Blue F. (blueflash)]

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

[branadic (Gast)]

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é

[Crazor (Gast)]

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

[Crazor (Gast)]

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

[Blue F. (blueflash)]

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

[branadic (Gast)]

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

[Blue F. (blueflash)]

Prima Anleitung - werd ich mal direkt übernehmen und auch ins Englische 
übersetzen.

Hayo

[branadic (Gast)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Michael W. (slackman)]

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

[Johannes S. (demofreak)]

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

[Blue F. (blueflash)]

...bei der Gelegenheit auch gleich für die Dateiendung .ram 
freischalten!

Gruß Hayo

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Robert (Razer) (Gast)]

Bei mir schaut der linke Soft-Button auch mal komisch aus. Er ist nur 
ein normales gelbes Rechteck. Kein abgerundetes.

[Guido (Gast)]

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:

//Testlines
  y = 300;

  for ((x = 0); (x < 640); x++)
  {
    PIXELP(x, y, 1, UI_Plane1); 
  }
  y += 20;
  
  for ((x = 0); (x < 640); x++)
  {
    PIXELP(x, y, 1, UI_Plane4); 
  }
  y += 20;

  for ((x = 0); (x < 640); x++)
  {
    PIXELP(x, y, 1, UI_Plane5); 
  }

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

[Guido (Gast)]

Und noch das Tomcat.ram!

Gruß zum zweiten, Guido

[Michael W. (slackman)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

@Guido

sieht bei mir alles exakt genauso aus wie bei Dir. Hardware scheint also 
in Ordnung zu sein.

Hayo

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

@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)

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

Ach ja, XY-Modus hab ich vergessen abzuschalten, kommt in der 0.67

Hayo

[Johannes S. (demofreak)]

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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

[Johannes S. (demofreak)]

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:

perl GERMSloader.pl <Schnittstelle> <MODUS> <Datei> [<Startadresse> <Endaddrese>]

Also zum Schreiben der Firmware z.B.

perl GERMSloader.pl COM3 -w Tomcat.flash

und zum Lesen

perl GERMSloader.pl /dev/ttyUSB0 -r Tomcat.backup 40000 7fffff

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

[Blue F. (blueflash)]

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

[Johannes S. (demofreak)]

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:

perl GERMSloader.pl <Schnittstelle> <MODUS> <Datei> [<Startadresse> <Endadresse>]

>
> Also zum Schreiben der Firmware z.B.
>

perl GERMSloader.pl COM3 -w Tomcat.flash

>
> und zum Lesen
>

perl GERMSloader.pl /dev/ttyUSB0 -r Tomcat.backup 40000 7fffff

>
> 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

[Blue F. (blueflash)]

Super!

Ich werde das mal wieder schön in Shellskripte (bzw. in Batchdateien) 
verpacken. Dann ist das schön komfortabel

Hayo

[Kurt B. (kurt)]

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

[Johannes S. (demofreak)]

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

[Kurt B. (kurt)]

Der WU braucht ca. 12 Minuten zum schreiben ins Flash glaube ich, das 
Script nur 128 Sekunden.

[Johannes S. (demofreak)]

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

[Interessent (Gast)]

[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]

[André (Gast)]

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

[Blue F. (blueflash)]

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

[Interessent (Gast)]

Danke für die Hinweise. Darf man denn Fragen, was ihr so für die Geräte 
hingelegt habt?

[André (Gast)]

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

[Odic X. (odic)]

@Interessent

Ich habe die Wittig Electronics GmbH direkt über [e-mail] 
kontaktiert. Funktioniert ebenfalls.

Beste Grüße,
odic

[Guido (Gast)]

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

[Fritz R. (f_richter)]

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ß

[Blue F. (blueflash)]

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

[Guido (Gast)]

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

[Guido (Gast)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Kurt B. (kurt)]

Hier die angepassten batch Dateien.

[Kurt B. (kurt)]

Und noch ein Backup der V1.4 von 0x00040000 bis 0x000DFFFF. Also nur das 
reine Programm ohne Config/Protected flash.

[Guido (Gast)]

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

[Guido (Gast)]

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

[Kurt B. (kurt)]

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

[Johannes S. (demofreak)]

So ein Komplettbackup hab ich auch noch hier rumliegen vom W2024. Wenn 
wir jetzt einmal beim Hochladen sind... ;)

/Hannes

[Blue F. (blueflash)]

@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

[Guido (Gast)]

@ 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

[Blue F. (blueflash)]

@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

[Guido (Gast)]

@ 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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

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

[Blue F. (blueflash)]

@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

[Guido (Gast)]

@ 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

[Blue F. (blueflash)]

@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

[Guido (Gast)]

@ 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

[André (Gast)]

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é

[Stefan E. (stefan_e)]

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?

[Guido (Gast)]

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

[André (Gast)]

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é

[Stefan E. (stefan_e)]

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.

[Roberto (Gast)]

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