Wittig(welec) DSO W20xxA Open Source Firmware

Die sind bestimmt alle in Italien...   ;-)

Hayo

Hier nochmal schnell vor dem Schlafen gehen ein kurzer Blick auf den 
Zwischenstand:

Was Ihr seht ist das Spektrum eines 500Hz Rechtecksignals bei einer 
Abtastung von 25 MSa/S. Die Gridbreite entspricht der halben Abtastrate 
- d.h. ganz links ist der Gleichanteil 0 Hz (DC-Offset) und ganz Rechts 
die Frequenz 12,5 MHz.

Das ganze bei Vollaussteuerung im Zeitbereich und einer 512 Punkte FFT.

Im nächsten Bild...

...seht Ihr die gleiche Situation mit einer 1024er FFT. Man sieht schon 
die etwas feinere Auflösung.

Die Routine habe ich damals für ein System mit mathematischem 
Coprozessor geschrieben. Die vielen Fließkommaberechnungen waren da kein 
Problem. Auf unserem NIOS liegt die Wiederholrate z.Zt. bei 2 - 4 S pro 
FFT.

Da muß ich mal die Berechnungen auf Integer umstellen, das dürfte 
einiges bringen.

Gruß Hayo

Das Fenster hatte ich für diese Bilder abgeschaltet, da das von WELEC in 
der tc_vars.cpp definierte Fenster Störlinien verürsacht. Ich werde da 
meine eigenen Fensterdefinitionen einbauen (habe da noch von meinem 
damaligen Projekt etliche 1024er Fensterdefinitionen).

Die Darstellung ist linear, die logarithmische Darstellung erkennt man 
daran dass die Linien nicht so schmal sind, sondern eher bauchige 
Buckel.

Es gibt allerdings noch viele Details die ich noch programmieren muß 
bevor das Ganze rund genug für die nächste Beta ist. Ich halte Euch auf 
dem Laufenden.

Wie sieht es denn an den anderen Fronten aus?

@Guido

Was machen die C-Routinen? Es sieht so aus, dass wir eine Korrektur für 
die Signalverschiebung einbauen müssen, da böte es sich an das mit in 
die C-Routinen einfließen zu lassen.


@Jürgen

Hast Du da mit der Umschaltung was rausgefunden?


@Stefan

Wie sieht es an der QM-Front aus?

Gruß Hayo

Zum Thema Signal-Delay zwischen den Kanälen:

Ich habe mal bei meinen Geräten nachgemessen und war doch ziemlich 
erstaunt. Es gibt da erhebliche Delays zwischen den Kanälen. Und wie 
einige von Euch auch schon festgestellt haben scheint in der original 
WELEC FW eine Korrektur eingebaut zu sein (vermutlich in der alten 
Graphikroutine).

Damit wir eine einigermaßen gemeingültige Korrektur durchführen können 
bräuchten wir möglichst viele Daten von Euren Geräten. Ich habe mal eine 
Excelliste erstellt und angehängt in der ich mal meine Werte eingetragen 
habe. Tragt einfach Eure Werte dazu und stellt die Liste dann wieder 
hier ein. Ich trage dann die Ergebnisse zusammen in eine Gesamtliste.

Gruß Hayo

@ hayo

wie ungewünscht meine offset's
(-2ns bedeutet Kanal 2 ist 2ns früher als Kanal 1)

Martin

Hallo,

erstmal Danke fuer eure tolle Arbeit an der Firmware,
bin seit einem halben Jahr Besitzer eines W2024A und
beobachte schon eine Weile die Entwicklung.

Waere es moeglich, den Bildschirminhalt als einfache
Bitmap ueber RS232 (oder USB) auszugeben, damit das
Abfotographieren des Bildschirms entfallen kann?

(Entsprechendes Programm auf PC-Seite zum Auslesen
kann ich selbst schreiben.)

Das waere nicht nur fuers Debugging interessant sondern
auch bei der normalen Benutzung und wesentlich einfacher
als ueber die Originalsoftware von Wittig/Welec.

Gruss,
Niklas

@Martin

Ja genauso wars gedacht. Danke.


@Niklas

Willkommen in der Gemeinde ;-)

Tja, grundsätzlich gibt es ja ein entsprechendes Programm von WELEC, mit 
dem die Bildschirminhalte angezeigt werden können. Allerdings habe ich 
noch nicht ausprobiert ob das auch mit der Beta FW funktioniert. Es 
kursierten mal Gerüchte, dass bei der FW 1.2 die ja der Beta FW zugrunde 
liegt genau diese Übertragung buggy war.

Das wäre also ein Punkt an dem z.Zt. jegliche Erkenntnisse fehlen und 
wenn sich da jemand (Du??) berufen fühlt Hand anzulegen, dann haben wir 
wieder eine Ecke abgedeckt (zumindest könnte man das mal testen). Man 
kann sich da natürlich auch zu zweit zusammentun - einer auf PC-Seite 
und einer
auf DSO-Seite.

Mir selbst fehlen Windows Programmierkenntnisse, also wäre es eine 
willkommene Hilfe.

Mein eigenes Fernziel war es eigentlich mal nach schon vorhandenen 
PC-Programmen von renomierten Herstellern zu suchen, und dann das 
WELEC-Protokoll so anzupassen, dass man diese Programme nutzen kann 
(z.B. von Agilent/HP/Tektronix etc.).

Gruß Hayo

@Martin

wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da 
eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW 
eingebaut hat.

Hayo

Hallo,

im Anhang noch die Delays von Ch zu Ch bei meinem Geraet.

@Hayo:

Das Programm von Welec importiert soweit ich das sehe
die Rohdaten vom Oszi und bastelt sich dann (wenn
man die Scope Ansicht aufmacht) wieder nen Oszillogram
daraus.

Direkt aus dem Utility-Menue heraus "Save to..." passiert
auch nicht wirklich das, was man (ich) erwarten
wuerde, naemlich dass die Bildschirmausgabe, inkl.
gesetzter Cursor, gemessener Werte usw., genau wie
angezeigt gesichert wird.  Da wird auch nur wieder ein
Dump der Rohdaten gezogen.

Das Protokoll so anzupassen, dass es mit gaengigen Programmen
funktioniert waere wie Du schon sagst ein gutes Fernziel,
fuer meine Belange waere eine reine 1:1 Screenshot Funktion
und einfacher Datenexport schon ausreichend.

Ich habe auch gerade mal das Welec-Programm mit Deiner Firmware
getestet (die 0.75), es erkennt dass das Oszi am USB haengt und
verbindet sich, der Datenimport dauert aber ewwwwig (noch viel
laenger als mit der Originalfirmware) und am Schluss scheint
das Programm zu haengen, jeweils werden die Daten nicht angezigt,
das Oszi ist jedoch wieder "verfuegbar" (waehrenddessen lahmgelegt).
D.h., wie Du schon vermutest hast, funktioniert so nicht.

Ich habe schon gesehen das auf RS232 Testroutinen verfuegbar sind,
die die ADC Werte ausgeben, zudem hat Jochen Schaeuble mal das
USB-Protokoll reverse-engineered und auch eine LabVIEW Bibliothek
angelegt, mit der schonmal Importe funktionieren sollen:
http://schaeuble.info/de/category/jochen/w2000a

Auch liegt ja bei der Google Groups Gruppe ein C-File was
mit libusb unter Linux die Daten dumpt, was ich bei mir
allerdings noch nicht zum Funktionieren gebracht habe (ich muss
auch gestehen das ich mit USB noch nicht gearbeitet habe).

Ich denke, den Export der Kurven ueber RS232 und darstellen
mit Hilfe von evtl. gnuplot und die 1:1 Screenshot-Funktion
sind gute Erstziele.  Zu letzerem weiszt Du sicher mehr.

BTW: Komme nicht wirklich aus der Windows-Ecke, bin eher
im Unix-Bereich zu Hause.

Guido schrieb:

> also ich bin immer noch völlig ratlos, wie ich die Verschiebung
> messen soll. Dazu bräuchte ich ja zwei Signale mit 50-Ohm ohne
> kleinste Phasenverschiebung und mit einer Anstiegszeit von ca.
> 1 V/ns. Das aber kann das Welec doch garnicht darstellen?

Nein es geht viel einfacher. Man nehme eine Signalquelle mit 
BNC-Ausgang, dann ein Stückchen BNC-Kabel und am Ende ein T-Stück drauf. 
Dann zwei Tastköpfe hergenommen und auf die Enden die mitgelieferten 
BNC-Adapter aufstecken. Jetzt die Tasstköpfe in das T-Stück einführen 
und man hat exakt gleichlange Signalwege. (die Tastköpfe sollten nat. 
abgegl. sein)
Verwendet habe ich ein 5 MHz Rechtecksignal.

Bei der Messung kann man dann auch gleich die Vorzüge der interpolierten 
Zeitbasen der Beta FW nutzen. Im Vergleich dazu läßt sich das mit der 
originalen FW relativ schlecht ablesen.

> Naja, ich hatte doch gelesen dass die Zweikanaler nicht davon
> betroffen sind, dann bleibt mir das erspart.

Falsch! Ein Blick ins Excelfile und Du bist schlauer.

> Korrigieren könnte ich das im Prinzip schon, warten wir mal ab,
> ob es da eine Einheilichkeit gibt.

Eher einen Mettelwert denke ich.

> @ Hayo: Steht in "timebase" der in den Programmingmaps angegebene
> TB-Idx? Das müsste ich dann ja berücksichtigen. Ich räume die
> C-Routine mal etwas auf und poste dann den aktuellen Stand.

Steht in "Selected_Timebase".

> Was den PC anbetrifft: Es müsste doch ohne riesigen Aufwand
> möglich sein, nach Druck auf den Button "Quick-Print" die
> Kanaleinstellungen und Messdaten über RS232 rauszuhauen. Dann
> würde man ja sehen, was der eine oder andere damit anfängt.

Könnte man machen, ist nur eine Frage der Prioritäten.

Hayo

Hallo,

Hayo W. schrieb:
> @Martin
> wenn ich mir Deine und meine Werte so ansehe, scheint mir, dass WELEC da
> eine feste Korrektur von 10 nS zwischen Kanal 1 + 2 in der originalen FW
> eingebaut hat.

Das wuerde auch den Bug bestaetigen, den ich mit der originalen 1.4 FW
hab', wenn ich bei nem Snapshot (unerlaubterweise vmtl.) die
Zeitbasis aendere.  Dann verschiebt sich Ch2 zu Ch1 nochmal um ~10nS.

Schalte ich wieder auf die Zeitbasis, mit der ich den Snapshot gemacht
habe, ist der zusaetzliche Versatz im Snapshot wieder weg.

Hallo,

@branadic:
Bravo, ganz meine Meinung. So viel Flexibilität wie möglich, 
Beschränkungen nur wo nötig.

Gruß, brunowe

P.S.: Natürlich hab ich heute wieder niemanden telefonisch bei Welec 
erreicht. Es ist einfach ein Trauerspiel!

Sag ich ja - sind in Italien!


@branadic

Das mit dem Individuellen Delay-Abgleich können wir natürlich machen, 
das wäre sicherlich die eleganteste Lösung


@Niklas

Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232 
Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das 
wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur 
Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick 
Print Button legen. Wäre Dir das recht?

Hayo

Hallo Hayo,

an der QM-Front hat sich die Erkenntnis ergeben, dass es möglich eine 
einzigen Funktion über 2423 Programmzeilen zu erstrecken, ohne einen 
einzigen Kommentar zu hinterlassen. g

Die FFT wird wohl früher fertig ;-)

Gruß,
Stefan

Hallo,

Hayo W. schrieb:
> @Niklas
> Wenn Du was zum Entwickeln haben möchtest, kann ich Dir über die RS232
> Daten schicken, die kannst Du dann auf der PC-Seite verwursten. Das
> wären zuerst einmal nur die Signaldaten und einige Parameter, da ich zur
> Zeit an einer anderen Baustelle zu tun habe. Ich könnte das auf Quick
> Print Button legen. Wäre Dir das recht?

Jau, das passt.  Ich werd' auch am WE mal schauen, dass ich
CDK4Nios bei mir zum Laufen bekomme, dann kann ich evtl.
auch selbst Hand anlegen.

Hallo,

hier die Werte von meinem Gerät. Bei mir scheint es mit dem 10 ns 
Korrekturwert in der Originalsoftware nicht zu passen.

Gruß

Kristian

@Stefan

Dann weißt Du ja auch warum ich da bislang noch nicht rangegangen bin. 
Das mit den nicht vorhandenen Kommentaren zieht sich durch die Ganze 
Software. Ungefähr 95% der Kommentare die Du jetzt in der Software 
findest sind von mir nachträglich eingefügt für besseres Verständnis.

@Kristian

Hm, die Werte weichen ja ziemlich ab. Na mal abwarten was noch so kommt.



Gruß Hayo

Hier meine Delayzeiten.

By the way: mit hohen Frequenzen (50 & 60 MHz Oszillatoren) hatte ich 
einige Probleme mit dem Triggern. Das Signal steht dann nicht still und 
springt hin und her.

Michel

Ich hatte gestern mal Verucht Wittig per Mail zu ereichen. Heute kam 
folgende Antwort:



Lieber Kurt,

vielen Dank auch nochmal für Ihre Anfrage zur Veröffentlichung
des Chip-Designs. Wir haben kein Problem von seitens Altera.
Unser Problem besteht bei einer Veröffentlichung, dass wir
eine Gemeinsamentwicklung mit einem namhaften Oszilloskophersteller
hatten, die auch einiges an IP zugesteuert hat. Deshalb konnten
wir keine Unterstützung in diesem Fall beibringen.

Bitte haben Sie Verständnis, dass wir nicht weiterhelfen können.
Wir selbst hätten auch keine Probleme die Veröffentlichung vorzunehmen.
Es sind also rechte an Dritten, die wir verletzen würden...
Das können Sie auch so an Ihre Gemeinschaft weiterleiten, so dass
bekannt wird, dass wir deshalb nicht weiterhelfen können.

Viele Grüße
Thomas

Dann gibts da draußen noch weitere Oszilloskope mit dem Design? Oh je

