Forum: Mikrocontroller und Digitale Elektronik Wittig(welec) DSO W20xxA Open Source Firmware


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kurt B. (kurt)


Lesenswert?

Die 0.82 läuft hier auf einem 2024A 8C7.C9 ohne Probleme.

von Stefan (Gast)


Lesenswert?

Ging ganz genau so, wie Hayo beschrieben hat. Man, was bin ich 
erleichtert :)

Btw: vielen Dank Euch allen, dass Ihr Euch so reinhängt !

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

@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

von Stefan (Gast)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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 ?

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

@Stefan,
gefällt es dir so besser?

/* Channel_Plane2 */  { 0x00, 0xFF, 0x00 }, /* green */
/* Channel_Plane3 */  { 0x18, 0x35, 0xc2 }, /* blue */

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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.

von Kurt B. (kurt)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

@Falk

Prima, einfach hier hochladen, ich baue das dann ein.

Gruß Hayo

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

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

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

Hier als bmp. Das hat schärfere Kanten.

von Niklas O. (nevm)


Lesenswert?

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

von Niklas O. (nevm)


Angehängte Dateien:

Lesenswert?

Hallo,

hier wie im letzten Post beschrieben die ZModem Routinen.
Sourcecode im Anhang, Header Inline:
1
#ifndef _zmodem_h_
2
#define _zmodem_h_
3
4
static void zm_send_hexhdr(int, char [4]);
5
static void zm_send_zdle(int);
6
static void zm_send_binhdr(int, char [4]);
7
static void zm_send_data(char, char *, int);
8
static int zm_get_hexhdr(void);
9
static int zm_get_binhdr(void);
10
static int zm_get_header(void);
11
static int rd_char(void);
12
void zm_test(void);
13
void zm_buf(int);
14
static int GETCH(void);
15
16
#endif

Niklas

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

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.

von Niklas O. (nevm)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Geht klar!

Hayo

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
  case 1: UART_NewData = 0;               //reset UART ISR flag
3
          if (UART_RXData == 'a' ) { lMenuKey = 0; }     // Acquire
4
  ....
5
  case 2: handle_remote_control(...)
6
  }
7
  UART_NewData=0

Ich würde das einbauen, wenn wir uns nicht gegenseitig dabei stören.

