Wittig(welec) DSO W20xxA Open Source Firmware

@Odic

Hmmm, da läuft aber bei Deinem Gerät was mächtig schief. Leider kann ich 
mir da so auf Anhieb auch keinen Reim drauf machen.


> Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden
> Bereich einzeln ermitteln zu können?

Erstens wäre es schon einiger Aufwand und außerdem ist es technisch auch 
eigentlich nicht nötig, da die jeweiligen Analogbereiche der Hardware 
immer für alle 5er  2er  1er Bereiche ausgelegt sind. Daher auch nur 
drei Korrekturfaktoren.

Meine Idee wäre zuerst mal einen Flashdump einzuspielen um sicherzugehen 
dass da nichts schief hängt.

Hayo

Also ich hab jetzt auch etwas getestet.

Gestern hat der abgleich auf allen Kanaelen noch wunderbar geklappt... 
als ich dann heute das Scope angeworfen habe war alles wieder voellig 
durcheinander, d.h. die Nulllinien wieder irgendwo. Als ich kann den 
Abgleich auf allen Kanaelen gleichzeitig durchgefuehrt habe (also 1-4 AN 
und dann die ganze Prozedur), trat genau das Problem das du beschrieben 
hast auf.

Jetzt habe ich mich dann nochmal Hayo's Hinweis, das man alle Kanaele 
auch einzeln abgleichen kann, erinnert und das durchgefuehrt. Also nur 
Kanal 1 an und dann 1V-5V abgeglichen. Dann das selbe nur mit Kanal 2 
an, alle andren aus usw. Nun habe ich in allen Bereichen schoene 
Nullinien und das Scope merkt sich die auch beim Neustart.


Woran das genau liegt kann ich mir so aber nicht erklaeren. Gestern 
dachte ich das das auf allen Kanaelen sauber funktioniert hat... war 
aber auch schon spaet.

Nach weiteren Tests habe ich jetzt bemekrt das das Scope sich die 
Offsets wohl nicht merkt. Nachdem das Scope jetzt laenger aus war und 
ich es angeschalten habe war erstmal alles durcheinander, nix hat 
gepasst. Nach ausfuehren von Default Setup:

5V Bereich: Alles in Ordnung, auch nach Neustart

2V Bereich: Abweichung um ca. 0.3Div nach Neustart

1V Bereich: Abweichung um ca. 0.3Div nach Neustart


Auffallend ist das die Offsets sich alle nach unten verschoben haben.

@Alexis

Durch Temperaturunterschiede (kaltes / warm gelaufenes Gerät) habe ich 
auf allen Kanälen auch Schwankungen der Nullinie von -0,2 bis -0,5 DIV. 
Das ist zwar lästig, aber erklärbar.

@Hayo

Ich versuche es mal mit dem Dump. Die FW hatte ich bereits nochmal neu 
eingespielt da ich vermutet habe, dass dabei etwas schief gegangen ist. 
Leider ohne Erfolg.

Ok, nächstes Problem. :-(

Das Zurückspielen des Dumps bricht reproduzierbar an folgender Stelle 
ab.

Writing line 044014 of 071372: ............ 422 sec / 262 sec left
Error: Timeout while reading response from DSO!
Response was: 'S3150005247FFF<#33><#13>

Kann sich jemand einen Reim darauf machen??

Odic X. schrieb:
> Writing line 044014 of 071372: ............ 422 sec / 262 sec left
> Error: Timeout while reading response from DSO!
> Response was: 'S3150005247FFF<#33><#13>

Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo 
beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der 
GERMSloader ab. Der Script (s.Anhang) ist bereits geändert, um das 
schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket 
integriert.

/Hannes

Johannes Studt schrieb:
> Odic X. schrieb:
>> Writing line 044014 of 071372: ............ 422 sec / 262 sec left
>> Error: Timeout while reading response from DSO!
>> Response was: 'S3150005247FFF<#33><#13>
>
> Hatten wir weiter oben schon mal. Das DSO antwortet aus leider nirgendwo
> beschriebenen Gründen mit einem "!" statt einem "+". Deswegen bricht der
> GERMSloader ab.

Wenn ich mich recht erinnere, bedeutet "!", daß ein Fehler (beim 
Schreiben) aufgetreten ist. Das kann daher kommen, daß der zu 
schreibende Bereich nicht gelöscht wurde...

> Der Script (s.Anhang) ist bereits geändert, um das
> schlicht zu übergehen, allerdings wohl noch nicht in das Firmwarepaket
> integriert.

Ich würde den Fehler nicht ignorieren...

Falk

Ja, "ignorieren" ist falsch ausgedrückt. Es bricht nicht sofort ab (wie 
es dummerweise bisher war), sondern versucht bis zu 10mal die gleiche 
Zeile erneut zu schreiben. Erst dann wird mit einem Fehler wirklich 
abgebrochen. Man muss dann halt untersuchen, was der Grund für das "!" 
ist.

Und stimmt, weiter oben war der Grund für das "!" wohl eine etwas 
instabile serielle Verbindung, was hier offenbar anders ist, wenn der 
Fehler immer an derselben Stelle auftritt. Da wird also der geänderte 
Skript auch nicht helfen.

/Hannes

@Odic

Es ist nicht die Firmware, sondern der Configbereich der hin und wieder 
beim Rumexperimentieren mit unterschiedlichen FW-Versionen einen 
abkriegt.

Übrigens braucht man eigentlich nicht die Kanäle einzeln abzugleichen, 
das kann er auch gleichzeitig.

Hayo

Hi,

gerade wollte ich die neue 0.84 Firmware mit dem neuen Screenshot 
ausrüsten,
aber bei SFN ist kein Durchkommen. Weder komme ich an die Sourcen heran, 
noch an die Screenshot.exe.

Daher werde ich gleich die 0.83 mit der alten Screenshot-Funktion 
rausgeben.

Hayo

New beta release 0.83 out now!

Please pay attention to the release notes! You will find it here:

https://sourceforge.net/projects/welecw2000a/files/

Es sind zahlreiche Bugfixes und Neuerungen eingeflossen. Leider konnte 
ich die neue Version der Screenshot-Funktion nicht mit einbauen. Das 
wird dann in der nächsten kommen. Die passenden PC-Programme zur alten 
Version sind mit im Paket.

Die Statusanzeigevariante (gelbe Buttons oder "black edition") im 
FFT-Modus kann über ein Terminal mit shift + V umgeschaltet werden und 
bleibt dann auch nach dem Aus- und wieder Einschalten so eingestellt!

Die FFT-Sektion ist noch in Arbeit und an einigen Stellen nicht ganz 
fertig. Die Skalierung ist nur für die linearen Bereich korrekt und bei 
den logarithmischen FFT stimmt nur der 5V Bereich.

Da es mich bei der Cursorfunktion etwas störte, das die Deltaanzeige die 
kleineren Werte verdeckte, habe ich der Cursorfunktion eine zwei 
Stufenlogik verpasst (auch im Normalbetrieb).

- Einmal den Cursurknopf drücken -> Anzeige ohne Delta
- nochmal den Cursorknopf drücken -> Anzeige mit Delta
- nochmal drücken -> Cursor aus

Kritik und Anregungen sind wie immer ausdrücklich erwünscht.

Viel Spass

Hayo

Habe auch schnell einen Test mit der Abgleichfunktion gemacht. Habe dazu 
alle vier Kanäle eingeschaltet gelassen, Default Setup aufgerufen, dann 
ADC, Zero Lines und DAC ausgeführt auf 5V, dann nochmal DAC auf 2V und 
auf 1V. Danach war bei mir über alle Spannungsbereiche alles im Lot. Das 
einzige, das mir aufgefallen ist, ist, dass die Nullliniensuche erstmal 
zig DIV's danebengehauen hat, was nach dem DAC Abgleich dann aber i.O. 
war.
Also bei mir gabs kein Problem mit dem gleichzeitigen Abgleich aller 
Kanäle.


Den neuen GERMSloader werde ich morgen testen, wenn ich dann die 0.83 
flashe. Aber ich befürchte fast, dass ein Retry nach einem ! nichts 
bringt. Außerdem denke ich, dass das ! nix mit der wackeligen seriellen 
Schnittstelle zutun hat. Wenn ein Zeichen fehlte oder zuviel war, 
scheiterte die Übertragung ja auf andere Weise, was dann dank der 
Retries ziemlich schnell vom Tisch war.

Gibt's eigentlich Sourcen vom GERMSloader irgendwo? Ich meinte mal 
gelesen zu haben, dass jemand den verändert hätte für eine neue 
Plattform. Eventuell lassen sich in den Sourcen ja Infos finden, was die 
Rückgabe des ! zu bedeuten hat? In diverser Doku von Altera bin ich 
jedenfalls nicht fündig geworden.

@Hannes:
Besten Dank für das Skript, damit funktioniert es

@Hayo
Das Einspielen des Dumps hat keine Veränderung gebracht. Das Verhalten 
tritt auch mit der Orginal-FW auf. Damit würde ich ein SW-Problem 
eigentlich ausschließen.
Ach ja, ich mache den Abgleich für alle Kanäle gleichzeitig. Da habe ich 
mich vielleicht unklar ausgedrückt...


Hat irgendwer eine Idee, wie die HW diesen Effekt verursachen könnte?

@Odic

Wenn sich die Nulllinien weder mit der beta FW noch mit der originalen 
FW einigermaßen einstellen lassen, ist das meines Erachtens ein 
Garantiefall. Schließlich ist die (zugesicherte) Funktion nicht 
vorhanden.

Hayo

Daniel H. schrieb:
> Bzgl. SVN: Ich hatte hier:
> https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal
> angefangen, die Struktur des Repositories zu dokumentieren.

Ich dachte eigentlich, dass auf der Seite oben direkt ersichtlich wird, 
dass die verschiedenen Entwicklungszweige auf FPGA-Seite nach 
verwendetem Softprozessor geordnet sind... Mehrdeutigkeiten wie eure 
jetzige Location "/fpga/firmware/" wollte ich eigentlich vermeiden. Mal 
davon abgesehen, dass es sowas wie "Firmware" eh' nicht gibt (Entweder 
hard oder soft), wäre vermutlich alles andere im Repository im 
fpga-Ordner nach eurer Definition auch Firmware ;) Also, warum packt ihr 
eure Sourcen nicht lieber nach "/fpga/nios/*"? z.B. im NIOS-Ordner noch 
einen Unterordner "Blueflash" oder so anlegen? Dann könnte noch der 
offizielle Welec-Kram auch dort reingeschoben werden und alles ist 
wieder übersichtlich (ok, vielleicht nicht übersichtlich, aber dennoch 
nach einer Regel abgelegt. Deswegen ja die Wiki-Seite.)

@Daniel

Du hast Recht, die von Dir vorgeschlagene Struktur ist logisch gesehen 
korrekt. Allerdings würde ich vorschlagen möglichst nicht so tiefe 
ordnerstrukturen anzulegen, denn ich finde die Navigation doch recht 
mühsam, da man bei Zurücknavigation immer zum Rootverzeichnis 
zurückspringt und sich dann wieder neu durchkämpfen muß.