Oder sollten wir uns lieber freuen, dass es im FPGA nicht so schlimm 
sein kann, wie allgemein angenommen?

Genau, siehe auch Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"

@Stefan,
Es ging ja auch nicht nur darum den FPGA zu debuggen, sondern auch Teile 
der Hardwareansteuerung einzubauen, damit diese den Softcore nicht mehr 
belasten.

Die Delays scheinen aber auch vom Tastkopf abzuhängen. In die Lösung des 
Problems sollte man meiner Meinung nach jetzt nicht viel Energie stecken 
weil es für langsamere Signale keine Rolle spielt und das Oszi für HF 
zur Zeit noch nicht zu gebrauchen ist.

Hallo Kurt,

man kann auch richtig schnelle Signale messen, solange man nicht über 
einen best. Signalpegel (am ADC) kommt.
In der Anlage siehst du einen 140MHz_Sinus von meinem selbstgebauten DDS 
Signalgenerator. Wenn ich den Signalpegel aber nur etwas erhöhe, bzw. in 
den 1V/Div Messbereich runter schalte, fängt das Oszillieren an und 
macht eine sinnvolle Darstellung absolut unmöglich.
Eine Schwebung oder Aliasing konnte ich auch nicht feststellen.

Gerade weil die Delays etwas von den Tastköpfen abhängen, halte ich eine 
individuelle, einstellbare Anpassung für so wichtig!

Gruß, brunowe

Hallo Bruno,
so gesehen hast du natürlich Recht. Da brauchen wir aber bald schon 
Untermenüs weil die Softkeys knapp werden. ;-)

Gibt es irgendwo eine Beschreibung von deinem DDS?

Mfg,
Kurt

Kurt Bohnen schrieb:
> Die Delays scheinen aber auch vom Tastkopf abzuhängen.

Nein bei mir nicht. Ich habe extra die Tastköpfe bei jeder Messung 
getauscht - mit dem gleichen Ergebnis

> In die Lösung des Problems sollte man meiner Meinung nach
> jetzt nicht viel Energie stecken
> weil es für langsamere Signale keine Rolle spielt und das Oszi für HF
> zur Zeit noch nicht zu gebrauchen ist.

Meine Messungen habe ich mit einem 5MHz Rechteck durchgeführt. Selbst 
bei dieser Frequenz fand ich das schon recht störend. Der Aufwand für 
eine Mittelwertkompensation (wie in der originalen FW) ist recht gering 
und reduziert das Problem schon ziemlich. Nur für den manuellen Abgleich 
müßte man einen etwas höheren Aufwand betreiben.

Gruß Hayo

An die GERMSloader-Bastler:

Es wäre schön, wenn beim Dumping des Flashes auch die Prüfsummen 
berechnet und vergleichen würden. Im Falle eines Fehlers kann dann die 
Zeile einfach nochmals angefordert werden. Einerseits würde ich damit 
die Funktion überhaupt erst nutzen können (mein toller Port), 
andererseits ist somit für alle sichergestellt, dass der Dump 100% 
korrekt erfolgt ist.

Oha, so wie ich das sehe, spuckt der GERMSmonitor gar keine Prüfsummen 
aus?

Genau so ist es.

Dann werden wir mal kräftig Gas geben mit der Implementierung des 
Flash-Controllers, so geht das ja nicht weiter!

Kurzer Zwischenstand:

Ich habe die letzten Tage damit zugebracht die FFT komplett auf Integer 
umzustellen und das letzte an Performance herauszukitzeln. Ich denke es 
kann sich sehen lassen. Der Geschwindigkeitsgewinn liegt bei etwa Faktor 
8 bis 10. Das ist schon recht anständig wenn man bedenkt dass die 
Routine an sich ja eigentlich schon auf Geschwindigkeit optimiert war. 
Die Geschwindigkeit liegt jetzt bei 2 bis 3 FFTs pro Sekunde gegenüber 2 
bis 4 Sekunden pro FFT vorher.

Jetzt werde ich mal das Drumherum programmieren, damit man das auch 
anständig benutzen kann.

Gruß Hayo

Hallo liebe Gemeinde,

dieses Wochenende wird es mal kein neues Release geben, die Menüführung 
und Einstellmöglichkeiten für die FFT im Menü sind noch zu unausgereift. 
Ich denke da ist es besser erst einen etwas runderen Zwischenstand 
abzuwarten. Vielleicht kann ich bis dahin ja auch außer den Neuerungen 
von Guido auch noch weitere Verbesserungen von Euch mit einbauen.

Gruß Hayo

Hi Stefan,

das höre ich gerne. Ja bei mit wird es auch etwas dauern, ich habe 
gerade mal eine To Do Liste gemacht was ich so für eine komfortable 
Bedienung alles noch einbauen muß, da gibt es ordentlich was zu tun.

Guten Start in die neue Woche

Hayo

Hi Jürgen,

> In der o.g. Funktion ist also nur der Kommentar bei Ch3 bezüglich
> der Adresse falsch!

Immerhin haben wir jetzt wieder weitere Details geklärt und können davon 
ausgehen, dass zumindest hier alles funktioniert wie es soll. Ich werde 
mal die Kommentare in der Funktion überarbeiten (immerhin sind überhaupt 
irgendwelche Kommentare drin!).


> Bei ext.Triggerung und Trig.Modus Normal wird auf Ch3 und
> Ch4 nur jeder zweite Screen korrekt dargestellt.

Danke für den Hinweis das werde ich mal näher untersuchen. Interessant 
wäre, ob das ein Bug ist den ich eingebaut habe, oder ob der bei der 
originalen FW auch auftritt.

Gruß Hayo

Ok, gut zu wissen, dass das auch in der orig. FW auftritt.

Die Drehrichtungen sind zum Teil etwas durcheinander, und waren mir auch 
schon immer ein Dorn im Auge. Das wollte ich evtl. mal umstellen auf 
eine durchgängige Drehrichtung

- im Uhrzeigersinn erhöhen
- gegen den Uhrzeigersinn verkleinern

Gruß Hayo

Hallo,

ich hab' heute mal CDK4Nios eingerichtet und kann schon einzelne
Planes in S/W als Stream rausschreiben, ins PPM-Format wandeln
und darstellen.

Soweit ich den Aufbau bis jetzt verstehe besteht die GUI
aus etlichen Planes, die uebereinander gelagert schlieszlich
die sichtbare Ausgabe ergeben.

Um einen 1:1 Screenshot ueber "Quick Print->Save to BMP" usw.
rauszuschreiben muesste man also alle Planes in der richtigen
Reihenfolge aufeinander legen und kombinieren, d.h., Pixel
sichtbar/set oder nicht sichtbar/!set.

Dazu nun folgende Fragen an die Leute die schon laenger mit
der Firmware zutun haben:
* Ist mein Verstaendnis soweit richtig?
* Ist die Darstellreihenfolge der Planes bekannt?

Zudem noch die Frage, inwieweit der ganze Akt in der Firmware oder
einem PC-Programm erledigt werden soll, d.h., wieviel Flashspeicher
geopfert werden soll/kann.

Gruss,
Niklas

Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man 
die Screenshots direkt auf den Stick speichern kann.

Hi Niklas,

ich denke dass der Aufwand einen direkten Screenshot zu machen recht
hoch ist. Da ist es doch wesentlich einfacher nur die Signaldaten und
Parameter zu übertragen und dann das Signal zu rekonstruieren.

Ja Du hast das schon richtig gesehen mit den Planes. Es gibt eigentlich
für Alles und jede Ausgabe eine eigene Plane. Von der Plane abhängig ist
auch die Farbe, da die Farben immer pro Plane eingestellt werden. Welche
Planes da so auf den Schirm übertragen werden und in welcher Folge 
kannst
Du in TransferPlanes() sehen (in Hardware_t.cpp  Zeile 21245).

Flashspeicher ist knapp, da dort die ganzen Signale gespeichert werden,
siehe die von mir hier schon mehrfach veröffentlichten Memory Maps 
(gibts
auch in Google Groups). Ich habe jetzt schon Probleme die
trigonometrischen Tabellen für die FFT dort abzulegen.

D.h. dafür müßte man dann Signalspeicher hergeben.

Gruß Hayo

Hallo Hayo,

ich habe gerade fix mal meinen Code erweitert um "alle" Planes
zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
erstellt.  Dabei habe ich noch nicht die Reihenfolge in
TransferPlanes() beruecksichtigt, daher fehlen offensichtlich
einige Texte.

Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
im Code zurueck liegen, die clFarbe Konstanten sind definiert
und anscheinend nirgendwo referenziert.  Auch stoeren mich
bei dem bissl Code was ich bisher sah viele doppelte oder nicht
durchgehend benutzte Konstanten, wie auch fuer die Planes.

Da muesste mal aufgeraeumt werden.  Wie sieht da die Planung aus?
Ich waere natuerlich bereit da mit anzupacken.  Ich sehe, dass
ihr wohl bisher eher vorsichtig auskommentiert und teilweise
neu implementiert habt, um nicht gleich alles zu brechen.

Anbei der PoC-Screenshot.

...und hier noch der Stueck Code mit dem ich den Output erzeuge:

1

void Display::SCREENSHOT(void)

2

{

3

        int x, y;

4

        int bit, pos, offset;

5

        unsigned long *planes[] = {

6

                Grid_Plane,

7

                UI_Plane1, UI_Plane2, UI_Plane3, UI_Plane4, UI_Plane5,

8

                Channel_Plane1, Channel_Plane2, Channel_Plane3, Channel_Plane4,

9

                Channel_Math_Plane,

10

                Memory_Plane1, Memory_Plane2, Memory_Plane3,

11

                Marker_Plane1, Marker_Plane2,

12

                NULL

13

        };

14

        unsigned long *plane;

15

        int i, set;

16

17

        (void)printf("Pixel printout follows\r\n");

18

19

        for (y = 0; y < 480; y++) {

20

21

                for (x = 0; x < 640; x++) {

22

                        offset = x >> 5;                // x div 32

23

                        pos = Display_Line_Adresses[y] + offset;

24

                        bit = x - (offset << 5);        // x - (offset mod 32)

25

26

                        set = 0;

27

                        for (i = 0; (plane = planes[i]) != NULL; i++)

28

                                if (*(plane + pos) & BitMasks2[bit]) {

29

                                        set = 1;

30

                                        break;

31

                                }

32

                        if (set)

33

                                (void)printf("1");

34

                        else

35

                                (void)printf("0");

36

                }

37

                (void)printf("\n");

38

        }

39

40

        (void)printf("Pixel printout DONE\r\n");

41

}

Um das ganze darstellbar zu machen hab' ich einen PPM-Header
hinzugefuegt und 0/1 fuer Pixel gesetzt/ungesetzt in erfundene
Farbwerte gewandelt.  PPM habe ich nur gewaehlt, weil ich mich
da schon auskannte ;)

Natuerlich fehlen da noch die Original-Farben und eine platzsparende
Ausgabe (sind ja so 307200+480 Bytes die geschrieben werden auf RS232),
aber es ist m.E. mit geringerem Aufwand als erwartet machbar.

Gruss,
Niklas

Niklas O. schrieb:
> ich habe gerade fix mal meinen Code erweitert um "alle" Planes
> zu beruecksichtigen und einen Proof-of-Concept S/W Screenshot
> erstellt.  Dabei habe ich noch nicht die Reihenfolge in

Super! Genau sowas will ich schon immer haben, das ewige Abfotografieren 
des Bildschirms geht mir gewaltig auf den Zeiger. Nun das ganze einmal 
für Linux bitte. :D

/Hannes

Hallo,

ich hab' noch fix RLE Kompression fuer die Datenuebertragung(*)
eingebaut und blende ein paar Planes(**) aus damit man bei der
S/W Version die Beschriftungen lesen kann.

Damit kann man nun schonmal ein wenig anfangen.

Das Ganze samt Ausleseprogramm in C und kurzer Beschreibung
im Anhang.

Falls ich heute Abend Zeit habe geht's dann weiter an die
farbige Ausgabe.  Dazu werde ich wahrscheinlich die Planes
einzeln exportieren und ausserhalb des DSOs wieder eingefaerbt
zusammensetzen.  Haette auch den Nebennutzen einzelne unwichtige
Sachen, etwa fuer Dokumentationszwecke, wieder ausblenden zu koennen.

@Guido:
Soweit ich sehe wird PIXELP() mit den selben Speicherstellen
aufgerufen die ich auch verwende. Genau angeschaut habe ich
mir das allerdings noch nicht.

Gruss,
Niklas

(*) Etwa 10-15kB Daten pro Screenshot.
(**) Jene Planes die die Softbutton-Beschriftungen 
einrahmen/untermauern.

...und hier noch ein Beispiel-Screenshot.

Hallo Niklas,

Du gehst ja mächtig zur Sache. Das sieht schon wirklich prima aus. Ich 
hätte nicht erwartet, dass da so schnell solche Ergebnisse zu erzielen 
sind. Echt super.

> Bzgl. der Farben ist mir aufgefallen, dass da einige Altlasten
> im Code zurueck liegen, die clFarbe Konstanten sind definiert
> und anscheinend nirgendwo referenziert.  Auch stoeren mich
> bei dem bissl Code was ich bisher sah viele doppelte oder nicht
> durchgehend benutzte Konstanten, wie auch fuer die Planes.

Oh ja, wenn wir von etwas ausreichend haben, dann sind es Altlasten. Es 
sind leider so viele, dass wir nur Stück für Stück vorankommen.

> Da muesste mal aufgeraeumt werden.

Allerdings!

> Wie sieht da die Planung aus?

Zur Zeit gibt es im Wesentlichen folgende Hotspots:

- die Hardwareecke versucht Designfehler auf der Platine
  aufzuspüren und zu verbessern.

- ebenfalls der Hardwareecke zugeordnet sind die Kollegen
  die an anderen FPGA-Designs arbeiten.

- in der Softwareecke versuchen wir das Assemblercoding
  möglichst ohne Performanceverluste nach C zu portieren (Guido)

- an der Überarbeitung der Quick Measure Funktion ist Stefan dran

- einige der Forumsbesucher testen und schreiben Fehlerberichte

