@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
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
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.
Jürgen
@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
Hallo Niklas O.,
nach kurzem Test: Funktioniert so recht gut! Sogar der -i - Switch ist
schon da!( Spart viel Tinte :-)
Vielleicht noch das Abräumen der einzelnen Plane-Dateien nach dem
Zusammensetzen der Screenshot-xxx-Datei?
Danke!
Gruß Jürgen
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
Habe die letzten Screenshots mal getestet.
Leider finde ich bei keinem das File, das er wohl schreiben sollte ?
Die älteren Versionen haben das in das gleiche Verzeichnis geschrieben,
in dem das Programm gestartet wurde.
Bei der letzte Version verschwindet das Programm beim auslesen ganz ?!
FFT:
Habe mit dem mal gespielt..
Schaut gut aus aber..
Nach FFT und dann Osci ausschalten (ein paar Stunden), hatte ich nach
dem Wiedereinschalten das FFT im LCD und der ganze FFT-Bereich war
gelb..
Wollte das dann mal nachstellen, ging bis jetzt aber nicht mehr...
Ab und zu beim zurück vom FFT durch "Math" sind die Kanäle
durcheinander...
Wenn ich im FFT das Osci aus schalte und wieder ein, sehe ich das FFT
Display aber die "Math" Taste leuchtet nicht aber die Lampe unter der
Frequenzanzeige (zum Drehen)leuchtet.
Auch die Soft-Tasten sind nicht im FFT-Modus.
Versuche dann rauszukommen mit "Math"-Taste--> Softtasten werden zu FFT.
Dann wieder "Math"-Taste und komme dann aus dem FFT.
Leider sind jetzt alle Kanäle in der Mitte!
Mit "Default Setup" geht dann wieder alles.
l.G. Roberto
Hallo Hayo
0.84 funktioniert bei mir
Von "Quick Print" (Taste) bis zum Menue vergehen leider so ca. 3
Sekunden.
Der Screenshot funktioniert jetzt in ein File :-)
Das aussteigen aus dem FFT funktioniert auch.
Nach dem Aus/Ein schalten vom DSO ist FFT auch weg :-)
Das FFT ist aber die 1er Version (2er ist schöner :-)
Könnte man die Umschaltung der FFT-Versionen im Soft-Menue machen ?
mmhh.. irgendwas spinnt da noch...
Einmal hatte ich wieder den ganzen FFT-Bereich in gelb und einmal nach
FFT wieder die Kanäle durcheinander ?!
Gehe immer in FFT, DSO aus/ein schalten und dann wieder in FFT.
Jetzt hat er sogar die Version 2 vom FFT eingeschalten ?!
(Length auf 1024)
l.G. Roberto
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
Oh Gott man - geh doch auch mal in den Biergarten (mit Frauchen)...bei
dem Wetter!!
elgodil
PS: Der Tipp dient natürlich nur dazu, deinen Programmierelan über
möglichst lange Zeit zu erhalten ;-)
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
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
Kann's ja gar nicht erwarten das morgen früh einzuspielen :)
Wenn ich das vorhin im Hardware-Thread, beim kurzen Überfliegen, richtig
mitbekommen habe, nimmst Du jetzt 5 Samples im einen Wert zu mitteln.
Evtl. wäre es für die Performance hilfreich, einen Wert fallen zu lassen
und mit 4 Werten zu arbeiten; je nachdem wie der Compiler optimiert...
@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.
Hallo Hayo,
die neuen Änderungen, mein letztes aufgespieltes Release war die 0.75,
schauen wirklich sehr interessant aus. Dies bezieht sich auch auf die
Screendump-Funktion. Wirklich gute Arbeit!
"Wie mit dem Lineal gezogen!" kann ich so zwar nicht abkaufen, aber die
Verbesserung ist deutlich zu sehen.
Mal eine Frage anderer Natur. Es wurde ja mal irgendwo schon
angesprochen. Die Welec-Timebasetabelle ist ja etwas merkwürdig mit
ihrem Sprung von 250MS/s auf 25MS/s. Erwarten würde man ja noch die
Zwischenschritte 100MS/s und 50MS/s. Habt ihr dahingehend irgendwie
Zugriff drauf, um eine Änderung zu erzielen?
Falls ja, so würde ich dies ziemlich weit oben in der Prioritätenliste
sehen.
Beste Grüße, branadic
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, und etwas Entwanzung (ich küümmere
mich in den nächsten Tagen um die Pixelfehler, kann ja nichts
Großes sein), dann wird aber die 1.00 fällig :-).
Gruß, Guido
@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
Wäre jemand so freundlich bei Gelegenheit einen Screenshot mit/ohne
Mittelwertbildung im Vergleich einzustellen. Ich würde diese
Verbesserung auch gerne sehen.
@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
@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
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!
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
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
Andere scheinen das auch (standardmäßig) zu machen - bei meinem OWON
sahen die Kurven bis jetzt deshalb auch besser aus (und ich glaube
nicht, das der eine besonders edle Eingangsstufe hat ;-))
LG,
egberto
@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
Hier mal 3 Bilder mit den verschiedenen Einstelleungen.
Kanal 4 =10mV, Kanal 3 =20mV, Kanal 2 =50mV, Kanal 1 = 1kHz Signal
erstes Bild = Normal, zweites mit Averaging, drittes mit Denoising.
Die 1er und 2er Bereiche sind furchtbar, aber durch die neues Funktion
jetzt schon besser :-)
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 ?
FFT:
Funktioniert soweit :-)
Probiert mal:
Default Setup, 1kHz Signal an Kanal1, 500mv und 500us (alle 4 Kanäle
EIN)
dann auf Math,FFT,Settings,Length auf 1024, 3 Sekunden warten, Gerät
AUS/EIN
Dann sehe ich nur mehr Kanal 1 in der Mitte!
Und wieder ein Kompliment und Dankeschön an alle Entwickler :-) :-)
l.G. Roberto
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
Hallo zusammen,
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
wobei die Anzahl der aufgezeichneten Samples explizit angezeigt wird.
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
Als Data Destination stehen zur Auswahl:
- Spreadsheet CSV
- Spreadsheet TXT
- Mathcad
- Matlab
Die Mathcad und Matlab Daten werden in einer .dat-Datei abgespeichert.
In den ersten 5 oder 6 Zeilen stehen die aktuellen Oszi-Einstellungen,
danach folgen mit Tabulator getrennt x-Werte [s] und y-Werte [V].
Ein Export der Daten mit Tabulatortrennung und in einer x-y-Auflistung
wäre sicherlich auch in unserem Falle hilfreich. Als x-Wert wird der
Triggerzeitpunkt zu NULL gesetzt, x-Werte vor dem Triggerereignis
entsprechen dann negativen Zeitpunkten und x-Werte nach dem
Triggerereignis entsprechend positiven.
Einen ähnlichen Datenexport gab es ja seinerzeit schon in der originalen
FW. Hier wurden alle Werte der aktiven Kanäle folgendermaßen exportiert
Zeitpunkt - Samplewert CH1 - Spannungswert CH1 - Samplewert CH2...
Der Vorteil wäre, dass sich ein Ereignis zeitlich besser eingrenzen
ließe.
Bezüglich des Aquisition Modes. Am Tek stehen hier ebenfalls
verschiedene Einstellung zur Verfügung:
- Samples (schätzungsweise entspricht das der übereinander gezeichneten
Darstellung von Samples, wie weiter oben schon erbeten, denn das
vermeintliche Rauschen ist hier extrem hoch)
- Peak Detect
- High Resolution
- Average
- Envelope
Als weitere Anregung möchte ich noch die Window-Types der FFT aufzählen:
- Rectangular
- Hamming
- Hanning
- Black-Harris
- Gaussian
- FlatTop2
- KaiserBessel
Ich bin natürlich gern bereit euch mit weiteren Info's vom Tek zu
versorgen, sofern dies gewünscht oder erfragt wird. Schaden kann es
meiner Meinung nach nicht zu schauen, was andere Geräte können. Ob sich
sowas dann auch im Welec realisieren lässt sein mal dahingestellt.
Nächste Woche bekomme ich übrigens eine Vorführung bei uns im Hause.
Dann werden mir ein Tek der 4000er-Serie und ein vergleichbares Agilent
vorgestellt. Nach Aussagen des Außendienstmitarbeiters heute arbeitet
Agilent mit einer Aquisition von 100000, Tek dagegen nur mit der Hälfte.
Hameg ist mittlerweile wohl von einem namenhaften Hersteller aufgekauft
worden.
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.
Soweit erst einmal von hier.
Beste Grüße, branadic
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
Hab's nicht verstanden... was genau spricht gegen die momentan
schnellere serielle Schnittstelle (?) evtl. der erforderliche
usb-to-serial dongle für 3-4 Euro ?
Meiner Meinung nach gibt es noch so viele Baustellen, bei denen es keine
funktionierende Alternative gibt.
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 Niklas,
ich habe mal die vier Datenexportformate im Anhang. Signal ist das
1kHz-Probesignal vom Oszi selbst. Exportiert habe ich in CSV, TXT,
Mathcad und Matlab. Bei dem Mathcad-Export wird zusätzlich noch eine
x_hdr.dat erzeugt, beim Matlab-Export ist es direkt eine x.hdr
> - 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.
Ich denke das ein Export der Werte zwischen den Cursorn bspw. sehr
sinnvoll sein kann. Reduziert schließlich die Anzahl der zu
exportierenden Daten.
Auch die erste Möglichkeit ist so abwägig nicht. Angenommen man hat
500.000 Samples, dann besteht die Möglichkeit bspw. Sample 12.000 -
120.000 zu exportieren. Auch diese Möglichkeit reduziert die Anzahl der
zu übertragenden Daten.
Bei der Zoom Area liegen wir beide richtig, das entspricht den im
Delayed-Fenster dargestellten Daten. Auch dies hat eine Datenreduktion
zur Folge.
Save All bezieht sich lediglich auf den gewählten Kanal und bedeutet,
dass die gesamten Samples, also die volle Fensterbreite an Daten,
übertragen wird. Diese Einstellung bezieht sich allerdings beim Tek
ebenfalls wieder nur auf einen gewählten Kanal, nicht auf alle.
Als Grafikformate stehen übrigens
24-bit Bitmap (*.bmp)
JPEG (*.jpg)
PCX (*.pcx)
Portable Network Graphic (*.png)
Tagged Image File Format (*.tif)
zur Verfügung.
Was es mit dem Ref 1 - 4 auf sich hat muss ich mal noch in Erfahrung
bringen, hab ich bisher selbst noch nicht genutzt. Könnte aber ein
früher abgespeichertes und zum Vergleich mit einem Signal herangezogenes
Signal sein. Könnte bei uns dem Recall-Signal entsprechen. Das ist aber
Spekulation meinerseits.
Beste Grüße, branadic
So, es hat mir gerade keine Ruhe gelassen und ich hab am Oszi mal etwas
näher nachgeschaut.
Es ist so wie schon von mir spekuliert wurde. Man kann Signale
aufzeichnen und abspeichern, um sie anschließend als Referenzsignal
wieder hereinzuladen. Das Oszi kann dabei bis zu vier gespeicherte
Referenzsignale gleichzeitig mit vier Messsignalen und vier
mathematischen Signalen verarbeiten. Schon heiß, sag ich mal ;)
Das heißt auch, dass das Referenzsignal unserem Recall-Signal
entspricht. Also alles genau so wie vermutet korrekt.
Beste Grüße, branadic
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
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
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?
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
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
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
Just btw:
Das trac welches auf dem Sourcefrosch angeboten wird, lässt sich auch
sehr gut zum Projektmanagement (Bugs, Features, etc) nutzen und spielt
auch sehr nett mit svn (subversion). Ein Beispiel ist (neben anderen):
http://trac.macports.org
@Hayo: Kommst Du aus HH? Dann könnten wir ggf. auch mal eine direkte
Einführung in Subversion/Trac machen ;)
Grüße,
Danke für die tolle Arbeit!
rowue
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
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
Hallo Zusammen,
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?
Beste Grüße, branadic
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
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
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:
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:
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
Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter
Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf
rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.
Weis jemand wo ich hochladen könnte ohne Registrierung?
Gruß, Ben
xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta).
Welche Variante von Hayos 0.86 ist das? Aus dem SVN oder eine ältere?
> Auf> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.>> Weis jemand wo ich hochladen könnte ohne Registrierung?
Ich weiß nicht, ob ich ausführbare Programm da herunterladen würde, wo
das ohne jede Registrierung hochzuladen geht...
Falk
xCometz schrieb:
> Für alle die noch kein Nios compiler haben, hab ich den Compiler (unter> Windows) als portable gepackt (cygwin + nios-gnupro + Hayo .86beta). Auf> rar file 25MB. Er kann auch direkt in einer USB-Stick laufen.>> Weis jemand wo ich hochladen könnte ohne Registrierung?>> Gruß, Ben
Das ist nicht übel, wäre was für meinen Urlaubsrechner! Wo Du allerdings
25MB so einfach hochladen kannst weiß ich auch nicht. Eine Registrierung
braucht man eigentlich immer. Notfalls könnte ich meinen Server
anwerfen, da könntest Du das dann draufspielen und ich reiche das dann
weiter.
Hayo
xCometz schrieb:
> Ja richtig, ich hab 2 mal hochgeladen falls ein error hätte.> Hat funktioniert?>> Ben
Hi Ben,
hat hervorragend funktioniert. Prima Beschreibung. Auspacken, zweimal
klicken, fertig. Echt super!
Man muß nur drauf achten das nicht in ein Verzeichnis mit Sonderzeichen
im Namen zu kopieren.
Danke
Hayo
Rolf Würdemann schrieb:
> Hi Falk, (@all)>> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)
Kein problem: make; gzip TomCat.flash; svn add TomCat.flash
"svn: This client is too old to work with working copy '.'; please get a
newer Subversion client"
Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen
Version des Versionshandlingtools? Was eine %$&%@€&§$ !!
Während ich also die Sourcen hole und mir ein neues svn baue, verschicke
ich's mal im Anhang.
> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.
Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm
Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist
SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.
Gruß,
Falk
P.S.: Du kannst nicht zufällig QT ;-)
P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir
das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal
schicken.
die Makefile mit ram support steht weiter oben in diesem Thread
Autor: Günter Jung (gjung)
Datum: 16.05.2009 00:28
Dateianhang: Makefile.zip (3,9 KB, 52 Downloads)
eventuell geht auch:
http://www.mikrocontroller.net/attachment/50963/Makefile.zip
hat jetzt das angepasste Makefile, TomCat.flash.gz und TomCat.ram.gz.
Falk
P.S.: Falls es jemanden interessiert: Subversion lies sich nicht
übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime)
haben wollte.
Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi
Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht,
ein commit zu machen.
Falk Willberg schrieb:
> P.S.: Falls es jemanden interessiert: Subversion lies sich nicht> übersetzen, weil es irgendeine Indianer-Lib (Apache Portable Runtime)> haben wollte.> Ein Tritt in den Allerwertesten (rm -rf FW1.2.BF.087beta; svn co ...; vi> Makefile; make; svn add ....; svn commit) hat subversion dazu gebracht,> ein commit zu machen.
Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin
oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem
System. Ich würde mal eventuelle grafische Clients durchchecken, ob die
nicht in der Lage sind, den Standard-Client deines Systems zu verwenden
anstatt ihrer eigenen Executables.
Daniel H. schrieb:
...
"svn: This client is too old to work with working copy '.'"
> Deine Meldung von oben deutet auf ein Downgrade deines SVN-Clients hin> oder zumindest auf das Vorhandensein mehrerer Versionen auf deinem> System.
Ich habe zwei Systeme. Einen PC im Büro und ein Notebook im Garten.
Subversion-Versionen 1.4 und 1.5. (OpenSuSE 10.3 bzw. 11.0)
> Ich würde mal eventuelle grafische Clients durchchecken...
Ich mag die "Kommandozeile" lieber. Die Klickerei in GUIs ist nicht so
mein Ding.
Ich müßte nur SuSE 10.3 auf 11.0 updaten.
Falk
Hallo Falk,
ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW
aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir
sinnvoll erscheint....
- Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben
wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei
Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die
Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt,
könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei
dargestellt aussehen.
(/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst
werden.)
- Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der
hinter einem Versionsverwaltungssystem steht.
- Die History sowie die netten Orginalkommentare von Wittig Technologies
würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt
auslagern.
Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion
richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich
irgendwo aktiv werden soll, bitte Bescheid sagen.
Beste Grüße,
Odic
PS: Zu deinem Subversion-Problem: ich nehme an, dass du versuchst, ein
und die selbe working-copy mit unterschiedlichen Clients zu bearbeiten.
Da sind leider alle SVN-Clients die ich kenne nicht sonderlich
kompatibel in sich. Einfach auf beiden Systemen getrennt auschecken,
dann funktioniert es auch ohne ein Update.
@Falk: Ok, ich hatte irgendwie im Hinterkopf, dass du auf Windows
unterwegs bist. Da ist das gern mal etwas unübersichtlich mit SVN.
@Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im
A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet
wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und
wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten
Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal
mit einem Haken versehen. Man muss dann auch schon auf Averaging oder
Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu
kommen.
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>>> Hi Falk, (@all)>>>> es wäre nett, wenn bei einer Release ein Compilat bei wäre ;)>> Kein problem: make; gzip TomCat.flash; svn add TomCat.flash> "svn: This client is too old to work with working copy '.'; please get a> newer Subversion client"> Watt? Die Version des Versionshandlingtools passt nicht zur aktuellen> Version des Versionshandlingtools? Was eine %$&%@€&§$ !!
Das reicht danach, als ob da einmal mit einer aktuelleren Version
ausgecheckt wurde. Sprich: entweder bearbeitest Du den gleichen
Check-Out von zwei Seiten aus, oder Du hattest einmal ein aktuelleres
Svn auf dem System (kenne ich z.B. von OS X (10.5) und MacPorts, wo
letzteres aktueller ist)
>> Während ich also die Sourcen hole und mir ein neues svn baue, verschicke> ich's mal im Anhang.>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>> Geht hier. Seltsam. Im Moment sitze ich am Notebook mit i586 unter'm> Sonnenschirm, (dafür geht subversion nicht) aber auf dem Büro-PC ist> SuSE 11.0 x86_64 (AMD) installiert und da läuft das NIOS-CDK.
o.k. - dann versuche ich es mal mit "-f" ;)
>> Gruß,> Falk
Grüße,
rowue
> P.S.: Du kannst nicht zufällig QT ;-)
Ne (habe mal etwas unter perl mit gtk gespielt), aber a) kann ich es mir
mal ansehen und b) kenne ich Leute (http://qucs.sourceforge.net/) die
schon länger was mit Qt (3) machen (und die mensch mal fragen kann
wenn es Probleme gibt ;)
> P.P.S.: Die Version für's RAM kann ich nicht kompilieren, da fehlt mir> das Makefile. Wenn Hayo wieder im Lande ist, kann er das ja mal> schicken.
Rolf Würdemann schrieb:
> Falk Willberg schrieb:
...
>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>>>> Geht hier.
...
> o.k. - dann versuche ich es mal mit "-f" ;)
Bei mir ist
1
cdk-nios-binutils-3.1-20040329
2
cdk-nios-libstdc++-3.1-20040329
3
cdk-nios-gcc-c++-3.1-20040329
4
cdk-nios-base-0.3-20031111
5
cdk-nios-libgloss-3.1-20040329
6
cdk-nios-newlib-3.1-20040329
7
cdk-nios-gcc-3.1-20040329
8
cdk-nios-related-tools-3.1-20040329
installiert. OpenSuSE 11.0 x86_64. Die NIOS-binaries sind aber für
32-Bit kompiliert.
Falk
Falk Willberg schrieb:
> Rolf Würdemann schrieb:>> Falk Willberg schrieb:>> ...>>>>> das Nios-CDK mag z.B. amd64 (Linux, 64Bit) nicht.>>>>>> Geht hier.> ...>> o.k. - dann versuche ich es mal mit "-f" ;)>> Bei mir ist[c]cdk-nios-binutils-3.1-20040329> [...]
Das Problem lag zwischen den Ohren - ich hätte einfach
dpkg --force-architecture -i PACKET
aufrufen müssen - so hat er (natürlich) rumgenörgelt, dass
die Packete nicht zu meinem System (Debian Lenny) passen.
Installiert, compiliert sauber durch ;)
Evtl. 'nen kleinen Kommentar in's Readme für die Debian
Packete (dann stolpert kein anderer drüber ;)
Btw: Könntest Du die Änderung des Makefiles (für das
RAM Image) noch in den Trunk übernehmen? Dann braucht
beim nächsten Release keiner dran zu denken ;)
>> Falk
rowue
Rolf Würdemann schrieb:
> Falk Willberg schrieb:> Evtl. 'nen kleinen Kommentar in's Readme für die Debian> Packete (dann stolpert kein anderer drüber ;)
Nur zu ;-)
> Btw: Könntest Du die Änderung des Makefiles (für das> RAM Image) noch in den Trunk übernehmen? Dann braucht> beim nächsten Release keiner dran zu denken ;)
Erledigt. Dabei habe ich auch die angezeigt Version auf 0.87 gesetzt.
Dabei fällt mir ein, daß der Trunk ja mal eine 0.88 wird.
Falk
Odic X. schrieb:
> Hallo Falk,>> ich habe mal ein paar Ideen zu den Sourcen der aktuellen FW> aufgeschrieben. Sieh es einfach als Anregungen und übernimm, was dir> sinnvoll erscheint....
Danke für die Anregungen. Vorläufig beschäftige ich mich mit der
PC-Kommunikation, wenn Zeit ist.
> - Ich nehme an, das die Aufteilung der Sourcen noch weiter betrieben> wird. Der Übersichtlichkeit halber würde ich *.cpp und *.h auf zwei> Verzeichnisse aufteilen. /inc und /src bieten sich an. Wenn man für die> Dateinamen der Scope-FW noch einen Prefix (z.B. ala 'TC_') einführt,> könnte eine übersichtliche Aufteilung z.B. wie in der angehängten Datei> dargestellt aussehen.> (/lib beinhaltet ja keine libraries und könnte daher auch aufgelöst> werden.)> - Die Versionsnummer in 'Screenshot_0.4' widerspricht dem Gedanke, der> hinter einem Versionsverwaltungssystem steht.
Ich weiß. Ich meine aber, daß irgendwo ein Stand gespeichert werden
sollte, bei dem die PC-Clients mit der zugehörigen Firmware
zusammenspielen.
> - Die History sowie die netten Orginalkommentare von Wittig Technologies> würde ich aus 'tc_vars.cpp' rausnehmen und z.B. in eine /changelog.txt> auslagern.
Ok.
> Wenn man das Verschieben bzw. Umbenennen in Verbindung mit Subversion> richtig macht, bleibt auch die Historie der Dateien erhalten. Falls ich> irgendwo aktiv werden soll, bitte Bescheid sagen.
Bescheid ;-) Ich erhebe keinen Anspruch auf ein Monopol auf
Hausmeistertätigkeiten im Repository.
Ich hoffe nur, daß niemand größere Änderungen an veralteten Sourcen aus
irgendwelchen .zip-Files vornimmt.
Falk
Daniel H. schrieb:
> @Hayo: Bei der 0.85 ist mir aufgefallen, dass der Status im> A(c)quire-Menü nicht über einen Neustart des Systems hinweg gerettet> wird. Stellt man also z.B. auf Denoising, schaltet das Gerät aus und> wieder an, dann ist Denoising zwar aktiv (kann man schön an der leichten> Schräglage der Flanken das Comp-Signals sehen), aber im Menü ist Normal> mit einem Haken versehen. Man muss dann auch schon auf Averaging oder> Denoising und dann wieder auf Normal drücken, um wirklich auf Normal zu> kommen.
Passiert auch bei der 0.86. Die lag noch aufm Desktop herum, ganz
vergessen einzuspielen schäm
Odic X. schrieb:
> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??> (SF-Account habe ich)
Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und
Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan
hast überlegen und diese eingeben.
Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf
das Repository brauchst ;)
Ansonsten gäbe es noch die Möglichkeit (wäre aber vorher zu
diskutieren), ob Du mit svn diff einen Diff erstellst und dieses an
ein Ticket im Trac hängst. So wird das z.B. bei MacPorts gemacht, wo
nicht alle Port-Maintainer auf das Repository committen können. (Die,
die es können, machen das dann direkt ;)
Grüße,
rowue
PS: Der Diff kann dann mit "patch" einfach eingefügt und von berufener
Seite committed werden ;)
Rolf Würdemann schrieb:
> Odic X. schrieb:>> Hmmm.... was muss ich anstellen, um aufs Repository commiten zu können??>> (SF-Account habe ich)
Mit dem subversion-Cli (Linux):
In das künftige Arbeitsverzeichnis wechseln,
> Theoretisch: einfach bei Deinem SVN-Client "commit" sagen (svn ci) und> Dir eine möglichst kurze und passende Beschreibung dessen, was Du getan> hast überlegen und diese eingeben.>> Praktisch kann es aber sein, dass Du erstmal die Write-Permissions auf> das Repository brauchst ;)
Hat die nicht jeder?
Ich fand http://svnbook.red-bean.com/nightly/de/index.html hilfreich.
Falk
Checkout ist anonym möglich, aber checkin nur mit SF.net Account und
Freischaltung der Schreibrechte. Wenn einer der Oberbastler grünes Licht
gibt (und ich den SF.net handle von Odic X. erfahre), kann ich das
entsprechend einrichten.
Thread beobachten
Seitenaufteilung abschalten