Übrigens habe ich meine Probleme beim Zugriff auf SFN zu einem großen 
Teil auf den Browser zurückführen können. Mit Opera und Firefox komme 
ich an einige Stellen im Repository nicht heran. Nur mit dem IE klappt 
es dann. Den benutze ich aber eigentlich lieber nicht.

Hayo

Ich bräuchte noch etwas Unterstützung.

Für die neue Screenshotversion fehlt mir noch die aktuelle Windows-.exe

Wo kann ich die finden, bzw. kann die jemand hier einfach mal posten?

Dann kann ich nähmlich kurzfristig noch eine aktualisierte Fassung 
rausbringen.

Hayo

Hallo Hayo,

wie ich gerade feststelle kompiliert das ganze wegen der
Aenderungen von Falk nicht mehr unter Windows.  Zudem
muss noch eine generalisierte Write-Funktion her.

Ich versuche das gerade umzustricken, mehr in ein paar Minuten.
Bin allerdings nicht zu Hause, habe daher keine DSO da und
kann es nicht testen.

Niklas

Hallo nochmal,

okay, sollte laufen.  Win32 .EXE im Anhang.  Bitte sowohl unter
unixoid als Windows testen.  Aenderungen siehe SVN Log.

(und wenn Du die Sourcen dabei packen solltest nicht vergessen
die aktuellen aus dem SVN zu nehmen ;)

Niklas

Niklas O. schrieb:
> Hallo Hayo,
>
> wie ich gerade feststelle kompiliert das ganze wegen der
> Aenderungen von Falk nicht mehr unter Windows.  Zudem
> muss noch eine generalisierte Write-Funktion her.

Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht 
man dazu?

Falk

Hallo Falk,

> Ich sehe schon, ich muß das auch für Windows kompilieren. Was braucht
> man dazu?

ich nehme MinGW ( http://www.mingw.org/ ) dafuer.  Damit kann man
auch fuer Win32 crosscompilen.

Niklas

Hallo Hayo,

sorry, eine Sache vergessen.  Bei -c (Angabe Com-Port) musste
das Argument bei 0 starten (0 fuer COM1), entgegen der
dokumentierten und vorherigen Praxis.  Anbei korrigierte Fassung.

Niklas

Alles klar, danke für die schnelle Reaktion.

Noch zwei Fragen (hatte nur kurz aufs Coding geschaut):

1. Werden bei der V 0.4 noch die nicht benötigten Memoryplanes 
übertragen, oder ist das schon optimiert? Ich habe nämlich im Coding 
gesehen, dass diese noch mit definiert werden.

2. Ist die Triggerung des Screenshots über das PC-Programm optional oder 
wird der ScrShot immer getriggert wenn das Programm aufgerufen wird?

Hayo

Ah, zu 2. hab ich gerade gesehen dass mit der Option  -l wie gehabt 
gewartet wird.


Hayo

Hallo Hayo,

zu (1):  Die Memory-Planes werden noch uebertragen.  Auch andere
unbenutze Planes (abgeschaltete Channels, abgeschaltete Cursor)
werden noch weiter uebertragen.

Das ist alles noch nicht implementiert.

zu (2):  -l ist allerdings noch nicht implementiert.  Es wird
jetzt vom Programm aus immer getriggert (Falk moege mich korrigieren
wenn das nicht stimmt).  -l noch einzuauen waere aber nicht
schwierig.

Niklas

denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter 
Linux nicht zum Laufen.

Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen -> 
hier kann noch optimiert werden!

Hayo

@Niklas

wir haben uns hier gerade überschnitten. Ich hab noch mal schnell 
ausprobiert, man könnte zumindest für die neue Beta schon mal die drei 
Memory planes rausnehmen und die -l Option einbauen.

Ich bin gerade dabei für das QP-Menü eine zweistufige Logic einzubauen

Einmal drücken -> QP Menü
Zweimal kurz hintereinander drücken -> direkter Screenshot

Daher ist das Triggern über PC-Programm nicht unbedingt nötig. Praktisch 
wäre z.B.

- default ist warten
- optional ist externes Triggern des ScrShot

Hayo

Hallo Hayo,

> denkste, es gibt keinen Parameter -l. Irgendwie kriege ich das unter
> Linux nicht zum Laufen.

Unter Linux sollte das nun ungefaehr so ablaufen:

1

$ ./w2000a-screenshot -c /dev/ttyUSB0 -b

Triggert einen Farb-Screenshot auf dem ersten USB<->RS232 Adapter
und schreibt ihn als Bitmap raus.  (-c hat Falk fuer non-Windows
implementiert.  Unter Windows ist das -c 1 fuer COM1 wie gehabt.)

Dank Falks Optimierung dauert das ganze bei mir jetzt nur noch
iirc 37 Sekunden statt knapp unter einer Minute.

Die nicht-existente Option -l wuerde dann halt warten bis das
Scope etwas sendet (Screenshot oder Messdaten), im Falle von
Screenshot das ganze in eine Datei mit aufsteigendem Zahl als
Suffix schreiben und weiterlaufen.  Also so wie das einst bei Kurts
Windows-Port war.

> Wie ich sehe (zu 1.) werden die überflüssigen Planes noch übertragen ->
> hier kann noch optimiert werden!

Ja, das wissen wir :)  Die Entwicklung hat ja nur gestoppt weil Falks
Scope zur Reperatur ist und ich im Moment nicht so viel Zeit habe.

Wenn Du warten moechtest bis zu Deinem naechsten Release kann ich
versuchen das heute Abend und/oder morgen noch einbauen.

> wir haben uns hier gerade überschnitten. Ich hab noch mal schnell
> ausprobiert, man könnte zumindest für die neue Beta schon mal die drei
> Memory planes rausnehmen und die -l Option einbauen.

Ja das waere die einfachste Variante.

> Einmal drücken -> QP Menü
> Zweimal kurz hintereinander drücken -> direkter Screenshot

Das klingt gut.

> - default ist warten
> - optional ist externes Triggern des ScrShot

Ja, das waere auch das alte Verhalten.  -l wuerde dann zudem das
Programm am Laufen halten um so ohne Neustart mehrere Dinge
empfangen zu koennen.

Ist jetzt die Frage wie lange Du warten moechtest bis zum naechsten
Release?

Niklas

Meine Bastelecke (FFT) bleibt erstmal unverändert. Ich wollte eigentlich 
nur die Screenshotfunktion nachreichen, damit wir einen kurzen Break 
machen können um auf einer gemeinsamen Sourcebasis die nächsten Schritte 
abstimmen zu können:

- weitere Aufteilung der Sourcefiles -> hatte Falk angestossen
- ordnen der SFN-struktur
- kurze Abstimmung wer macht wo weiter

Morgen habe ich ziemlich wenig Zeit, daher wäre es vielleicht am Besten 
den Stand so rauszugeben wie wir Ihn heute fertiggestellt bekommen.

Würdest Du die Änderungen denn heute Abend schaffen? Dann würde ich so 
lange warten.

Hayo

Niklas O. schrieb:
...

>> Einmal drücken -> QP Menü
>> Zweimal kurz hintereinander drücken -> direkter Screenshot
>
> Das klingt gut.
>
>> - default ist warten
>> - optional ist externes Triggern des ScrShot
>
> Ja, das waere auch das alte Verhalten.  -l wuerde dann zudem das
> Programm am Laufen halten um so ohne Neustart mehrere Dinge
> empfangen zu koennen.

Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV) 
wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den 
download?

Falk
P.S.: Ich hatte man eine Fernsteuerung mit QT angefangen. Damit kann man 
Knöppe drücken, sich die Ausgabe ansehen, Parameter einstellen etc. Das 
werde ich mal an die neue Firmware anpassen und mit SVN bei SFN 
einwerfen.
P.P.S.: Das scope ist Samstag bei Wittig angekommen. Ich bin mal 
gespannt, wie lange der Tausch dauert...

Hallo,

@Hayo:
> Würdest Du die Änderungen denn heute Abend schaffen?
Ich versuche es.

@Falk:
> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)
> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den
> download?

Mhm, verstehe ich gerade nicht ganz.  Soll das Programm eine gewisse
Zeit warten ob vom Scope etwas kommt und dann, falls nicht, den Vorgang
selbst anstoszen?

Faende ich dann ueberfluessig, m.E. will man etwas sofort abspeichern
oder man moechte alles bereit haben und dann auf Knopfdruck ein
oder mehrere (-l) Screenshots ziehen, wobei es egal ist ob der Mensch
am DSO sich da ne Minute oder mehrere Stunden Zeit laesst.

Niklas

> Wie wäre es damit: Ohne Angabe, was geladen werden soll (Farbe,BW,CSV)
> wartet das Programm, was vom Scope kommt, andernfalls veranlasst es den
> download?

Das ist gut. Optional dann noch der Parameter -b für .bmp

Hayo

Mal wieder überschnitten...

Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h. 
ohne Angabe läuft das Programm in einer Schleife. Nur wenn die 
zusätzlichen Parameter für das Format angegeben werden wird extern der 
Screenshot getriggert.

Hab ich das so richtig interpretiert?

Hayo

Hayo W. schrieb:
> Mal wieder überschnitten...
>
> Ich habe das so verstanden, dass der -l Parameter der Default ist, d.h.
> ohne Angabe läuft das Programm in einer Schleife. Nur wenn die
> zusätzlichen Parameter für das Format angegeben werden wird extern der
> Screenshot getriggert.
>
> Hab ich das so richtig interpretiert?

So meinte ich das.

Falk

@Niklas

Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die 
Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei 
geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon. 
Vielleicht kannst Du das ja mit einfließen lassen?

Hayo

Jürgen schrieb:
> Hallo Hayo,
>
> warum nicht, wie schon mal vorgesehen war, ein separates 3-er QP-Menü
> mit 3 Tasten ( Color,BW,CSV ) vom Oszi aus? Wenn die PC-SW unterscheiden
> kann was kommt... (Hab noch nicht getestet.) Fernbedienung vom PC ist da
> für mich zweitrangig.

Hi Jürgen, hab mich wohl nicht so deutlich ausgedrückt weiter oben. 
Genauso wie Du sagst wird es sein, bzw. ist es sogar schon in der 0.84. 
Nur das zusätzlich die Möglichkeit besteht durch schnelles 2fach drücken 
des QP-Buttons einen direkten Print anzustoßen.

Hayo

Da sich die 0.84 nicht mehr ändern wird hier schon mal vorab die 
Flashdateien für alle die sich die neue QP-Funktionalität mal ansehen 
möchten.

Das komplette Paket mit aktualisierter PC-Software wird es auf SFN geben 
wenn Niklas soweit ist.


@Niklas

Da kannst Du dann gleich sehen ob die 0.84 mit der PC-Software 
harmoniert.

Hayo

Neues vom Vinculum:
Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas 
Demo Code.

Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema 
WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei 
ist "Hallo Welt!"

Jetzt dürfen die Profis ran: Vorhandene Funktionen optimieren, neue 
ergänzen, Lauflängendekomprimierung einbauen, Interrupts benutzen...
Ich werde natürlich auch weiter daran arbeiten, nur bei der ganzen 
Dekomprimierung usw. blicke ich nicht ganz durch.