- einige sind auch einfach nur so im Coding unterwegs geben
  hier und da gute Hinweise auf mögliche Fehler.

- ich bin zur Zeit an der FFT-Implementierung dran

Du siehst es sind noch eine Menge Themen offen.

> Ich waere natuerlich bereit da mit anzupacken.

Das ist prima. Seit sich hier die Anzahl der Hilfswilligen so erhöht hat 
geht es deutlich schneller voran und wir können fast jede Woche ein 
neues Release mit zig Verbesserungen rausbringen.

> Ich sehe, dass ihr wohl bisher eher vorsichtig auskommentiert
> und teilweise neu implementiert habt, um nicht gleich alles
> zu brechen.

Ja, wir wollen das möglichst so machen, dass wir immer ein einigermaßen 
stabiles Release haben mit dem man auch richtig arbeiten kann. Bislang 
haben wir das so gehandhabt, dass ich die neuen Release rausgegeben habe 
und die Änderungen der anderen Entwickler mit eingebaut habe. Das läuft 
auch ganz gut und verhindert, das es zig Versionen mit unterschiedlichem 
Stand gibt. So können immer alle auf den gleichen neuen Stand wieder 
aufsetzen mit Ihrem nächsten Entwicklungsschritt. Auch bei den Tests ist 
das wegen der Vergleichbarkeit der Ergebnisse sehr Hilfreich.

Gruß Hayo

Kurt Bohnen schrieb:
> Evtl. wäre später auch ein USB Host mit dem Vinculum sinnvoll, damit man
> die Screenshots direkt auf den Stick speichern kann.

Hallo Kurt,

da muss ich dich leider enttäuschen. Im Gerät steckt ein Cypress EZ-USB 
FX1, der nicht als Hostcontroller taugt. Da müsste also eine 
Zusatzplatine entwickelt werden...

Wenn wir gerade schon dabei sind: Ich habe am Wochenende nach dem 
JTAG-Zugang zum 2. FPGA der 20x4er gesucht. Leider kam heraus, dass 
vergessen wurde, TCK an den 2. FPGA zu routen, aber das kennen wir ja 
nicht anders von den Wittigs.
Nichts desto trotz habe ich eine interessante Entdeckung dabei gemacht. 
Direkt oberhalb des 2. FPGA, neben dem Steckverbinder zum Frontpanel, 
sind 8 ungenutzte Pins des 2. FPGA auf Pads geführt. Hier könnte evtl. 
eine Art Erweiterungsschnittstelle realisiert werden für Nutzer der 
20x4-Geräte (die 20x2-Eigentümer müssten dazu leider schon direkt an die 
BGA-Bälle der Pins, die vom 1. FPGA kommen, ran. Haare spalten (der 
Länge nach) ist glaube ich einfacher).
Mindestens aber könnte dort z.B. ein SD-Cardreader angebracht werden.

Soviel zur Hardware, denn das ist hier der Softwarethread!

P.S. das nächste FPGA-Design zum "Spielen" lässt leider noch auf sich 
warten, da noch einige grundlegende Umstrukturierungen ausstehen, da ich 
mich mit einigen Fiesigkeiten lange aufgehalten habe. Sorry! Aber 
Downsampling und Timebases funktionieren, mittlerweile auch korrekt.

Hallo Daniel,
das mit dem EZ-USB ist schon klar.

Für den VNC1L-1A (Vinculum) USB-Controller gibt es eine fertige Firmware 
(VDAP) die alle Aufgaben der Ansteuerung eines USB Sticks inkl FAT 
realisiert.
Man muss nur einige Parameter über SPI oder UART übergeben, und der 
Vinculum schiebt die Daten auf den Stick.
Siehe auch Beitrag "USB-Stick am Mikrocontroller VNC1L"

Ich selbst habe sowas noch nicht gemacht und hoffe es trotzdem richtig 
verstanden zu haben.

Der Hinweis im Firmware-Thread weil es vieleicht sinnvoll ist, einen 
kompletten Screendump inkl. Dateiheader im Oszi zusammenzusetzen. Aber 
darüber muss mann weiter nachdenken...

Auch wenn Abfotografieren bald nicht mehr State of the Art ist ;-)
(wenn Niklas da so weitermacht) hier ein Screenshot einer
Logarithmierten FFT.

Ich freue mich, dass ich es geschafft habe die Logarithmierung zu 
implementieren, ohne spürbaren Performanceverlust gegenüber der 
liniearen Darstellung.

Das war nicht von Anfang an so! Erste Versuche mit der originalen 
Bibliotheksfunktion log10() haben massive Performanceverluste nach sich 
gezogen und die Wiederholrate auf 5 S pro FFT runtergedrückt - trotz der 
optmierten FFT-Routinen.

Das sieht schon alles soweit ganz gut aus, so dass ich hoffe zum 
nächsten Wochenende die nächste Beta rausgeben zu können.

Gruß Hayo

Deswegen habe ich ja auch etliche Sachen komplett neu gemacht.

Hayo

Jupp!

Hallo,

so, ich bin dann noch dazu gekommen die Screenshot-Funktion
auf farbige Ausgabe zu erweitern.  Wie angekuendigt exportiere
ich die Planes einzeln.  Das Programm speichert diese auch
einzeln ab, was vllt. auch fuer die Entwicklung interessant ist.
Was mir schon auffiel:  Die Plane fuer den Ch 4 wird "missbraucht"
um die roten Pfeile und das Stop(p)-Schild zu malen.

Diff, fertig kompilierte TomCat.ram und C-Programm wie beim
letzten Mal schon im angehaengten .tgz.  Alles weitere und
Changelog in der README-Datei.

Dem C-Programm steht btw. nichts entgegen, nicht auch mit Cygwin
oder MinGW fuer Windows kompiliert zu werden.  In der kurzen
Zeit hab' ich (auch mangels Windows mit installiertem Cygwin
oder anderem Environment) mich noch nicht darum gekuemmert.

Falls fuer Windows-User die PGM/PPM Bildformate ein Problem
darstellen laesst sich das sicher auch zu BMP umstricken, wie
schon gesagt, wird nur verwendet da ich mich damit schon
auskannte.

@elgodil:
> -Auslösen durch Tastenkombination(nen z.B. 1 x RAW
> (durch ext. Programm manipulierbar) 1x als BMP o.ä.
> (also gleich verwendbar)

Tastenkombination waere ' bzw. # derzeit.  BMP weisz
ich nicht was es da fuer Platzeinsparungsmoeglichkeiten
mit RLE und Paletten gibt und wie hoch da der jeweilige
Aufwand in der Firmware waere.

Generell bin ich auch fuer die Option der Ausgabe in einem
wohldefinierten und universellen Format.
Bei USB sehe das vmtl. schon anders aus da dort offensichtlich
die Uebertragungsgeschwindigkeit nicht so ins Gewicht faellt.

> -Ausgabe seriell als Z-Modem (also so, das gleich
> der "Abspeichern" Dialog aufpeppt

Die Idee finde ich gut und es waere ein Schritt dahin,
das DSO mit "Boardmitteln" wie HypterTerm oder
Minicom ueber RS232 ansprechen zu koennen, auch
hinsichtlich der Ausgabe und Speicherung von
Messwerten direkt in eine (CSV-)Datei.

Ich werde dann aber wahrscheinlich X-Modem-1K-(CRC16) benutzen.

Gruss,
Niklas

...und hier noch ein Beispielscreenshot mit der Ausgabe
von Hayos Test-Signal-Funktion.

Hinweis:  Auf dem Oszi uebermalt der lila Math-Channel
die Browse-Scroll-Leiste (wie heiszt die korrekt? ;)),
im Ausleseprogramm habe ich die Reihenfolge veraendert
damit die Ausgabe im Screenshot "korrekter" ist.

Hi Niklas,

Du bist ja mächtig fix! Ich bin noch nicht zum Ausprobieren gekommen, 
aber ich denke ich werde das mal mit in die nächste Beta einbauen. Da 
bietet es sich ja an das ins Print-Menü zu integrieren, damit man nicht 
immer über das Terminal triggern muß.

Super!

Gruß Hayo

Schöne Sache dein Screenshoot.

Hi,

für diejenigen, die nicht so oft im Hardwarethread unterwegs sind hier 
die Anleitung wie man die Luftzufuhr im Gerät optimieren kann.

Gruß Hayo

Hallo Hayo,

tolle Beschreibung! Ich hab mir erlaubt das ganze in SF einzufügen.
http://sourceforge.net/apps/trac/welecw2000a/wiki/Modifications

Noch etwas aus meiner Wishlist:
Bei meinen Tests ist es mir schon häufiger aufgefallen, das mein 
HF-Signal von einer  NF-Schwingung überlagert ist. Sehr schwer 
gleichzeitig darzustellen- Man muss die Zeitbasis entsprechend verändern 
und verliert dadurch zwangsläufig die andere Schwingung aus dem Auge. 
Deshalb mein Wunsch nach einer zweiten Zeitbasis. D.h. es wäre doch 
wunderbar wenn ich z.B. den Ch1 mit 50ns/Div und den CH2 mit z.b. 
1ms/Div darstellen könnte. Gute, teure Oszis haben da ja eine echte 
zweite Zeitbasis, aber eine entsprechende Darstellung zweier Kanäle mit 
unterschiedlicher Zeitbasis sollte doch auch bei uns zu verwirklichen 
sein? Im neuen VHDL Design werden wir eine entsprechende Verwirklichung 
dieses Features auf jeden Fall anstreben.

Gruß, brunowe

P.S.: Meine Wunsch nach einer variablen Verstärkung (vertikales zooming) 
ist auch noch in der ToDo list? Nicht das das verloren geht...

Hi Bruno,

wie soll denn die zweite Zeitbasis einzustellen sein? Der Einsteller für 
die eigentliche Zeitbasis ist ja schon vergeben.

Eine Möglichkeit wäre ein Umschalter oder sowas in der Art. Wie ist das 
denn an den besagten teuren DSOs realisiert?

Gruß Hayo

p.s. Hier geht nix verloren - letztlich werden alle Wünsche erfüllt 
(hoffe ich)

Hallo,

also ich kenne jetzt konkret das HAMEG 1508-2 (Mixed Signal combi 
scope), das HM 2005-2 (analog scope) und das Philips PM3092 mit 2 
Zeitbasen. Wie die Umsetzung bei den analogen Oszis funktioniert ist 
relativ einfach erklärt. Es gibt eine Haupt- Zeitbasis (die langsamere), 
mit dieser wird das Signal getriggert und dargestellt. Innerhalb dieser 
dargestellten Zeitspanne wird jetzt mit einem bestimmten, einstellbaren 
delay, dieses Signal mit einer schnelleren Zeitbasis dargestellt. Es 
kann damit also eine Ausschnittsvergrößerung dargestellt werden.

In unserem Fall müsste man das interessierende Signal auf zwei Kanälen 
sampeln um eine entsprechende Vergrößerung darstellen zu  können. Ich 
würde auf jeden Fall den Kanal 1 fix mit der Hauptzeitbasis koppeln. Den 
Ch2 dann, mit einer über das Menü (neuer Menüpkt. neben Probe), zu 
aktivierenden zweiten Zeitbasis belegen. Zugegeben ist das 
wahrscheinlich etwas komplexer zu verwirklichen (Trigger und delay 
Problematik...) und bestimmt gibt es noch einen ganzen Stapel anderer, 
wichtigerer Baustellen... Dennoch wollte ich dieses Feature einfach mal 
erwähnen.

gruß, brunowe

@Guido,

das wäre wohl die einfachste und genialste Möglichkeit. Man würde sich 
damit sogar den zweiten Kanal einsparen. Guter Einfall!


gruß, brunowe

Den verstehe ich nicht so ganz.

Wo ist da der Unterschied zum jetzigen Delayed Modus, wenn man mal davon 
absieht das es nicht mit zweimal sampeln realisiert ist sondern einfach 
mit unterschiedlichen Zoomfaktoren.

Oder hab ich da was falsch verstanden?

Hayo

Hallo,

ich hab hier als Beispiel die Darstellung von einem Fernseh-BAS Signal 
angefügt. Mit unseren Mittel ist es derzeit nicht möglich, gleichzeitig 
das komplette BAS Signal für eine Bild-Zeile und das 
Trägerfrequenzsignal darzustellen... um solche und ähnlich komplexe 
Signaldarstellung geht es im Prinzip.

Vielleicht noch ein wichtiger Punkt zur Anmerkung. Die Nutzung des 
Delayed Modus hat natürlich den gravierenden Nachteil, das man für die 
zeitl. gezoomte Darstellung die Spannungsauflösung nicht unabhängig von 
der Hauptdarstellung einstellen kann. Ein echtes Manko meiner Meinung.


gruß, brunowe

Hallo werte Gemeinde,

leider bin ich heute nicht mehr ganz fertig geworden, so dass es die 
neue Beta erst morgen geben wird. Schon mal soviel vorweg, das Warten 
hat sich gelohnt. In das neue Release sind zahlreiche Bugfixes und 
Korrekturen eingeflossen (Mathfunktion, Statusbar Kanalanzeige, 
Menü-Updatelogik etc.). Desweiteren habe ich die C-Routinen von Guido 
eingebaut und die neue Screenshot-Funktion von Niklas ins Quickprint 
Menü integriert. Und als Highlight verfügt das W20xxA jetzt über eine 
Spektralanalyse (FFT) die sich nicht vor der teurerer Geräte verstecken 
muß.

Bis morgen

Hayo

Hallo,

ich hab' heute Nachmittag damit angefangen, eine minimale
ZModem-Implementation (derzeit ca. 290 Zeilen) fuer das DSO zu bauen. 
Eigentlich wollte ich ja, weil wesentlich einfacher, XModem, aber dann
haette man den Dateiempfang per Hand anstoszen muessen.

Das ganze laeuft schonmal "im Trockenen", ich muss allerdings
noch eine zusaetzliche ISR Routine fuer den UART schreiben, der
die empfangenen Bytes zwischenbuffert bis diese weiterverarbeitet
werden.

(Derzeit mache ich ungefaehr:

1

static int rd_char(void)

2

{

3

        while (!(puart->np_uartstatus & np_uartstatus_rrdy_mask))

4

                ;

5

        return nr_rxchar();

6

}

1

Hardware::DoDisableUARTInterrupt();

2

[Verarbeitung]

3

Hardware::DoEnableUARTInterrupt();

Was, im Schneckentempo ;), zum ersten Testen okay ist.)

