@Bruno
Also grundsätzlich zur Scalierung ist anzumerken, dass sich die
Performance bei der FFT unter anderem nur bewerkstelligen ließ, in dem
auf Multiplikationen verzichtet wurde und stattdessen Shift-Operationen
eingesetzt wurden. Dadurch sind die verfügbaren Skalierungen erstmal
beschränkt. Man kann das sicher auch noch etwas feiner abstufen, wie bei
der normalen Grafikroutine, aber auch das kostet zusätzlich Zeit. Hier
muß man also abwägen.
Die Beschriftung für das Grid ist erstmal nur im Log-Modus verfügbar da
diese sich ja wegen der Normierung nicht ändert. Wenn ich den Linearen
Modus beschrifte muß ich jedesmal einen Refresh durchführen wenn der
Messbereich wechselt. Ist aber durchaus machbar. Das Gleiche gilt für
die Frequenzanzeige.
Ich habe auch schon überlegt was sich da an eleganten Lösungen so
anbietet.
Die Beschreibung von Lecroy ist sehr interessant, die werde ich mir noch
mal genauer ansehen. Ich lasse da gerne Anregungen von anderen Oszis mit
einfließen.
> 4.) Lecroy korrigiert die fft Darstellung so, daß die> Spektralllinien im Pegel dem Level im Zeitbereich entsprechen> s.h. Dokument, Seite C-5 oben.
Das war ursprünglich bei mir auch so, aber ich fand es besser die volle
Gridhöhe zu nutzen. Spricht was dagegen?
OdB bezieht sich auf die Amplitude des Signals im Zeitbereich bei
Vollaussteuerung. D.h. ein Sinussignal sollte eine Frequenzlinie mit 0
dB Verlust haben, während ein Rechteck sogar mit der Grundschwingung H1
ein wenig im +dB Bereich (Verstärkung) liegen sollte wenn im Zeitbereich
der ADC-Wandler mit den vollen 8 Bit (255) ausgesteuert ist.
Zu 8: Die Aliasfrequenzen entstehen leider nicht erst bei der FFT,
sondern schon direkt bei der Abtastung, so dass man einem Datensatz
nicht ansieht ob die Frequenzen nun echt sind oder nicht. Wenn man die
Auswirkungen kennt, kann ein Mensch das zwar auf dem Bild erkennen, aber
der Rechner kann es nicht herausrechnen - schade, sonst könnte man sich
Bandbegrenzungsfilter sparen.
Gruß Hayo
@Bruno
Ich habe mir die LeCroy-Doku noch mal genauer durchgelesen. Mit der
Skalierung der Amplitude auf die Amplitudenhöhe im Zeitbereich war hier
nicht der Skalierungsmaßstab gemeint, sondern die Korrektur der
Amplitude, wenn diese in einen gedämpften Frequenzbereich fällt. Siehe
hierzu auch meine Anleitung Seite 10 Abb. 7 - Gewichtung im
Frequenzbereich.
Eine solche Korrektur ist natürlich eine feine Sache, das wäre noch was
für die ToDo-Liste, ebenso wie die Anzeige des Leistungsspektrums. Werde
ich mir mal vornehmen...
Gruß Hayo
@Niklas
Der Screenshot funktioniert ja, wie die Anderen ja auch bereits
feststellten, prima; nur ist das Ergebnis auf dem PC doch sehr flau.
Besteht da eine Chance, dass die auf dem Scope dargestellten satte
Farben auf dem PC ein ähnliches Niveau erreichen. Also Gelb ein FFFF00,
Grün ein 00FF00 u.s.w.
Das Blassgrün in Verbindung mit dem Blassblau hat einen doch sehr
niedrigen Kontrast.
Ich möchte nicht quengelig erscheinen; das was Du hier abgeliefert
hast, hilft mir sehr und ist weit mehr, als man eigentlich in so kurzer
Zeit erwarten konnte - vielen Dank noch einmal !
Hallo Hayo,
zu 8.) hast du natürlich recht... war ein Schnellschuß- kann in meinem
Alter schon mal vorkommen ;-)
Wenn das so einfach wäre, würden das renommierte SA Hersteller schon
lange so machen.
Kannst du unter 2.) aufgeführtes Phänomen nachvollziehen?
zu 5.) Soweit kein Problem- wenn man weiß wo der Bezugspunkt, sprich 0dB
liegt.
Gruß, brunowe
Quick-Measure funktioniert prima - viel besser als erwartet.
Mir ist dabei aufgefallen, dass eine Umschaltung des Kanals via Softkey
nichts bewirkt. Erst das Aus- und wieder Einschalten von Quick-Measure
übernimmt den geänderten Kanal.
Wenn man einmal 'Measure Average' gewählt hat, wie kommt man wieder zur
vorhergehenden Einstellung (?) ist das eine Einbahnstraße ?
Ich habe die Datenkompression für Niklas' Quick-Print-Funktionen etwas
überarbeitet.
Die Datenmenge ist deutlich kleiner, die Geschwindigkeit leider nicht so
ganz. Ein SW-Dump dauert jetzt 10s, Farbe dauert 30s.
Bei Interesse stelle ich die Änderungen hier ein. (Oder zieht Ihr einen
anderen Ort vor?)
Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.
Falk
Hallo Kurt,
das macht es schon deutlich einfacher, die Darstellung der einzelnen
Kanäle zu differenzieren. Auch wenn hier noch etwas Abstimmung in bezug
auf die Wahrnehmung der einzelnen Farben (annähernd gleiche Helligkeit)
erforderlich wäre. Ist das gleiche Problem, dass sich beim layouten
darstellt. Grün und Gelb recht dominant gegenüber Rot und in diesem Fall
besonders Blau.
Weitere Möglichkeit zur Datenreduktion:
Die FFT läuft jeweils nur auf einem einzigen Kanal. Die Planes der
anderen 3 Kanäle müssen nicht übertragen werden.
Das Grid, auch wenn es mehrere gibt ist immer gleich. Es reicht die
Grids durchzunummerieren und die Nummer des jeweils aktiven Grid zu
übertragen. Die eigentlichen Daten dieser Plane liegen im PC Prog als
Tabelle vor.
Es muss nicht die Cursor oder Math Plane übertragen werden, wenn die
garnicht benutzt werden...
Wenn man zuerst den aktuellen Betriebsmodus sendet und nur die nötigen
Daten solle sich die Übertragungszeit um 15-20 sec. reduzieren lassen.
@Bruno
Nein, bei mir sieht das völlig anders aus. Bei 25mV + 50mV mit
Rechteckfenster werden 40mV angezeigt, mit Poisson-Fenster nur noch ca.
12mv - Das ist ein durchaus nicht unerwartetes Ergebnis.
Hayo
Stefan, du könntest auch diese Bild mit einem Zeichenprogramm ausmalen
;-)
PaintNet zeigt direkt die HEX Werte der Farben an.
Die geraden Linien mit dem "Farbeimer", die diagonalen mit dem
Linienwerkzeug.
Wenn du die schönste Farbkombination gefunden hast kann man die im Oszi
und im Programm einbauen.
Ich bin leider Farbenblind. ;-)
Hallo,
@Stefan:
> Besteht da eine Chance, dass die auf dem Scope dargestellten satte> Farben auf dem PC ein ähnliches Niveau erreichen.
Ja, sicher. Die Werte die ich genommen habe sind nur per Daumen
und Augenmass anhand meiner Wahrnehmung vom DSO Output von mir
geschaetzt, hab' da aber nicht wirklich Zeit fuer investiert.
Wie Kurt zeigt kann man die Konstanten aendern, sicher koennen
wir in zukuenftigen Versionen die Werte ueber z.B. eine .ini-Datei
direkt vom Benutzter anpassen lassen.
@Falk:
[Optimierung RLE Algo, Zeitreduktion]
Das klingt gut, ich finde wir sollten Deine Aenderungen direkt
uebernehmen. Ich persoenlich finde das diff-Format dazu
( http://de.wikipedia.org/wiki/Diff ) am praktischsten.
> Bei Interesse stelle ich die Änderungen hier ein.> (Oder zieht Ihr einen anderen Ort vor?)
Ob wir das immer alles hier in dieses Forum posten sollten weisz
ich nicht, fuer mich waere auch die Google Group i.O.. Das pflegen
des Codes ueber eine Versionsverwaltung waere auch in Ordnung, ich
hab' hier schonmal gelesen das wohl der Service von Sourceforge
nicht so prickeln ist und Leute Probleme damit haben.
Wenn Interesse besteht kann ich sowas aber auch selbst hosten
(habe eigene Rechner in RZ).
> Als nächstes könnte ich die "Save to CSV"-Funktion schreiben.
Ja kannst Du wenn Du Zeit hast mit anfangen, ich hab' da diesbzgl.
auszer den geschilderten Vorueberlegungen nocht nichts gemacht.
Ich werde auch noch meine bereits geschriebenen ZModem Funktionen
einstellen, auch wenn da noch noch auf dem DSO die ISR Anpassung
fehlt um die verwenden zu koennen.
@Kurt:
[Nicht alle Planes uebertragen]
Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16
Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst
noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten"
pro Plane braucht liesze sich da deutlich Zeit einsparen.
Es gibt allerdings ein paar Sachen zu beachten, ich hab' ja schon
die Beobachtung gemacht (im Sourcecode gibt's nen Kommentar dazu),
dass die roten Pfeile und das rote Stop(p)-Schild auf die Channel 4
Plane gelegt sind (weil die vmtl. gerade rot war, oder so...).
Ohnehin war mir zum Zeitpunkt als ich das schrieb' noch nicht klar,
welche Planes nun genau zu welchem Zweck genutzt wurden und habe
alle rausschreiben lassen, auch die Marker Planes, die gar keine
Einfaerbung erhalten.
Also ja. Auch die Zeitersparnis die wir dadurch gewinnen koennen wir
bitter gebrauchen. Vllt. noch fuer die Entwicklung die Moeglichkeit
offen lassen trotzdem alles zu uebertragen, um wie schonmal gesagt
Darstellungsfehler einfacher lokalisieren zu koennen.
@alle:
Sollten wir vllt. irgendwo eine stets aktuell gehaltene Liste haben
"wer arbeitet gerade woran" um doppelte Arbeit zu vermeiden?
Niklas
Kurt,
Ich musste eben auch feststellen, dass es nicht ganz so trivial ist wie
es auf den ersten Blick schien :-\
Ein paar Linien mit Corel auf einer schwarzen Fläche sind ähnlich blass,
wenn nicht schlimmer; hingegen kommt ein Screenshot aus dem Layout doch
deutlich "leuchtender" rüber - mir fehlt jetzt ein sich am Kopf
kratzender Smiley ;)
Ich vermute mal, dass mein Bildschirm bescheiden abbildet oder meine
Augen schlecht eingestellt sind...
Ich glaube auch es sind deine Augen ;-)
Im Layout will man immer möglichst große Flächen haben, wohingegen im
Screenshot die Linien möglichst dünn sein sollen. Das verbessert deren
Sichtbarkeit natürlich nicht gerade.
Hallo Kurt,
> Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er> glaube ich nicht.
Ja, ich hab' die w2000a-screenshot.c nur zu nem .cpp gemacht weil
der Parser die ComTools.h sonst nicht fressen wollte. Die benoetigten
Sachen die die ComTools machen koennen wir denke ich auch leicht
selbst neu bauen.
> Die unistd darf bei mir nur unter Linux eingebunden werden.> Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)
sleep(1000) wuerde 1000 Sekunden warten unter allen mir
bekannten libc... (Ist abgesehen davon auch POSIX)
> Ersetzen von snprintf() durch sprintf_s().> Aus fopen wird fopen_s
Noch nie irgendwo implementiert gesehen, was machen die
anders als die n-Versionen?
http://netbsd.gw.com/cgi-bin/man-cgi?snprintf
Die n sind egtl. soweit ich weisz auch C99...
> Dann gibt es noch Probleme mit optarg und getopt()...
Zu erwarten...
> Die Frage ist ob die Änderungen auch mit Linux laufen.
Leider nicht.
> PS:> Mit MinGW geht es bei mir aber auch so. Ich musste erstmal> googlen wie man damit kompiliert. ;-)
Wollen wir bei MinGW bleiben, oder statt der n die ganz normalen
Versionen verwenden und getopt() selbst implementieren?
Statt fopen() geht ja auch open(), oder fehlt das auch?
Niklas
Hallo, nochmal,
urgs, merke gerade das ich oben als ich von den Planes mit
(mir) noch nicht bekannten Funktionen sprach da die Marker
Planes erwaehne. Da meinte ich natuerlich die Memory Planes.
Niklas
Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre
es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei
Hardware | Software auch ganz gut.
Dieser hier würde dann für Rückmeldungen bzgl. eventueller Fehler,
Usability und ggf. Wunschdenken aktiv bleiben, während sich ein neuer
Thread in Richtung allgemeine Entwicklung, Tools, sowie konzeptionelle
Ausrichtung und Strategien abspaltet... ich vermute mal, dass eine
Abspaltung der überschaubaren Anzahl aktiver Entwickler disziplinierter
vonstatten gehen würde, als die Vielzahl der hier mitlesenden auf einen
neuen Thread umzubiegen.
Ist nur so eine Idee - bitte nicht kreuzigen :)
Ich denke eine weitere Aufsplittung würde es eher unübersichtlicher
machen, allerdings könnte man den Thread evtl. mal wieder neu aufsetzen
damit die Beiträge überschaubar bleiben.
Hayo
Hallo Hayo,
ich habe folgendes Problem:
ich nehme ein Signal auf (5µs/div), drücke auf Stop. Signal bleibt
stehen. Ich zoome rein auf 2µs/div, Signal wird kurz vergrößert
dargestellt, so wie es gedacht ist. Aber dann wird auch schon ein neues
aufgezeichnet.
Kannst du das mal fixen?
Gruß,
Stefan
Hi, anbei die diffs für die überarbeiteten Screenshot-funktionen.
Das diff für die Firmware ist für 0.82, kann aber einfach am Ende von
src/display_t.cpp gegen die drei ursprünglichen Funktionen,
tschuldigung, Methoden, is ja C++ ;-) ausgetauscht werden.
Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas
den entsprechend einpflegen könnte?
@Hayo: Mein Vorschlag zur Bedienung der Screenschot-Funktion:
Quick-Print macht einen Screenshot wie in 1.2.BF.0.82.
Da die Screenshots und Rohdaten ohne ein Stück Software auf dem PC
sowieso sinnlos sind, kann die PC-Soft einfach ein Kommand über RS232
schicken, das die gewünschte Aktion startet.
Ich stelle mir das so vor, daß die bisherige Steuerung unverändert
bleibt, abgesehen von dem Zeichen "starte spezielle funktion" STX, ASCII
0x02.
Hardware::ISR_UART bekommt eine simple State-machine, die alles
durchreicht, außer STX-LEN-Daten-ETX und nach ETX ein Flag setzt. Das
könnte mit UART_NewData=2 realisiert werden.
In Hardware::Keyboard_Interface könnte dann etwa so aussehen:
1
switch(UART_NewData){
2
case1:UART_NewData=0;//reset UART ISR flag
3
if(UART_RXData=='a'){lMenuKey=0;}// Acquire
4
....
5
case2:handle_remote_control(...)
6
}
7
UART_NewData=0
Ich würde das einbauen, wenn wir uns nicht gegenseitig dabei stören.
Gruß,
Falk
Stefan schrieb:
> Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre> es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei> Hardware | Software auch ganz gut.
Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach
HW, Software, Diskussionen etc. trennen.
Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.
Falk
@BF.0.82: Läuft ziemlich gut. 3 Dinge sind mir aufgefallen:
* About Oscilloscope: Auch hier gibts Artefakte, wenn man z.B. vorher
im Quick Measurement Menü war
* Quick Measurement: Wenn ich z.B. das Probe Comp Signal (bei
200uS/div) anschaue, dann ist die Periode dauerhaft 1.00ms, aber die
Frequenz flackert zwischen 995.0 und 999.0 Hz, ohne dass die
Nachkommastelle mal ungleich wäre. Auch die Spannungsmessungen wie z.B.
Pk-Pk ändern nie ihre Nachkommastelle.
* UART: Wenn ich im Quick Measurement Modus bin, reden die
Messfunktionen bei jedem Aufruf auf der UART. Solche Meldungen, die beim
Entwickeln sehr helfen, solltet ihr unter Zuhilfenahme eines Makros
ausspucken, damit die in den Releases still sind. Das kostet alles
unnötige Zeit, wenn andauernd auf die UART geschrieben wird.
Falk Willberg schrieb:
> Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach> HW, Software, Diskussionen etc. trennen.>> Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.
Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:
http://sourceforge.net/apps/phpbb/welecw2000a/
SourceForge-Handles haben eh' die meisten schon, und ihr könnt gern alle
Mod- oder Admin-Rechte haben und eine beliebige Menge Foren und
Kategorien anlegen. Würde mich freuen, wenn das Forum dort mehr genutzt
würde.
Daniel H. schrieb:
...
> Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:> http://sourceforge.net/apps/phpbb/welecw2000a/
Gefällt mir ;-)
Mal sehen, ob es ankommt...
Falk
@Daniel
SFN könnte man natürlich machen, aber ich fand das immer recht zäh und
langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit
eigene Foren einzurichten ist natürlich nicht übel.
@Falk
Auch Dein Angebot einen Server zur Verfügung zu stellen ist recht
reizvoll da dann die Kontrolle quasi "in unserer Hand" bzw. in Deiner
läge. Vermutlich wären auch die Antwortzeiten attraktiver als bei SFN.
Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in
regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht
immer neue Treads nötig sind.
Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr
zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also
am Besten mit Ihm abstimmen. Meine Baustelle ist nach wie vor die FFT,
die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno
und die LeCroy Broschüre).
Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im
Hardwarethread, eigentlich müßte doch nur das Flash fur den
USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da
waren doch schon einige aktiv glaube ich.
Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist,
nachdem ich einige Zeit nichts mehr von Dir gehört hatte.
Gruß Hayo
Hallo,
ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas
kaputt mache, will ich vorher nochmal kurz nachfragen.
Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
nächsten Oszi Start dann wieder weg?
Kann ich das unter Windows einfach mit der WelecUpdater.exe machen? Oder
muss ich mir vorher nen Perl-Interpreter zulegen, damit ich das mit dem
Skript machen kann?
Danke! Gruß,
Michael
Hayo W. schrieb:
> @Daniel>> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit> eigene Foren einzurichten ist natürlich nicht übel.
Ich habe da jetzt einfach mal einen Thread zum Thema screendump
aufgemacht.
Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.
...
> Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr> zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also> am Besten mit Ihm abstimmen.
Ok. Ich denke, Niklas hat es mitbekommen. Ich brauche die ISR
wahrscheinlich nicht, meine Erweiterung sollte sich in
Hardware::Keyboard_Interface einbauen lassen.
> Meine Baustelle ist nach wie vor die FFT,> die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno> und die LeCroy Broschüre).
Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.
Eingang ist der Sonnenschirm als Antenne ;-)
> Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im> Hardwarethread, eigentlich müßte doch nur das Flash fur den> USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da> waren doch schon einige aktiv glaube ich.
Werde ich mal machen. Mit RS232 komme ich aber gut aus. Schneller ist
die sowieso...
> Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist,> nachdem ich einige Zeit nichts mehr von Dir gehört hatte.
Ich habe mich jetzt wieder hineingefunden und werde das Scope eine Weile
nicht zum Arbeiten brauchen.
Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
>Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.>Eingang ist der Sonnenschirm als Antenne ;-)
Coole Idee ;-)
>Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim>nächsten Oszi Start dann wieder weg?
Die ist beim nächsten Start wieder weg. Aber trotzdem vorsicht, da die
Firmware trotzdem Einstellungen in den Flash speichert. Also vorher auf
alle Fälle einen Backup ziehen. Da ist eine Sicherung der
Config-Bereichs mit dabei.
Ich würde mir Perl installieren. Der WelecUpdater ist schnarch langsam.
Ob .ram damit überhaupt geht, hat glaube ich, keiner mehr ausprobiert.
Gruß,
Stefan
Falk Willberg schrieb:
...
> Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas> den entsprechend einpflegen könnte?
Hier das diff-file für 0.3.
Falk
Michael schrieb:
> ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas> kaputt mache, will ich vorher nochmal kurz nachfragen.
Beides eine gute Idee... allerdings steht eigentlich so ziemlich alles
in den Beipackzetteln die ich mit dazugetan habe. Trotzdem hier schnell
noch ein Antwort auf Deine Fragen.
> Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim> nächsten Oszi Start dann wieder weg?
So ist es. Aber wie Stefan schon anmerkte - die neue Version verwaltet
die im Flash abgelegten Daten etwas anders. D.h. beim nächsten Start der
alten Software kann es merkwürdige Nebenwirkungen geben, die sich jedoch
mit Default Setup beheben lassen sollten. Auf jeden Fall solltest Du Dir
mit dem Welecupdater ein Backup Deines Flash machen - Anleitung dazu
liegt im Doku Ordner der Betaversion.
> Kann ich das unter Windows einfach mit der WelecUpdater.exe machen?
Nein! Der Welecupdater kann es nicht, und zwar einfach deswegen nicht,
weil er die Endung .ram nicht unterstützt. Du müßtest die TomCat.ram
einfach nur umbenennen in TomCat.flash (aber nicht mit der Richtigen
verwechseln ;-) ), dann sollte es gehen.
> Oder muss ich mir vorher nen Perl-Interpreter zulegen,> damit ich das mit dem Skript machen kann?
Wenn Du das öfter machen möchtest, kann ich das nur dringend empfehlen,
da
der Unterschied 20 Minuten zu 3 Minuten doch schon gewaltig ist.
Gruß und viel Spaß
Hayo
@Falk
> Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:
Sehr schön, wenn wir so weitermachen schrumpft das File noch unter 1,2
MByte trotz neuer Funktionen ;-)
Auf jeden Fall wird der Code langsam immer übersichtlicher und
strukturierter.
Gruß Hayo
Hallo,
nachdem ich euren Thread jetzt eine Weile verfolgt habe, habe ich mir
auch ein Welec bestellt, das nächste Woche eintrudeln müsste. Zur Zeit
bin ich noch im Prüfungsstress, danach möchte ich mich aber auch an der
Verbesserung des Gerätes beteiligen.
Achja, was mir noch aufgefallen ist: können die Dinger wirklich nur bis
zu 5V/div nach oben? Mein jetziges Oszi lässt sich auf bis zu 50V/div
schrauben und zumindest 10V/div und 20V/div habe ich auch schon
desöfteren benutzt.
Mir fehlt noch der Überblick über Hard-/Software des Welec - kann man
die Messbereiche noch hinzufügen oder steht dem etwas entgegen?
Viele Grüße,
Michael
Hayo W. schrieb:
> @Daniel> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit> eigene Foren einzurichten ist natürlich nicht übel.
Erstmal gehts ja nur um das Forum. Das ist ein phpBB und entspricht
somit wohl dem de-facto-Standard für Forensoftware. Die Antwortzeit ist
wesentlich besser als bei diesen Mega-Threads hier im Forum
> Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in> regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht> immer neue Treads nötig sind.
Das können wir bei SF auch. Da gibts vollen Zugriff auf die übliche
phpBB-Administration. Allerdings sollte sowas garnicht nötig sein, denn
meiner Meinung nach sollte für das, wofür hier Threads verwendet werden,
im phpBB ein Unterforum angelegt werden, in dem dann für
unterschiedliche Gedankengänge unterschiedliche Threads genutzt werden
;) Aber das ist sicherlich Geschmackssache (des Moderators =)
> Ich habe da jetzt einfach mal einen Thread zum Thema screendump> aufgemacht.> Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.
Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das
andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich
(wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet
werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.
Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit
dem Google Groups Kram).
Aktuelles:
- Die Option -c <serial-port> geht auch unter Linux
- Mit einer kleinen Firmwareänderung wird der Dump vom Programm
gestartet
- Man kann die Option "-m" für einen monochromen screendump angeben
(10s)
- Mit "-d" werden die Daten als CSV ausgegeben (7s).
- Ohne Optionen -c oder -m wird ein farbiger screendump ausgegeben (30s)
Die entsprechenden Patches kommen morgen...
Die Grafik zeigt die Ausgabe, die "kst" aus dem CSV-file erzeugt.
Falk
Daniel H. schrieb:
> Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das> andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich> (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet> werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.
Gute Idee. Ich werde meine Änderungen künftig in SFNET ablegen und hier
darauf hinweisen.
Dieses Forum ist nicht schlecht, aber mit Themen, Unterthemen etc. ist
SFNET einfach besser geeignet.
> Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit> dem Google Groups Kram).
Ich werde den Google-Groups-Kram bald zumachen und einen Hinweis hierhin
und nach SFNET anbringen (wenn ich herausfinde, wie das geht).
Falk
@Stefan
Nur kurz zur Abstimmung, ich habe die vertikalen Cursordaten korrigiert,
so dass jetzt alle Spannungen korrekt angezeigt werden
-> void Display::CALCCURSORDATA(void)
Hayo
@Stefan
Nochmal kurz zur Abstimmung - ich schmeiße die bei einigen
Anzeigefunktionen die sich wiederholenden switch() Anweisungen raus und
ersetze sie durch indizierten array fetch. -> Display::MEASURETIME(),
CALCCURSORDATA(), CALCPRETRIGGER(), CALCTIMEBASE()
Hayo
Niklas O. schrieb:
Hallo Niklas,
> @Kurt:> [Nicht alle Planes uebertragen]>> Daran hab' ich auch schon gedacht. In der Tat sind ein paar der 16> Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst> noch weitere ausschlieszen. Da das DSO ohnehin da "Ewigkeiten"> pro Plane braucht liesze sich da deutlich Zeit einsparen.
Im aktuellen Stand werden ja so weit ich das überblicke sämtliche Planes
übertragen und dann auf dem PC genauso wie auf dem Oszi mit Farben
versehen und übereinandergelegt. Bei der Übetragung der Planes geht viel
Zeit drauf. Wäre folgender Weg nicht besser?
Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane
ist:
Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt
ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der
Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist
wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält
dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). Wenn der
Pixel auch in Plane B nicht gesetzt ist, dann wird Plane C geprüft. Wenn
der Pixel hier gesetzt ist, erhält dieser Pixel den Wert "3" wenn nicht,
erhält der Pixel den Wert "0" (für transparent bzw. schwarz).
Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi
dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf
ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1
pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden
müssen.
RLE funktioniert hier natürlich immer noch, da man ja statt einzelner
Bits auch 4-Bit Sequenzen zusammenfassen kann. Auch auf dem Oszi dürft
sich auch einiges an Laufzeit sparen lassen. Für das Überlagern der
Planes im Oszi geht zwar etwas Zeit drauf, aber statistisch müssen nur
noch 50% der Plane-Daten gelesen werden, da die "hinteren" Planes nach
einem Match gar nicht mehr gelesen werden müssen.
Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,
aber schnelle Screenshots sind noch schöner.
Gruß,
Bernd
Bernd O. schrieb:
>> Hallo Niklas,
Ich bin zwar nicht Niklas, habe aber seine Routinen bearbeitet.
...
> Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane> ist:>> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der> Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist> wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält> dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen).
...
Klingt gut! Sollte sich einfach implementieren lassen.
> Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,> aber schnelle Screenshots sind noch schöner.
Auf 30s sind wir schon, mit Deinem Vorschlag könnte das noch schneller
werden.
Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke
ich mal...
Gruß,
Falk
Hallo Hayo,
die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen
ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick
reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal
eingestellt, auch mit SourceForge "relativ" fix.
Gruß,
Stefan
Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich
perfekten Client wie z.B. Tortoise unter Windows. Bei mit leistet "eSVN"
noch am wenigsten Widerstand. KSVN geht bei mir mit SF nur sehr träge.
Gruß,
Stefan
Stefan E. schrieb:
> Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich> perfekten Client wie z.B. Tortoise unter Windows.
Im alltäglichen Umgang braucht man eigentlich nur eine Handvoll
Kommandos:
svn checkout
svn update
svn status
svn commit
svn add
damit sind 95% aller Tätigkeiten abgedeckt.
Dafür kann man gut, auch als nicht Kommandozeilen-Freund, mit
der Kommandozeile leben.
Gruß,
Günter
Falk Willberg schrieb:
> Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke> ich mal...
Leider hilft ein Flash-Update nicht gegen kalte Lötstellen oder
Wackelkontakte. Jedenfalls startet die Firmware nur noch bis
Ein wenig ans Gehäuse zu klopfen hat das Problem kurzfristig lösen
können.
Der GERMS-Monitor funktioniert aber noch.
Schön, wenn man drei Jahre Garantie hat :-)
Falk
Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und
oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da
würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...
Na geil.
Ich gebe zu, dass ich mich durch die Anfrage von Hayo inspiriert sah.
Die Idee schwirrte mir schon so lange im Kopf rum, dass es wohl einfach
nur eines Triggers bedufte.
@Stefan
finde ich auch gut :-)
@
0.82 funktioniert bei mir (W2024A) :-)
Was mir auch noch aufgefallen ist:
Wenn ich "Search Zero Lines" drücke, wandern die Kanäle 3 und4 ein paar
Pixel nach unten. ?!
erst nach "calibrate DAC" sind sie wieder in der Mitte ..
Ist das bei Euch auch so ?
Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei
200ms/div
Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit
man damit auch richtig messen kann .( "Quick Meas" zeigt dann 3,84Hz an
)
Bei 1ms/div zeigt es mit "Quick Meas" richtig die 1kHz an :-)
Und ein Großes Lob und DANKE, an alle die hier so toll mitarbeiten!!
l.G. Roberto
@Roberto
Was du bemängelst (und misst) ist das typische Antialiasing das bei
allen DSO's auftritt. Es ist dem Anwender überlassen die richtige
Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit
einer möglichst hohen sample-rate beginnen und runtergehen bis das
Signal richtig dargestellt wird).
Martin
>Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei>200ms/div>Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit>man damit auch richtig messen kann
Das ist nur eine "optische Täuschung" (Aliasing), die durch das Abtasten
bei zu geringer Frequenz entsteht.
Unter Linux habe ich die besten Erfahrungen mit "rapidsvn"
(http://rapidsvn.tigris.org/) gemacht. Ist aber denke ich bei jedem
unterschiedlich.
Svn selbst ist ziemlich cool, hat aber den Nachteil, dass es auf
Client-Seite das doppelte an Speicherplatz für die Sourcen braucht.
PS:
"svn diff" als Befehl auf der Kommandozeile ist auch sehr nett.
Damit kann mensch eine Projektbetreiber seine Änderungen schicken,
wenn mensch selbst keinen Schreibzugriff auf das Repository hat.
Hab gerade die 1.2.82 eingespielt. Funktioniert leider erstmal gar nicht
gut.
Im Math Menü habe ich beim FFT-Softkey ein Rufzeichen drinnen. Wen ich
in ein anderes Menü wechsle bleibt dieses Rufzeichen erhalten.
Zusätzlich im Softkey "1+2" ein paar Artefakte.
Das Math-Menü reagiert bei mir gar nicht. Auf keinen Tastendruck.
Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht
gar nichts mehr.
Die violette Math-Linie, die angezeigt wird sobald der Math-Modus aktiv
ist, durchbricht Menüs. Zb das Quick-Measure Menü. Wobei das eher ein
Minor Bug ist.
Ich denke, das Beste ist wenn ich den Komplett-Dump neu einspiele.
lg Robert
@Robert
Wenn sich das Problem durch Default Setup, Drehen an der Timebase und
Neustart nicht beheben läßt, ist das Einspielen eines Dumps in der Tat
die beste Lösung. Bei mir war das auch schon mal nötig, danach ist dann
aber alles wieder in Ordnung.
Hayo
Robert S. schrieb:
...
> Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht> gar nichts mehr.
Das ist normal, sollte aber nach ca. 30s vorbei sein.
Falk
@Falk
> spurious interrupt number: .................
die gleiche Fehlermeldung hatte ich beim versehentlichen Überschreiben
des Stacks als ich eine Assemblerroutine mit falschen Parametern
versorgt habe. Bist Du sicher, dass es sich um einen Hardwarefehler
handelt?
Hayo
Hallo,
Da ich auf meinem Windowsrechner keinen Platz für ein zweites
Betriebssystem habe konnte ich bisher den Source nicht selbst
compilieren.
Jetzt habe ich jedoch auf dem ftp server von altera die cygwin version
des compiler's gefunden! (in der Version 3.2)
Mit dem ist es möglich auch unter Windows an der SW Entwicklung mit zu
machen.
Anbei eine kleine Anleitung in englisch (sicherlich noch
verbesserungswürdig).
Martin
Hi Martin,
das ist cool, dann kann ich auch im Urlaub in Italien weiterentwickeln,
mein Lappy hat nämlich nur Windows drauf (meine Frau wird mich
steinigen).
Ich werde das mal nach Deiner Anleitung versuchen.
Gruß Hayo
Wenn deine Frau den ersten Stein aufhebt, dann mach' ihr klar, wie viele
arme kleine Wittig User sie ins Unglück stürzen würde. Vielleicht lässt
sie dich dann uns zu liebe am Leben und zielt nur auf Körperteile, die
nicht zur Firmwareentwicklung benötigt werden...
Kurze Anfrage zum Organisatorischen:
Nachdem jetzt Google.Groups geschlossen ist, wo kann ich außer hier noch
das komplette Firmwarepaket hochladen? Gibt es da auf SFN eine
Möglichkeit?
Hayo
Ja, die gibt es. Ich habe dir mal die Berechtigungen gesetzt, damit du
Releases erstellen kannst. Hier ist alles erläutert:
http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download
Falls es nicht klappen sollte, können wir das ja mal zusammen
durchgehen, Skype-Daten von mir sind ja überall zu finden. Bin
allerdings erst morgen abend wieder richtig zugegen (Prüfungsstress).
Konkrete Fragen kann ich sonst auch hier oder per Mail/PN beantworten.
Hallo werte Gemeinde,
ab sofort gibt es die aktuellen Open Source Releases hier:
https://sourceforge.net/projects/welecw2000a/files/
Zur Zeit ist noch die 0.82 das aktuelle beta Release, aber das Nächste
ist schon in Arbeit und kommt hoffentlich zum Ende der Woche.
Gruß Hayo
Hallo,
ist ja einiges in den letzten paar Tagen in meiner Abwesenheit
passiert :)
@Falk:
Hab' Deine Patches gesehen und werde die die naechsten
Tage migrieren, wohl gar direkt ins SourceForge SVN
Repository, wenn ich das richtig sehe das ihr euch
entschlossen habt dieses zu nutzen.
Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir
jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
ist ja an sich etwas gestiegen). Hast Du schonmal probiert,
aus der RLE Funktion ein Makro zu machen? (ich gehe mal
ungeprueft davon aus dass der GCC die Funktion nicht inlined)
@Bernd:
Das was Du beschreibst ist in etwa das was bei dem S/W Dump
passiert, nur wird dort dann gleich auch noch die Farbe/dominante
Plane mit weg geworfen. Zeitlich waren das trotzdem noch
iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir
wie Falk auch Recht. Die Frage ist, ob jetzt Falks
Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
schneller waere oder Dein Neuansatz. Erstere (alte) Loesung
waere flexibler und bereits implementiert, von daher wuerde
ich, sollte letztere nicht schneller sein, dabei bleiben.
@Falk: Hast Du da diesbzgl. in der Zwischenzeit schon
weiter gemacht?
Niklas
Jürgen schrieb:
>> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für>> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?>> Aber sicher wäre das Klasse!!
Ich finde die Idee auch gut, aber das sollten wir erstmal auf der
Wishlist unterbringen und die Realisierung erst dann vornehmen wenn wir
vom beta Status weg sind.
Gruß Hayo
@Niklas
Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht
kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da
dann die alten Programme nicht mehr kompatibel sind zum Datenformat.
Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen nur
jetzt mit der SFN Releaseverwaltung
Gruß
Hayo
Niklas O. schrieb:
...
> @Falk:> Hab' Deine Patches gesehen und werde die die naechsten> Tage migrieren, wohl gar direkt ins SourceForge SVN> Repository, wenn ich das richtig sehe das ihr euch> entschlossen habt dieses zu nutzen.>> Schoen das wir jetzt auf 30 Sekunden sind. Wobei sich mir> jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten> Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet> ist ja an sich etwas gestiegen).
Das frage ich mich auch. Leider habe ich keine Informationen, welche
Operationen, wieviel Last erzeugen. Im Standardfall (Sehr viele gleiche
Bytes), passiert aber ca. 60.000-mal nicht anderes als ein increment und
ein 16-Bit Vergeich.
> Hast Du schonmal probiert,> aus der RLE Funktion ein Makro zu machen? (ich gehe mal> ungeprueft davon aus dass der GCC die Funktion nicht inlined)
Das dürfte die Code-Größe gewaltig steigern (640*480-mal die
RLE-Funktion...)
> @Bernd:> Das was Du beschreibst ist in etwa das was bei dem S/W Dump> passiert, nur wird dort dann gleich auch noch die Farbe/dominante> Plane mit weg geworfen. Zeitlich waren das trotzdem noch> iirc. 10-15 Sekunden allein an Rechenzeit. Ansonsten gebe ich Dir> wie Falk auch Recht. Die Frage ist, ob jetzt Falks> Verbesserungen plus Planes aussparen (wie Kurt vorschlug)> schneller waere oder Dein Neuansatz.
Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten
Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist
simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der
Definition geändert werden.
> Erstere (alte) Loesung> waere flexibler und bereits implementiert, von daher wuerde> ich, sollte letztere nicht schneller sein, dabei bleiben.> @Falk: Hast Du da diesbzgl. in der Zwischenzeit schon> weiter gemacht?
Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.
Ich sage Bescheid, wenn ich weitermachen kann, bis dahin lasse ich den
Kram in Ruhe.
Inzwischen mache ich mich auch mit SVN vertraut.
Vielleicht bastele ich inzwischen ein ppm2splashlogo.pl ;-)
Falk
P.S.: Ich finde es prima, daß wieder mehr Leute dazu beitragen, ein
Scope so zu verbessern, daß Anwenderwünsche direkt berücksichtigt werden
können.
Hallo Hayo,
> Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht> kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da> dann die alten Programme nicht mehr kompatibel sind zum Datenformat.
Ja das werde ich machen. Den Sourcecode fuer die Tools wuerde ich dann
unter pc/screenshot/ einpflegen.
> Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen> nur jetzt mit der SFN Releaseverwaltung
D.h., (noch) nicht den Sourcecode im SVN Repository pflegen? Haette
den Vorteil das wir alle direkt Aenderungen committen koennten ohne
dass Du die selbst einbauen muesstest. Damit man sich nicht in die
Quere kommt koennten wir noch Branches machen, aber im Moment sollten
wir auch ohne auskommen. Oben wurden ja schon ein paar SVN-Clients
genannt. Ich faend's super wenn wir uns darauf einigen koennten
das SVN zu nutzen. Kleine Bugfixes und Verbesserungen wie zuletzt
das charTOlMenuKey Array von Falk waeren so sofort eingebaut und auch
von allen Interessierten noch vor dem naechsten offiziellen Release
getestet. Ich koennte auch etwas wie einen automatischen
"Nightly Build" bereit stellen, also eine fertige Firmware die den
aktuellen Stand im Repository wiederspiegelt.
Niklas
Hallo Falk,
>> Hast Du schonmal probiert,>> aus der RLE Funktion ein Makro zu machen? (ich gehe mal>> ungeprueft davon aus dass der GCC die Funktion nicht inlined)> Das dürfte die Code-Größe gewaltig steigern (640*480-mal die> RLE-Funktion...)
Stimmt, bloede Idee. (auch wenn man das auf 640*480/8 runter
dreht noch...)
>> @Bernd:>> Das was Du beschreibst ist in etwa das was bei dem S/W Dump>> passiert, nur wird dort dann gleich auch noch die Farbe/dominante>> Plane mit weg geworfen. Zeitlich waren das trotzdem noch>> iirc. 10-15 Sekunden allein an Rechenzeit. [..]>> Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten> Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist> simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der> Definition geändert werden.
Ja, stimme ich Dir zu. Waere 'ne simple Modifikation der B/W Funktion,
baue ich mal ein.
> Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.
:/ Bin mal gespannt wie der Service bei Wittig ist.
Niklas
Mit SVN muß ich mich erst noch näher auseinander setzen. Da ich momentan
einiges zu tun hatte und gleichzeitig am nächsten Release dran war hatte
ich da keine Zeit für. Deine Lösung mit dem Nightly Build klingt ganz
Interessant, denn mir ging es in erster Linie darum nicht nur die
Entwickler mit dem neuesten Stand zu versorgen, sondern auch den
Benutzern die Gelegenheit zu geben die aktuellsten Versionen
auszuprobieren.
Weiterhin möchte ich auch vermeiden meinen Verwaltungsoverhead zu groß
werden zu lassen um möglichst viel Zeit für die Entwicklung zu nutzen.
Gruß Hayo
Hallo Zusammen,
ich arbeite gerade an einer "Hardwarelösung" für die Screenshots. Die
Platine enhällt:
ATMega32/644, VNC1L, MAX232, 64kBit FRAM, SUB-D Anschlüsse für Oszi und
PC, USB Anschlüsse für Stick und Oszi und eine Pinleiste um den Vinculum
das erste mal zu programmieren. Größe ist 80x80mm einseitig mit einigen
Brücken.
Ich werde noch Layout und Schaltplan etwas überarbeiten und dann hier
reinstellen. Allerding befürchte ich, das der Vinculum etwas schwierig
zu löten ist.
Sollte das Konzept funktionieren kann man aber immer noch auf ein
fertiges Modul ausweichen. Der Flaschenhals ist definitiv nicht auf der
Platine sondern die lahme RS232 vom Oszi.
Mfg,
Kurt
Moinsen allerseits,
wenn man hier ein paar Tage nicht reinschaut hat man ganz schön was zu
lesen. Respekt vor dem Elan mit dem hier gewerkelt wird...
Noch eine Tipp zu Subversion-Clients: ich kann jedem nur aller wärmstens
eclipse ans Herz legen. Nicht nur, dass es die Entwicklung massiv
vereinfacht, es bringt auch einen sehr brauchbaren SVN-Client
(Subversive) mit.
Viel Spaß weiterhin.
Beste Grüße,
odic
Hallo Kurt,
na deine Platine sieht ja echt gut aus. Vielleicht sollten wir, wenn
feststeht das die Schaltung funktioniert, auch dafür eine professionelle
Lösung in Betracht ziehen? Bei den meisten dieser "Produkte" drückt eine
Herstellung von 30...50 Stck. ganz massiv den Preis.
Ich hätte da auf jeden Fall Interesse dran.
Gruß, brunowe
P.S.: mit Eagle3D gemacht?
Hallo Bruno,
ja, mit Eagle 3D.
Auch ja zur Professionellen Lösung. Leiterbahnen mit 8mil und Abstände
mit 11mil sind nicht für jeden einfach zu ätzen. Außerdem soll die
Platine später kleiner und doppelseitig werden damit man die
Versorgungsspannungen ordentlich routen kann.
Sehr interessante Erweiterung, die dürfte weggehen wie warme Semmeln
(ich bin z.B. ein Doppelabnehmer). Daher denke ich sollte eine größere
Auflage zu Gunsten des Preises kein Problem sein.
Was Anderes: Um die ToDo-Liste zu komplettieren bin ich mal in Gedanken
die wichtigsten Funktionen des DSO durchgegangen, dabei ist mir
aufgefallen, dass ich noch nie die Speicherfunktion für die Signale
benutzt habe. Hat das schon jemand ausprobiert? Ist das ein Feature das
ausnahmsweise mal einfach so funktioniert, oder müssen wir da auch das
Baustellenschild aufstellen?
Gruß Hayo
Hallo Hayo,
die Save/Recall Sachen funktionieren bei der Original-Firmware
einigermaszen, habe ich schon oefters benutzt wenn ich z.B. Signale
vergleichen wollte. Dummerweise konnte ich die dann allerdings
nicht mehr mit der Welec Originalsoftware vom Oszi holen, da wurde
einfach eine neue Signalfolge aufgenommen.
Auch kann man die Funktion nutzen um Kanal- und Zeitachsen-
einstellungen zu sichern, die werden naemlich gleich mit
wiederhergestellt.
Bei der Beta-Firmware scheint da aber genau gar nichts zu
funktionieren. Habe da sehr absurde Effekte. Genau genommen
ist wohl Reboot faellig nach einem Save gefolgt von Recall,
in benutzbaren Zustand habe ich mein Geraet zumindest nicht
wieder versetzt bekommen.
Waere schoen wenn wir das zum Laufen bekaemen, habe mich da aber
noch nicht umgeschaut. Vermutlich werden die ADC-Daten samt
Parameter abgelegt und einfach neu gerendert, oder? Die iirc.
80 Speicherplaetze die da Wittig vorgesehen hat sind aber IMHO
etwas uebertrieben. Vllt. koennen wir das auch aufteilen, d.h.,
Recall Trace und Recal Settings.
BTW: Hast Du meine Nachricht auf SF wg. Devel schon gesehen?
Niklas
Hallo Hayo,
mhm, muesstest egtl. die SF E-Mails an Deine Adresse
geforwardet bekommen. Ging nur darum dass Du mich
(niklas_olmes auf SF) als Devel zum Projekt hinzufuegst.
Geht mit "Project Admin->Membership" eingeloggt unter
https://sourceforge.net/projects/welecw2000a/develop
Niklas
Ich hab mir die Save/Recall-Geschichte mal angesehen, ich glaube es
liegt an den geänderten Parametern die im Flash abgelegt werden, da kann
ich bei Gelegenheit mal beigehen.
Hayo
Hallo,
wenn sich einer dranmacht an der Save/ Recall Funktion rum zu basteln,
dann sollte man direkt den Vorschlag von stendres aus der SF Wishlist
mit einfließen lassen. Halte ich für nen guten Vorschlag.
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWwishlist
Gruß, brunowe
Hallo Bruno,
ja, das waere in der Tat sehr nuetzlich. Koennte man dazu einfach
die (scheinbar) unbenutzten Memory-Planes hernehmen? Sind allerdings
nur drei.
Wo ich gerade die Wishlist sehe finde ich den ersten Vorschlag
von michelwernersen auch wichtig. Da ich (noch) die Original-Firmware
im Flash habe und die aktuelle Beta ins RAM lade bin ich staendig
am Justieren. Das liesze sich sicher recht einfach realisieren,
ich werde da spaeter mal drueber schauen.
Niklas
Stefan E. schrieb:
> Hallo Hayo,>> die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen> ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick> reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal> eingestellt, auch mit SourceForge "relativ" fix.
Ich hab's mal ausprobiert:
auf die Nase.
Wer kann einem SVN-Anfänger mal das Brett vom Kopf nehmen?
Außerdem scheint mir, daß es eine gute Idee wäre, die Dateien weiter
aufzuteilen. So könnte der PC-Kommunikationsteil doch in
"pc-comms.[cpp|h]" ausgelagert werden.
Gruß,
Falk
Hallo Falk,
die doppelten/dreifachen Sourcen siehst nicht nur Du :)
Der letzte committete Stand scheint 0.80 zu sein.
Hayo hat selbst ja noch nichts eingepflegt.
Mit
1
$ svn log $file
kannst Du Dir die Commit Messages der Revisions anschauen, bei
der die angegebene Datei betroffen ist.
Mit
1
$ svn diff -r113 src/hardware_t.cpp
siehst Du die Aenderungen seit Revision 113 (und warum es
nicht kompiliert). (Wenn Du die Datei hinten weglaesst
siehst Du den ganzen Diff.)
Warum da jetzt mehrfach Sourcen rumliegen weisz ich nicht,
die Logmessage dazu besagt "creating new brachn for QM".
Sieht fuer mich nach nem Unfall aus, da ich sonst aber mit
CVS und GIT vertraut bin will ich mich nicht festlegen, kann
auch nen Feature sein ;)
Wir sollten IMHO erstmal hergehen und den aktuellen Versionsstand
(0.82) einmal sauber importieren.
Ansonsten, nochmal Kurzeinweisung fuer Falk:
Mit svn commit wuerdest Du den Kram abschicken, wirst dabei
noch um eine Logmessage als Beschreibung gebeten.
Die restlichen Kommandos erklaert Dir svn help gerne :)
Niklas
Hallo,
jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,
wieder zu löschen.
Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die
QM-Funktion ändere und dann später wieder in die anderen sourcen
einpflege.
Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich
schlagen ;-)
Vielleicht gibts ja hier einen, der das mal so aufräumt, wie es sich
gehört.
hat denn schon mal jemand das compilieren unter windows getestet? ich
hab es nicht hin bekommen. es kommt folgende meldung
># 2009.07.08.19:37:21 --- Compiling nios-elf-gcc -I ./inc -I ./src -I ./inc >-I .>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >-D_Debug_> src/TomCat.cpp -o obj/TomCat.cpp.o>process_begin: CreateProcess(NULL, nios-elf-gcc -I ./inc -I ./src -I ./inc >-I ..>/inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32 >src/TomCat>.cpp -o obj/TomCat.cpp.o, ...) failed.>make (e=2): Das System kann die angegebene Datei nicht finden.>make: *** [obj/TomCat.cpp.o] Error 2
er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch
gar nicht existiert. hat jemand einen tip?
gruß sunny
Stefan E. schrieb:
> Hallo,>> jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,> wieder zu löschen.
Könnte ich mit ksvn vielleicht schaffen. Die Dateien sind sowieso alle
identisch.
> Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die> QM-Funktion ändere und dann später wieder in die anderen sourcen> einpflege.>> Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich> schlagen ;-)
Schade, hatte den Knüppel gerade geputzt ;-)
Stattdessen habe ich Version 0.4 von w2000a-screenshot committed.
Vielleicht hat das ja geklappt...
Falk
sunny schrieb:
> hat denn schon mal jemand das compilieren unter windows getestet? ich> hab es nicht hin bekommen. es kommt folgende meldung
...
>>make (e=2): Das System kann die angegebene Datei nicht finden.>>make: *** [obj/TomCat.cpp.o] Error 2> er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch> gar nicht existiert. hat jemand einen tip?
Er findet nicht die tomcat.cpp.o nicht (die will er ja gerade erzeugen),
sondern die includes unter inc/. Die findest Du da:
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/inc/
Hat mich auch eine Weile gekostet, das herauszufinden.
Falk
die .inc datein sind aber da. im \inc verzeichniss.
ich habe den kompletten build aus dem svn gezogen und nach c:\build
entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.
wie genau (name,wert) hast du denn bei dir die umgebungsvariablen
gesetzt?
gruß sunny
sunny schrieb:
> die .inc datein sind aber da. im \inc verzeichniss.> ich habe den kompletten build aus dem svn gezogen und nach c:\build> entpackt. dann das makefile geändert und die umgebungsvariablen gesetzt.> wie genau (name,wert) hast du denn bei dir die umgebungsvariablen> gesetzt?
Ich habe nichts setzen müssen. Ich hatte die gleiche Fehlermeldung wie
Du, aber unter Linux. Da mußte ich nur das .../inc besorgen, make
eingeben und es lief...
Vielleicht meldet sich noch ein Windows-User...
Falk
unter linux funktioniert es bei mir auch. ist nur unpraktisch weil ich
linux nur af dem satreciver laufen hab.
vielleicht hat ja noch jemand einen tip zum compilieren windows.
gruß sunny
Hallo sunny,
ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die
Umgebung liefern und dementsprechend müsste das Makefile geändert
oder Umgebungsvariablen gesetzt werden. Das wäre jetzt aber mal
wirklich ein Anlass für einen neuen Thread. ;-)
Gruß, Guido
>ev. fehlen nur die Standardheader wie stdio.h u.ä. Die müsste die>Umgebung liefern
ja, tut sie auch die sind in einem unterverzeichniss
>dementsprechend müsste das Makefile geändert>oder Umgebungsvariablen gesetzt werden.
da müsste man halt nur wissen wie und wo.
>Das wäre jetzt aber mal wirklich ein Anlass für einen neuen Thread. ;-)
ach, so wichtig ist es nun auch wieder nicht. hätte ja sein können das
es schon einer hinbekommen hat.
gruß sunny
Hallo sunny,
suche halt die Standardheader und ergänze im Makefile unter
"INCLUDE_PATHS = \" noch
-I /wo_sind_die Standardheader\
Das musste ich unter Ubuntu auch machen, da war es /usr/include.
Gruß, Guido
Hallo,
so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber
in fpga/firmware importiert und Falks letztes Diff eingespielt.
Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.
Das obj/ Verzeichnis wird automatisch angelegt.
fpga/welec/official habe ich entsorgt.
Etwaige Aenderungen in fpga/welec/src und/oder fpga/welec/src/src
usw. ;) muessten noch manuell uebertragen werden. Z.B. ueber
1
<0>[23:46]niklas@empire:/tmp/W/welecw2000a/fpga/welec$ diff -u ../firmware/src/ improved/src/ | less
schauen was noch relevant ist und uebertragen.
@Falk:
Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?
Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle
Angabe jeder Datei findet.
diff -uNr (u fuer unified, N fuer include new files, ggfls. weglassen,
r fuer rekursiv, auch ggfls. weglassen) ist ganz okay.
Andere Sache: Wo wir jetzt schon mal das Format fuer die Ausgabe
geaendert haben und auch noch Messwerte rausschreiben koennen waere
IMHO nen kleiner Header nuetzlich, der besagt was kommt und in welcher
Version das ist. Also statt 'S' 0xff am Anfang koennten wir machen
'S' p v 0xff, Rest beibehalten.
Wobei p Protokoll/Anwendung ist, z.B. 0x01 fuer Screenshot, 0x02
fuer Messdaten. V waere die Version. Das Ausleseprogramm koennte
dann entsprechend handeln.
Niklas
>so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber>in fpga/firmware importiert und Falks letztes Diff eingespielt.>Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.
Sollte auch davor möglich gewesen sein, die Sourcen zu kompilieren. War
eigentlich auf dem aktuellen Stand. Bis auf der zweite src-Ordner, der
ein Versehen war.
Jetzt liegt es irgendwie bescheuert, da nich klar ist, für welches
FPGA-Design die Firmware gedacht ist.
Gruß,
Stefan
Hallo (Martin)
>Was du bemängelst (und misst) ist das typische Antialiasing das bei>allen DSO's auftritt. Es ist dem Anwender überlassen die richtige>Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit>einer möglichst hohen sample-rate beginnen und runtergehen bis das>Signal richtig dargestellt wird).
Habe mal einen Freund gebeten, ein 1kHz Signal mit seinem
Agilent Infiniium 54831B, 4Kanal, 600Mhz, 4Gsa
aufzunehmen...
Schaut schon viel besser aus!
Bilder : links oben mit 200us/div bis rechts unten mit 500ms/div
Vermutlich schaut das durch den grösseren Speicher besser aus?!
Versuch gerade das mit der Abtastrate und dem Speicher zu verstehen...
Stimmen da meine Rechnungen?
Bei 1ms/div = 250kSa/s -> = 12ms pro Bild würde ich auf 3000 Samples
kommen?
Bei 200us/div = 1MSA/s -> = 2,4mS pro Bild --> 2400 Samples?
Hat das Welec DSO nicht 16KB/ Kanal?
(oder denke ich da irgendwie falsch?)
l.G. Roberto
Hallo Roberto,
Ist etwas unfair einen Rolls Royce mit einem Fiat zu vergleichen!
Aber zu deiner frage:
Die Darstellung hangt von der Samplerate ab, beim Welec (das uebrigens
nur 4KB Samplespeicher hat) ist die bei 500ms/div nur
500Samples/Sekunde, bei dieser Samplerate kann ein 1kHz Signal
natuerlich nicht mehr richtig dargestellt werden (niquist sagt das die
sample rate mindestens doppelt so hoch sein muss wie die hoechste
Eingangsfrequenz, und ein Rechtecksignal enthaelt nicht nur die 1kHz
sondern auch oberwellen). Das Agilent hat 2MB Samplespeicher und kann
daher bei 500ms/div mit 400kSamples/Sekunde samplen!
Martin
Niklas O. schrieb:
> Hallo,
...
> @Falk:> Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?> Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle> Angabe jeder Datei findet.
Ich hatte einfach "diff" benutzt und manuell nacheditiert. Mit svn
brauchen wir das ja nicht mehr.
Ich habe übrigens den PC-Teil nach
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/
hochgeladen und ihn Version 0.4 genannt.
Falk
@Roberto
Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe
hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben
schon mal im Zusammenhang mit Aliasing erklärt. Die genauen
Zusammenhänge entnimmst Du der Timebasetabelle in den Programming Maps,
die Du hier findest:
http://groups.google.com/group/welec-dso/files
Hayo
Hayo W. schrieb:
> Sag mal Falk,>> wie machst Du eigentlich diese schicken Bilder? Hast Du da ein> Datenauswertungsprogramm das Diagramme erstellt?
Ja: http://kst.kde.org/
Damit mache ich die meisten Auswertungen von geloggten Daten.
Falk
Falk Willberg schrieb:
> Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer> die 16KB auszulesen.
Kommt drauf an was man damit machen will. Für die Rekonstruktion das
Bildschirmbildes reicht weniger. Um selbiges zu rekonstruieren muß man
verschiedene Parameter kennen:
- mit welchem Offset beginnt das aktuelle Memory Window
- welcher Faktor wird verwendet (Timebasetabelle)
Bsp.: der Offset liegt bei 400, mit dem Faktor 5.
Dann müßte die Übertragung beginnend beim 400sten Wert jeden 5. Wert
übertragen und zwar so viele wie das Grid breit ist (600 char Werte)
D.h. ausgewertet wird der Bereich von 400 - 3400
Ein Sonderfall sind die Ultra Slow Time-Bases, und die interpolierten TB
da die Daten hier in separaten Speicherbereichen abgelegt sind und auch
ohne Offset mit Faktor 1 ausgewertet werden.
Gruß Hayo
Hallo,
@Stefan:
tut mir Leid, das mit Deiner Namensgebung erschlieszt sich mir
erst jetzt mit Deiner Erklaerung. Wobei das irgendwie auch
bloed ist, dass da sowohl C Code fuer den Nios Softcore und
VHDL vermischt liegt. Koennte man (wenn man nicht wuesste
dass Welec das Design nicht hergeben will/kann wegen fremder
IP) auch so intepretieren, dass fpga/welec/improved das
verbesserte Design enthaelt. Der Pfad sagt ja nicht aus,
ob es sich da um Softcore Code oder VHDL-Design handelt.
"Firmware" erschien mir da logischer, ohne natuerlich wie
Du schon richtig klarstellst zu beachten, dass es ja
parallel eine zweite Entwicklungslinie gibt.
Ich stelle mal die Frage in den Raum was man da tun sollte.
Da die importierte 0.82 Deine (@Stefan) Aenderungen enthaelt
kann fpga/firmware/ jetzt als aktuell angesehen werden. doc/
und tools/ von fpga/welec/improved/ kann noch uebernommen
werden oder, vllt. besser, die PDFs koennten (wenn nicht schon
getan) im Wiki verlinkt werden.
@Falk:
[PC-Teil]
Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
Conditionals ungefragt neu eingerueckt habe, da sich
die Ebenen fuer mich einfach nicht mehr entschlossen.
Was ich noch einbauen wollte war die -l Loop Funktion,
angeregt durch das Standard-Verhalten der Windows-Versionen
von Kurt, wo automatisch eine neue Datei mit aufsteigender
Nummerierung erzeugt wurde. Zudem noch eine kurze
deutschsprachige Anleitung. Dann kann Hayo den Sourcecode
und die Windows-.EXE ja vllt. kuenftig in seinen Releases
direkt mitfuehren.
kst ist btw. sieht ja wirklich schick aus, muss ich auch
mal ausprobieren. Ich haette jetzt einfach das diesbzgl.
unhandlichere gnuplot hergenommen.
Niklas
Niklas O. schrieb:
> Hallo,
...
> @Falk:> [PC-Teil]> Hab' ich gestern noch gesehen und schon etwas rumgefummelt.> Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.> Conditionals ungefragt neu eingerueckt habe, da sich> die Ebenen fuer mich einfach nicht mehr entschlossen.
Kein Problem. Schön, daß Du die Fehlerbehandlung eingebaut hast.
Ich sollte vielleicht aufhören, nach dem Motto zu verfahren "wenn es
kompiliert, gib's frei, wenn es nicht läuft, versuche -Wall" ;-)
Falk,
derzeit Sope-los...
@Niklas
Da die ganze Versionsgeschichte hier im Augenblick etwas unübersichtlich
ist eine schnelle Frage:
Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten
gepatchten Stand, korrekt?
D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch
korrekt?
Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.
Zur Windows .exe - klar, die kann ich mit ins Release-Package tun.
Gruß Hayo
@Sunny
ich hatte auch solches Problem bei Kompilieren unter Windows. Das
Problem war nur falsche cygwin version. Ganze Quartus zu installieren
ist ja mühsam nur für richtige cygwin version zum kriegen.
Als Anhang ist abgespeckte cygwin von Quartus II 41sp2 und registry
patch
Gruß Ben
Hallo Hayo,
> Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten> gepatchten Stand, korrekt?
Ja, genau.
Ganz konkret ist's:
BlueFlash_Build_0_62.zip
+ FW1.2.BF.0.82_beta.zip
+ FW1.2.BF.0.82_beta-dl3daz.diff
(aus Beitrag "Screendumps" )
- *~ (vi (u.a.) Backup Files), obj/,
WelecUpdater (ist woanders im SVN), usw.
(GERMSloader.pl ist jedoch drin, kann Hannes entscheiden
ob er das im SVN verwalten will, woanders hinschieben usw..
Bzgl. der WelecUpdater.exe: Die sollte in den Files/Releases
Bereich, da sie ja aus den Sourcen erzeugt werden kann und
statisch ist. Gleiches fuer die Windows Screenshot.exe.
Oder wir sparen das und wir tun sie allein in die
Firmware-Releases.)
> D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen,> auch korrekt?
Ja, genau.
Niklas
Da die Screenshot.exe unter Umständen (so wie jetzt) nur zu dem
jeweiligen Release passen, ist es eigentlich keine schlechte Idee sie
mit ins Paket zu tun, dann gibts keinen Frust wegen inkompatibler
Versionen.
Hayo
@Falk & Niklas
Wenn ich das so richtig mitverfolge, ist ja auch ein reiner
Datendownload in Arbeit.
Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software
zurückzugreifen und das Datenformat auf DSO-Seite entsprechend
anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal
erfinden müßte. Ich denke da sowohl an Open Source Programme für
verschiedene andere DSOs als auch evtl. Programme von den
DSO-Herstellern, sofern das Datenformat bekannt ist.
Wie ist denn da Eure Meinung?
Bzw. @all
Wer kennt denn evtl. entspechende Programme?
Hayo
Hallo Hayo,
>D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch>korrekt?>Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.
...und was ist mit dem XY-Grid - Patch? War nach der 0.82!
Oder hab ich etwa eine Beta verpasst?
Gruß
Jürgen
Mal eine Frage an die Experten:
Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,
kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?
Ich denke, wir sollten die gigantischen Monolithen sinnvoll in möglichst
kleine Files aufteilen. Ich würde das übernehmen, wenn ich damit nicht
hintenherum etwas anderes umwerfe...
@Niklas:
was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
Beim kompilieren werden die nicht angefasst...
@Hayo:
Ich halte es für eine gute Idee, das Datenformat für die
PC-Kommunikation von einem anderen Scope zu kopieren, wenn es dafür
ordentliche Software gibt, die auch unter Linux läuft.
Ich habe nur keine Idee, welches geeignet sein könnte.
Falk
@Jürgen
der XY-Grid Patch ist in der 0.83, die aber noch nicht released ist, da
die neu aufgesetzte FFT noch unfertig ist. Mir ging es darum die
gepatchte 0.82 mit meiner 0.83 abzugleichen bevor ich die jetzt zum
Wochenende raushaue. Vielleicht sollte ich mit dem Abgleich auch noch
bis zum Schluß warten falls noch Patches dazukommen.
Gruß Hayo
@Falk
Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,
d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen
Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es
ein heilloses durcheinander von Versionen, die nicht zueinander passen.
Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt
machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt
ist.
Hayo
Moin moin,
melde mich von der ersten Klausur des Semesters erfolgreich zurück ;)
Bzgl. SVN: Ich hatte hier:
https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal
angefangen, die Struktur des Repositories zu dokumentieren. Ist nicht
ganz aktuell wie ich gerade sehe, aber vll könnt ihr euch auch dran
halten bzw. eure Zweige dort grob benennen. Die Struktur könnte noch
optimiert werden, da es ja mittlerweile euren Branch gibt der auf dem
NIOS basiert und auch noch den Kram von Slog, wobei ich bezweifle, dass
da mal wieder was passiert... Ach ja, und die Originalsourcen...
Was mir aufgefallen ist ist dass der ein oder andere Commit der letzten
Tage gut hätte zusammengefasst werden können, statt pro Datei ein
Changeset zu machen. Man kann also durchaus mehrere Dateien in einem
Rutsch (und mit einer gemeinsamen Lognachricht) einchecken. Aber ich
glaube das habt ihr nun auch bemerkt ;)
Was die Sache mit dem src/src/ Ordner angeht: Wenn ich die Logs richtig
im Kopf habe, sollte das ne "Branch" zum Entwickeln werden. Dazu
vielleicht noch ein paar Worte:
1) Wenns geht, würde ich persönlich das Branch&merge gebastel bei SVN
lieber vermeiden. Hab schon diversen Kram mit SVNs versioniert und bin
auch bei größeren Gruppen nicht in die Verlegenheit gekommen, sowas zu
machen. Aber wenn's jemanden gibt, der das Merging am Ende voll drauf
hat, nur zu ;)
2) SVN unterscheidet nicht zwischen Branching, Tagging und Kopieren.
Alles geschieht mittels svn copy, also sowohl release-tags anlegen als
auch branching ist letztlich nix anderes als ne Kopie. Wobei
Serverseitig natürlich nix dupliziert wird, solange es keine Änderungen
gibt. Das mal im Hinterkopf behalten, wenn gebranched wird. Es empfielt
sich also, eine Struktur anzulegen, wie man das in vielen öffentlichen
SVN sieht, also "branches/ tags/ trunk/"-Ordner, wobei Trunk natürlich
der Hauptentwicklungszweig ist.
Da wir hier mehrere parallele Projekte in einem Repo haben, sollte jedes
Unterprojekt in seinem Unterprojekt-Ordner sowas anlegen.
3) ... hab ich gerade vergessen. Naja Vortrag beendet ;)
LG
Hayo W. schrieb:
> @Falk>> Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,> d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen> Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es> ein heilloses durcheinander von Versionen, die nicht zueinander passen.>> Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt> machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt> ist.
Ok, ist das sinnvollste.
Siehe auch Daniels Beitrag.
Falk
Hallo,
@Falk:
> was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?> Beim kompilieren werden die nicht angefasst...
Die stammen offensichtlich aus dem 0.62. fft/ habe ich glatt
uebersehen und ist dann wohl die alte FFT Implementation aus
der 1.2. Beides kann dann weg.
> Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,> kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?
Kann es, ja, in der Regel geht das aber gut wenn nicht gerade genau
dieselbe Stelle im Code von beiden Bearbeitern modifiziert wird.
Wenn die Software das Problem nicht selbst loesen kann (Im Falle
von "Bearbeiter haben an verschiedenen auseinander liegenden Stellen
was geaendert" kann sie das) wird der commit verweigert und man
muss selbst Hand anlegen. Wie das bei SVN konkret ablaeuft kann ich
Dir jetzt allerdings nicht sagen.
Ich stimme Dir zu dass die Dateien teilweise wirklich gigantische
Ausmasze haben und unuebersichtlich sind. Vom Standpunkt der
Revisionsverwaltung muss das aber nicht unbedingt zu schweren
Kollisionen fuehren wie gerade gesagt. Ich wuerde Deinem Vorhaben,
da aufzuraeumen voll zustimmen. Da gerade Hayo aber schon an
0.83 dran war waere es aber sinnvoll, dass Hayo nen Diff zieht
und wir (oder er) das direkt einspielen und Du erst dann aufteilst,
so dass Hayo da spaeter nicht ein groszes Chaos hat.
@Hayo:
> Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software> zurückzugreifen und das Datenformat auf DSO-Seite entsprechend> anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal> erfinden müßte. Ich denke da sowohl an Open Source Programme für> verschiedene andere DSOs als auch evtl. Programme von den> DSO-Herstellern, sofern das Datenformat bekannt ist.
Das sehe ich genau wie Falk und Du auch. Ich hatte auch schonmal
nach Ausgabeformaten gefragt, leider kam diesbzgl. kein Vorschlag,
ist vllt. auch unter gegangen in der Fuelle von Posts.
Leider kenne ich keine anderen DSOs bzw. Programme dazu. Jeden
Hinweis und Dokumentation gehe ich da gerne nach.
Leider komme ich im Moment zeitlich noch nicht dazu die von mir
angepeilten Dinge (Auto-Setup/Kalibrierung, -l in Screenshot
Programm, usw.) zu realisieren. Wir haben aber ohnehin genug
Baustellen. Wie sieht es btw. da nochmal mit einer immer aktuell
gehaltenen Liste "wer arbeitet gerade woran" aus? SF Wiki
waere da nun die praedestinierte Stelle.
(btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
in einer vorhanderen Unterseite eine neue Seite verlinken.
Kann man das der Software irgendwie abgewoehnen?)
Update/Edit: Hab' den Satz in Klammern bzgl. Kollisionen mal
ausgeweitet damit klar wird, dass ich dort den automatisch
loesbaren Fall meinte.
Niklas
@Niklas
Der FFT Ordner stammt von mir. Da hatte ich mir mal einige
Beispielsourcen reinkopiert und dann den Ordner vergessen zu löschen -
kann also weg.
Ich hatte mal in der SFN Roadmap einige Entwicklungen eingetragen.
Aktueller wärs natürlich wenn jeder seine momentanen Sachen selber
einpflegt.
Hayo
Niklas O. schrieb:
> (btw: Irgendwie ist das ziemlich unpraktisch, wenn nur Admins> die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt> in einer vorhanderen Unterseite eine neue Seite verlinken.> Kann man das der Software irgendwie abgewoehnen?)
Kann man, möchte ich aber nicht. Öfter mal bei letzten Projekt scheinbar
automatisierten Frontpage-Vandalismus gehabt, deswegen die alte
Gewohnheit, die Seite auf Read-Only zu sitzen. Wenn du mir dein Handle
sagst, kannste gern die entsprechenden Bearbeitungsrechte bekommen.
Wär vll ne gute Gelegenheit, erstmal die Developer-Tabelle im Wiki zu
aktualisieren, damit der Überblick erhalten bleibt ;)
Hallo,
@Hayo:
Roadmap habe ich gefunden :)
@Daniel:
Merke gerade auch, dass ich manche andere Seiten
auch nicht editieren kann (Developers, ...).
Mein Handle entspricht meinem vollen Namen.
Die Rechte beim Trac Wiki hab' ich noch nicht ganz
verstanden. Kann man es so machen, dass alle
eingetragenen und aktiven Developer/Members
(die ja ohnehin manuell von einem Admin hinzugefuegt
werden muesen und damit "geprueft" sind) entsprechende
Rechte bekommen? Im Repository konnte ich direkt
ohne weiteres "rumfuschen", btw..
Abgesehen davon, geht das nur mir so oder ist
das Webinterface bei SF irgendwie ziemlich lahm?
(hab' diverse Firefox Plugins (Ad-Blocker, NoScript, ...)
die das bei mir ausbremsen koennten, daher frage ich mal)
Niklas
Hayo W. schrieb:
> SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise> mußte ich pro Seitenaufbau 10s - 20s warten.
Ist hier auch so...
Einerseits gab es mehrere Angebote, einen eigenen Server aufzusetzen,
andererseits gefällt mir, daß es nicht so viele verschiedene Orte gibt,
an denen das Thema bearbeitet wird.
Noch was: Wie wäre es mit Unterverzeichnissen .../FW1.2.BF.0.82/
../FW1.2.BF.0.84/ etc?
Falk
@Niklas: Rechte gesetzt.
@Antwortzeit SF: Das schwankt bei mir stark, ist aber im Mittel gerade
noch erträglich. Aber der Server bei SF ist unabhängig. Im letzten
Projekt war plötzlich der Mensch mit dem Server nicht mehr erreichbar,
nachdem kurz vorher alle Daten weg waren und plötzlich kein Backup
existierte. Ob er sich geschämt hat?
@Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter
trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release
herausgebracht wird, ist der erste Schritt, trunk/* nach
tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das
dient ausschließlich der Konservierung von definierten Ständen. Falls
ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das
erledigen, ohne dass History verloren geht.
Daniel H. schrieb:
...
> @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter> trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release> herausgebracht wird, ist der erste Schritt, trunk/* nach> tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das> dient ausschließlich der Konservierung von definierten Ständen. Falls> ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das> erledigen, ohne dass History verloren geht.
Ich sehe schon, ich werde mich mal näher mit SVN beschäftigen müssen.
Da ich derzeit kein Scope habe und anderes zu tun ist, halte ich mich
aus der Software ein paar Tage lang heraus.
Falk
@xCometz
danke für deine hilfe. leider hat es mich nicht weiter gebracht.
ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin
folgenden fehler
# 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I
./inc -I .
./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32
-D_Debug_
src/TomCat.cpp -o obj/TomCat.cpp.o
Assembler messages:
for reading.open
: No such file or directory
make: *** [obj/TomCat.cpp.o] Error 1
das einspielen deiner cygwin version hat da auch nichts daran geändert.
trotzdem danke.
gruß sunny
sunny schrieb:
> @xCometz> danke für deine hilfe. leider hat es mich nicht weiter gebracht.> ich hatte zuvor selber schon etwas rumprobiert und bekahm daraufhin> folgenden fehler> # 2009.07.09.19:41:22 --- Compiling nios-elf-gcc -I ./inc -I ./src -I> ./inc -I .> ./inc -I ../../inc -I ../../../inc -W -g2 -c -O2 -mno-zero-extend -m32> -D_Debug_> src/TomCat.cpp -o obj/TomCat.cpp.o> Assembler messages:> for reading.open> : No such file or directory
Mhhh, irgendwie hätte ich da mehr als ":" erwartet....
Kannst Du mal
hi falk
der gcc sagt folgendes
Reading specs from
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-l
ib/nios-elf/2.9-nios-010801-20030718/specs
gcc version 2.9-nios-010801-20030718
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/cpp.exe -lang-c++ -v -I ./inc -I ./src -I ./inc -I
../inc -I
../../inc -I ../../../inc -iprefix
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/
bin/../lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/ -D__GNUC__=2
-D__GNUG__=2
-D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios)
-D__EXCEP
TIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp
/cygdrive/c/DO
KUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
GNU CPP version 2.9-nios-010801-20030718 (cpplib)
(nios)
ignoring nonexistent directory `../inc'
ignoring nonexistent directory `../../inc'
ignoring nonexistent directory `../../../inc'
ignoring nonexistent directory
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/inc
lude/g++-3'
ignoring nonexistent directory
`/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nio
s-elf/sys-include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/include/g++-3'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/lib/gcc-lib/nios-elf/2.9-nios-010801-20030718/include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/sys-include'
ignoring nonexistent directory
`C:/nios_gnu_win32/nios_gnupro_win32_20030718_104
128/nios-gnupro/nios-elf/include'
#include "..." search starts here:
#include <...> search starts here:
inc
src
inc
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/lib/gcc-lib/nios-elf/2.9-ni
os-0108
01-20030718/include
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/nios-elf/include
End of search list.
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/cc1plus.exe
/cygdrive/c/DOKUME~1/op/LOKALE~1/Temp/ccMyr3vG.ii
-quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o
/cygdri
ve/c/DOKUME~1/op/LOKALE~1/Temp/ccaKz1Xj.s
GNU C++ version 2.9-nios-010801-20030718 (nios-elf) compiled by GNU C
version 2.
9-cygwin-990830.
/cygdrive/c/altera/kits/nios/bin/nios-gnupro/bin/../lib/gcc-lib/nios-elf
/2.9-ni
os-010801-20030718/../../../../nios-elf/bin/as.exe
Assembler messages:
for reading.open
: No such file or directory
ich glaub aber das führt jetzt hier zu weit. ich dachte es ist nur
irgend ein kleines problem. wenn es unter windows nicht geht ist es auch
noch so. ich kann ja immer noch meinen satreciever misbrauchen. auf
meinem laptop will ich mir kein linux installieren. es reicht mir schon
wenn ich mich bei meinem reciever mit diesem linuxmist rumärgern muß.
auf jeden fall danke für eure hilfe.
gruß sunny
@Sunny
Wie viele cygwin hast du im deinem PC? Bist du sicher dass du auf die
richtige cygwin gelaufen hast?
Es sieht wie falsche cygwin version aus wahrscheinlich einen falsche
path search.
Schau mal den Anhang
Gruß, Ben
Ich habe den Eindruck, das SVN ist schwieriger zu verstehen als die
Welec Firmware?
@Robert,
danke für das Angebot. Aber die Platine ist schon geätzt und bestückt.
Es wird aber bestimmt einen zweiten Prototypen geben...
Der Vinculum läuft auch schon einigermaßen. Jetzt muss ich mich etwas
näher mit dem Befehlssatzt beschäftigen. Sobald die Kommunikation läuft,
werden aus dem Schaltplan die letzten Fehler beseitigt und ich laden ihn
hier hoch.
Ein erstes kleines Beispieprojekt wird es dann auch geben.
PS:
Später ist auch eine RTC geplant damit die Dateien ein vernünftiges
Datum und eine Uhrzeit haben.
@xCometz
ich habe jetzt 2 cygwin auf meinem pc. einmal das was bei quartus mit
dabei war und dann das von dir.
ich hab es jetzt aber hin bekommen. es funktioniert nur wenn ich zuerst
cygwin starte, dann in der cygwin konsole in mein build verzeichniss
wechsle und make starte.
danke noch mal
gruß sunny
Kurze Info für die Screenshot-Spezis.
Im Rahmen einer Fehlersuche habe ich mal schnell eine Colordemo
gebastelt. hier zu sehen sind alle angezeigten Planes (13 Stück,
UI-Plane 2 ist schwarz). Die Memory-Planes werden in der Tat nicht
angezeigt, ebenso wie die Buffer-Planes.
Leider sieht man den Fehler den ich gesucht habe hier nicht. Dafür muß
man kurz aus dem nächsten Beitrag...
...die TomCat.ram laden. Dann Sieht man den Fehler deutlich. Und zwar
hat die UI-Plane 1 eine Macke (hatte Guido ja auch schon vermutet). Die
gesamte Plane ist um 32 Pixel nach rechts verschoben, was dazu führt,
dass die ersten 32 Pixel nicht gezeichnet werden, aber dafür die letzten
32 Pixel auf der rechten Seite durchgeschoben werden und um eine Zeile
nach unten verschoben auf der linken Seite wieder rauskommen.
Daher auch die komischen Linien bei dem ganz linken Funktions-Button.
Hayo
Nachtrag:
Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA
liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem
nicht haben??
Hayo
Hayo W. schrieb:
> Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA> liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem> nicht haben??
Ich sehe keinen Grund, warum diese Plane-Geschichte in HW realisiert
sein sollte... Das würde ja bedeuten, dass es sozusagen für jede Plane
einen Framebuffern gäbe, also in getrennten Speicherbereichen? Ich hätte
jetzt vermutet dass die in Software zusammengeführt werden, habe aber
noch nicht in den Source geschaut.
Wo steckt denn überhaupt der Framebuffer? Im SRAM oder im FPGA-Blockram?
Kann man das evtl. an der Adressaufteilung sehen?
In der Firmware konnte ich den Fehler bislang noch nicht lokalisieren,
in dem Bereich ist das Coding auch ziemlich unübersichtlich.
Kann gut sein, dass es auch eine reine Softwaresache ist. ich bin noch
nicht dazu gekommen zu prüfen ob das Problem auch bei der originalen
FW1.4 auftritt.
Wenn nicht, wäre die Frage geklärt.
Hayo
Hallo,
nö, ich glaube nicht, dass das von der Firmware kommt. Hab da ja schon
mal länger rumprobiert inkl. Neuschreiben von DrawRoundButton und
PixelP.
@ Hayo: Wenn es eine Verschiebung wäre, ließe sie sich leicht
korrigieren. Die 8, 16 und 32 Bit, waren es, wenn ich mich recht
entsinne, aber nicht. Mein Verdacht war eher, dass im VHDL-Code
zwei Adressbits für den Framebuffer vertauscht sind. Das war das
letzte womit ich rumprobiert habe, denn auch das müsste man
korrigieren können.
Gru0ß, Guido
So, für alle die um diese Urzeit auch noch vor dem Rechner sitzen ein
kurzer Zwischenstand in Sachen FFT-Redesign.
Anzubieten hätte ich diese Version...
...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?
Die Cursorfunktion geht natürlich bei beiden.
Hat jemand Verbesserungsvorschläge oder eine Idee welche Daten z.B. im
Bereich Magnitude noch von Interesse wären?
Gruß
Hayo
Hallo Hayo,
mir gefällt die zweite Version deutlich besser, nicht nur weil
sie auch mit übermüdeten Augen noch ablesbar ist ;-), auch das
Grid wirkt harmonischer.
Magnitude in dBm ist zu ehrgeizig, da der Abschluss ja nicht
gewährleistet ist. Besser db mit Bezugspunkt. Wenn aber Mag in
dB oder dBm angegeben ist, sollte Delta-Y nicht in mV sein.
Ich hoffe doch sehr, demnächst auch mal wieder einen Beitrag
leisten zu können, aber es geht wirklich super voran.
Gruß, Guido
Hayo W. schrieb:
> ...oder diese. Welche erregt denn bei Euch mehr Wohlwollen?
^^^^^^
Diese (#2) erregt ähm, also, genau: mein Wohlwollen ;-)
> Die Cursorfunktion geht natürlich bei beiden.
Applaus!
Falk
Also ich finde die untere vorallem wegen der Lesbarkeit besser. Koennte
man denn auch beide kombinieren ?? Also obere Version mit den Farben der
unteren.
Ich finde das Subtile der schwarzen Version eigentlich auch nicht uebel
aber das gelb halte ich fuer praktischer. Form follows function... ;)
Die Skalierung ist noch nicht ganz fertig. Das untere Bild zeigt aber
schon die korrekten Cursorwerte in Volt. Die Anzeige im Abschnitt
Magnitude ist nur eine statische Zeile für Testzwecke.
So jetzt jetzt haben wir schon zwei Meinungen und natürlich genau
gegensätzlich.
Meine Meinung dazu ist noch etwas schwankend. Die Anzeige im ersten Bild
ist etwas technischer gehalten und hat den Vorteil, dass sie in der
Helligkeit mit dem Grid zusammen verstellt werden kann. Die zweite
Version ist dafür etwas angenehmer abzulesen, weil die schwarze Schrift
auf dem hellen Untergrund mehr Kontrast bietet.
Nicht einfach zu entscheiden.
Gruß
Hayo
Hallo Hayo,
beide Versionen sehen echt gut aus! Top Arbeit.
Die Erste ist etwas unaufdringlicher, die Schrift etwas schwer zu lesen-
das mag im Original natürlich besser sein. Die zweite Vers. ist dafür
einheitlicher. Würde eher zur Version 2 tendieren.
Was noch an Info dazu sollte bzw. kann?
Evtl. mal bei den renommierten Herstellern nachsehen, so spontan fällt
mir nichts ein.
Gruß, brunowe
Ja mir fiel so spontan auch nichts mehr ein. Sonst lasse ich das erst
mal frei, da kommen bestimmt noch Vorschläge.
Angeregt durch Deine Kommentare und die LeCroy Broschüre habe ich auch
die FFT-Modi etwas aufgebohrt. Wir wollen ja schließlich nicht hinter
LeCroy zurückstehen... ;-)
Hayo
Sehr schoen, ich warte schon gespannt auf den naechsten Release und
werde dann gruendlich Testen. Jedenfalls wenn ich bin dahin alle meine
Pruefungen geschrieben habe. ;)
Hallo,
ja Hayo du hast recht, wir sollten uns an der Spitze orientieren.
Wenn das nicht klappt, verfahren wir getreu dem Wahlspruch:
WO WIR SIND IST VORN...
UND WENN WIR EINMAL HINTEN SIND, DANN IST HINTEN VORN!
Gruß, brunowe
Es kommt wie es kommen muß:
Ich habe beide Varianten dringelassen. Default ist die Variante 2. Über
Shift + X kann die Variante 1 ein und ausgeschaltet werden. So kann sich
jeder selbst eine Meinung bilden und das dann entsprechend einstellen.
Hayo
Hier schon mal der vorläufige Schaltplan des Vinculum Boards.
Über eine 3MBaud UART Verbindung zum Vinculum kann man mit ca.
112kByte/s auf den Stick schreiben. Getestet vom PC aus.
Allerdings soll später der parallele FIFO zum Einsatz kommen.
PS: LED3 und LED4 sind natürlich falschrum drin.
Hallo Kurt,
Ich habe mir deinen Schaltplan angeschaut, und habe zwei kleine
Anmerkungen:
1. Die last C's des 12MHz Quatz sollten 68pF sein (meiner Erfahrung nach
ist der VNC1L hier recht empfiendlich).
2. Wenn du den FIFO mode nutzen willst ist es von Vorteil auch den PIN
45 (DATAREQ# in FIFO und SPI mode) von der CPU aus steuern zu koennen.
Martin
Muss es eigentlich sein, dass der Trigger automatisch auf einen anderen
Kanal gelegt wird, wenn der momentan den Trigger führende Kanal
deaktiviert wird ? Ich finde das mehr als unpraktisch denn:
- es kommt vor, dass man auf einen Kanal triggern, diesen aber zwecks
Übersichtlichkeit nicht permanent darstellen möchte. Der kleine
Bildschirm ist schon so voll genug :\
- triggert man auf Kanal 1 mit einer hohen Impulsfolge und womöglich mit
einem hohen Signalpegel, sieht man von den anderen Kanälen nahezu nichts
mehr, da das Gelb doch sehr dominant ist. Schaltet man nun Kanal 1 kurz
aus, um sich einen Eindruck von den anderen Signalen zu verschaffen, ist
sofort der Trigger flöten und man steht erst mal im Regen; bzw. fummelt
wieder am Trigger rum bis es passt.
Da die Triggermarke, bedingt durch die farbliche Darstellung am Rand,
die Triggerquelle auch dann eindeutig anzeigt, wenn der Kanal
deaktiviert ist, empfinde ich die Zwangsumschaltung als sehr lästig.
Evtl. geht es ja dem einen oder anderen auch so...
Stefan
Hallo,
echt toll was ihr da Entwickelt.
Was mir noch fehlt ist das Umschalten des Sampleverhalten.
D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann
gleich auf die benötigte Samplerate heruntergerechnet.
Professionelle Oszis können da:
Peak (min und max der ADs wärend eines Erfassungstaktes)
HiRes (Mittelwert der ADs wärend eines Erfassungstaktes)
Sample (Nur 1. Wert der ADs wärend eines Erfassungstaktes) so ist es
jetzt immer
Average (HiRes und Mittelwert über mehrere Triger)
Mfg Michael
Hallo Martin,
die Kondensatorgeschichte scheint sehr abhängig vom Quarz zu sein. Bei
mir läuft es mit 10pF ohne Probleme.
Ich werde trotzdem im Schaltplan den Wert auf 22pF oder 47pF erhöhen.
Wofür brauche ich denn den DATAREQ# Pin? Ich dachte mit dem schaltet man
nur zwischen Data und Command Mode um.
Kann aber auch angeschlossen werden. Der AVR hat noch genug Pins.
Mfg,
Kurt
Kurt,
Der Kondensator haengt sowohl von dem Quarz als auch von dem Treiber /
Eingang des IC's ab. Ich habe mit dem VNC1L boese Erfahrung gemacht, der
Prototyp lief mit einem zu kleine C ohne Probleme, aber in der Serie
hatte ich dann einige Baugruppen wo der Oszillator nicht immer an lief.
Was DATAREQ# betrifft hast du recht wenn du nur den Pendrive verwenden
willst ist er nicht noetig (wird fuer di Umschaltung von Kommandomodus
in einen reinen Datenmodus verwendet, zum Beispiel fuer die Verbindung
zu einem PC).
Martin
Michael schrieb:
> D.h. es wird immer mit der vollen Samplerate gemessen und im FPGA dann> gleich auf die benötigte Samplerate heruntergerechnet.
Nein. es wird nicht immer mit der vollen Samplerate gemessen, sondern
mit der angezeigten. Das weitere Herunterrechnen findet dann in der
Firmware statt.
Hayo
Ich habe die aktuelle Firmware und das Problem, dass sich -je nach
Messbereich- der negative Bereich der gemessenen Spannung verschiebt.
Mache ich da etwas falsch oder kann ich dem Scope nicht mehr trauen ?
Anbei zwei Bilder, es geht mir um Kanal 4 (Rot, Kanal steht auf DC)
Besteht evtl. die Möglichkeit, dass QuickMeassure im nächsten Update
gefixed wird? Die Wahl des QM-Kanals via Menü wird leider erst
übernommen, nachdem QM aus- und wieder eingeschaltet wurde.
Btw: QM läuft ganz prima - vielen Dank !
Hallo,
als frisch gebackener W2024A-Besitzer habe ich heute eure Firmware
0.82beta getestet und gleich eine Frage dazu. Ich habe den Abgleich von
ADC bzw. DAC nach Anleitung gemacht, komme aber was den Abgleich der
Nullinien angeht nicht zum gewünschten Ergebnis. Ich kann zwar den DAC
z.B. für 5V, 2V und 1V kalibrieren, wenn ich dann aber den 500mV Bereich
kalibriere verschiebt es den 5V Bereich wieder, bei 200mV den 2V u.s.w.
Was mache ich falsch?
>Die Wahl des QM-Kanals via Menü wird leider erst>übernommen, nachdem QM aus- und wieder eingeschaltet wurde.
Kann ich so leider nicht nachvollziehen. Bei mir klappt das alles
einwandfrei. Mit Ausnahme der weiter oben genannten funktionen.
Kannst du genauer beschreiben, was du nacheinander drückst und welche
Einstellungen du verwendest?
>Btw: QM läuft ganz prima - vielen Dank !
Danke für das Lob!
Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben. Ansonsten wird es
voraussichtlich erst wieder Mitte August Neuerungen von meiner Seite
geben.
Bis dahin wollen noch eine Reihe Klausuren bestanden werden und der
Computer braucht dann so Anfang August mal zwei Wochen Ruhe ;-)
Gruß,
Stefan
Andreas schrieb:
> Ist nicht Dein Ernst !?> Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem> Schwung. Aber Danke, das erklärt so manches.
Im Paket der Beta FW ist eine Beschreibung wie man den Abgleich in der
richtigen Reihenfolge macht.
Die DAC-Kalibrierung läuft getrennt für die 1er 2er und 5er Bereiche.
Hintergrund ist:
1. Ich wollte anfangs eine Möglichkeit haben das getrennt voneinander
durchzuführen um nicht schon gut kalibrierte Bereiche wieder zu
verschlechtern.
2. Die DAC-Kalibrierung ist als Ergänzung zu der ungenügenden original
Kalibrierung zu sehen.
2. Jetzt funktioniert das eigentlich so gut, dass man auch alle in einem
Durchgang kalibrieren könnte, hatte aber noch keine Zeit das zu
implementieren. Wurde auch schon von anderer Seite angefragt. Werde ich
mal mit den Prioritäten der anderen Baustellen abgleichen.
Für alle neu Dazugestoßenen - die original FW war leider so schlecht
geschrieben, dass es bei den anfänglich geringen Entwicklerkapazitäten
nur langsam voran ging. Ich bitte daher noch nicht so perfekt
funktionierende Bereiche zu entschuldigen. Dafür geht es jetzt bei der
starken Beteiligung hier erheblich zügiger voran.
Hayo
Hallo Hayo,
kannst du dir erklären, warum bei mir die bereits kalibrierten Kanäle
wieder verschoben werden, wenn ich andere kalibriere? Bin genau nach
Anleitung vorgegangen, bekomme aber Nullinien die bis zu mehreren DIVs
abweichen...
Du brauchst dich doch nicht zu entschuldigen :) Ich habe mir ueberhaupt
erst ein solches Scope gekauft als ich gesehen habe was ihr hier
veranstaltet. So einen Aufwand kann bei gott keiner erwarten und ich
moechte mich nochmal in aller Form bei euch fuer das bis jetzt
geleistete bedanken.
Ich werde nach den Pruefungen auch sehen wie ich zu dem Projekt
Beitragen kann. Leider hab ich noch 0 erfahrung mit Oszi-Programmierung,
aber vielleicht kann man ja etwas Learning by Doing betreiben :) Ich
schaue jedenfalls jeden Tag hier rein und fast immer wurde irgendwas
verbessert. Wirklich super !!!
Ohh! Nein das höre ich zum ersten Mal. Bei meinen Geräten klappt das
einwandfrei und auch die Anderen hier hatten das Problem nicht.
Du sagst ja, Du hast das nach Anleitung gemacht und vorher alle Eingänge
abgezogen oder kurzgeschlossen? Wenn nicht bekommt man nämlich genau
diesen Fehler. Am besten macht man erstmal den ADC-Abgleich, da der nur
einen relativen Vergleich der Pegel durchführt. Dann den originalen
Search Zeros und zum Schluß als Feinschliff den DAC-Abgleich.
Ach ja, ganz zu Anfang am Besten noch Default Setup, dann ist man auch
gleich in der günstigsten Timebase für den Abgleich.
Hayo
>Sollte sich tatsächlich noch ein Fehler in der Kanalwahl herausstellen,
werde ich versuchen den noch zu beheben.
Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal
wählen, den QM auswertet. Wählt man hier während der Messung einen
anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und
wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert
und dann wieder aktiviert.
Mist, ich hasse solche Sonderrollen....
Also,
- FW 0.82beta (compiliertes HEX-File aus dem Release-Archiv) liegt im
Flash
- Gerät ist warmgelaufen
- alle Probes sind abgezogen
Vorgehen:
- "Default Settings" im "Edge" Menü
=> alle Kanäle sind an und im 5V-Bereich
- einmal "Calibrate ADC"
- einmal "Search Zero Lines"
=> Abweichungen von max. 0,2DIV in den 5V-Bereichen
- "Calibrate DAC"
=> alles bestens im 5V Bereich
- alle Kanäle auf 2V
- "Calibrate DAC"
=> alles bestens im 2V Bereich
- alle Kanäle auf 1V
- "Calibrate DAC"
=> alles bestens im 1V Bereich
- Kontrolle
=> alles bestens in den Bereichen 1V, 2V und 5V
- selbes Vorgehen für 500mV, 200mV und 100mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis
ca. 1 DIV verschoben
- selbes Vorgehen für 50mV, 20mV und 10mV
=> Nullinien der Kanäle sind in den Bereichen 1V, 2V und 5V wieder bis >
8 DIV verschoben
Insgesamt sind die Verschiebungen auf Kanal 1+3 nur gering, auf Kanal 2
ausgeprägt und Kanal 4 ist nicht benutzbar (Abweichung > 6 DIV).
Habe ich ein Montagsgerät erwischt??
Stefan schrieb:
> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?> Einen Logic-Analyzer hab' ich zwar bereits, aber der ist PC-basiert und> oft möchte man einfach nur mal kurz einen Datenstrom verifizieren; da> würden die 2-4 Kanäle -je nach Protokoll- völlig ausreichen...
Ich hab' mir mal Gedanken gemacht:
https://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14
Falk, derzeit scopelos
>Also wenn QM aktiv ist, kann man ja im dazu gehörigen QM-Menü den Kanal>wählen, den QM auswertet. Wählt man hier während der Messung einen>anderen Kanal, arbeitet QM trotzdem weiter auf dem bisherigen und>wechselt auf die geänderte Einstellung erst, nachdem man QM deaktiviert>und dann wieder aktiviert.
Na ja. Du kannst ja unterschiedliche Kanäle gleichzeitig messen und
willst nicht für alle Messungen gleichzeitig den Kanal ändern. Ich
glaube,das was du meinst ist, dass du einen der drei Mess-Slots
auswählen und diesen dann geziehlt bearbeiten (Messfunktion, Kanal) oder
gezielt löschen willst.
Das wäre auch mein Wunsch an die GUI. Bis jetzt kann man nur alle drei
Slots gleichzeitig löschen. Um einen Kanal zu ändern kommt man nicht
drum rum alle zu löschen.
@ Odic X,
willkommen im Club ;-)
Ich mache den DAC-Abgleich nur für 5-, 2- und 1-V-Bereich, für
die kleineren stimmt er dann automatisch. Durch die höheren
Störpegel in den empfindlicheren Bereichen kann der Abgleich
wohl schon ins Schleudern kommen.
Also: erst Search-Zero (ev. mehrmals), dann ADC-Abgleich und
dann dreimal DAC-Abgleich.
Gruß, Guido
@Odic
Ahh, verstehe, Du wiederholst die Kalibrierung zig mal bis in alle
Unterdivisions. Das ist so nicht gedacht. Es gibt jeweils einen
Korrekturfaktor für alle 5er Bereiche, einen für alle 2er Bereiche und
einen für alle 1er Bereiche (also nur drei Korrekturfaktoren). Du mußt
also nur einmal für 5V, 2V und 1V kalibrieren, dann sollte es stimmen,
auch in den kleineren Spannungsbereichen.
Hayo
Funktioniert leider bei mir nicht. Wenn ich z.B. Kanal 4 im 5V-Bereich
perfekt abgeglichen habe, liegt die Nullinie im 500mV-Bereich 0,5 DIV
höher und im 50mV-Bereich 4 DIV höher.
Das ist so leider nicht zu gebrauchen....
So, ich habe das Ganze nochmal lediglich in den 1-5V Bereichen
durchgespielt. Bei den Kanälen 1 und 3 klappt es. Bei Kanal 2 kann man
mit der sich ergebenden Abweichung von 0,3 DIV notfalls leben. Nur bei
Kanal 4 funktioniert das Ganze leider überhaupt nicht:
5V: abgeglichen
500mV: +0,2 DIV
50mV: +1,8 DIV
2V: abgeglichen
200mV: +0,5 DIV
20mV: +4,6 DIV
1V: abgeglichen
100mV: +0,9 DIV
10mV: >+8 DIV
Wäre es in der Firmware viel Arbeit, die Korrekturwerte für jeden
Bereich einzeln ermitteln zu können?