Eigentlich sollte es möglich sein eine Byte vom Oszi zu empfangen, es zu 
verarbeiten und auf das Vinculum zu schreiben noch bevor das nächste 
Byte vom Oszi ankommt. So bräuchte man kaum RAM im µC.
Dafür muss aber die Oszi Firmware entsprechend umgeschrieben werden?

Die Hardware: Ist nicht wirklich zum Nachbau geeignet und versteht sich 
nur als Layout Vorschlag. Die Leiterbahnführung ist teilweise etwas 
ungünstig, es fehlen Elkos an den USB Buchsen, das Footprint für den 
MAX232 ist zu groß, die Steckverbinder sind auf einer einseitigen 
Platine kaum zu löten...

Wenn jemand noch einen Prototypen bauen will, kann er gerne die Platine 
neu routen. Ansonsten warten wir wie die Softwareentwicklung lauft und 
ich entwerfe Version 2.0 sobald die neuen Anforderungen bekannt sind.

Kurt Bohnen schrieb:
> Neues vom Vinculum:
> Im Anhang Schaltplan und Layout als PDF und Eagle Dateien sowie etwas
> Demo Code.
>
> Die Software erstellt alle 2 Sekunden eine Datei nach dem Schema
> WELECXXX.TXT mit fortlaufender Nummer von 0 bis 255. Inhalt der Datei
> ist "Hallo Welt!"

Kannst Du mich mal erleuchten, wie das Ding angeschlossen wird und was 
genau es tut?

Falk

Naja, an die DC Buchse kommen 5V.
Der 9-Pol D-Sub Stecker unten links geht zum Oszi.
Die 9-Pol D-Sub Buchse dient für Debug Zwecke und geht zum PC.

Mit dem 10-Pol Wannenstecker wird der AVR programmiert und mit der 5-Pol 
SIL Buchsenleiste das Vinculum.
Die linke USB Buchse ist für den Speicherstick.

Und es tut genau das was ich oben geschrieben habe: Alle 2 Sekunden eine 
neue Datei erstellen und auf den USB Stick speichern. Das ist absoluter 
schwachsinn, zeigt aber wie man mit dem VNC1L kommuniziert und Dateien 
anlegen kann.

Oder habe ich deine Frage falsch verstanden?

PS: Der Rest sollte aus dem C-Code und den Datenblättern zum Vinc. 
ersichtlich werden. Oder habe ich noch essentielle Infos unterschlagen?

Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als 
CSV) erstellen zu können ohne einen PC anschließen zu müssen.
Außerdem kann man bestimmt auch einen Drucker anschließen.

Kurt Bohnen schrieb:
> Sinn des ganzen ist es, Screenshots und Speicherdumps (Messdaten als
> CSV) erstellen zu können ohne einen PC anschließen zu müssen.
> Außerdem kann man bestimmt auch einen Drucker anschließen.

Ich glaube, ich hab's jetzt auch begriffen.

Damit wäre in der Firmware ja nur wenig zu tun.

Mit dem Drucker sehe ich Probleme. Selbst ein Postscript-File könnte die 
Firmware überfordern. Das überlasse ich gerne dem AVR ;-)

Falk

Hallo,

so, zusammengestrickt, einiges geaendert und committed.  Im Einzelnen
bekomme ich das jetzt nach dem langen Tag gar nicht mehr alles zusammen.
Bitte SVN Log (und diff) schauen :)

@Hayo:
> Ich habe mir erlaubt die .csv Funktion etwas zu ändern, damit die
> Ausgabe nicht mehr nach stdout geht sondern direkt in eine Datei
> geschrieben wird. Trennzeichen ist dabei (Excelkonform) das Semikolon.
> Vielleicht kannst Du das ja mit einfließen lassen?

Hab' ich gemacht und gleich noch ne Art generisches Framework
(in Ermanglung eines besseren Begriffs) drumrum, so dass man
die Ausgabe spaeter um diverse Formate erweitern kann.  Moeglich
derzeit: -t csv (default) und -t ascii (so wie Falk das im Original
gebaut hatte).

Neu ansonsten unter anderem -i (invertieren), -s (Screenshot, Farbe),
-n num (manuelle Startnummer fuer die notwendig geworde 
Dateinummerierung),
-o (One-Shot, -l (Loop) ist Default-Verhalten (den Switch gibt's daherE
nicht) und -o wuerde das alte Verhalten (einen Dump empfangen, beenden)
wiederherstellen.

Eigentlich wollte ich noch gerne die Faerbung fuer die Planes mit einer
INI-Datei anpassbar machen, das hab' ich aber wegen der Umstruktierung
nicht mehr geschafft.  Wer da bessere Farben raussuchen moechte muss
dies ueber Aenderungen der Sourcefiles tun (gibt oben eine Tabelle,
leicht auch fuer Laien zu machen).  Verbesserungen nehmen wir gerne
entgegen.

@Hayo:
Im Moment schreibt das DSO ja noch die 16 Planes raus.  Wenn die
drei Memory-Planes raus sollen kann das sehr leicht im Programm
angepasst werden.  Das kann ich gerne noch tun.  Vllt. kannst
Du auch noch ne ganz kurze LIESMICH.txt oder so dabei tun, fuer Leute,
die nicht so gut Englisch koennen und mit der README.txt nicht klar
kommen.

@Kurt & Hayo:
Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient
(im Vergleich zu vorher geworden (28k vs. 12-15k)).  Konsequenterweise
muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal 
verbessern).
duck

Win32 .EXE im Anhang.  Bitte nochmal testen.

Niklas

Niklas O. schrieb:

...

> Der Monochrome-Dump ist mit dem geaenderten RLE ja nun sehr ineffizient
> (im Vergleich zu vorher geworden (28k vs. 12-15k)).

Huch, ist er das? Werde ich mir ansehen.

> Konsequenterweise
> muessten wir den alten Algo wieder hernehmen dafuer (oder nochmal
> verbessern).

> *duck*

Da gibts nichts zu ducken. Wenn ich was verschlimmbessert habe, hilft 
Kritik doch nur, es besser machen zu können.

Der Dump der Rohdaten ist ja auch nicht RLE-komprimiert, weil klar war, 
daß kaum jemals mehrere identische Werte aufeinander folgen.

Hat eigentlich mal jemand versucht, die Baudrate zu erhöhen? Es gibt da 
ein Element np_uartdivisor in der puart-Struct. In excalibur.h steht 
allerdings

1

// Parameters for altera_avalon_uart named uart1

2

// baud             = 115200

3

// data_bits        = 8

4

// fixed_baud       = 1

. Das könnte ein Hinweis sein, daß im FPGA ein fester Teiler ist. Im 
USB-UART ist fixed_baud übrigens "0"...

Falk

Hi, echt super!

Bin gerade erst wieder zuhause. Werde mal alles einsammeln und als Paket 
ins SFN stellen. Zum Dokumentieren und Testen komme ich heute nicht 
mehr.

@Niklas

Gibts die Source auf SFN, oder stellst Du die eben noch hier mit ins 
Forum?

Hayo

Hallo Jürgen,

> nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist
> schon da!( Spart viel Tinte :-)

Das war die Intention :)  Muesste man in zukuenftigen Versionen
egtl. auch erweitern koennen und direkt auf einem Windows-Drucker
drucken.

> Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem
> Zusammensetzen der Screenshot-xxx-Datei?

Das sollte nur bei dem (default) PPM/PGM-Output passieren und ist
bei BMP mit -b abgeschaltet.  Eine programmtechnische Notwendigkeit
dafuer gibt es nicht, die Daten sind im RAM.  Gedacht war das primaer
zum Debuggen von Fehlern in der Bildschirmausgabe.  Wenn irgendwo ein
Artefakt ist kann man so leicht rausfinden in welchem Plane.  In
zukuenftigen Versionen sollte man optional machen, das sehe ich
genauso.

@Falk:
> [Baudrate]
Da wir die Daten ohnehin nur im Schneckentempo verarbeitet bekommen
erreichen wir ja nichtmal 38400 Baud.  Nun wissen wir auch, warum
das Datendumping in der Original-Firmware mit der Welec-Software
auch schon ewig dauerte -- und das war via USB.  Bzgl. der Baudrate
hab' ich nur mal getestet ob man theoretisch mit dem Nios die
Leitung saturieren koennte, und das ging.  >=10kB/s sustained
mit putchar().  Ansonsten haben oben iirc. Crazor und andere schonmal
was zum im FPGA implementierten UART geschrieben.

> [Rohdaten Trace]
Ja, RLE bringt eher nix dort.  Hatte wie schonmal ausgefuehrt an
Ausgabe von Delta zwischen Messwert und Messwert n+1 gedacht
(was in der Theorie im Durchschnitt ein geringer Wert sein sollte)
aber die Idee fallen gelassen, da es eh nur max. 4*16kB sind und
jegliche Verarbeitung auf dem Nios die Sache vmtl. langsamer statt
schneller machen wuerde.  CSV Ausgabe ueber ZMODEM direkt an
beliebiges Terminalprogramm wuerde ich aber dennoch gerne hinzufuegen.

Niklas

Hallo Hayo,

die Sourcen gibt's auf SF.  README.txt, retrieve.bat, ComTools.cpp, 
ComTools.h, w2000a-screenshot.cpp, Makefile und
http://www.mikrocontroller.net/attachment/54252/w2000a-screenshot-v0_4.exe
solltest Du in Dein Release dabei packen.

Niklas

@Roberto

Ja ich weiß - default Setup hilft in dem Fall.

-> Ist in Arbeit

Gruß Hayo

Ok folks, release 0.84 with new (late night) screenshot function from 
Falk and Niklas out now - available here:

https://sourceforge.net/projects/welecw2000a/files/


Hayo

Wie schon gesagt, ist noch in Arbeit!

Gruß Hayo

@ Roberto:
Danke, ich dachte schon, mein Scope ist defekt. Vor .83 hatte ich solche 
Probleme mit geänderten Einstellungen nicht...

Michel

Ok Jungs keine Sorge,

angeregt durch die Diskussion im Hardwarethread habe ich ein wenig mit 
Rauschunterdrückung experimentiert. Das funktioniert so gut, das ich 
heute noch ein neues Betarelease rausgebe, da ist dann auch Euer Problem 
beseitigt.

Hayo

Geht nicht - Frauchen sitzt auch am Computer und braucht meinen Support.

Hayo

So, bin soweit. Hier das neue 0.85 beta Release.

Die neue Rauschunterdrückung arbeitet wirklich überzeugend. Dadurch 
werden die 2er und 1er Bereiche tatsächlich benutzbar!!! Die 
Rauschunterdrückung nutzt die sonst unbenutzten Samples bei 
Timebasefaktoren > 1. D.h. der Arbeitsbereich liegt zwischen 100ns und 
500ms. Keine Beeinträchtigung der Bandbreite!! Besonders überzeugend 
kommt die neue Funktion z.B. im 2V Bereich bei 500ns. Natürlich kostet 
die Funktion etwas Performance, aber das liegt denke ich, noch im grünen 
Bereich.