Gruß,
Falk

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Michael (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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:
1
char    charTOlMenuKey[]={
2
//  0x0  0x1  0x2  0x3  0x4  0x5  0x6  0x7  0x8  0x9  0xA  0xB  0xC  0xD  0xE  0xF
3
      -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1, -11, -12, -10,  -1,  -1,  -1,  -1,  -1,
4
//  0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F
5
      -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1, -11, -12, -10,  -1,  -1,  -1,  -1,  -1,
6
//  ' '  '!'  '"'  '#'  '$'  '%'  '&'  '''  '('  ')'  '*'  '+'  ','  '-'  '.'  '/'
7
      -2,  80,  81,  -1,  83,  84,  85,  -1,  87,  88,  -1,  -1,  69,  71,  70,  86,
8
//  '0'  '1'  '2'  '3'  '4'  '5'  '6'  '7'  '8'  '9'  ':'  ';'  '<'  '='  '>'  '?'
9
      39,  30,  31,  32,  33,  34,  35,  36,  37,  38,  68,  67,-127,  89,-127,-127,
10
//  '@'  'A'  'B'  'C'  'D'  'E'  'F'  'G'  'H'  'I'  'J'  'K'  'L'  'M'  'N'  'O'
11
     -1,  50,  64,  62,  52,  42,  53,  54,  55,  47,  56,  57,  58,  66,  65,  48,
12
//  'P'  'Q'  'R'  'S'  'T'  'U'  'V'  'W'  'X'  'Y'  'Z'  '['  '\'  ']'  '^'  '_'
13
     49,  40,  43,  51,  44,  46,  63,  41,  61,  60,  45,-127,-127,-127,-127,-127,
14
//  '`'  'a'  'b'  'c'  'd'  'e'  'f'  'g'  'h'  'i'  'j'  'k'  'l'  'm'  'n'  'o'
15
     -1,   0,  10,  16,   5,  14,   7,  23,  55,   1,   2,   3,   4,  13,  22,  26,
16
//  'p'  'q'  'r'  's'  't'  'u'  'v'  'w'  'x'  'y'  'z'  '{'  '|'  '}'  '~'  DEL
17
     15,  19,   9,   8,  12,   6,  21,  20,  27,  17,  29,  -1,  -1,  -1,  -1,  -1};
Spart fast 100 Zeilen Code.

Gruß,
Falk

von Stefan E. (stefan_e)


Lesenswert?

>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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Michael H. (stronzo83)


Lesenswert?

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

von Karl (Gast)


Lesenswert?

Man nehme einen 10:1 Tastkopf und gut. So machen es auch die Agilents. 
Man kann im Menü auswählen, was für eine Probe dran ist (auch A/div 
usw...)

von Cra Z. (crazor)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@Stefan

Nur kurz zur Abstimmung, ich habe die vertikalen Cursordaten korrigiert, 
so dass jetzt alle Spannungen korrekt angezeigt werden
-> void Display::CALCCURSORDATA(void)


Hayo

von Blue F. (blueflash)


Lesenswert?

@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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Die Diffs für die Firmware und screenshot-0.3 findet Ihr hier: 
https://sourceforge.net/apps/phpbb/welecw2000a/download/file.php?id=8

Das Bild ist aus "kst" mit dessen FFT. Statt kHz sollte das MHz 
heißen...

von Bernd O. (bitshifter)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Hmm, wahrscheinlich oute ich mich jetzt als Trottel, aber was ist SVN?

Das VN steht vermutlich für virtual network oder?

Gruß Hayo

von Michael W. (slackman)


Lesenswert?

SubVersioN, Versionsverwaltungstool, müsste unter Linux eigentlich 
installiert sein, unter Windows ist Tortoise momentan eine gute Wahl...

Michel

von Armin D. (ardiehl)


Lesenswert?


von Michael W. (slackman)


Lesenswert?


von Blue F. (blueflash)


Lesenswert?

Danke, ich mach mich da mal schlau und guck mal was sich machen läßt

Gruß Hayo

von Stefan E. (stefan_e)


Lesenswert?

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

von Günter J. (gjung)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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
1
+S80484AA00CD                                                 
2
beta firmware starting!                                       
3
                                                              
4
- Flash initialization                  - done                
5
2-Channels found Signatur : 98013000                          
6
Keyboard found                                                
7
Setup hardware                            - done
8
HW Version : 8c7  Channels : 2                                
9
Testing LEDs                                                  
10
Building trigonometric tables           - done                
11
Setup vars                              - done                
12
Setup vars to default values            - done                
13
Flash not loaded - setting standards                          
14
Read config from flash                     - done
15
Read protected config from flash        - done
16
Recalc vars                             - done
17
- Hardware initialization               - done
18
******************************************************************
19
calculating timebase...
20
timeoff = Timebase_Offset_Pos * tfactor  / 1000000
21
22
Timeoffset          = -0.000000300
23
Timebase_Offset_Pos = -300
24
tfactor             = 0.00000000100
25
******************************************************************
26
27
spurious interrupt number: .................

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

von Stefan (Gast)


Lesenswert?

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

von Robert S. (razer) Benutzerseite


Lesenswert?

@Stefan, Ich habe das gerade im Hardware Thread gepostet =)

von Stefan (Gast)


Lesenswert?

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.

von Roberto (Gast)


Lesenswert?

@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

von Martin H. (martinh)


Lesenswert?

@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

von Stefan E. (stefan_e)


Lesenswert?

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

von rowue (Gast)


Lesenswert?

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.

von rowue (Gast)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

Hat eigentlich noch keiner bemerkt, dass das XY-Grid nicht eingeblendet 
wird bei der 0.82?

Macht nichts ist schon gefixed.

Hayo

von Robert S. (razer) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Martin H. (martinh)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

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

von Stefan E. (stefan_e)


Lesenswert?

Hey,
trifft sich super. Mach mer doch gleich ne Session in Italien ;-)

Gruß,
Stefan