Screenshots (und Messdaten) sollen dann wahlweise "roh" wie
gehabt oder per ZModem direkt in eine Datei uebertragen werden
koennen.

Nun stellt sich aber noch ein Problem:  Bei ZModem muss
ich dem Empfaenger den Dateinamen mitteilen.  Wenn der
Dateiname bereits existiert wird je nach Implementation
des Empfaengers unterschiedlich verfahren: HyperTerminal
ueberschreibt wohl ungefragt, lrzsz ueberspringt die Datei.
Immer den gleichen Dateinamen benutzen scheidet also aus.

Optimal waere es natuerlich, wenn wir einen Dateinamen
mit Uhrzeit und Datum generieren koennten, aber das scheidet
wohl auch aus.  Daher wuerde ich vorschlagen, eine mehrstellige,
aufsteigende Zahl anzuhaengen (also z.B. screen-nnnn.dat und
meas-nnnn.dat) aehnlich dem wie es Digitalkameras machen.
Dabei wuerde der letztverwendete Wert fest im Flash
gespeichert und so einen Reboot ueberdauern.

Vllt. hat jemand auch eine andere Idee?

Gruss,
Niklas

Hi Folks, new 0.80 Beta out now!

Wie versprochen die neue Version vollgepackt mit Neuerungen.

Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
ganz perfekt, aber schon ganz ordentlich.

Ich bitte explizit um kritische Rückmeldungen.


@Niklas

Zu Deinem ZMODEM/XMODEM Problem kann ich leider nichts beitragen, aber
vielleicht kannst Du mir helfen. Ich habe Deine Routinen ins Quick Print
Menu eingehängt, aber das Programm scheint keine Verbindung zum DSO zu
kriegen.

Ich starte das Programm in einem Shellfenster und es signalisiert, dass
es wartet. Wenn ich dann den Screenshot starte friert der DSO-Bildschirm
kurz ein - und das war's. Das Programm reagiert aber nicht.

Stell ich mich da zu dusselig an oder hab ich was falsch verstanden?

Gruß Hayo

Jetzt noch die Datei...

Ach ja,

nicht vergessen erstmal Default Setup zu drücken und dann die Timebase 
zu drehen, damit die neuen Flashwerte für die FFT initialisiert werden.

Gruß Hayo

Lässt sich das nicht irgendwie automatisieren? Man kann doch bestimmt 
die Firmwareversion irgendwo unter den Einstellungen ablegen, so dass 
sie bei einem Flash nicht überschrieben wird, und dann beim Boot die 
aktuelle gegen die Version im Configbereich prüfen und die ganze 
Initialisierung dann bei Bedarf starten.

Ok, wirr ausgedrückt, aber sicher kommt rüber, was ich meine?

/Hannes

Hallo Hayo,

ich vermute mal, dass Du vergessen hast dem Programm
stdin auf das serielle USB-Device umzuleiten, ansonsten
liest das Programm nur die Tastatureingaben auf der
Konsole und wartet ewig.

Wichtig ist auch, dass das tty richtig konfiguriert ist,
wichtig ist der raw-Modus, da ich ohne Ruecksicht auf
Verluste (etwa Software-Handshake mit XON/XOFF) 8bit binaer
rausschreibe.

Bei mir mit USB<->RS232 Wandler sieht das z.B. dann so aus:

1

$ stty -F /dev/ttyUSB0 raw 115200 

2

$ ./w2000a-screenshot < /dev/ttyUSB0

3

* Waiting for Screenshot...

4

[Quick Print->Save to PGM]

5

* Found Screenshot Start Marker

6

  - Receiving Plane #01...

7

    Read 12572 bytes.

8

    (another plane follows)

9

[..]

10

* End of Transmission

11

* Total bytes transferred: 62918

12

* Combining...

13

* Done

Ich hoffe es klappt dann bei Dir auch.

Niklas

Niklas O. schrieb:
> Ich hoffe es klappt dann bei Dir auch.

Bei mir klappt es so auf jeden Fall, allerdings sind eine (bzw. mehrere) 
Planes verschoben und es werden Planes mit ins Endbild reinkombiniert, 
die gar nicht auf dem DSO angezeigt werden.

Auf dem angehängten Bild sieht man das verschobene Grid, das Signal 
dagegen ist nicht verschoben (hab es vorher mit dem Testsignal 
ausprobiert, nicht dass du denkst, ich hätte das Rauschen da im Anhang 
mit dem DSO verglichen :D). Und die Plane mit dem Quickmeasusre-Display 
war auf dem Scope selbst nicht sichtbar. Ich hatte vorher mal irgendwo 
Quickmeas kurz ein- und wieder ausgeschaltet, vllt liegt es daran?

/Hannes

Hallo Hannes,

das sollte so natuerlich nicht sein, ich vermute mal, dass da
aus irgendwelchen Gruenden da andere, falsche, Speicheradressen fuer
die Pixeldaten ausgelesen werden -- oder es ist ein Fehler im
Ausleseprogramm.  Offene Menues usw. sind egal.

Ich schaue mir das morgen in Ruhe an, welche Firmwareversion hast
Du denn verwendet?

Niklas

1.2.BF.0.80

/Hannes

So der Reihe nach:

@Hannes

Das ist eine nette Idee, aber das funktioniert leider nur rückwärts wenn 
überhaupt. Denn wenn ich neuen Speicherplatz für neue Variablen im Flash 
belege, dann steht da erstmal nur irgendein Zufallswert drin. Durch das 
Default Setup und das Verändern der Zeitbasis  werden dann definierte 
Werte ins Flash geschrieben und in Zukunft ist alles ok. Normalerweise 
verwende ich jedesmal neue Adressen, so dass bei Verwendung älterer 
Versionen keine Probleme auftreten. Nur in Ausnahmefällen ändere ich 
bestehende Belegungen (z.B. bei vorherigen Inkonsistenzen).


@Niklas

Ok, dann hab ich mich wohl dusselig angestellt. Ich gebe zu, dass ich 
nicht so der erfahrene Linux Kommandozeilenfreak bin. Zwar habe ich mich 
langsam mit meiner Suse Distribution angefreundet, aber eigentlich bin 
ich eher Windowsbenutzer und durch die FW-Programmierung auf die Vorzüge 
von Linux aufmerksam geworden.

Danke für den Hinweis, ich werde das mal ausprobieren. Grundsätzlich 
scheint es ja zu funktionieren wie ich dem Beitrag von Hannes entnehme.


@Elgodil

Wieso Fehlkauf? Ich hab mir die Teile gekauft weil ich wußte dass es da 
was dran zu optmieren gibt. Und bevor einer fragt: Ja ich habe auch eine 
Frau und Freunde und auch noch andere Interessen  ;-)


@all

Wer nicht so richtig was mit der FFT-Funktion anzufangen weiß - nicht 
verzweifeln, ich arbeite gerade an einer Anleitung mit 
Hintergrundinformationen, die hab ich aber heute nicht mehr 
fertiggekriegt, kommt aber in Kürze.

Gruß Hayo

Hayo W. schrieb:
> Hi Folks, new 0.80 Beta out now!
>
> Wie versprochen die neue Version vollgepackt mit Neuerungen.
>
> Die FFT ist noch nicht ganz durchgetestet und die Menüführung noch nicht
> ganz perfekt, aber schon ganz ordentlich.
>
> Ich bitte explizit um kritische Rückmeldungen.
Hallo Hayo,

super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was 
mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch 
mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der 
FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024) 
eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und 
rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten 
der beiden Kanäle ging über zunächst einschalten (LED an) und dann 
wiederum ausschalten - dann waren sowohl die LED aus als auch die 
Anzeige des Kanals auf dem Monitor aus.

Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert 
liegt an der fehlenden Anpassung an das neue Grid - oder?

Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin 
(vermutlich noch von der Welec-FW her): "Frequency" heißt dort 
"Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme 
- dafür aber auch in wenigen Sekunden gefixt :-)

Super Arbeit - ist schön zu sehen, wie immer mehr geht!

Gruß,
Bernd

Hallo,

(siehe UPDATE unten)

ich hab' mal die Screenshot-Funktion in der aktuellen 0.80
bei mir getestet, im Verdacht, dass das von Hannes beobachtete
Problem etwas mit Aenderungen in der Firmware zutun hat.

Funktioniert allerdings weiter wie gehabt bei mir.  Ich tappe
auch ziemlich im Dunkeln, woran es bei Hannes liegen kann.

Daher mal frage an alle die es testen koennen:   Funktioniert es
bei euch korrekt?

@Hannes/demofreak:
Kannst Du mir ein Log der RS232 Ausgaben vom Oszi zukommen lassen?
(also stty ttyS0 115200 raw, cat /dev/ttyS0 > log,
Quick-Print->Save to PGM, warten bis Oszi wieder reagiert
und CTRL-C zum beenden von cat).
Dann koennte man eine Seite schonmal ausschlieszen.

UPDATE:  Ich hab' gerade mal frisch FW in RAM eingespielt,
keine Veraenderungen an Schaltern, keine Drehgeber bewegt
und auch kein Default-Setup vorgenommen und direkt Screenshot,
und das Oszi schreibt wild komische Speicherinhalte raus mit
Textausgaben aus dem Programmcode.
Ergab 180984 Bytes (!) (statt 60-65K).

Das ganze durch das C-Programm gejagt, und siehe da, es
sieht erschreckend aehnlich zu Hannes Ausgabe aus.

D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
usw. und nochmal Screenshot testen.

Den Effekt verstehe ich nicht so ganz, wo doch egtl. der RAM-Inhalt
ueberschrieben wird.  @Hayo oder jemand anderes eine Idee?

Gruss,
Niklas

Mhm, nochmal kurz etwas im Firmware Code rumgeschaut:

In Hardware::Set_Vars_Default() werden zwar die von mir
verwendeten Konstanten mit den Speicheradressen der Planes
nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),
was mir doch spontan in Anbetracht der beobachteten
Effekte ziemlich wichtig erscheint nach dem Laden der FW
ins RAM und vor Screenshot ;)
(Installierte FW ist bei mir btw. die Original 1.4)

D.h., Frage an @Hayo damit wohl erledigt.

Mehr bzgl. ZModem und Messdaten vllt. heute Abend.

Niklas

Niklas O. schrieb:
> D.h.: Bitte Default-Setup durchfuehren, Zeitbasen veraendern
> usw. und nochmal Screenshot testen.

Hatte ich selbstverfreilich gemacht, direkt nach'm Boot unten rechts den 
Knopf "Default Setup" und danach oben einmal hin- und hergedreht. Hab 
ich jetzt eben nochmal gemacht, ohne Effekt.

/Hannes

Hallo Hannes,

mhm, komisch...

Lass mir dann doch mal die RS232 Ausgabe vom DSO beim
Screenshot zukommen.

Niklas

Bernd O. schrieb:
> super Arbeit, die FFT funktioniert tatsächlich schon ziemlich gut. Was
> mir noch fehlt ist eine Beschriftung der Frequenzachse. Rein statisch
> mit Anfangsfrequenz + Delta/div würden schon ausreichen.

Ja, sowas ging mir auch schon durch den Kopf, allerdings ist das 
statisch nicht möglich, da ja die Frequenzachse je nach eingestellter 
Zeitbasis vatiiert. da müßte man also einen Refresh mit einbauen

> Ich hatte noch ein Problem beim Einstieg bzw. bei der Rückkehr aus der
> FFT. Dabei haben sich immer mal wieder Kanal 3 und 4 (WL 2024)
> eingeschaltet und zwar so, dass auf dem Monitor sichtbar die blaue und
> rote Linie kommt, aber die blaue und rote LED aus blieben. Ausschalten
> der beiden Kanäle ging über zunächst einschalten (LED an) und dann
> wiederum ausschalten - dann waren sowohl die LED aus als auch die
> Anzeige des Kanals auf dem Monitor aus.

Danke für den Tip, ich habe alle Tests nur auf dem Zweikanalgerät 
gemacht weil es den leiseren Lüfter hat. Daher sind mir diese 
Eigenheiten noch nicht aufgefallen.

> Dass bei den QuickMeasurements noch (so gut wie) nichts funktioniert
> liegt an der fehlenden Anpassung an das neue Grid - oder?

Ja so ist es, da hab ich bis jetzt auch nichts geändert oder getestet. 
Stefan hatte sich das mal angesehen und war eher nicht so begeistert...

> Bei den Quickmeasurements ist noch ein kleiner Schreibfehler drin
> (vermutlich noch von der Welec-FW her): "Frequency" heißt dort
> "Freqency" (also ohne "u"). Sicherlich eines der allerkleinsten Probleme
> - dafür aber auch in wenigen Sekunden gefixt :-)

Kann ich ich mal fixen für die nächste Beta.

> Super Arbeit - ist schön zu sehen, wie immer mehr geht!
>
> Gruß,
> Bernd

Danke,

Hayo

Da ist definitiv noch was krumm.

Wollte direkt nach dem Erstellen des obigen Screenshots nochmal ein Log 
anfertigen, allerdings hat sich das Oszi nach Drücken von "Save to PGM" 
dann aufgehängt. Also rebootet und nochmal versucht, Log zu schreiben.
Dabei wuchs die Logdatei auf über 300kb an, hab das dann ebenfalls 
abgebrochen. Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und 
unten links war ein Softbutton "Cancel" zu sehen, als ich den gedrückt 
habe, bin ich im Quickmeasure gelandet (Cursor sichtbar und unten die 
Einblendung der Messwerte).
Also nochmals rebootet und wieder versucht, Log zu schreiben. Das hab 
ich dann ebenfalls bei reichlich 300kb abgebrochen und hier mal 
angehängt. Das Oszi reagiert nicht, komischerweise war Triggerung auf 
einmal auf PW statt auf Edge, das muss sich im Verlauf des 
Datentransfers irgendwie geändert haben. Musste also wieder rebooten.