Wo kann man die Rauschunterdrückung anschalten?

-> im Acquire Menü.

Ansonsten gibt es für Roberto jetzt einen Button für das FFT-Layout im 
FFT-Menü und die undefinierten Startzustände sind beseitigt.

So bin mal gespannt auf die Reaktion.

Hayo

Ja wie geil ist das denn??
Wie mit dem Lineal gezogen! Super!

  Lothar

Hayo W. schrieb:
> So bin mal gespannt auf die Reaktion.

Alda!!!!

Plötzlich sieht es genau so aus, wie ich es von Anfang an gern gesehen 
hätte. Das ist ein Unterschied wie zwischen Tag und Nacht!

Super Sache!

/Hannes

Nix da, hier wird kein Sample verschenkt! :-D

/Hannes

@Stefan

Das war nur der Prototyp. Die jetzige Version ist auf shift optimiert.

D.h. der am wenigsten effektive Bereich ist der 100ns Bereich, da hier 
der Faktor nur 2 ist.

die Bereiche mit Faktor 4 und 5 (also die meisten) arbeiten mit 8 Werten 
d.h. shift um 3 nach rechts, die TB mit Faktoren >= 10 arbeiten mit 16 
Werten d.h. >> 4.

Hayo

Das Ergebnis ist super =)
Ein minor Bug, wenn man die FFT Ansicht ändert, wird das schwarze Layout 
hinter dem gelben gezeichnet. Nach nochmaligem de- und aktivieren wird 
das Menü richtig gezeichnet.

@Robert

Danke für den Hinweis, hatte ich mit der heißen Nadel gestrickt und 
nicht geprüft. Beim nächste Release ;-)

Hayo

Ja da hatte ich mir auch schon Gedanken zu gemacht. Wollte ich mir mal 
näher ansehen und gucken ob man das nicht verbessern kann...

Hayo

@branadic

Du kennst meine Lineale nicht! ;)
Zugegeben - war leicht übertrieben. Aber die Begeisterung nach dem 
Flashen war groß und ist es immmernoch.
Dickes Kompliment an Hayo!

  Lothar

@Hayo

Gute Arbeit, ein bisschen beschneidest du mit der Mittelung die 
dargestellte Bandbreite (um das zu verhindern duerftest du in jedem 
Bereich max. Faktor Werte fuer die Mittelung verwenden), meiner Meinung 
nach kann das aber so bleiben, und zudem kann man die Mittelung ja 
abschalten.

Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)

Martin

@Lothar

Ich war selbst überrascht als ich das Ergebnis sah. Deshalb auch noch 
das spontane neue Release.

Hayo

@Martin

Ja, durch die Überlappung gibt es natürlich rein rechnerisch eine 
Bandbreitenverringerung. Praktisch ist diese aber außerhalb der 
darstellbaren tatsächlichen Signalbandbreite unseres DSO. D.h. bei einem 
realen Signal wirst Du beim Umschalten keinen Unterschied bemerken. Wo 
man es sehen kann, dass ist beim Testsignal. Da das Rechtecksignal hier 
unendlich steile Flanken hat und damit natürlich extrem hohe 
Frequenzanteile, sieht man beim Umschalten, dass die Flanken minimal 
flacher werden.

> Wenn du nun auch noch meine andere Idee in betracht ziehen koenntest ;-)

Da bin ich schon längst bei. Ich habe aber Schwierigkeiten mir das 
vorzustellen wie sich das auswirkt, wenn ich mehrere Werte an eine 
X-Position schreibe. Dadurch wird doch eigentlich nur der Linienzug 
breiter und damit das Signal unschärfer - oder hab ich das 
mißverstanden?

Hayo

Ohne Mittelwert

Mit Mittelwert

@Hayo

Das die Linie breiter wird ist richtig, diese Darstellung hilft aber ein 
untersampling zu erkennen (es wird die angezeigte Samplerate dargestellt 
und nicht die durch den Faktor reduzierte).

Martin

Einmal ohne Rauschunterdrückung...

Guido schrieb:
> Hallo Hayo,
>
> das sieht wirklich gut aus. Langsam wird das Welec so, wie ich
> mir das beim Kauf vorgestellt habe. Fehlt nur noch die USB-
> Anbindung für Screendump,

USB für Screendump sollte kein Problem sein. Da hat man aber nur die 
halbe Gaudrate und auf der PC-Seite ist USB nicht so trivial wie RS232.

Mit Libusb habe ich schon etwas für Linux, wie das unter Windows 
aussieht, weiß ich nicht.

Gruß,
Falk
P.S.: Heute kam mein Scope zurück. Anscheinend wurde das Mainboard 
ausgetauscht. Über den Service kann ich mich nicht beklagen!

Oh da läuft wohl was beim Screenshot etwas schief - also das war mit 
Rauschunterdrückung und hier ohne.

Hayo

Ich benutze die neue Screenshotfunktion gerade das erste mal und stelle 
fest, dass bei mir immer zwei Screebnshots produziert werden statt einer 
(unter Windows getestet). Ist das bei Euch auch so?

Hayo

Scheint die zweistufige Logik zu sein, anscheinend ist das Timing noch 
nicht ganz optimal.

Hayo

@Falk

Da hast du scheinbar eine bevorzugte Behandlung! Ich warte seit dem 
1.7.2009 auf das bei Ebay erworbene W2024A!

Martin

Hallo Hayo,

also bei mir wird nur ein Screendump erzeugt (screenshot-0000.bmp). Ich 
starte mit den Parametern -b-s. Schade allerdings das Screendump.exe 
nicht wartet bis ich einen Dump mit Quick Print anfordere, sondern 
direkt loslegt. Keine gute Lösung!

Sehr überzeugendes Ergebnis mit der Rauschunterdrückung. Hätte gedacht 
das dadurch die Performance stärker leidet, ist aber absolut im grünen 
Bereich ;-)

Jetzt müssen wir nur noch das Rauschen in den schnelleren Bereichen in 
den Griff bekommen... und die blöde Oszillation... und die Wishlist...

Gruß, brunowe

@Bruno

-s ist der Parameter für externes Auslösen! Wenn Du den weglässt wartet 
das Programm auf das DSO.

Ich hab den Fehler für die "Doppelbelichtung" gefunden und beseitigt, 
gibts im nächsten Release.

Ebenso gibt es einen kleinen Bug im neuen Acquire-Menü. Die Buttonlogik 
wird beim Neustart hin und wieder durch alte (falsche) Flashwerte aus 
dem Tritt gebracht und blockiert dann. Hier hilft erstmal default Setup. 
Ist in der nächsten beta beseitigt.

Hayo

Hallo,

kann mir einer die 0.85 hier reinstellen? SF liefert gerade einen Fehler 
beim Download.

Danke

0.85 hat Hayo schon oben reingestellt: 
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Ich warte auch seit 1.7. auf mein Scope, das mir bis 8.7. zugesagt 
wurde. Als es nicht kam wurde es bis gestern zugesagt und kam natürlich 
wieder nicht. Langsam bin ich ziemlich genervt, schließlich will ich 
hier auch endlich mitmischen können!
Außerdem ist das doch reichlich unprofessionell von den Wittigs, Zusagen 
zu machen und dann nicht einzuhalten. Naja, vielleicht ist 
Unprofessionalität ja ihre Firmenphilosophie? Dann müsste man zumindest 
große Konsequenz bei der Umsetzung in allen Bereichen bescheinigen.
Hat das bei euch auch so lang gedauert?

Gruß, Michael

branadic schrieb:
> Nach wie vor bin ich übrigens der Meinung, dass der Triggerlevel nicht
> auf einen Pixelwert auf dem TFT eingestellt werden soll, sondern auf
> einen Spannungswert. Sobald ich also den Spannungsbereich meines
> Signales umstelle sollte der Triggerlevel nach wie vor auf den gleichen
> Spannungswert des Signales triggern.
> Vielleicht lassen sich hier ja auch beide Möglichkeiten implementieren,
> dann wäre es für jeden individuell einstellbar.

Das finde ich auch, allerdings wirst du kleinere Sprünge in der zu 
triggernden Spannung hinnehmen müssen, da ja (vermutlich auch im 
Originaldesign; definitiv aber bei mir) auf ADC-Rohwerte getriggert 
wird.

Hallo Roberto,

> Screenshot:
> Beim Screenshot kommen bei mir auch immer zwei Bilder!
> Einstellung -c1 -b
> Warum kann eigentlich der Photoshop 5.0 das BMP nicht lesen?
> Kann das jemand bestätigen ?

Das Problem zum ersten Punkt hat Hayo ja schon gefunden und
ist Firmware-seitig.

Letzteres habe ich in der englischen README beschrieben.
Es haengt damit zusammen, dass die Standardvariante, die Pixel
im BMP Format abzuspeichern, entgegen der konventionellen
Reihenfolge geht.  Statt von oben links Zeilenweise bis unten
rechts geht's da von unten links bis oben rechts.  Aber es
ist durch Angabe einer negativen Hoehe auch vorgesehen in
"normaler" Reihenfolge abzuspeichern.  Wie sich fuer mich
erst nach Implementation heraus stellte ist dies anscheinend
manchen Bibliotheken und/oder Programmen nicht bekannt und
wollen mit der Datei nichts anfangen.

Niklas

@ Hayo,

ich hab da noch einmal ein paar prinzipielle Frage zu deiner FFT:

1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer 
Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt. sind 
ok. --known Bug?
2.) die Anzeige rechts bedeutet?
df = kleinster Frequenzauflösung bei der FFT- Berechnung (man erkennt 
schön wie bei Übergang von 512 zu 1024 dieser Wert halbiert wird)
_fn_: Hälfte der oben angezeigten Samplingfrequenz- wobei hier der TB- 
Faktor nicht berücksichtigt wird- Was bringt diese Anzeige also dann?
_div_: ??? das erschließt sich mir jetzt leider nicht.

Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die 
Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor 
gar nicht nutzbar ist und nur zu Fehlinterpretation führt)
Falls ich das soweit richtig verstanden habe, sollte man dann den 
angezeigten Frequenzbereich nicht auf den sinnvollen Wertebereich 
einschränken?
Das hatte ich oben schon mal angeregt, hatte mich diesbzgl. aber wohl 
missverständlich ausgedrückt.

Gruß, brunowe

@Branadic

- Der Punkt mit dem Triggerlevel steht auch in meiner ToDo liste im 
Beipackzettel des Paketes. Wie so of gibt es allerdings so viele Punkte 
dass wir da nur Prioritäten sortieren können.

- Die FFT-Fenster stimmen ja schon fast überein, allerdings wollte ich 
noch einige hinzufügen (z.B. Flat Top ist noch in Arbeit, Hamming steht 
auch in der Pipeline und zu Poisson und Kaiser-Bessel hab ich noch 
Versionen mit anderen Koeffizienten parat).

- Der Datendownload ist nur ein erster Prototyp. Deine Anregungen sind 
schon mal sehr gut. An diesem Thema werden wohl Niklas und Falk (jetzt 
wieder mit Oszi) dran sein.

Hayo

Sehr schöne FFT. Hut ab!

Auch die Unterordnung des Screenshot-Verzeichnisses unter die Firmware 
finde ich gut.