von Blue F. (blueflash)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Jürgen (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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.

von Niklas O. (nevm)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

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

von Odic (Gast)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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?

von Kurt B. (kurt)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Nein ich schau mal kurz rüber.

Hayo

von Blue F. (blueflash)


Lesenswert?

Ich kann da nichts finden, wo muß ich suchen?

Hayo

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Ist erledigt

Hayo

von Blue F. (blueflash)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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:
1
svn checkout https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/ improved

Jetzt finde ich in src/ die Sourcen, aber auch src/src und 
src/quickmeasure..

"make" in src/ übersetzt die "alten" Sourcen und faällt mit
1
src/hardware_t.cpp:427: invalid types `int[int]' for array subscript
 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

von Niklas O. (nevm)


Lesenswert?

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:
1
<0>[18:28]niklas@empire:/tmp/improved$ cat > src/newfile
2
Inhalt
3
<0>[18:28]niklas@empire:/tmp/improved$ svn add src/newfile 
4
A         src/newfile
5
<0>[18:28]niklas@empire:/tmp/improved$ svn diff
6
Index: src/newfile
7
===================================================================
8
--- src/newfile (revision 0)
9
+++ src/newfile (revision 0)
10
@@ -0,0 +1 @@
11
+Inhalt
12
<0>[18:28]niklas@empire:/tmp/improved$ svn status
13
A       src/newfile

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

von Stefan E. (stefan_e)


Lesenswert?

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.

von Robert S. (razer) Benutzerseite


Lesenswert?

@ Kurt: Falls du einen Prototyp bei LeitOn mach lassen willst, ich habe 
noch einen 10€ Gutschein. Den kannst du haben.

von sunny (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von sunny (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von sunny (Gast)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

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

von sunny (Gast)


Lesenswert?

>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

von Guido (Gast)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

Hallo nochmal,

@Falk:
Den selben Gedanken mit dem Header hattest Du schon sehe
ich erst jetzt gerade :)  Sorry.

Niklas

von Stefan E. (stefan_e)


Lesenswert?

>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

von Roberto (Gast)


Angehängte Dateien:

Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Falk W. (dl3daz) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hayo W. schrieb:
> @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.

Hatte ich nicht verstanden ;-)

Für die Dump-Funktion ist es auch nur wichtig, ob es sinnvoll ist, immer 
die 16KB auszulesen.

Mein letzter Dump ist hier zu finden: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/example.csv.gz

Was bei 500MS/s herauszuholen ist, sieht man hier: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/FFT-from-dump.png

Falk

von Blue F. (blueflash)


Lesenswert?

Sag mal Falk,

wie machst Du eigentlich diese schicken Bilder? Hast Du da ein 
Datenauswertungsprogramm das Diagramme erstellt?

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von xCometz (Gast)


Angehängte Dateien:

Lesenswert?

@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

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Jürgen (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Blue F. (blueflash)


Lesenswert?

@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

von Cra Z. (crazor)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@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

von Cra Z. (crazor)


Lesenswert?

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

von Niklas O. (nevm)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

SFN ist so lahm! Daher auch mein eher zögerlicher Zuspruch. Teilweise 
mußte ich pro Seitenaufbau 10s - 20s warten.

Hayo

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

http://svnbook.red-bean.com/

Edit: Die Antwortzeit von diesem Forum ist auch nicht kürzer als die bei 
SF.net ;)

von sunny (Gast)


Lesenswert?

@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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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
1
nios-elf-gcc -v -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

versuchen? Mit "-v" sagst Du dem gcc, daß er mal erzählen soll, was er 
wirklich treibt.

Hier (Linux) sieht das so aus:
1
Reading specs from /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/specs
2
gcc version 2.9-nios-010801-20030923
3
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cpp -lang-c++ -v -I ./inc -I ./src -I ./inc -I ../inc -I ../../inc -I ../../../inc -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=9 -D__cplusplus -D__nios__ -D__nios__ -Amachine(nios) -D__EXCEPTIONS -D__OPTIMIZE__ -g2 -W -D__nios32__ -D_Debug_ src/TomCat.cpp /tmp/ccI2Biu1.ii
4
GNU CPP version 2.9-nios-010801-20030923 (cpplib)
5
 (nios)
6
ignoring nonexistent directory `../inc'
7
ignoring nonexistent directory `../../inc'
8
ignoring nonexistent directory `../../../inc'
9
ignoring nonexistent directory `/opt/cdk4nios/nios-elf/sys-include'
10
ignoring duplicate directory `inc'
11
#include "..." search starts here:
12
#include <...> search starts here:
13
 inc
14
 src
15
 /opt/cdk4nios/include/g++-3
16
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/include
17
 /opt/cdk4nios/nios-elf/include
18
End of search list.
19
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/cc1plus /tmp/ccI2Biu1.ii -quiet -dumpbase TomCat.cc -mno-zero-extend -m32 -g2 -O2 -W -version -o /tmp/ccIHjI1U.s
20
GNU C++ version 2.9-nios-010801-20030923 (nios-elf) compiled by GNU C version 3.3.1 (Mandrake Linux 8.2 3.3.1-4mdk_slz).
21
 /opt/cdk4nios/lib/gcc-lib/nios-elf/2.9-nios-010801-20030923/../../../../nios-elf/bin/as -m32 -o obj/TomCat.cpp.o /tmp/ccIHjI1U.s

Falk
P.S.: Wie wär's mit Linux in einer VirtualBox oder eigenen Partition?

von sunny (Gast)


Lesenswert?

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

von xCometz (Gast)


Angehängte Dateien:

Lesenswert?

@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

von Kurt B. (kurt)


Lesenswert?

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.

von sunny (Gast)


Lesenswert?

@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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Cra Z. (crazor)


Lesenswert?

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?

von Blue F. (blueflash)


Lesenswert?

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

von Johannes S. (demofreak)


Lesenswert?

Du bist schuld! Bestimmt! :-P

duck

/Hannes

von Guido (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Ich hab jetzt erstmal in DrawRoundButton einen Workaround eingebaut, 
damit nicht die falsche Linie gezeichnet wird.

Hayo

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Johannes S. (demofreak)


Lesenswert?

DIe erste find ich hübscher. Hat es was zu sagen, dass da oben rechts 
Blackman und unten Rechteck steht?

/Hannes

von Blue F. (blueflash)


Lesenswert?

Einige Zeilen sind noch statisch um die Position richtig einzustellen, 
also keine Sorge...

Hayo

von Guido (Gast)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Alexis S. (seraptin)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Oh, in der Zwischenzeit gibt es doch noch mehr Meinungen. Tendenz 
Richtung Version 2 wie ich feststelle.

Hayo

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Blue F. (blueflash)


Angehängte Dateien:

Lesenswert?

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

von Alexis S. (seraptin)


Lesenswert?

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

von Bruno W. (brunowe) Benutzerseite


Lesenswert?

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

von Michael H. (stronzo83)


Lesenswert?

Das sieht ja wirklich klasse aus!
Aufgrund der besseren Lesbarkeit finde ich die zweite Variante auch noch 
besser als die erste.

Gruß,Michael

von Blue F. (blueflash)


Lesenswert?

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

von Kurt B. (kurt)


Angehängte Dateien:

Lesenswert?

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.

von Martin H. (martinh)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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

von Kurt B. (kurt)


Lesenswert?

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

von Martin H. (martinh)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Andreas (Gast)


Angehängte Dateien:

Lesenswert?

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)

von Andreas (Gast)


Angehängte Dateien:

Lesenswert?

hier das Zweite.

von Stefan E. (stefan_e)


Lesenswert?

DAC-Abgleich für alle Spannungsstufen (1V, 2V, 5V) einzeln durchgeführt?

von Andreas (Gast)


Lesenswert?

Ist nicht Dein Ernst !?
Und ich dachte, der DAC-Abgleich erledigt alle Einstellungen in einem 
Schwung. Aber Danke, das erklärt so manches.

von Stefan (Gast)


Lesenswert?

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 !

von Gast (Gast)


Lesenswert?

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?

von Stefan E. (stefan_e)


Lesenswert?

>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

von Blue F. (blueflash)


Lesenswert?

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

von Gast (Gast)


Lesenswert?

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

von Alexis S. (seraptin)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

@Alexis

Das hört man gern.

Hayo

von Andreas (Gast)


Lesenswert?

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

von Odic X. (odic)


Lesenswert?

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

von Falk W. (dl3daz) Benutzerseite


Lesenswert?

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

von Bernhard M. (boregard)


Lesenswert?


von Falk W. (dl3daz) Benutzerseite


Lesenswert?

Bernhard M. schrieb:
> über:
>
> http://sourceforge.net/apps/phpbb/welecw2000a/viewtopic.php?f=5&t=14
>
> gehts ohne user / passwort...

Wahrscheinlich nicht. Tip: Freemail-Account für solche Fälle besorgen 
und anmelden.

Falk

von Stefan E. (stefan_e)


Lesenswert?

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

von Guido (Gast)


Lesenswert?

@ 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

von Blue F. (blueflash)


Lesenswert?

@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

von Odic X. (odic)


Lesenswert?

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

von Odic X. (odic)


Lesenswert?

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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.