Hab jetzt dreimal "Save to PGM" gedrückt, ohne auf der Rechnerseite das 
cat zum Logschreiben zu starten, dabei hängt sich das Oszi nicht auf.

[...]

Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt. 
Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht 
denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine 
Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim 
Rumdrücken auf dem Oszi mehrmals plötzlich im Quickmeasure-Menü 
gelandet, Math hat sich lustig ein- und wieder ausgeschaltet und auch 
die Triggerung war ab und an auf PW. Wenn cat nicht läuft, passiert 
sowas (natürlich) nicht.

Hat cat ein Echo?

/Han-"Der Ratlose"-nes

Niklas O. schrieb:

> In Hardware::Set_Vars_Default() werden zwar die von mir
> verwendeten Konstanten mit den Speicheradressen der Planes
> nicht gesetzt, aber ganz am Ende folgt ein ClearPlanes(),

Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz 
Bescheid sagen damit ich das einbauen kann.

Hayo

@Hannes

Das hört sich für mich definitiv danach an, dass Daten in die Serielle 
Schnittstelle (Richtung DSO) geschrieben werden. Denn was Du da 
beschreibst ist genau das was man sonst via Terminal und Tastatur 
fernsteuern kann.

Ansonsten hat es sich schon des Öfteren bei unerklärlichen 
Merkwürdigkeiten bewährt einen frischen Flashdump einzuspielen.

Gruß Hayo

Johannes Studt schrieb:
> Hängt irgendwie mit cat zusammen, hab gerade nochmal bissi rumgespielt.
> Offenbar wird das Oszi "fernbedient". Kann mir zwar nicht so recht
> denken, wie das gehen soll, weil ich ja die Daten von ttyS0 in eine
> Datei schreibe und nicht umgedreht, aber es ist definitiv so. Bin beim

ist da irgentwo noch das Echo eingeschaltet ?

Gruß,
Günter

Dass sich das so anhört, als wenn Daten in die serielle Schnittstelle 
geschrieben werden, ist mir klar. :D Und welches Echo soll wo 
angeschalten sein? Ich verwende cat, dass das echot, wäre mir neu.

stty -F /dev/ttyUSB0 raw 115200
cat /dev/ttyUSB0 > log

Desterwegen bin ich ja ratlos. ;)

Hab vorhin einen weiteren Logversuch bei ca. 300kb Dateigröße 
abgebrochen (das Oszi war noch nicht fertig, sprich: reagierte noch 
nicht) und einfach nicht weiter hingeschaut. Ein oder zwei Minuten 
später stand das Oszi wieder im Quickmeasure. :D

Es lebt.

/Hannes

Johannes Studt schrieb:
> stty -F /dev/ttyUSB0 raw 115200

ergänze das mal:
  stty -F /dev/ttyUSB0 raw -echo 115200

Gruß,
Günter

Hallo Hannes,

Dein Log sieht so aus als haette das DSO wie in einer
Endlosschleife immer und immer wieder Screenshots auf
RS232 ausgegeben.

Wenn ich hergehe, und den ersten aus der Log-Datei
wegwerfe, erhalte ich einen korrekten Screenshot
(siehe Anhang).

D.h.:

1

$ ./w2000a-screenshot < logalt

2

[..]

3

* Total bytes transferred: 59326

4

[..]

5

$ dd if=logalt of=logalt2 bs=1 skip=59326

6

[..]

7

$ ./w2000a-screenshot < logalt2

8

[..]

9

* Total bytes transferred: 61556

10

[..]

(Und das ist der angehaengte Screenshot als .png.
Genau so kann auch verfahren werden um die weiteren
zu extrahieren.)

Wenn man sich die Logdatei im (Hex)-Editor anschaut,
sieht man auch warum da der erste Screenshot bei
Dir kaputt ist.  Nach dem Start-Marker S 0xFF kommen
zwei vmtl. gueltige Bytes und dann die Textausgabe
einer Test-Funktion, gefolgt vom Rest des Screenshots.

Warum die da erscheint/erscheinen kann hab' ich noch
nicht geschaut, vmtl. aus einer ISR heraus.

---

Bzgl. "Oszi aufhaengen" gehe ich daher auch davon aus
das es damit beschaeftigt ist auf RS232 auszugeben.

Da dies nicht passiert wenn kein Programm die Schnittstelle
ausliest deutet tatsaechlich darauf hin, dass da irgendwas
"geschrieben" wird.  Aber cat kann es nicht sein, stdout
und stderr waeren ja die Konsole und nicht /dev/ttyS0.

Auch das unmotivierte Rumspringen in den Menues deutet
darauf hin, denn man kann ueber RS232 das Oszi fernsteuern.
(1-6 sind die Soft-Buttons, i,j,k,l sind die Kanaele usw. usf.)

Ich kann nur mutmaszen, wuerde aber auf falsche Konfiguration
des ttys tippen.  Schau mal nach ob das bei Dir anders aussieht:

1

$ stty -F /dev/ttyUSB0

2

speed 115200 baud; line = 0;

3

min = 1; time = 0;

4

-brkint -icrnl -imaxbel

5

-opost

6

-isig -icanon

7

$ stty -g -F /dev/ttyUSB0

8

0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

> Sah sowieso seltsam aus, es war nur Kanal 1 sichtbar und
> unten links war ein Softbutton "Cancel" zu sehen [..]

Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
aufrufe.

---

@alle:
Haben noch andere hier Probleme mit der Screenshot-Funktion?

Niklas

Hallo nochmal,

ich hab' leider Eure Nachrichten in der Zwischenzeit
erst jetzt gesehen.

Das echo wie Guenter und Hayo vermuten wird's wohl sein.

@Hayo:
> Hätte ich da irgendwelche Werte setzen müssen? Wenn ja dann kurz
> Bescheid sagen damit ich das einbauen kann.

Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
das am sinnvollsten anstelle.

Niklas

Niklas O. schrieb:
>

1

  $ stty -F /dev/ttyUSB0

2

  speed 115200 baud; line = 0;

3

  min = 1; time = 0;

4

  -brkint -icrnl -imaxbel

5

  -opost

6

  -isig -icanon

7

  $ stty -g -F /dev/ttyUSB0

8

  0:4:1cb2:8a38:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

9

>

das ist genau die raw Einstellung und da ist echo noch an,
d.h. der tty-Treiber echo(ed) einkommende Zeichen,
deshalb mein Vorschlag noch ein -echo beim stty Befehl anzuhängen.

Gruß,
Günter

Kaum macht man es richtig, geht es plötzlich. Komisch. :D

@Günter: danke, wieder was gelernt. Das -echo hat's gebracht.

/Hannes

Niklas O. schrieb:
> Das hab' ich wenn ich ohne im GERMS-Monitor zu sein GERMSLoader.pl
> aufrufe.

Ah, guter Hinweis. Das könnt ich sicher mit abfangen bzw. zumindestens 
versuchen, herauszubekommen, ob ich ins Menü oder wirklich in den 
GERMS-Monitor "reingucke".

Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...? 
grübel
Ich werd echt alt.

/Hannes

Hallo Guenter,

Du hast absolut recht.

Ich nehme jetzt stark an, dass der Effekt den ich heute Morgen beim
eiligen Reproduzier-Versuch hatte genau darauf zurueckzufuehren ist,
ich hab' naemlich das ganze samt Dongle auch am Laptop getestet...

Niklas

Niklas O. schrieb:

> Nein :)  Aber fuer die aufsteigende Zahl als Anhang bei den
> ZModem-Dateinamen braeuchte ich dann wohl nen festen Speicherplatz
> im Flash, vllt. kannst Du mir da nen Hint geben wo und wie ich
> das am sinnvollsten anstelle.
>
> Niklas

Jupp, das machst Du in flash_t.cpp:

- Funktion AMDFlash::Write_Config_Flash() Zeile 1408 schreibt Daten in 
den Konfigbereich. Da sind noch einige Plätze frei von buf[268] bis 
buf[299]. Da könntest Du Dir einen von greifen.

- Funktion AMDFlash::Read_Config_Flash() Zeile 1800 liest die Daten 
wieder ein.

Da ich mal annehme, das Du nicht jedesmal den gesamten Konfigbereich 
schreiben und lesen willst, könntest Du die Funktionen einfach als 
Vorlage für eigene Routinen nehmen mit denen Du dann Deine Daten ins 
Flash schreibst und sie wieder ausliest.

Gruß Hayo

Johannes Studt schrieb:
> Irgendwas anderes wollte ich doch letztens eh noch mit reinbauen...?

Ja, bitte beim Dumping des Flashes einen Plausibilitätscheck einbauen: 
Falls die Anzahl der Zeichen in einer Zeile nicht stimmt (zu viele oder 
zu wenige), die Zeile erneut abfragen.
Ich hatte ja schon festgestellt, dass der GERMSmonitor leider keine 
Prüfsumme ausspuckt, aber mein konkretes Problem ist ja nicht die 
Verfälschung, sondern nur das Verschlucken oder Verdoppeln von Zeichen. 
Schade, dass nichtmal ein Parity-Bit verwendet wird.

> Ich werd echt alt.

Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein 
=)


@Hayo und co, bzgl. Flash:

Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das 
FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE 
Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn 
man auf Default Setup geht oder deine Firmware einspielt oder was auch 
immer. Falls das nicht der Fall ist, sollten wir uns bezeiten schonmal 
einen Up- und Downgrade-Weg zwischen deiner und unserer Firmware 
überlegen.

Daniel H. schrieb:
> Tipp: Todo-Liste führen, fand ich sonst auch albern, hilft aber ungemein

Genau meine Taktik!


> @Hayo und co, bzgl. Flash:
>
> Da wir auch gerade dabei sind, einen Flash-Speichercontroller für das
> FPGA-Redesign zu bauen, wollte ich mal fragen, ob denn eigentlich ALLE
> Flash-Speicherbereiche mit sinnvollen Werten initialisiert werden, wenn
> man auf Default Setup geht oder deine Firmware einspielt oder was auch
> immer.

- wenn eine neue Firmware eingespielt wird, dann wird auch nur der
  Progrmmbereich beschrieben. Alle anderen Bereiche bleiben unberührt.

- bei Default Setup wird überhaupt nicht auf den Flashspeicher
  zugegriffen, weder lesend noch schreibend, sondern es werden nur
  hart codierte Werte geladen.

- Der Flashspeicher wird eigentlich überhaupt nicht initialisiert.
  Es werden lediglich einige Konfigwerte hineingeschrieben bzw.
  ausgelesen. Desweiteren werden einige Bitmaps beim Start geladen.
  Es können Signal im Speicher abgelegt werden, das wars auch schon.

Gruß Hayo

Okay, aber ich gehe eben von dem Fall aus, dass der Flash komplett von 
uns verwurstet wurde und jemand nun zurück zu deinem Branch wechseln 
will. Wir werden mit Sicherheit nicht die Config-Speicherbereiche 
unangefasst lassen (können|wollen), daher meine Anfrage was passiert, 
wenn dort "Müll" steht (oder Nullen oder so).

Dann startet das DSO erstmal völlig undefiniert. Im ungünstigsten Fall 
hängt es sich auf -aarrgh, ansonsten hilft Default Setup und einmal an 
der Timebase drehen, dann ist der Konfigbereich wieder initialisiert. 
Das gilt allerdings nicht für den Bereich in dem die Bitmaps abgelegt 
sind, die lassen sich nur durch das Einspielen eines Flashdumps wieder 
restaurieren.

Gruß Hayo

Das hört sich gut an - gleich in die Wishlist eintragen!

Hayo

Hallo Niklas,
mach die Dateinamen nicht zu lang. 8.3 muss reichen.

Hast du brauchbare und verständliche Infos zum ZMODEM?

Gute Arbeit!

Mfg,
Kurt

Nö, für den USB-Host oder das speichern auf SD-Karte. Viele fertige 
Routinen mögen nur die kurzen Namen.

@Niklas

Nach Deinem Tip für die stty-Umleitung hat es dann auch bei mir 
geklappt. Sehr praktisch. Ich mache damit gerade die FFT-Doku.

Prima Arbeit!

Hayo

Hallo Kurt,

> Hast du brauchbare und verständliche Infos zum ZMODEM?

ich schaetze mal Du spielst auf die IMHO nicht sonderlich
gute Originalbeschreibung von Forsberg an:
http://pauillac.inria.fr/~doligez/zmodem/zmodem.txt
(was anderes habe ich auch nicht gefunden)

Wenn man sich dazu vllt. noch ein paar fertige Implementationen
anschaut (andere als (l)rzsz) blickt man dann schon durch.

Gruss,
Niklas

Hallo,

ich teste gerade mit der 0.75 und auch da ist ein Fehler in der 
Zeitbasis, so wie Roberto es beschrieben hat.
Beim Test mit dem 1kHz Testsignal ergibt sich bei mir folgendes Bild:
Mit den Timebases bis 20ms/Div ist alles i.O. - Die Anzahl der 
dargestellten Schwingungen stimmt mit Periodendauer des Signals überein.
* Bei 50ms/Div wird mir eine Periodendauer von 250ms suggeriert- eine
  Periode geht über 5 Div!
* Bei 100ms/Div eine Periodendauer von 50ms.
* Bei 200ms/Div wieder eine Periodendauer von 250ms.
Bei noch langsameren Timebases zieht sich der Fehler konsequent weiter 
durch.

Einmal abgesehen davon, dass eine Darstellung mit TB > 20ms/Div bei 
unserer Auflösung nicht möglich ist (weniger Pixel zur Darstellung als 
Schwingungen des Signals), so liegt wohl doch irgendwo noch ein 
Berechnungsfehler bei den langsamen TB vor.

Gruß, brunowe

@Roberto + Bruno

Danke für den Hinweis. Das muß ich mal ausprobieren. Ich gebe zu, dass 
die langsameren Zeitbasen nicht so oft zum Einsatz kommen und daher 
Fehler auch nicht so schnell auffallen.

Gruß Hayo

So, dafür hier etwas Lesestoff.

Ich weiß, dass viele von Euch mit dem Thema vertraut sind, aber es gibt 
wohl auch noch einige die sich damit noch nicht so beschäftigt haben 
oder bei denen es schon länger her ist. So oder so ist es aber wohl für 
alle ganz interessant die Theorie mal am eigenen W20xxA 
nachzuvollziehen.