Zur Baudrate: Beim RS232-UART ist die anscheinend nicht zu ändern. Das 
könnte beim USB-UART anders sein. Das aber wäre nur sinnvoll, wenn man 
auch die des Cypress ändern könnte, und davon verstehe ich nix.

Bei mir dauert der BW-Screenshot übrigens 12s...

Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis 
und alle anderen Parameter in einem Header mitzusenden. Das kann ja 
nicht allzuviel sein.

Falk

Hallo branadic,

> zum Export von Samples in ein CSV oder ASCII File hätte ich noch ein
> paar Anregungen. Beim Tek gibt es die Möglichkeiten:
>
> - Save Samples xxx to xxx
> - Save Samples between Cursors
> - Save Samples in Zoom Area (entspräche wahrscheinlich den Daten im
> Delayed-Fenster)
> - Save All

Mhm.  Wahrscheinlich hat das Tek eine wesentlich groeszere 
Samplingtiefe,
oder?  Jedenfalls sind das IMHO bissl viel Einstellungsmoeglichkeiten.

Die Cursor-Werte usw. koennen wir mituebermitteln, so dass diese
entsprechend gekennzeichnet werden koennen.

Einbau von selektiver Speicherung ist sicherlich nicht schwierig, die 
Frage ist, was da bei unserem Geraet sinvoll ist und die Bedienung
nicht unnoetig verkompliziert.  Cursor, Screen und All z.B..  Bei nem
Delayed-Fenster waere Screen dann der untere "gezoomte" Teil.

> wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.

Siehe oben, bringt bei uns nicht so viel.

> Darüber hinaus lässt sich auswählen, welcher Kanal exportiert werden
> soll:
>
> - Channel 1  2  3 / 4
> - Math 1  2  3 / 4
> - Ref 1  2  3 / 4

Mhm, was ist denn Ref da?  Koennte man statt da nochmal die Kanaele
auszuwaehlen die ungewollten nicht einfach fuer den Export ausschalten? 
Waere intuitiver.
(Vorrausgesetzt natuerlich, man hat das Sampling bereits gestoppt.)

> Als Data Destination stehen zur Auswahl:
>
> - Spreadsheet CSV
> - Spreadsheet TXT
> - Mathcad
> - Matlab
> [Textuelle Beschreibung]

Kannst Du uns da mal fuer alle Moeglichkeiten reale Ausgaben
vom Tek zukommen lassen?

Niklas

@Bruno

> 1.) Wenn ich auf Gauss bzw. Kais.-Bess. schalte wird mein ganzer
> Bildschirm gelb/ bzw. grün- übersteuert- alle anderen Fensterfkt.
> sind ok. --known Bug?

Äh nein, war mir noch nicht aufgefallen - ist notiert

> 2.) die Anzeige rechts bedeutet?

df -> delta frequency - ist die spectrale Auflösung der FFT (Bandbreite 
einer Linie)

fN -> Nyquistfrequenz, entspricht der maximal darstellbaren Frequenz der 
FFT

div -> frequenzteilung des Grid, Bandbreite eines Gridrasters

> Wenn ich das richtig sehe, dann stellt die FFT- Funktion immer die
> Frequenzen bis fn dar? (Obwohl der obere Bereich ggf. wg. dem TB- Faktor
> gar nicht nutzbar ist und nur zu Fehlinterpretation führt)

Der TB-Faktor wird bei der FFT nicht berücksichtigt. Entscheidend ist 
daher für die FFT nicht die TB in Zeit/div sondern die angezeigte 
Samplerate und dementsprechend auch der halbe Kehrwert nahmlich die 
Nyquistfrequenz

Hayo

Noch einer zur Datenübertragung:

Der Math-Channel enthält nur redundante Daten, die zudem auch nur für 
den angezeigten Fensterausschnitt berechnet werden. Da diese Daten auch 
problemlos extern (in einem Excelsheet oder einem Programm) 
rekonstruiert werden können, muß man die nicht auch noch durch die 
Strippe quetschen.

Hayo

Hallo,

@Falk:
> Bei mir dauert der BW-Screenshot übrigens 12s..
Falls Du Dich auf meine "Kritik" von zuvor beziehst:
Ich meinte nicht eine verschlechterte Zeit sondern
die Verdopplung der Datenmenge :)

@Hayo:
Wo ich gerade am Testen bin:  Wir hatten mal das Thema
Save/Recall, was in unserer FW nicht mehr funktionierte.
Du meintest glaube ich, dass es an den geaenderten
Speicherstellen laege.  Hattest Du das schon gefixt?

Bin gerade zufaellig wieder drauf gekommen als branadic
die Ueberlagerung/den Vergleich von Samples erwaehnte.
Bei mir funktioniert Save/Recall bei 0.85 jedenfalls
noch nicht.

Ich hatte glaub' ich auch angeregt, fuer solche Vergleiche
unbenutzte Planes herzunehmen.  Wie sieht das aus technischer
Sicht aus, ist da was "hart verdrahtet" im FPGA oder koennen
wir auch eigene Planes fuer diese Zwecke erzeugen?

Niklas

Hi,
kann man zu der FFT nicht noch 'ne Möglichkeit hiinzufügen, um das 
Originalsignal (meinetwegen auch skaliert) mit darzustellen? Hab hier 
mal einen Screenshot eines anderen scopes gefunden...
(nur so eine Idee, nicht das Hayo noch auf den Gedanken kommt, ein Bier 
trinken zu gehen...)
;-)

Hallo Falk,

> Bezüglich der CSV-Dumps halte ich es für sinnvoll, Auflösung, Zeitbasis
> und alle anderen Parameter in einem Header mitzusenden. Das kann ja
> nicht allzuviel sein.

Ja, so hatte ich mir das urspruenglich auch vorgestellt.

Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
wolltest, sollten wir nicht gleich aus dem vorhanden Auslesecode
eine Library machen, die dann sowohl GUI und Konsolenprogramm
benutzen?

Wie sieht Dein Plan aus?  Wenn uns branadic die Beispielausgaben
liefert wuerde ich mich gerne daran machen das umzusetzen.
Du wolltest ja auch die Firmware handlicher machen.
(Ich habe die btw. die naechsten Tage wieder Zeit.)

Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation
des Repositories durch Daniel/crazor.

Niklas

@Niklas

An der Save/Recall-Sache war ich noch nicht dran, da ich erst mal unsere 
Organisatorische Pause abwarten wollte, das Release gestern war nur eine 
Spontane Sache. Ich könnte allerdings die minor Fixes von heute noch
reinstellen bevor wir dichtmachen, soll ich?


@Michael

Ist machbar, erfordert aber eine neue bzw. stark überarbeitete 
Zeichenroutine. Daher wird das wohl kurzfristig nichts (bin in zwei 
Wochen erstmal im Urlaub zum Biertrinken ;-))
Ist aber im Hinterkopf.


Hayo

Niklas O. schrieb:
> Hallo,
>
> @Falk:
>> Bei mir dauert der BW-Screenshot übrigens 12s..
> Falls Du Dich auf meine "Kritik" von zuvor beziehst:
> Ich meinte nicht eine verschlechterte Zeit sondern
> die Verdopplung der Datenmenge :)

"Size does not matter" ;-)

Ich kann mit 12s/30s gut leben, also lasse ich das vorerst so.

Interessanter finde ich ja ohnehin die Rohdaten. Die kann man 
schließlich auf dem PC beliebig weiterverarbeiten, während ein 
Screenshot nur ein Bild darstellt.

Die Übertragung der Daten aller vier Kanäle dauert ca. 7s, die ganzen 
Parameter sollten in unter einer Sekunde zu übertragen sein.

Dann hat man alle Informationen, um auf dem PC ein Bild zu malen, zu 
Drucken, Mathcad/Matlab-Files zu schreiben, wildeste Analysen 
anzustellen oder automatisiert einen Twitter-Eintrag zu schreiben ;-)

Als sinnvolle Verbesserung sehe ich eher, die Einstellungen zu 
übertragen und nur die ausgewählten Kanäle.

Eine Fernsteuerung mit dem PC könnte auch noch interessant sein.

Meine 2¢,
Falk

Niklas O. schrieb:
> Hallo Falk,

> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
> wolltest,

Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert 
genauso mit dem Scope, wie das screendump-Programm.

> sollten wir nicht gleich aus dem vorhanden Auslesecode
> eine Library machen, die dann sowohl GUI und Konsolenprogramm
> benutzen?

Ok, mach' ich.

> Wie sieht Dein Plan aus?  Wenn uns branadic die Beispielausgaben
> liefert wuerde ich mich gerne daran machen das umzusetzen.
> Du wolltest ja auch die Firmware handlicher machen.
> (Ich habe die btw. die naechsten Tage wieder Zeit.)

Im ersten Schritt fände ich es gut, die PC-Kommunikationsfunktionen in 
eine getrennte Datei auszulagern, also "Display::DUMPCSV", 
"Display::SCREENSHOT", Display::SCREENSHOT_BW, und "rle_enc" in 
pc_comm.cpp/h.

> Wir sollten uns da mal abstimmen, auch bzgl. der Reorganisation
> des Repositories durch Daniel/crazor.

Mein Vorschlag: Irgendwo unterhalb /
- firmware/FW1.2.BF.X.yy/src
- firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
etc.

Aber soll Daniel doch einfach einen Vorschlag machen (oder hatte er das 
nicht schon?)

Falk

Mal ne Frage an die Spezis:

Die USB-Verbindung zum Rechner ist doch im Scope auch "nur" ne UART. Wie 
geht es denn ab dem FX1 dann weiter zum Rechner? Zumindest bei einem 
schnellen Test konnte ich nicht ausmachen, dass die Originalsoftware 
(+Treiber) einen virtuellen COM-Port anlegt, über den dann die 
Kommunikation erfolgt.

Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu 
reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob 
eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über 
USB machbar ist...

Habe etwas zu frueh geschumpfen: Das W2024A ist heute bei mir 
eingetroffen (und scheint auch in gutem Zustand zu sein), wieder 
erwarten sogar mit 4 Sonden!
Auf die Wittigs ist noch verlass.

Martin

Daniel H. schrieb:
> Mal ne Frage an die Spezis:
...

> Irgendwer hatte doch auch schonmal angefangen, das USB-"Protokoll" zu
> reversen, wo gab's denn noch die Infos dazu? Ich frage mich, ob
> eventuell ohne allzugroße Änderungen doch noch eine UART-Verbindung über
> USB machbar ist...

Ich hatte mit "usbmon" getraced und dann mit der "libusb" verschiedene 
Kommandos ausprobiert.
Das Ergebnis steht hier: 
http://groups.google.com/group/welec-dso/web/usb-commands?hl=en

Das scheint nicht einfach USB-RS232 zu sein, sondern etwas 
Capress-spezifisches. Deswegen nehme ich auch an, daß man per USP auch 
die Baudrate des Chips ändern kann.

Falk

Der Cypress ist im Grunde ein um den USB erweiterter 8051er.

Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang 
mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die: 
Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit 
der PC-Software die entsprechende Funktionalität in den Cypress nachlädt 
(ByteBlaster, UART, ... was auch immer).

Leider bin ich als 'Hochsprachler' noch nicht viel weiter gekommen und 
habe jobmäßig auch arg viel zu tun... Bin froh, wenn ich diese Woche die 
ersten Taschen raushauen kann ;-)

Michel

Falk Willberg schrieb:
> Niklas O. schrieb:
>> Hallo Falk,
>
>> Sag mal, wo Du ja auch noch Deine QT-GUI ins SVN Repository stellen
>> wolltest,
>
> Das will ich noch an die geänderte Firmware anpassen. Das kommuniziert
> genauso mit dem Scope, wie das screendump-Programm.

Ok, ich hatte es ja angedroht. Das tar-Archiv ist angehängt. Es 
kompiliert unter Linux, funktioniert aber nicht mit irgendeiner 
Firmware. Betrachtet es bitte als Qt-Übung.

Leider habe ich im SVN völlig die Übersicht verloren, daher hier als 
Anhang.

Jeder, der sich mit Qt auskennt, ist herzlich eingeladen, Verbesserungen 
einzubauen.

Falk

Stefan schrieb:
> Hab's nicht verstanden... was genau spricht gegen die momentan
> schnellere serielle Schnittstelle (?)

IMO nichts. Wenn wir es schaffen sollten, die Baudrate da zu 
vervierfachen (223400), könnte es sinnvoll sein...

Falk

Michael W. schrieb:
> Der Cypress ist im Grunde ein um den USB erweiterter 8051er.
>
> Es gibt auf der Cypress Seite Tools und Code. Hatte mich im Zusammenhang
> mit dem ByteBlaster mal ein wenig eingelesen. Die beste Lösung wäre die:
> Einen rudimentären Treiber zu schreiben, der dann im Zusammenhang mit
> der PC-Software die entsprechende Funktionalität in den Cypress nachlädt
> (ByteBlaster, UART, ... was auch immer).

Genau soetwas habe ich im Gespräch mit Hans auch schon ausgeheckt. Hans 
hat sich daraufhin auch schon mit der Materie auseinandergesetzt. Unsere 
Idee ist, die ByteBlaster-Firmware dahingehend zu erweitern, dass sie 
eben auch als virtueller COM-Port fungieren kann. Falls das nicht 
zeitgleich möglich ist, dann sollte die Umschaltung von der Seite des 
Softprozessors im FPGA aus realisiert werden. Man könnte dann ein 
kleines Powerup-Protokoll implementieren, das bei Ausbleiben einer 
Meldung von Seiten des FPGA einfach die ByteBlaster-Firmware startet, 
damit man den Zugriff auf den FPGA nicht verlieren kann.

Falls du oder jemand anderes mehr Erfahrungen mit den EZ-USB's hat, 
mache ich dich/euch gern mit Hans bekannt.

Edit: Bei der Gelegenheit sollte man den Humbug mit der "ReNumeration" 
auch sein lassen und solch eine Firmware direkt in das EEPROM packen, 
das am FX1 (gnädigerweise) dranhängt. Habe da momentan fest die 
ByteBlaster-Firmware drin, da es so keine Probleme mehr mit Quartus 
gibt.

Hallo,

ich hab' Falks Qt-GUI ins SNV importiert unter /pc/w2000a-qtgui/
(Namen koennen wir ja spaeter nochmal aendern) und einen Ordner
/pc/libw2000a/ fuer gemeinsam genutzten Code angelegt.
Wer sich dem Code annehmen moechte aber nicht mit SVN klarkommt
kann natuerlich auch die Aenderungen hier senden.

@branadic:
Danke fuer die Files.

@Hayo:
> [SVN Repository, Strukturierung, Firmware handlicher machen]
> Ich könnte allerdings die minor Fixes von heute noch
> reinstellen bevor wir dichtmachen, soll ich?

Ja waere vllt. nicht schlecht.  Stefan hat ja das Repository
bereits auf den Stand 0.84 und dann 0.85 gebracht.  Fehlt also
wirklich nur heute.

Der egtl. angedachte Platz von Daniel fuer die Firmware waere
dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und
/fpga/nios/welec fuer die 1.2.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

@Falk:
> Mein Vorschlag: Irgendwo unterhalb /
> - firmware/FW1.2.BF.X.yy/src
> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/

Das widerspraeche etwas dem Konzept von Versionssystemen :)
Was Du meinst kann man durch Tagging erreichen, also
einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"
auszeichnen.  Wenn jemand dann genau den Stand moechte kann
er diesen explizit auschecken.

Aber da muss ich bei SVN leider passen, wie das dort geschieht
muesste ich selber nachlesen.

> Aber soll Daniel doch einfach einen Vorschlag machen
> (oder hatte er das nicht schon?)

Ja hatte er, Link ist paar Zeilen hierueber.  Wenn also einer
der versierten SVN Nutzer des Amtes walten wuerde und das in
die Tat umsetzt :)

Niklas

Niklas O. schrieb:
> Der egtl. angedachte Platz von Daniel fuer die Firmware waere
> dann unter /fpga/nios/, z.B. also /fpga/nios/blueflash und
> /fpga/nios/welec fuer die 1.2.
> Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Super!

> @Falk:
>> Mein Vorschlag: Irgendwo unterhalb /
>> - firmware/FW1.2.BF.X.yy/src
>> - firmware/FW1.2.BF.X.yy/Screenshot_X.Y/
>
> Das widerspraeche etwas dem Konzept von Versionssystemen :)
> Was Du meinst kann man durch Tagging erreichen, also
> einen bestimmten Versionsstand z.B. als "Release-FW1.2.BF.0.85"
> auszeichnen.  Wenn jemand dann genau den Stand moechte kann
> er diesen explizit auschecken.
>
> Aber da muss ich bei SVN leider passen, wie das dort geschieht
> muesste ich selber nachlesen.

Wie ich oben schonmal geschrieben habe: SVN unterscheidet nicht zwischen 
Copy-, Branch- und Tag-Operationen. Wenn man in ein Tag-Verzeichnis den 
aktuellen Trunk kopiert, dann ist der Inhalt des Ordners einfach nur 
eine Referenz auf den aktuellen Stand. Arbeitet man am Trunk weiter, 
dann sind die Dateien im Tag-Verzeichnis quasi Zeiger auf die Versionen, 
von denen beim Erstellen des Tags kopiert wurde. SVN verhindert 
allerdings nicht, dass im Tag-Ordner herumgebastelt wird. Da ist dann 
die Disziplin der Nutzer gefragt. Falls es dennoch mal passiert, sieht 
man das schnell am Log und man kann mit nem Rückwärts-Diff die Lage 
wieder richten.
Branchen geht genau wie Taggen, nur ist anschließend das Modifizieren 
ausdrücklich erlaubt ;)

Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.

Ich habe die heute gemeldeten Bugs gefixed und noch eine neue Kanalwahl 
für die FFT spendiert - man kann jetzt die Source auch direkt über die 
Kanalknöpfe anwählen.

Hayo

Bevor es jemand anderes meldet: Eine Kleinigkeit hab ich jetzt bei der 
Nachlese noch gefunden, die Kanalanzeige oben in der Statuszeile wird 
nicht umgeschaltet wenn man die Source über das Menu einstellt. Da das 
nich wirklich wehtut werde ich das mal bis zum nächsten Release 
offenlassen.

Hayo

Ach ja, ich mach jetzt erstmal Entwicklungsstop. Wenn Ihr also 
Organisatorisch oder Sourcemäßig was ändern wollt ist jetzt der richtige 
Zeitpunkt. Die Sourcen sind noch nicht mit SVN eingepflegt, da ich mich 
mit dem Teil noch nicht angefreundet habe. Vielleich kann das jemand für 
mich übernehmen - danke!

Hayo

hab mal Nägel mit Köpfen gemacht und das angepasst. Langsam werde ich 
war mit subversion

Hayo W. schrieb:
> Ok, die 0.86 beta ist jetzt auch auf SFN verfügbar.
>
> Ich habe die heute gemeldeten Bugs gefixed
......

Ich habe mal angefangen, eine neue Klasse PCComms mit

1

static void SCREENSHOT_BW(void);    // nevm

2

    static void SCREENSHOT(void);       // nevm

3

    static void DUMPCSV(void);      // #FW#

4

    static void handle_extended_command(unsigned char extended_cmd_buffer[EXTCMDLEN]); //#FW#

anzulegen.

In hardware_t.cpp habe ich (möglichst wenig) geändert. Ich würde gerne 
alles zwischen

1

    if (UART_NewData) {

2

        UART_NewData = 0;               //reset UART ISR flag

3

        switch (state) {

4

...

5

            break;

6

            }

7

        }

In die Klasse PCComms auslagern und mit PCComms::handleInChar(unsigned 
char c) behandeln....

Dann kann ich nämlich die rudimentären Fernsteuergeschichten ins GUI 
einbauen.

Allmählich müssen wir uns mit den Konzepten von SVN auseinandersetzen:
http://de.wikipedia.org/wiki/Subversion_(Software) und 
http://svnbook.red-bean.com/nightly/de/index.html

Falk

Sodala,

SF ist jetzt abgeändert. Sourcen liegen unter fpga/nios/oss

Die aktuelle Version ist die .86

Wo finde ich die original Sourcen? Nur der vollständigkeit halber.

@Hayo

wenn du eine persönliche Einführung in subversion willst, dann kannst ja 
mal eine PM schreiben.

Gruß,
Stefan

Stefan E. schrieb:
> hab mal Nägel mit Köpfen gemacht und das angepasst. Langsam werde ich
> war mit subversion

Wunderbar, wir haben einen Repository Manager ;-)

Nur, wo finde ich die aktuelle Version?

1

welecw2000a/fpga/firmware/src/flash_t.cpp

2

welecw2000a/fpga/welec/improved/src/flash_t.cpp

3

welecw2000a/fpga/welec/improved/src/quickmeasurement/flash_t.cpp

4

welecw2000a/fpga/welec/improved/src/src/flash_t.cpp

??

Das sieht ja shconmal gut aus im SVN Repo. Ein Hinweis noch: SVN bietet 
auch einen Move-Befehl, der macht dann Copy&Delete in einem Schritt, mit 
dem Vorteil, dass alle Repository-Browser das dann korrekt darstellen.

Hallo,

@Stefan:
> Wo finde ich die original Sourcen? Nur der vollständigkeit halber.

Ich bin erst seit kurzem dabei aber so wie ich das verstanden habe
hat Bruno urspruenglich
http://welec-dso.googlegroups.com/web/W2000A+Firmware+V1.2-+Sourcecode.zip
von Wittig erhalten.

Das sind aber nur ein paar C++ Dateien, es fehlt mind. die 
Buildumgebung.
(Das war auch bis r129 im SVN Repository unter /fpga/welec/original/,
habe ich dann etwas uebereilig geloescht da es fuer mich unvollstaendig
aussah.)

Da muessten die "alteingesessenen" Bruno, Hayo und Co. was zu sagen.  In
alten Threads habe ich Verweise auf Sourceforge gefunden die aber leider
nicht mehr funktionieren.