Leider ist das Ganze doch etwas umfangreicher geworden, so dass ich 
erstmal nur eine deutsche Version fertiggestellt habe.

Sollte ich mich unverständlich ausgedrückt oder was falsches geschrieben 
haben - nur keine Hemmungen, immer raus damit.

Viel Spaß beim Lesen und Ausprobieren

Hayo

Oh,

hab schon einen Fehler entdeckt! Auf Seite 8 ist natürlich das Doppelte 
von 24,414 nicht 48,414 sondern 48,828. Ich hoffe Ihr könnt damit leben.

Hayo

Das klappt doch schon sehr gut! Die Cursor sind noch in Arbeit?

Hallo,

kleines Update mal von mir:  Stellt sich raus, dass meine
schnelle Idee vom Montag mit dem ersetzen der ISR fuer
den UART (Hardware::ISR_UART()) so nicht funktioniert.

Liegt daran wie die Original ISR in der Firmware benutzt
wird:  Zeichen holen, Zeichen in Wust von if-Abfragen
in MenuKey Wert umsetzen, dann Buttonhandler() mit
MenuKey aufrufen.

Hardware::Buttonhandler() macht dann wiederum nen
select/switch-case-Konstrukt ueber MenuKey und ruft
evtl. darin noch weitere Funktionen auf.

Falls der Groschen noch nicht gefallen ist:  Die ISR
ist zu diesem Zeitpunkt immer noch nicht verlassen!

..und sie wird natuerlich auch so lange sie nicht
fertig ist nicht nochmal aufgerufen.

Das ist, gelinde gesagt, nicht die uebliche Art,
wie man ISRs benutzt.  Da ich nicht wirklich Lust
hatte den bestehenden Code weiter als noetig zu
lesen, ist mir das auch erst aufgefallen, als ich
mich wunderte, warum meine ISR nie zum Zuge kam.

Eine Loesung ohne den Original-ISR umzustricken
sehe ich im Moment nicht.  Da es, wenn ich das
richtig sehe, in TomCat.cpp eine Main-Loop gibt,
waere es das einfachste, wenn im ISR nur eine
Variable geschrieben wird und dann ein Handler
die Eingabe interpretiert (wie das mit mehreren
zwischenzeitlich eingegangen Eingaben und
Prioritaet aussehen sollte habe ich noch nicht
ueberlegt).

Um das gewohnte alte Verhalten beizubehalten
koennte man alle Interrupts fuer die Laufzeit
der jeweiligen Funktion deaktivieren.

Bevor ich jedoch da einen chirurgischen Eingriff
beginne moechte ich noch Eure Meinung und Ideen
einholen.

@Hayo:
Hab' mal kurz durchgeblaetter, schoene Anleitung!

Gruss,
Niklas

Die nächsten Punkte auf der Roadmap sind:

- FFT Feinschliff - da warte ich mal auf Rückmeldungen
- Cursorfunktion an das neue Grid anpassen
- Cursor für die FFT nachrüsten
- Quick Measure komplett überarbeiten

Hayo

@Niklas

Ich gebe Dir Recht, die Implementierung der ISR ist recht 
gewöhnungsbedürftig. Da es so viele andere Baustellen gab hatte ich mich 
darauf beschränkt den Buttonhandler (es gab früher nur einen einzigen!) 
aufzuteilen in einen Haupt-Buttonhandler und jeweils einen für die 
Funktionstasten. Dadurch kann man sich immerhin schon mal besser 
orientieren. Technisch gesehen hat das natürlich nichts geändert.

D.h. auch hier besteht noch Optimierungsbedarf, allerdings schien mir 
das bislang nicht so dringlich wie die anderen Themen.

Hayo

Ach ja noch einer:

Das mit der ISR hatte der Programmierer auch beim Rollmode so gemacht - 
weswegen das wohl auch nicht funktioniert hat. Ich konnte es zuerst gar 
nicht glauben als das erste Mal gesehen hab dass die komplette Logik im 
ISR des Timers abgefackelt wurde. Bei meiner Implementierung stehen 3 
Zeilen im ISR - das war's.

Hayo

@Stefan

Cool! Ich hätte gedacht dass erst die Cursor geradegebogen werden müssen
bevor da ein sinnvolles Vorgehen möglich ist.

Hayo

Hallo,

als Ergaenzung noch, da das vllt. nicht deutlich
rueber gekommen ist:

ZModem geht aufgrund des Protokolls und der noch
fehlenden Moeglichkeit, (alle) vom Terminalprogramm
ueber RS232 reinkommenden Zeichen zu lesen, erstmal
ohne weiteres nicht.


Messdaten einfach rauswerfen geht natuerlich trotzdem,
analog wie dies beim Screenshot gemacht wird.

Diesbzgl. hatte ich mir schon ueberlegt, die Parameter,
also Kanal, Zeitbasis usw., in Plaintext gefolgt von
den Samples, je als Byte, zu uebertragen und wieder mit
einem Programm fertig interpoliert in CSV oder gnuplot
Script zu wandeln.

Um ein paar zu uebertragende Bytes zu sparen koennte
man vornehmlich Deltas zwischen zwei Samples uebertragen,
z.B. 4 Bit breit.  Inwieweit sich das ueberhaupt lohnt
muesste ich mal austesten -- in Anbetracht der maximal
16K*4 Samples die anfallen.

Meine Frage waere dann auch jetzt, was ihr Euch fuer
Ausgabeformate wuenschen wuerdet und ob das
Vorgehen insgesamt so in Ordnung ist.


Mein Plan sieht also dann so aus:
- Messdaten rausschreiben und Ausleseprogramm
- Screenshotprogramm: BMP-Dateien schreiben
  (evtl. auch PNG, falls ich eine einfache Moeglichkeit finde)
- Ausleseprogramme auch fuer Windows und fertig kompiliert
- Firmware anpassen damit ZModem geht

(in keiner festen Reihenfolge, vmtl. nun ZModem zuletzt)

Niklas

Das Ausleseprogramm für Windows bastele ich gerade. Ist nicht schön, 
funktioniert aber und wird heute hoffentlich noch fertig.

@Bruno + Roberto

Die langsamen Zeitbasen sind ok. Habe gerade noch mal geprüft. Was Ihr 
da gesehen habt ist Aliasing in seiner reinsten Form, d.h. 
Scheinfrequenzen pur (siehe meine Veröffentlichung von heute). Wenn Ihr 
in den Programming-Maps in der Timebase-Tabelle nachseht werdet Ihr 
fündig.

Die kleinste Zeitbasis mit der ein 1 KHz Signal noch dargestellt werden 
kann ist 20ms/div. Bei den langsameren Zeitbasen wird das Abtasttheorem 
verletzt (insofern hat Roberto schon Recht, dass es sich um eine 
DSO-spezifische Sache handelt). Und zwar müßt Ihr im Zeitbereich immer 
berücksichtigen das zu der angezeigten Abtastrate noch der 
Timebasefaktor kommt um das dass Signal reduziert wird.

Die tatsächliche Abtastrate ist dann also angezeigte Sa/s durch 
Timefaktor. Bei 50 ms/div liegt die Abtastrate aber nur noch bei 5KSa/s 
durch 5 = 1KSa/s also halb so viel wie eigentlich minimal nötig.

Bei den noch langsameren TB wird das natürlich noch extremer, so dass 
täuschend echte Signale mit einer völlig anderen TB angezeigt werden. 
Ihr habt ein wirklich schönes Beispiel dafür gefunden ;-)

Das Ganze gilt übrigens nicht für die FFT. Hier bleibt der 
Timebasefaktor unberücksichtigt, so dass nur die tatsächlich angezeigte 
TB maßgeblich ist.

Gruß Hayo

Hallo Hayo,

hab deine o.a. Roadmap gelesen. Du vergisst nicht das Fixing des zeitl. 
Versatz zwischen den Kanälen?

gruß, brunowe

@Bruno,

nein, das habe ich auf dem Zettel. Allerdings sind nicht allzuviele 
Rückmeldungen gekommen verglichen mit den Downloadanzeigen wenn hier was 
veröffentlicht wird.

Die Korrektur ist eigentlich auch nicht sonderlich dramatisch, ich 
wollte sie nur gleich in die C-Routinen von Guido mit einfließen lassen. 
Da weiß ich aber nicht ab wann diese tatsächlich die Assemblerroutinen 
ersetzen werden.

Ich könnte das natürlich, wenn starker Bedarf besteht, auch vorher 
anders implementieren.


@Bernd

Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke 
nochmal für den Hinweis

Hayo

Hallo Hayo,

ja ok, ich hatte die blöden Timebase- Faktoren in meiner geistigen 
Rechnung nicht berücksichtigt! Daran sieht man, wie ungünstig die 
Sample-Raten in den einzelnen TB's gewählt ist. Der geringe Prozentsatz 
mit dem der zur Verfügung stehende Samplespeicher (16384 Samples) 
ausgenutzt wird, ist ein anderes Zeichen dafür.
Vor dieser TB- Anpassung standen wir im VHDL Design auch vor Kurzem ;-).
Tja, das Aliasing lässt sich leider nicht vermeiden, ein typisches ADC 
Problem.
Die Korrektur des zeitl. Versatz kann aus meiner Sicht noch warten, 
sollte halt nicht in Vergessenheit geraten. Schade das es keine To-Do- 
und Bug- list mit öffentlicher Möglichkeit von Ergänzungen gibt- sieht 
man einmal von der Wishlist unter Sourceforge ab.

Gruß, brunowe

Hier das Windows Konsolenprogramm für die aktuelle 80er Firmware.

Erklärung steht in der liesmich.txt.

Ich bräuchte eine Rückmeldung, ob die Farben korrekt wiedergegeben 
werden.
Wie gesagt, meine Ergänzungen sind etwas buggy und enthalten schwere 
Designfehler aber das Prog verursacht wenigstens keinen Bluescreen. ;-)

@Kurt

Prima, leider komme ich erst übermorgen zum Testen da ich bis dahin 
etwas beruflich eingespannt bin. Hab's mir aber schon mal runtergezogen.


@Bruno

Ja das hatte ich vergessen auf meiner ToDo Liste aufzuschreiben, die 
Timebasesteuerung wollte ich mal komplett umstellen. Ich sehe nämlich 
keinen vernünftigen Grund, warum die Samlerate nicht besser genutzt 
werden sollte. Keine Ahnung was sich der Programmierer dabei gedacht 
hat. Zuerst vermutete ich dass da irgendein tieferer Sinn hintersteckt, 
den ich nicht durchschaue, aber mittlerweile nach längerem Umgang mit 
dem Coding weiß ich dass es wohl eher nicht so ist.

Gruß Hayo

So Hayo,

habe dir unter SF meine aktuellen Änderungen für QuickMeasurment 
eingespielt. Viel Spass beim mergen. ;-) War doch sehr umfangreich. 
Dafür sind aber auch die 4 Kanäle in EINER Schleife zusammengefasst und 
nicht wie vorher jeder einzeln. Ich bin zufrieden ;-)

Bei mir geht derzeit auf beiden Kanälen (theoretisch auf allen 4, ich 
hab aber blos zwei, also fleißig Bericht erstatten) das Messen von 
Average, Duty Cycle, FallTime, Frequency, Maximum, Minumum, Peak-Peak, 
Rise-Time, +Width, -Width. Die Auswertung von einem Summen- oder 
Differenzsignal geht noch nicht.

Ich kenn mich mit dem Ändern der Menüsteuerung nicht aus. Aber wäre es 
möglich, die 3 Felder einzeln zu löschen?. Außerdem besteht prinzipiell 
jetzt die Möglichkeit die Genauigkeit einzustellen. (Auf kosten der 
Geschwindigkeit) Könnte man evtl. über das Menü ein und ausschalten.

Gruß,

Stefan

Und für alle andern auch noch die Ram-Datei

Nochmal @Niklas:
ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch 
ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze 
Pause einzulegen.

Zum Zielsystem:
Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die 
Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.

Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von 
einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte 
Ausgabe möglich?

Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den 
wichtigsten Parametern als txt File welches später mit einem PC Programm 
zu einem großen Bild zusammengesetzt werden kann.

PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet 
werden.

Tipps von einem Ahnungslosen:
BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte 
Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

Hayo W. schrieb:
> @Bernd
>
> Der Bug mit Kanal 3 + 4 nach der Rückkehr von der FFT ist gefixed, danke
> nochmal für den Hinweis
Super! Ich hatte gestern Abend noch etwas gespielt und gemerkt, dass der 
Fehler nicht immer auftritt und schon überlegt was zuvor anders war...

Beim Trigger bzw. seiner Darstellung habe ich noch ein paar Dinge 
bemerkt, die man verbessern könnte:

1) Wenn man im "Aquire"-Menü (*) zwischen Normal und Averaging wechselt 
wird der Averaging-Modus wird mit einem Durchmessersymbol dargestellt. 
Dieses Symbol verschiebt den Triggerpfeil um ca. 1/2 Symbolbreite nach 
unten (ca. 10 % eines Div). Da die numerische Anzeige rechts oben 
unverändert bleibt gehe ich davon aus, dass es nur ein 
Darstellungsproblem ist.

(*) Richtig wäre "Acquire" - aber den Druck des Bedienpanels wird man 
wohl nicht per SW ändern können ;-)

2) Die Pfeilspitze des Triggersymbols ist auch im Normal-Mode um ca. 
zwei Pixel zu tief. Bei beispielsweise 1 V/Div liegt der Trigger erst 
bei 1.04 V optisch auf der 1 V Linie.
(Ich weiß, ist pedantisch - aber so etwas sticht mir leider direkt ins 
Auge).

3) Die numerische Anzeige des Triggerlevels ist bei 2 V/Div manchmal 
falsch:

Ausgangssituation: 1 V/Div mit Triggerlevel 500 mV. Beim Umschalten auf 
2V/Div wird rechts oben ein Triggerlevel von "1.00 mV" angezeigt. 
Optisch per Pfeil dargestellt sind 1 V (also Volt statt Millivolt). Wenn 
man auf 5V/Div weiterschaltet wird der Level korrekt mit "2.50 V" 
angezeigt. Wenn man nun wieder auf 2 V/Div zurückschaltet, dann wird 
auch in diesem Bereich nun korrekterweise "1.0 V" angezeigt.
=> Es macht also für die Anzeige des Triggerlevels einen Unterschied, ob 
man von "oben" oder von "unten" in den 2V/Div Bereich kommt. Die 
restlichen Bereiche waren soweit ich gesehen habe O.K.

4) Wurde so weit ich weiß schon einmal angemerkt und könnte auch ein 
Feature und kein Bug sein ;-):
Intuitiv hätte ich erwartet, dass ein eingestellter Triggerlevel von 
beispielsweise 500 mV erhalten bleibt wenn ich den V/Div-Bereich 
wechsle. Im Normal-Mode ist es für mich gewöhnungsbedürftig, wenn man 
die Y-Auflösung ändert und erst mal "blind" ist bis man am Trigger 
gedreht (oder in den Auto-Modus gewechselt) hat.

Freue mich schon auf die nächste FW.

Gruß,
Bernd

@Stefan

Super, ich werde mir das mal übermorgen ansehen. Grundsätzlich kann ich 
Dir das Menü beliebig einrichten, Du müßtest nur genau beschreiben wann 
was wo gesetzt oder gelöscht werden soll (welche Variablen und so).



@Bernd


Das nenne ich einen detailierten Fehlerbericht. Nicht übel. Etliche 
Punkte fallen derzeit allerdings unter die Kategorie "minor problems". 
Daher denke ich werden sie entweder mal so zwischendurch behoben (was 
bei mir des öfteren vorkommt), oder es wird etwas dauern da es immer 
noch einige größere Baustellen gibt. Auf jeden Fall danke für die 
Hinweise.

Gruß Hayo

Hallo Kurt,

> ZMODEM ist ja auch noch komplizierter als XMODEM. Eigentlich reicht auch
> ein XON/XOFF oder sogar zwischen Datenblöcken von 128Byte eine kurze
> Pause einzulegen.

ZMODEM war ja nur dafuer gedacht um ein gaengiges Terminalprogramm
auf RS232 lauschen koennen zu lassen und automatisch Dateien vom
Oszi zu empfangen, ohne erstmal weitere Software zu installieren.
Mit XMODEM geht das leider nicht, weil da dummerweise im Protokoll
die Moeglichkeit fehlt auf Senderseite den Empfang direkt anzustoszen.

Mit dem XON/XOFF Software-Handshake geht es Dir primaer um die
Uebertragung an einen uC, oder?  Kann ich Dir einbauen, wie
beschrieben die UART ISR steht allerdings noch etwas im Weg.

> Zum Zielsystem:
> Für mich persönlich müssten die Daten auf einen mobilen Speicher. Die
> Screenshots direkt auf den PC zu übertragen ist meistens zu umständlich.
>
> Also müsste das Oszi schon ein fertiges ppm File ausgeben können was von
> einem µC auf einen Massenspeicher geschrieben wird. Ist diese direkte
> Ausgabe möglich?

Ja klar, das ist natuerlich moeglich.  Der Grund warum ich den Umweg
ueber die Planes mit RLE Kompression gegangen bin ist nur dass ich
dadurch auf ~15kB s/w und ~65kB Farbe komme (und mit minimalem
Programmcode).

Das DSO kann natuerlich auch gleich die Planes fertig ueberlagern
und eingefaerbt als PPM ausgeben, waeren auch nur geschaetzt nen
Dutzend Zeilen Code plus einige Konstanten mehr -- nur kaemen wir
da auf 640*480*3 = 900 kB. (Farbkomponenten kleiner als mit einem
Byte auszudruecken ist leider nicht spezifiziert bei PPM (setzt man
im Header < 255 muss man dennoch ein volles Byte ausschreiben pro 
Farbkomponente).)

Nehmen wir unkomprimiertes BMP mit 4 Bit Palette sind's noch ~150 kB.
Dazu kommt noch ein wenig Rechenzeit, Bufferung bei der Ausgabe fehlt
da auch noch...

Wenn Dir das nicht zu langsam ist ergaenze ich das gerne.  Kann
man ja so machen, dass das Ausgabeformat im Quick-Print Menue
und per RS232 fuer den Anwender/uC konfigurierbar ist.

> Zusätzlich die Möglichkeit der Ausgabe der ganzen Sampledaten mit den
> wichtigsten Parametern als txt File welches später mit einem PC Programm
> zu einem großen Bild zusammengesetzt werden kann.

Mit txt File meinst Du also direkt Menschen-lesbar?  Auch kein
Problem, nur in welchem Format genau muesste man sich einigen.

> PPM ist als Format erstmal ausreichend und kann mit IrfanView betrachtet
> werden.
>
> Tipps von einem Ahnungslosen:
> BMP verwendet angeblich eine Lauflängenkodierung. Eine begrenzte
> Datenreduktion ist vieleicht auch mit Huffman Codierung möglich.

Ja, RLE geht optional.  Die Spec dazu hab' ich aber noch nicht
angeschaut.  Bei den Screenshots hatte ich schonmal verglichen und
Gimp erzeugte mir unter Verwendung einer Palette und Kompression
ein iirc. 48kB BMP File.  Da liege ich mit 65kB ziemlich gut dabei,
mit einem sehr simplen Algo wo sicher noch was rauzuholen waere.


Also, zusammenfassend:
 - fertiges PPM oder BMP (unkomprimiert erstmal) rausschreiben:
     kein Problem, nur wenige Zeilen zusaetzlicher Code plus
     gesteigerte Rechenlaufzeit
 - Software-Handshake mit Blockung:
     auch kein groszes Problem, beschriebene Problematik mit der
     jetzigen UART ISR steht nur bloed im Weg
 - Messdaten gleich fertig menschenlesbar raus:
     genauso, muessten wir uns nur auf ein Format einigen
     (z.B. CSV, welche Felder, Anordnung)


Mit Massenspeicher meinst Du sowas wie eine SD-Card, per SPI
angesprochen?  Das faende ich klasse.  Besonders wenn man dann
ein schoenes Gehaeuse dazu macht koennte das fast "nativ" zum
DSO gehoerend aussehen.

Gruss,
Niklas

Richtig, XON/XOFF für den µC. Brauchst du aber noch nicht einzubauen, 
wir brauchen erstmal ein richtiges Konzept.

Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen. 
Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es 
nicht werden.
Also müsste man im Oszi ein PNG oder JPG basteln.
Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Massenspeicher als SD-Karte oder mein Favorit der USB-Stick.
Ganz verrückte könnten die Daten per RFM12 Modul durch die Gegend 
funken. ;-)

Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt 
vom FPGA aus. Das lässt sich aber vorerst nicht nachrüsten, außerdem 
fehlen ja den 2-Kanalgeräten die 5? herausgeführten Pins am FPGA.

PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz 
drin.

Hallo Kurt,

> Das Problem mit der Dateigröße ist mir eben auch in den Sinn gekommen.
> Die ~65kB zu senden dauert ja schon gut 50sec. Noch langsamer darf es
> nicht werden.

Theoretisch sollte es ja von der Schnittstelle her bei den 115200
Baud wesentlich schneller gehen (im Prinzip grob 10 Sekunden).
Wieviel Anteil da Rechenzeit hat und etwaiges Warten mangels
fehlender Bufferung habe ich nocht nicht genau geschaut.
Bufferung kaeme ohnehin bei ZMODEM wg. Blocking.

Rechenzeit scheint mir schon enorm zu sein.  Wobei ich vllt.
mal explizit sagen sollte, dass ich mich da nicht besonders
klever anstelle und jeden Pixel einzeln aus einer Speicherstelle
zurueck fuehre.  Das laesst sich mit einer Portion Bitmask
Voodoo sicher optimieren, uebersteigt jedoch derzeit meinen
Horizont (Hilfe wird dankend angenommen :)).

> Also müsste man im Oszi ein PNG oder JPG basteln.
> Diese Seite kennst du schon? http://www.wotsit.org/default.asp

Ne die Seite kannte ich noch nicht, gerade kurz bissl rumgeklickt,
sieht nett aus.  Schaue ich spaeter mal genauer.

> Sehr schön wäre die Bildkompression und Ansteuerung des Speichers direkt
> vom FPGA aus. [..]

Das waere natuerlich noch besser wenn ihr das hinbekommt.

> PS: Eigentlich sollte die Schaltung ins Oszi. Da ist noch genug Platz
> drin.

Oh, noch besser :)

@Roberto:
> Bei "PGM" ladet er 16Planes runter bei "PGM BW" nur eine.
> Grösse der Dateien 901KB

Ja das passt, bei S/W werden die 16 Planes direkt auf dem Oszi
kombiniert.  ~900KB passt auch, sind unkomprimierte 640x480
Pixel mit 24 Bit Farbtiefe.

> Aber blöde Frage: Was kann ich jetzt mit den Files machen?
> Kann es mit keinen meiner Programme öffnen ?

Ja, unter Windows ist PPM leider kein gaengiges Format, aber
fuer (ohnehin meist faule ;)) Programmierer ein extrem
einfach zu erstellendes Format.

Daher laengst meine Ansage fuer Windows-User auch BMP
zu generieren (was das naechst einfache Format waere ;)).

> Könnte man da vielleicht auch ein "jpg" oder ein "PNG" runterladen?

Ja, natuerlich.  Steht auch schon auf meiner Agenda.

Kurt oeffnet die PPM mit Ifranview, iirc.  Gimp sollte auch gehen.
Wobei ich natuerlich jetzt niemanden dazu bringen will nur
deswegen zusaetzliche Software zu installieren.

BMP-Ausgabe wird wie gesagt sicher in Kuerze folgen.

Gruss,
Niklas

@Stefan

Nachdem ich jetzt eine halbe Stunde lang bei SFN rumgeklickt habe und in 
der Zeit nur zwei Sourcedateien geladen bekommen habe - kannst Du mir 
die Sourcen hier hochladen, ich hab keine Lust mehr mich damit weiter 
rumzuärgern. Das ist ja langsam und zäh wie Kaugummi mit dem Trac-Tool.

Gruß Hayo

Hallo Hayo,

kann ich machen. Allerdings erst heute Abend.

Gruß,
Stefan

@Roberto & all,
ich werde mich um eine neue Win Applikation für das DSO kümmern (Anzeige 
und Steuerung des DSO), kann aber noch nicht sagen, unter welchem 
Framework. Lazarus vielleicht? Ist frei und auch für Linux/OSX 
verfügbar. Müsste mich aber erst einarbeiten.

Michel

Hallo,

so, ich hab' jetzt mal getestet wo da egtl. die Minute herkommt,
die so'n 65kB Dump braucht.

Erst einmal ist es kein Problem nur unter Verwendung von putchar()
da volle 10kB/s rauszuschoeffeln.  Das ist schonmal gut.

Nicht so gut ist aber, dass die grob restlichen 50 Sekunden
tatsaechlich voll und ganz in den Pixelschleifen verbracht
werden.  Dazu hab' ich nur die putchar() entfernt, RLE
wird weiter gemacht.  Auch bei B/W braucht das Oszi noch
fast 15 Sekunden nur dafuer.

NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...
Bislang vermutete ich verschenkte Zeit indem ich ungebuffert
rausschreibe, ist aber irrelevant...

Wenn man sich mein diff (aus den geposteten .tgz) nochmal
anschaut sieht man, dass da quasi "nix" passiert.  Natuerlich
ist wie in meinem letzten Posting gesagt die Pixelwandlung
nicht optimal, aber auch nicht so schlimm.

Damit dann gar PNG mit Deflate auf dem NiosII zu machen
koennen wir m.E. gleich mal komplett vergessen.

Sollten wir vllt. einfach die Speicherbereiche unveraendert
binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
sind, und alles auf dem Computer erledigen?
(den Code dafuer haben wir ja schon...)

Und auch Fragen an die Leute die schon laenger mit NiosII
und/oder der Firmware zutun haben:

- Wuerde es helfen das in Assembler zu schreiben?
- Ist da etwas was ich da mache auf NiosII besonders ineffizient?
- Andere Datentypen verwenden?

Gruss,
Niklas

mal zum USB-BUS:
die UARTS des CY7C64713 können mit bis zu 230 KBaud kommunizieren. Gibt 
es das Board/die Firmware her? Aus irgendwelchen Dokus sehe ich, dass 
nur mit einem Viertel der möglichen Rate übertragen wird. Hier wäre noch 
Potential.

Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich 
möchte lieber den USB nutzen als die serielle Schnittstelle.

Vielleicht sollte man eine Möglichkeit bieten, den Firmwareupload via 
Auswahl in der Firmware (Menüpunkt) zu initiieren.

Wahrscheinlich ein wenig viel, oder ;-)
Neuer USB-Treiber, neue CY-Firmware, Anpassungen in der 
Scope-Firmware...

sorry

@Niklas

Das Schreiben in Assembler könnte evtl. was bringen, ist aber eigentlich 
kontraproduktiv, da wir uns bemühen etwas plattformunabhängiger zu 
werden und daher die Assemblerroutinen durch c-coding zu ersetzen

> NiosII ist wohl einfach lahm.  Langsamer als ich gedacht haette...

So ist es. Bei dieser Variante wurde auch noch auf das 
Multiplikationsmodul verzichtet. D.h. bei der Optimierung auf 
Geschwindigkeit sollte man folgendes beachten:

- Floating Point Operationen -> ganz schlecht, möglichst umstricken
                                auf Integer

- Integer Multiplikationen -> möglichst vermeiden

- Integer Additionen -> sind ok

- Shift Operationen -> möglichst oft verwenden da erheblich schneller

- komplexe Bibliotheksfunktionen -> ganz schlecht, möglichst durch
                                    eigene optimierte Funktionen
                                    ersetzen.

- oder noch besser -> durch schnellen indizierten Tabellenzugriff
                      ersetzen

Gruß Hayo

Nach längerer Zeit habe ich mal wieder eine FW....80 eingespielt und bin 
begeistert.