@Falk:
> Nur, wo finde ich die aktuelle Version?

Ich gehe mal davon aus, dass Du schon "svn update" gemacht hast.
Es sollte dann /fpga/firmware/ bis auf Deine lokalen Aenderungen
freigeraeumt sein.  Die musst Du dann noch manuell uebernehmen.

Die aktuell gueltige Location ist nun wie Stefan schon schreibt
/fpga/nios/oss/.  In /fpga/welec/improved/ wurde u.a. an
QuickMeasure gearbeitet und der Pfad wird momentan nicht
(mehr) verwendet.

Niklas

Niklas O. schrieb:

> @Falk:
>> Nur, wo finde ich die aktuelle Version?
...
> Die aktuell gueltige Location ist nun wie Stefan schon schreibt
> /fpga/nios/oss/.

Da bin ich jetzt dran. Ich habe die Behandlung von Zeichen vom UART in 
die Klasse PCComms ausgelagert, ebenso unsere Screenshot-Funktionen.

Nach dem commit, werde ich diese Dateien auch wieder unlocken.

Damit ist praktisch alles, was mit der PC-Kommunikation zu tun hat, in 
PC-comms.cpp/h.

Wenn ich das richtig sehe, haben wir nur einen Trunk, in dem gearbeitet 
wird, aber keine Tags mit benutzbaren Zwischenreleases....

Falk

Das siehst du richtig. Bis zu dem Kapitel bin ich noch nicht gekommen 
;-)

Was ist eigentlich der Ordner "fft"? Ist das ein branch?

Hallo Stefan,

> Was ist eigentlich der Ordner "fft"? Ist das ein branch?

Nein, siehe:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Niklas

Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind, 
dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss' 
erstmal nur 'tags','branches' und 'trunk' erscheint?

Stefan E. schrieb:
> Ok, weg mit dem Ordner. Soll ich, wenn wir schon beim umstellen sind,
> dass ganze noch um eine Ordner-Ebene erweitern, so dass unter 'oss'
> erstmal nur 'tags','branches' und 'trunk' erscheint?

Wegen mir gerne. Gearbeitet wird dann in Trunk? Und wenn ein Oberguru 
"OK" sagt, macht er daraus einen Tag?

Falk, nix offen momentan

Nach dem wir die einzigen momentan sind, nutze ich gleich mal die 
Chance...

Stefan E. schrieb:
> Nach dem wir die einzigen momentan sind, nutze ich gleich mal die
> Chance...

Ich versuche das auch mit w2000a-qtgui.

Falk

Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber 
nur aus fünf Dateien - schön unübersichtlich.

Die jetzige Aufteilung und das komplette Build mit SDK auf das meine 
Entwicklungen aufbauen stammt von Andreas Fellnhofer, der das Ganze 
freundlicherweise ausgetüftelt und zur Verfügung gestellt hat.

Zur Abschreckung und als Museumsstück kann man das ja mit reinstellen. 
Der FFT-Ordner kann weg, sind nur Test und Beispielsourcen aus meinem 
damaligen Projekt.

Hayo

Hayo W. schrieb:
> Hi, die Origanalsource hab ich natürlich noch rumliegen, besteht aber
> nur aus fünf Dateien - schön unübersichtlich.

Hehe, die habe ich auch. Ich denke, über den Namen des Autors sollten 
wir angesichts der unbekannten Umstände den Mantel des Schweigens 
lassen.

Ich habe das mit dem SVN move auch mal probiert.

Wenn Du jetzt, statt ein ZIP-File zu bauen, "svn commit" eintippst, hat 
unser  CRO (Chief Repository Officer) auch weniger Arbeit ;-)

Schönen Abend,
Falk
P.S.: "Real Hackers don't do backups. They upload their sources and let 
the others do backups." Frei nach Linus Torwalds

EDIT: Hoffentlich hat's noch keiner gesehen...
EDIT2: Wie machst Du die RAM-Version? Könntest Du das ins Makefile 
einbauen?

Stefan E. schrieb:
> Nach dem wir die einzigen momentan sind, nutze ich gleich mal die
> Chance...

Mhhh.... Wo sind meine Änderungen PC-comms.cpp aus r150 hin?

Falk

Hi Jungs, noch ein Vorschlag zur Aufteilung der Sourcen: Ich würde das 
gesamte Signalprocessing in eine eigene Klasse auslagern - als da wären:

Die Hauptsignalprozessorroutine, die Mathfunktionen, FFT, Interpolation, 
Filterroutinen und USTB-Routinen.

Dann wird die Display-Klasse etwas schlanker.

Hayo

Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich 
habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn 
updte" gefehlt.
Sorry...

Stefan E. schrieb:
> Wollte die Dateien gerade nachtragen. Warst ne Minute schneller. Ich
> habe irgendwie den falschen Status kopiert. Vielleicht hat ein "svn
> updte" gefehlt.
> Sorry...

Passiert.... Mit

1

svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/oss/ -r 151

 hatte ich sie wieder und nach nochmaligem commit sind sie jetzt wieder 
da. EDIT: Im Trunk, wo die hingehören.

Zum editieren meines Beitrages war es schon zu spät.

Manchmal wäre IRC nicht schlecht ;-)

Falk

branadic schrieb:
> Hallo Zusammen,
...
> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,
> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht
> noch Potential für Geschwindigkeitsoptimierungen?

Im Grunde ist das doch reinrassiges C zuzüglich Klassen.

Ob es einen Vorteil brächte, alles auf C-Syntax umzuschreiben, 
bezweifele ich. Die zeitkritischen Sachen sind sowieso schon ziemlich 
optimiert.

Mir würde es eher helfen, wenn ich einen Überblick hätte, welche 
Variablentypen und Operationen wieviel Zeit kosten.

Falk

branadic schrieb:
> ich hatte gerade wieder ein Gespräch mit Crazor, um das neue FPGA-Design
> weiter voran zu treiben. Dabei haben wir uns auch kurz über den
> aktuellen Code von euch unterhalten.
> Daniel hatte da kurz erwähnt, dass es vielleicht hilfreich sein könnte,
> den Code komplett auf C anstatt C++ umzustellen. Besteht hier vielleicht
> noch Potential für Geschwindigkeitsoptimierungen?

Vielleicht nicht der Riesenbringer in Sachen Geschwindigkeit, aber da 
der Code ohnehin offenbar 95% C ist, könnte man sich zumindest die 
Laufzeitbibliothek von C++ schenken, was sicher einigen Gewinn in Sachen 
Codegröße bringen könnte. Eventuell werden Funktionen wie printf() oder 
so auch schneller, wenn kein C++-Quatsch mehr unterstützt werden muss...

Guido schrieb:
> @ Hayo: damit das hier nicht untergeht:
>
> Schönen Urlaub, ich bin sehr, sehr neidisch!
> Und das Notebook ist doch sicher dabei?

Also Urlaub geht erst in 2 Wochen los - dann aber für 3 Wochen in die 
Toskana. Notebook ist natürlich dabei, kann ich locker damit 
rechtfertigen dass wir die Urlaubsbilder Abends ansehen können ;-). 
Vielleicht finde ich ja den einen oder anderen WLAN-Spot, dann melde ich 
mich mal und schau mal was so abgeht...

@Wolle
> ..und nicht vergessen, das Oszi mit in die Tasche zu schmuggeln .....

Das wird schon schwieriger, ist mir aber auch schon durch den Kopf 
gegangen...


@rowue

> Kommst Du aus HH?
Jupp!

> Dann könnten wir ggf. auch mal eine direkte Einführung in
> Subversion/Trac machen ;)

Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu 
Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die 
wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot 
zurück.

Hayo

@Falk

In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab 
ich heute morgen auf dem Weg zur Arbeit mal angelesen. Ich werde das mal 
ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär 
ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen 
(auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten 
Alter legt man halt Wert auf Komfort ;-)...

Hayo

Hayo W. schrieb:
> @Falk
>
> In der aktuellen c't ist eine Einsteigeranleitung für Qt drin, die hab
> ich heute morgen auf dem Weg zur Arbeit mal angelesen.
> Ich werde das mal
> ausprobieren, dann kann ich da PC-seitig auch mit behilflich sein. Wär
> ja ganz nett wenn wir irgendwann vom Kommandozeilengewerkel wegkämen
> (auch wenn es bislang schon echt hilfreich ist). Ab einem bestimmten
> Alter legt man halt Wert auf Komfort ;-)...

Naja, ich finde bspw. svn auf der Kommandozeile sehr komfortabel.

Aber ich finde die Möglichkeit angenehm, alle Funktionen des DSOs am PC 
steuern zu können.

Und mit Qt kann man das auch für Windows kompilieren.

Eine Frage: Wie veranlasse ich das Scope dazu, eine neue Zeitbasis auch 
anzuzeigen? Ändern tue ich die mit

1

Display_Timebase = Selected_Timebase=(int)rxbuffer[1];

2

TimebaseChanged = 1;

Die Timebase ändert sich auch, aber die Statusanzeige nicht.

Sobald dieser erste Punkt funktioniert, werde ich einen commit im trunk 
machen.

Gruß,
Falk

Hi Falk,

setzen der Timebaseeinstellung geht so:

timebase_reg = tb_value[Selected_Timebase];
Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;

if (Selected_Timebase > 7)
{ adc_change12_reg |= 0x01000000; }
else
{ adc_change12_reg &= 0xFEFFFFFF; }

ändern der Anzeige geht so:

Display::StatusUpdate();


Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon 
wieder? Oder teilst Du noch auf? Eine Info über den Stand der Dinge wäre 
ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit 
angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst 
überlassen?

Hayo

Hayo W. schrieb:
> Hi Falk,
>
> setzen der Timebaseeinstellung geht so:
>
> timebase_reg = tb_value[Selected_Timebase];
> Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;
>
> if (Selected_Timebase > 7)
> { adc_change12_reg |= 0x01000000; }
> else
> { adc_change12_reg &= 0xFEFFFFFF; }
>
> ändern der Anzeige geht so:
>
> Display::StatusUpdate();

Ok, werde ich mir mal ansehen.

> Wie sieht es denn jetzt mit der Aufteilung aus? Entwickelst Du schon
> wieder? Oder teilst Du noch auf?

Ich hatte zunächst den Teil für die PC-Kommunikation in eine neue 
Klasse/Datei verlagert.

Daran bastele ich auch gerade. (Und am GUI)

> Eine Info über den Stand der Dinge wäre
> ganz hilfreich. Desweiteren, macht dann jemand ein neues Build mit
> angepasstem Makefile und den neuen Sourcen, oder bleibt das jedem selbst
> überlassen?

Ich werde meine Änderungen committen, sobald die Änderung der Timebase 
funktioniert, damit auch andere Qt-Spezialisten einen Ansatz haben.

Dann werde ich weiter aufteilen. Dazu werde ich mit Sicherheit einige 
Fragen haben. Bevor ich damit anfange, gebe ich Laut.

Falk

Ok, hattest Du meinen Vorschlag von gestern zur Auslagerung des 
Signalprocessing zur Kenntnis genommen?

Hayo