Niklas O. schrieb:
> Hallo,
...
> Sollten wir vllt. einfach die Speicherbereiche unveraendert
> binaer rausjagen, auch wenn's iirc. 38400 Byte * 16 = 600kB
> sind, und alles auf dem Computer erledigen?
> (den Code dafuer haben wir ja schon...)

Ich hatte mir auch mal eine Erweiterung geschrieben, mit der ich die 
rohen ADC-Daten seriell ausgegeben habe (USB habe ich totgespielt).

Auf dem Display werden doch sowieso nur 512 Bytes angezeigt. Bei vier 
Kanälen sind das maximal 512*4=2048 Bytes.

Wenn man im Header die Einstellung überträgt (Menü, Timebase...) und 
dann 512 Bytes/Kanal, sollte das ordentlich flott werden. Die "hübsche" 
Darstellung kann dann der PC übernehmen.

Aber auch die vollen 16kB/Kanal machen maximal 64kB, also ca. 6s.

Wenn man den PC-Teil in Qt schreibt, kann der auf allen gängigen 
Betriebssystemen laufen.

Ich hatte das mal angefangen. Es müßten sämtliche Parameter per RS232 
einstellbar sein. Auf Kommando könnten die Daten einmal oder dauernd 
gesendet werden.

Wenn sich ein Qt-Spezialist fände, würde ich die HW-Schnittstelle PC- 
und Scope-seitig implementieren. Wenn nicht, würde ich eine Oberfläche 
basteln können. Schön wird das aber nicht ;-)

Falk
P.S.: Wie läßt sich USB wiederbeleben, wenn sie absolut nicht mehr 
ansprechbar ist? Ich hatte mit ein paar Cypress?-Tools herumgespielt...

Hallo,

@Hayo:
Tja, ich mache ja egtl. nix anderes als Integer Additionen, Shift
und paar Array-Zugriffe...  D.h., damit ist dann wohl Ende der
Fahnenstange, da von 50s auf humane 10s oder so zu kommen steht
wohl auszer Frage.

@Falk:
Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
angezeigten 512(*4) Werte reduzieren bei der Implementation
der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
dann beinahe in Realtime den Output anzeigen.

Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
einfach nachmalt. Dennoch ist es IMHO schoen, wenn man die Option
hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
Measurements.  Koennte man natuerlich auch nachmalen mit Programm,
aber warum alles doppelt.  Ich moechte auf die Screenshot-Funktion
zumindest nicht verzichten und sie hat mir lange gefehlt.

Niklas

Hallo Falk,

ich vergasz:
> [..] Es müßten sämtliche Parameter per RS232 einstellbar sein.
> [..] [HW-Schnittstelle PC- und Scope-seitig implementieren]

Ja alle Knoepfe sind wohl bereits auf RS232 gemappt.

Da ich ohnehin einen Eingriff an der Original UART ISR vornehmen
muss, sollten wir vllt. das (und die Routinen die da draenhaengen)
direkt mal aufraeumen und zusammen ein klares Interface
festschreiben.

Wenn jemand Material/Erfahrung zu Interfaces von anderen
professionelleren Scopes hat sollte er die dann einbringen.
Ich zumindest hab' da leider nichts vorzuweisen.

Niklas

Niklas O. schrieb:

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das sehe ich genauso. Insbesondere für dokumentarische Zwecke sehr 
praktisch wie man auch in meiner Anleitung sehen kann. Die Wartezeit von 
einer Minute kann ich dabei locker verschmerzen. Mit der Kamera war ich 
auch nicht schneller und hatte auch noch diverse Fehlversuche wegen 
Verwackelung und Fehlbelichtung.

Für die FFT-Doku habe ich die Screenshot-Funktion statt ins QP-Menü 
direkt auf den QP-Button gelegt und noch zusätzlich den Popuptimer für 
die Dauer des Screenshots blockiert.

Hintergrund: Mit der Implementierung in der Version 0.80 läßt sich kein 
geöffnetes Popupmenü blitzen und auf den Screenshots ist dann auch immer 
das QP-Menü zu sehen, was aber für Dokumentationszwecke oft nicht so 
günstig ist, da man ja auch die aktuellen Menü-Einstellungen 
dokumentieren möchte.

Ich habe mir schon einige Gedanken gemacht wie man das lösen kann, dass 
man trotzdem das QP-Menü zur Verfügung hat. Mal sehen...

Hat einer von Euch eine spontane Idee?

Hayo

Niklas O. schrieb:
> Hallo,

> Jo die Ausgabe der ADC-Daten kann ich auch wahlweise auf die
> angezeigten 512(*4) Werte reduzieren bei der Implementation
> der Messdatenausgabe.  Dein und/oder Michaels Programm koennten
> dann beinahe in Realtime den Output anzeigen.
>
> Fuer viele reicht es natuerlich, wenn da ein Programm die Kurven
> einfach nachmalt.

Mit den Rohdaten kann man aber noch viel mehr anstellen. Beispielsweise 
mathematische Funktionen, die man im Scope nicht machen kann.

> Dennoch ist es IMHO schoen, wenn man die Option
> hat den originalen DSO-Screen 1:1 zu speichern, mit Cursorn und
> Measurements.

Natürlich ist das prima, keine Frage. Nur hat man dann keine Daten mehr, 
sondern ein Bild.

> Ich moechte auf die Screenshot-Funktion
> zumindest nicht verzichten und sie hat mir lange gefehlt.

Das geht mir nicht anders. Aber auch ein Dump der Daten ist praktisch 
und eigentlich mit "Dump to XLS" schon vorhanden. (Ich halte .xls für 
zwei/vier Spalten mit je 16.000 Zeilen für unsinnig. CSV reicht.)

Falk

@Guido

Ja, sorry hatte ich etwas verdrängt.

> 1.) Sollten wir nicht für die 1er und 2er Bereiche den OPA
> ebenfalls auf Verstärkung 1,25 schalten. Dann hätten wir
> nur noch zwei Auflösungen x2,5 und x2. Ich kann darin keinen
> Nachteil erkennen, die Änderungen in Set_Switches sollten kein
> Problem sein, nur die Grafik muss angepasst werden.

Könnte man machen, allerdings könnte es schon etwas Aufwand geben, da 
die Skalierung in alle möglichen Routinen mit einfließt. Ich denke 
Stefan wird da bei QM auch mit zu tun haben. Vorteil wäre natürlich die 
bessere Ausnutzung der Wandlerauflösung und damit verbunden das 
geringere Rauschen in der Darstellung. Evtl. könnte es reichen die 
Skalierungsfaktoren anzupassen. Ich hab mir die Set_Switches() noch 
nicht so genau angesehen, ist die Umschaltung so ohne weiteres möglich?


> 2.) Bei Timebase > 6 wird  nur jeder 4. Wert ausgewertet.

Nein das ist nicht ganz richtig. Grundsätzlich ist die Situation zur 
Zeit so:

- es werden grundsätzlich immer 16k Werte gesampled

- die 1er und 5er Bereiche > 5µs nutzen jeden 5. Wert
- die 2er Bereiche > 5µs nutzen jeden 4. Wert
- der 5µs Bereich nutzt nur jeden 25. Wert

> Wenn du eh an die Timebaseeinstellungen gehen möchtest,
> solltet wir das gleich ändern. Dann werden unabhängig von
> der Timebase immer 16k-Samples übertragen. Die Faktoren der
> ProgrammingMaps werden dann vervierfacht, sonst ändert sich
> nichts. Auf dem PC hätte das den Vorteil dass die FFT immer
> mit 16k-Samples ausgeführt werden kann, was nicht nur  die
> zeitliche Auflösung vergrößert, sondern auch vertikal 24 dB
> bringt,

Das habe ich nicht ganz verstanden. Wieso werden die Faktoren 
vervierfacht? Ich wollte die Faktoren eigentlich möglichst auf 1 oder 2 
bringen. Es stehen jedoch trotz allem für eine FFT immer die vollen 16k 
zur Verfügung, denn für die FFT ist nicht die eingestellte Timebase 
ausschlaggebend, sondern nur die indirekt damit verbundene tatsächliche 
Abtastrate. D.h. die Zeitbasen 2ns bis 1µs haben bei der FFT die 
gleichen Ergebnisse. Erst beim Wechsel auf 2µs verändert sich der 
Frequenzbereich durch die halbierte Abtastrate.

Für eine PC-Anwendung wäre es daher auch jetzt schon möglich die vollen 
16k zu nutzen, da die Werte ja vorhanden sind, nur bei der Grafikausgabe 
einfach übersprungen werden.

Gruß Hayo

@Niklas

Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab 
mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR 
auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Hayo

@Guido

Das glaube ich nicht. Ich hab mir da schon so meine Gedanken gemacht 
(anbei der neue Entwurf des Timebasecontrollers) und werde mal eine 
Testversion bauen um das zu überprüfen. Allerdings muß man natürlich 
damit rechnen, das sich die Sampledauer entsprechend verlängert, was 
sich  in den langsamen Zeitbasen schon recht spürbar auswirken kann.

Gruß Hayo

@elgodil

Keine schlechte Idee, aber per ISR läßt sich das gleichzeitige Drücken 
von zweei Tasten nur schwer ermitteln. Der Germsmonitor-Auslöser dagegen 
ist fest verdratet (siehe NIOS Doku).


@Stefan

Ja sowas in der Art dachte ich mir auch. Allerdings wenn weitere Daten 
Übertragen werden sollen (Excel etc.), wäre ein Menü nicht schlecht.

Hayo

@Kurt

Bei meine test's mit deinem screen.exe habe ich festgestellt, das die 
Farben um ein Pixel verschoben sind. Eine Analyse des screenX.ppm zeigt 
das unter Windows \n zu "0x0d 0x0a" wird! das fuehrt dazu dass die 
farb-tripples um 1 Byte verschoben sind (deshalb musstest du den index 
umstellen!). Anbei meine Version die mit \r arbeitet.

Martin

Michael W. schrieb:
> mal zum USB-BUS:

> Kann man den Germs-Monitor vielleicht auch auf den USB umbiegen? Ich
> möchte lieber den USB nutzen als die serielle Schnittstelle.

Das sieht erstmal schlecht aus, ohne die Verbindungen im FPGA zu ändern. 
Der Germsmonitor wird vermutlich nur auf einer UART des Systems lauschen 
und nicht auf mehreren.

Danke Martin,
das werde ich mir später nochmal ansehen. Ich wollte das Prog eh noch 
etwas aufräumen.

Johannes Studt schrieb:
> Crazor schrieb:
>> Writing line 004277 of 023377: .X............0 sec / 134 sec left
>> Error: Timeout while reading response from DSO!
>> Response was: 'S219815B3D34<#33><#13>
>> '
>
> Da muss mir mal ein GERMS-Kundiger weiterhelfen. Was bedeutet es, wenn
> der Monitor mit '!' antwortet? Darauf muss ich sicher nur korrekt
> reagieren und dann ginge es weiter.
>
> /Hannes

Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein ! 
nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal 
in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht 
sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder 
nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon 
helfen!

Hallo,

anbei noch die v0.3 vom Screenshot Programm:
Jetzt auch fuer Windows und auch mit BMP-Ausgabe.

Kompiliertes EXE-File (unter MinGW), .BAT und README.txt sind
dabei.  Wenn sich jemand wundert warum sein Lieblingsprogramm
die BMP evtl. nicht oeffnen vermag: steht in der README.

Ich wollte egtl. noch das Binaerformat der DSO Ausgabe
dokumentieren, habe aber nun keine Zeit mehr.  Ich hoffe es
funktioniert alles richtig, habe nicht sonderlich lange testen
koennen.

@Hayo:
> Morgen hätte ich etwas Zeit. Soll ich die UART ISR mal strippen? Ich hab
> mir das mal angesehen, das müßte eigentlich gehen ohne dem Keybord ISR
> auf die Füße zu treten. Dann könntest Du da Deine Ideen reinverwursten.

Ja, mach das mal.

Niklas

Daniel H. schrieb:
> Das Problem ist leider schon wieder aufgetaucht. Und es ist immer ein !
> nach dem CR, das da zurückkommt. Kann leider auch nix finden, nichtmal
> in der Referenz. Bin mir nach der Lektüre des Codes auch immernohc nicht
> sicher, ob denn nach einem ! die Zeile nochmals übertragen wird oder
> nicht (kann kein Wort Perl). Evtl. würde ein erneutes Senden schon
> helfen!

Ok, habe nun Zeile 184 von
      while ($buffer !~ /\+/) {
nach
      while ($buffer !~ /[\+|\!]/) {
geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte 
ich dann .X.X.X.X. usw. in der Ausgabe, und nach dem 10. Versuch nen 
Abbruch. Dann hab ich mir gedacht baue ich in die Abbruchfehlermeldung 
auch die Ausgabe des Buffers mit ein, um zu sehen was der GERMSmonitor 
weiterhin antwortet, aber dann hat der Upload (leider ;) gerade mal 
funktioniert, sodass ich erst bei einem der nächsten Hayo-Releases 
weitertesten kann...

Daniel H. schrieb:
> Ok, habe nun Zeile 184 von
>       while ($buffer !~ /\+/) {
> nach
>       while ($buffer !~ /[\+|\!]/) {
> geändert. Daraufhin wird auch bei einem ! weitergemacht, leider hatte

Ok, richtig wäre /[!+]/ (in Zeichenklassen hat das Plus wie auch das 
Ausrufezeichen keine Sonderbedeutung), aber es ist sicher prinzipiell 
keine gute Idee das so zu machen. Das Ausrufezeichen ist wahrscheinlich 
eine Fehlermeldung und keine Quittung, also sollte die Zeile erneut 
übertragen statt einfach fortgefahren werden. Ich guck dann mal rein und 
ändere das entsprechend, die Frau ruft nur eben wegen Abendbrots.

@Hayo: ich fände es ergonomisch, wenn der Druck auf QP einfach wie 
gehabt das Menü aufruft und ein längerer Druck die Übertragung 
stillschweigend auslöst. So würde ich das zumindestens bei meinen 
Applikationen machen.

/Hannes

@Robert

Meiner Meinung has du das ganze nicht new compiliert!

Desshalb hier auch das screen.exe (mit Visual C++ 2008 Express 
erstellt).

Martin