Hayo W. schrieb:
> Ok, hattest Du meinen Vorschlag von gestern zur Auslagerung des
> Signalprocessing zur Kenntnis genommen?

Ja, damit könnte ich anfangen.

Falk

Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei 
Steuervariablen für die Timebase

- Selected_Timebase ist die führende Variable und läuft nicht linear 
hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle 
entnehmen.

- Display_Timebase dient nur als Index bei Arrayzugriffen und Ähnlichem, 
läuft aber linear hoch.

Wozu diese inhomogenität gut ist? Keine Ahnung! Da sollte man lieber 
nicht allzulange drüber nachgrübeln. Das wollte ich beizeiten auch mal 
vernünftig implementieren, ist allerdings recht aufwändig, da die 
Variablen in diversen Berechnungen mit drinstecken.

Hayo

Hayo W. schrieb:
> Übrigens, ich weiß nicht ob Du das bemerkt hast, es gibt zwei
> Steuervariablen für die Timebase
>
> - Selected_Timebase ist die führende Variable und läuft nicht linear
> hoch, sondern macht Sprünge! Die Werte kann man meiner Timebasetabelle
> entnehmen.

Danke für den Tip...

Jetzt tritt mir die langsame Verarbeitungsgeschwindigkeit des Teils auf 
die Füße: Mal eben sechs Bytes mit 115200 Baud zu schicken, geht einfach 
nicht. Dazu müßte diese Verarbeitung in der ISR stecken, und die wollte 
ich nicht anfassen.
Ich werde aber wohl nicht drumherumkommen.
Jetzt probiere ich erstmal mit einem ACK, das das Scope nach jedem 
empfangenen Zeichen nach Erkennung eines GUI-Kommandos sendet.

Jetzt weiß ich auch wieder, warum ich das GUI damals hingeschissen hatte 
;-)

Keine Atempause, es geht voran,
Falk

Wolle schrieb:
>> GUI damals hingeschissen hatte
>
>
> Wie sagte schon mein Opa:
>
> Was ist das wichtigste beim schweißen?? - das W!!!!

Naja, das war ein echter Freud'scher Verbrecher. Erst habe ich es 
hingesch^Wzusammengestoppelt, dann hingeschmissen.

@Hayo:
Ich werde das doch über die ISR machen. Da wird ein kleiner 
Kommandopuffer gefüllt und ein Flag gesetzt, wenn der richtig gefüllt 
ist.

Die übrigen Funktionen wird das nicht beeinflussen.

Jetzt fange ich mal an, aufzuräumen. Alles im Trunk, mit Deinem 
Vorschlag werde ich anfangen.

Falk

Ach ja, noch ein kleiner Nachschlag zum Setzen der Timebase, ich hatte 
da noch was vergessen:

Setzen der Variablen:

  timebase_reg = tb_value[Selected_Timebase];
      Display_Timebase = Selected_Timebase + SIGNALFaktor_idx;

  if (Selected_Timebase > 7)
  { adc_change12_reg |= 0x01000000; }
  else
  { adc_change12_reg &= 0xFEFFFFFF; }

Neuberechnung der abhängigen Variablen:

    Recalc_Vars();
  config_changed = 1;

Setzen der Hardwareregister:

    SetupADC();

Danach ist dann die neue Timebase angeschaltet. Du solltest aber 
berücksichtigen das je nach aktuellen Einstellungen noch weitere 
Konfigurationen nötig sind.

Zum Beispiel die automatische Aktivierung des USTB-Modus, bei 
FFT-Betrieb, bei aktivierten Cursor.

Das findest Du alles im Timebasehandler ON_Timebase()

Am besten einfach nach der Umstellung den Timebasehandler aufrufen, dann 
must Du das nicht neu programmieren.

Hayo

So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse 
angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.

Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in 
denen das nicht passt, ist es aber kein Problem, die entsprechende 
Funktion in die passendere Datei zu schieben.

Das Verzeichnis sieht jetzt so aus:

1

      7 src/display_t.cpp

2

     45 src/floatprintf.cpp

3

     65 src/CALCPRETRIGGER.cpp

4

     66 src/TomCat.cpp

5

    123 src/USTB.cpp

6

    172 src/RenderText.cpp

7

    297 src/PC-comms.cpp

8

    347 src/floatstr_t.cpp

9

    364 src/zmodem.cpp

10

    505 src/Display-misc.cpp

11

    587 src/TestAndDemo.cpp

12

    788 src/FFT.cpp

13

    797 src/Calculations.cpp

14

   1078 src/DrawSignals.cpp

15

   1381 src/BasicDrawing.cpp

16

   2715 src/flash_t.cpp

17

   2813 src/Measure.cpp

18

   3402 src/DrawMenusFunctions.cpp

19

   3403 src/Drawing.cpp

20

   4865 src/tc_vars.cpp

21

  15801 src/display_t_bak.cpp

22

  15927 src/display_t_bitop.cpp

23

  24157 src/hardware_t.cpp

Gruß,
Falk

Falk Willberg schrieb:
> So, ich habe display_t.cpp mal aufgeteilt. Ich habe keine neue Klasse
> angelegt, nur .cpp-Dateien und das Makefile entsprechend angepasst.
>
> Ich habe versucht, das möglichst sinnvoll aufzuteilen. In den Fällen, in
> denen das nicht passt, ist es aber kein Problem, die entsprechende
> Funktion in die passendere Datei zu schieben.

Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind, 
aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage 
gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur 
gehören.


> Das Verzeichnis sieht jetzt so aus:

1

2

>      src/display_t.cpp

3

>      src/floatprintf.cpp

4

War nur eine Datei für die verröffentlichung einer Erweiterung

5

-> kann weg

6

7

>      src/CALCPRETRIGGER.cpp

8

War nur eine Veröffentlichung einer frühen Fehlerkorrektur. Die aktuelle Version ist in display.cpp und auf einem neueren Stand

9

-> kann weg

10

11

>      src/TomCat.cpp

12

>     src/USTB.cpp

13

>     src/RenderText.cpp

14

War nur eine Veröffentlichung einer frühen Fehlerkorrektur. Die aktuelle Version ist in floatstr_t.cpp und auf einem neueren Stand

15

-> kann weg

16

17

>     src/PC-comms.cpp

18

>     src/floatstr_t.cpp

19

>     src/zmodem.cpp

20

>     src/Display-misc.cpp

21

>     src/TestAndDemo.cpp

22

>     src/FFT.cpp

23

>     src/Calculations.cpp

24

>    src/DrawSignals.cpp

25

>    src/BasicDrawing.cpp

26

>    src/flash_t.cpp

27

>    src/Measure.cpp

28

>    src/DrawMenusFunctions.cpp

29

>    src/Drawing.cpp

30

>    src/tc_vars.cpp

31

>   src/display_t_bak.cpp

32

Ist nur ein altes Backup -> kann weg

33

34

>   src/display_t_bitop.cpp

35

Ist nur ein altes Backup -> kann weg

36

37

>   src/hardware_t.cpp

38

>

>
> Gruß,
> Falk

Hayo

Hayo W. schrieb:
> Falk Willberg schrieb:

> Ich weiß ja nicht so genau auf welcher Basis die Sachen entstanden sind,
> aber das sieht mir so aus als wäre da eines meiner Builds die Vorlage
> gewesen. Da waren aber einige Sachen drin die nicht hier in die Struktur
> gehören.

>> Das Verzeichnis sieht jetzt so aus:
>> src/floatprintf.cpp
>> src/CALCPRETRIGGER.cpp
>> src/RenderText.cpp
>> src/display_t_bak.cpp
>> src/display_t_bitop.cpp

Sind weg.

Dann werde ich man die UART-Sachen aus der hardware_t.cpp auslagern.

Falk

Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt 
werden würde. Ich schffe es gerade leider nicht den von google groups zu 
laden...
Es wäre dann möglich die ganze Buildumgebung aus dem Projektarchiv zu 
beziehen.

Gruß
Sebastian

Sebastian B. schrieb:
> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt
> werden würde. Ich schffe es gerade leider nicht den von google groups zu
> laden...

Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch 
einige sinnvolle Daten von GGroups zu "retten"...

Nimmst Du den!

Ist der aktuellste Build vor der Aufteilung. Wenn Du das SDK installiert 
hast reicht ein "make all" und alles geht von selbst.

Kann meinetwegen auch ins SFN Repository falls das Sinn macht.

Hayo

Danke! Ich binn der Meinung, dass die Build-Umgebung genauso in die 
Versionsverwaltung gehört, um auf einen definierten Stand umschalten zu 
können. der Compiler könnte ja auch im laufe der Zeit geändert werden.
Sebastian

Die eigentliche Entwicklungsumgebung gibt es in unterschiedlichen 
Varianten für die einzelnen Distributionen. Ich hab hier die 
Suse-Version, ist aber etwas zu groß um es hier reinzustellen (10 MB). 
Must also auf Google warten,  da hab ich das auch alles reingestellt.

Hayo

@Sebastian

Sehe ich auch so. Es muß für Neueinsteiger möglichst leicht sein sich 
das einzurichten und die ersten Schritte zu machen. So kriegen wir eine 
größere Menge an Mitentwicklern und Interessierten.

Hayo

Daniel H. schrieb:
> Sebastian B. schrieb:
>> Ich würde es begrüßen, wenn auch der Nios-Compiler im SVN abgelegt
>> werden würde. Ich schffe es gerade leider nicht den von google groups zu
>> laden...
>
> Sowas gehört in die Download-Sektion. Überhaupt sind glaube ich noch
> einige sinnvolle Daten von GGroups zu "retten"...

Ich habe vorerst nicht vor, die Gruppe zu löschen. Nur als weitere 
Diskussionsplattform war sie überzählig.

Falk

Hayo W. schrieb:
> Guido schrieb:
>> @ Hayo: damit das hier nicht untergeht:
>>
>> [...]
>
> @rowue
>
>> Kommst Du aus HH?
> Jupp!
Jarrestadt/Kampnagel ;)
>
>> Dann könnten wir ggf. auch mal eine direkte Einführung in
>> Subversion/Trac machen ;)
>
> Nettes Angebot. Ich wollte mir das jetzt mal in der Zwischenzeit zu
> Gemüte führen. Ich hab gesehen, dass es auch eine KDE-Version gibt, die
> wollte ich mal ausprobieren. Ansonsten komme ich gerne auf das Angebot
> zurück.

Ack - ich persönliche bevorzuge RapidSVN/svnX (OS X), aber da hat jeder 
seine Präferenz (http://subversion.tigris.org/links.html#clients hat 
eine
nette Übersicht)

Wenn Du möchtest, setzte ich Dir 'nen Repository auf meiner Kiste auf. 
Mit dem kannst Du dann "rumspielen" ohne auf SourceForge "Rücksicht 
nehmen" zu müssen ;)

>
> Hayo

Grüße,

   schönen Urlaub,

         rowue

Ich habe gerade eine Firmware und die erste Version des GUI committed, 
mit der zumindest die Timebase verändert werden kann.

Freue mich über jede Kritik.

Damit sind meine größeren Änderungen vorläufig abgschlossen.

Jetzt werde ich ein wenig am GUI und an PCComms.cpp schrauben.

Falk