Wittig(welec) DSO W20xxA Open Source Firmware

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

@Bruno

Also grundsätzlich zur Scalierung ist anzumerken, dass sich die 
Performance bei der FFT unter anderem nur bewerkstelligen ließ, in dem 
auf Multiplikationen verzichtet wurde und stattdessen Shift-Operationen 
eingesetzt wurden. Dadurch sind die verfügbaren Skalierungen erstmal 
beschränkt. Man kann das sicher auch noch etwas feiner abstufen, wie bei 
der normalen Grafikroutine, aber auch das kostet zusätzlich Zeit. Hier 
muß man also abwägen.

Die Beschriftung für das Grid ist erstmal nur im Log-Modus verfügbar da 
diese sich ja wegen der Normierung nicht ändert. Wenn ich den Linearen 
Modus beschrifte muß ich jedesmal einen Refresh durchführen wenn der 
Messbereich wechselt. Ist aber durchaus machbar. Das Gleiche gilt für 
die Frequenzanzeige.

Ich habe auch schon überlegt was sich da an eleganten Lösungen so 
anbietet.

Die Beschreibung von Lecroy ist sehr interessant, die werde ich mir noch 
mal genauer ansehen. Ich lasse da gerne Anregungen von anderen Oszis mit 
einfließen.

> 4.) Lecroy korrigiert die fft Darstellung so, daß die
> Spektralllinien im Pegel dem Level im Zeitbereich entsprechen
> s.h. Dokument, Seite C-5 oben.

Das war ursprünglich bei mir auch so, aber ich fand es besser die volle
Gridhöhe zu nutzen. Spricht was dagegen?

OdB bezieht sich auf die Amplitude des Signals im Zeitbereich bei 
Vollaussteuerung. D.h. ein Sinussignal sollte eine Frequenzlinie mit 0 
dB Verlust haben, während ein Rechteck sogar mit der Grundschwingung H1 
ein wenig im +dB Bereich (Verstärkung) liegen sollte wenn im Zeitbereich 
der ADC-Wandler mit den vollen 8 Bit (255) ausgesteuert ist.


Zu 8: Die Aliasfrequenzen entstehen leider nicht erst bei der FFT, 
sondern schon direkt bei der Abtastung, so dass man einem Datensatz 
nicht ansieht ob die Frequenzen nun echt sind oder nicht. Wenn man die 
Auswirkungen kennt, kann ein Mensch das zwar auf dem Bild erkennen, aber 
der Rechner kann es nicht herausrechnen - schade, sonst könnte man sich 
Bandbegrenzungsfilter sparen.

Gruß Hayo

@Bruno

Ich habe mir die LeCroy-Doku noch mal genauer durchgelesen. Mit der 
Skalierung der Amplitude auf die Amplitudenhöhe im Zeitbereich war hier 
nicht der Skalierungsmaßstab gemeint, sondern die Korrektur der 
Amplitude, wenn diese in einen gedämpften Frequenzbereich fällt. Siehe 
hierzu auch meine Anleitung Seite 10 Abb. 7 - Gewichtung im 
Frequenzbereich.

Eine solche Korrektur ist natürlich eine feine Sache, das wäre noch was 
für die ToDo-Liste, ebenso wie die Anzeige des Leistungsspektrums. Werde 
ich mir mal vornehmen...

Gruß Hayo

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

@Stefan,
gefällt es dir so besser?

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

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

Weitere Möglichkeit zur Datenreduktion:

Die FFT läuft jeweils nur auf einem einzigen Kanal. Die Planes der 
anderen 3 Kanäle müssen nicht übertragen werden.

Das Grid, auch wenn es mehrere gibt ist immer gleich. Es reicht die 
Grids durchzunummerieren und die Nummer des jeweils aktiven Grid zu 
übertragen. Die eigentlichen Daten dieser Plane liegen im PC Prog als 
Tabelle vor.

Es muss nicht die Cursor oder Math Plane übertragen werden, wenn die 
garnicht benutzt werden...

Wenn man zuerst den aktuellen Betriebsmodus sendet und nur die nötigen 
Daten solle sich die Übertragungszeit um 15-20 sec. reduzieren lassen.

@Bruno

Nein, bei mir sieht das völlig anders aus. Bei 25mV + 50mV mit 
Rechteckfenster werden 40mV angezeigt, mit Poisson-Fenster nur noch ca. 
12mv - Das ist ein durchaus nicht unerwartetes Ergebnis.


Hayo

@Falk

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

Gruß Hayo

Stefan, du könntest auch diese Bild mit einem Zeichenprogramm ausmalen 
;-)
PaintNet zeigt direkt die HEX Werte der Farben an.

Die geraden Linien mit dem "Farbeimer", die diagonalen mit dem 
Linienwerkzeug.

Wenn du die schönste Farbkombination gefunden hast kann man die im Oszi 
und im Programm einbauen.

Ich bin leider Farbenblind. ;-)

Hier als bmp. Das hat schärfere Kanten.

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

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

Ich glaube auch es sind deine Augen ;-)

Im Layout will man immer möglichst große Flächen haben, wohingegen im 
Screenshot die Linien möglichst dünn sein sollen. Das verbessert deren 
Sichtbarkeit natürlich nicht gerade.

Hallo Kurt,

> Den Wechsel von .c auf .cpp hat das Studio vorgegeben. Nötig ist er
> glaube ich nicht.

Ja, ich hab' die w2000a-screenshot.c nur zu nem .cpp gemacht weil
der Parser die ComTools.h sonst nicht fressen wollte.  Die benoetigten
Sachen die die ComTools machen koennen wir denke ich auch leicht
selbst neu bauen.

> Die unistd darf bei mir nur unter Linux eingebunden werden.
> Ersetzen von (int) usleep(1000) durch (void) Sleep(1000)

sleep(1000) wuerde 1000 Sekunden warten unter allen mir
bekannten libc...  (Ist abgesehen davon auch POSIX)

> Ersetzen von snprintf() durch sprintf_s().
> Aus fopen wird fopen_s

Noch nie irgendwo implementiert gesehen, was machen die
anders als die n-Versionen?

http://netbsd.gw.com/cgi-bin/man-cgi?snprintf

Die n sind egtl. soweit ich weisz auch C99...

> Dann gibt es noch Probleme mit optarg und getopt()...

Zu erwarten...

> Die Frage ist ob die Änderungen auch mit Linux laufen.

Leider nicht.

> PS:
> Mit MinGW geht es bei mir aber auch so. Ich musste erstmal
> googlen wie man damit kompiliert. ;-)

Wollen wir bei MinGW bleiben, oder statt der n die ganz normalen
Versionen verwenden und getopt() selbst implementieren?
Statt fopen() geht ja auch open(), oder fehlt das auch?

Niklas

Hallo, nochmal,

urgs, merke gerade das ich oben als ich von den Planes mit
(mir) noch nicht bekannten Funktionen sprach da die Marker
Planes erwaehne.  Da meinte ich natuerlich die Memory Planes.

Niklas

Ich denke eine weitere Aufsplittung würde es eher unübersichtlicher 
machen, allerdings könnte man den Thread evtl. mal wieder neu aufsetzen 
damit die Beiträge überschaubar bleiben.

Hayo

Hallo Hayo,

ich habe folgendes Problem:
ich nehme ein Signal auf (5µs/div), drücke auf Stop. Signal bleibt 
stehen. Ich zoome rein auf 2µs/div, Signal wird kurz vergrößert 
dargestellt, so wie es gedacht ist. Aber dann wird auch schon ein neues 
aufgezeichnet.

Kannst du das mal fixen?

Gruß,
Stefan

Geht klar!

Hayo

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

Stefan schrieb:
> Da dieser Thread mittlerweile die 1000 Einträge überschritten hat, wäre
> es da evtl. sinnvoll ihn noch einmal zu splitten (?) funktioniert ja bei
> Hardware | Software auch ganz gut.

Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach 
HW, Software, Diskussionen etc. trennen.

Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.

Falk

@BF.0.82: Läuft ziemlich gut. 3 Dinge sind mir aufgefallen:
 * About Oscilloscope: Auch hier gibts Artefakte, wenn man z.B. vorher 
im Quick Measurement Menü war
 * Quick Measurement: Wenn ich z.B. das Probe Comp Signal (bei 
200uS/div) anschaue, dann ist die Periode dauerhaft 1.00ms, aber die 
Frequenz flackert zwischen 995.0 und 999.0 Hz, ohne dass die 
Nachkommastelle mal ungleich wäre. Auch die Spannungsmessungen wie z.B. 
Pk-Pk ändern nie ihre Nachkommastelle.
 * UART: Wenn ich im Quick Measurement Modus bin, reden die 
Messfunktionen bei jedem Aufruf auf der UART. Solche Meldungen, die beim 
Entwickeln sehr helfen, solltet ihr unter Zuhilfenahme eines Makros 
ausspucken, damit die in den Releases still sind. Das kostet alles 
unnötige Zeit, wenn andauernd auf die UART geschrieben wird.

Falk Willberg schrieb:
> Wie wäre es mit einem eigenen Forum. Dann könnte man die Threads nach
> HW, Software, Diskussionen etc. trennen.
>
> Mir gefällt "Phorum" ganz gut und einen Server hätte ich dafür.

Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit: 
http://sourceforge.net/apps/phpbb/welecw2000a/
SourceForge-Handles haben eh' die meisten schon, und ihr könnt gern alle 
Mod- oder Admin-Rechte haben und eine beliebige Menge Foren und 
Kategorien anlegen. Würde mich freuen, wenn das Forum dort mehr genutzt 
würde.

Daniel H. schrieb:
...
> Nochmal das Angebot: Nutzt doch das phpBB auf SourceForge mit:
> http://sourceforge.net/apps/phpbb/welecw2000a/

Gefällt mir ;-)

Mal sehen, ob es ankommt...

Falk

@Daniel

SFN könnte man natürlich machen, aber ich fand das immer recht zäh und 
langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit 
eigene Foren einzurichten ist natürlich nicht übel.


@Falk

Auch Dein Angebot einen Server zur Verfügung zu stellen ist recht 
reizvoll da dann die Kontrolle quasi "in unserer Hand" bzw. in Deiner 
läge. Vermutlich wären auch die Antwortzeiten attraktiver als bei SFN. 
Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in 
regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht 
immer neue Treads nötig sind.

Zum UART: Von meiner Seite her keine Einwände. Ich bin da nicht mehr 
zugange, ich hatte nur für Niklas aufgeräumt - da müßtest Du Dich also 
am Besten mit Ihm abstimmen. Meine Baustelle ist nach wie vor die FFT, 
die ich gerade komplett überarbeite und erweitere (angeregt durch Bruno 
und die LeCroy Broschüre).

Zu Deiner zerschossenen USB-Schnittstelle: Poste das doch noch mal im 
Hardwarethread, eigentlich müßte doch nur das Flash fur den 
USB-Controller neu geschrieben werden wenn ich mir das so überlege. Da 
waren doch schon einige aktiv glaube ich.

Und zu guter Letzt finde ich es prima dass Du wieder aktiv dabei bist, 
nachdem ich einige Zeit nichts mehr von Dir gehört hatte.

Gruß Hayo

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

>Sehr schön. Ich habe mal einen screendump von einer FFT angehängt.
>Eingang ist der Sonnenschirm als Antenne ;-)

Coole Idee ;-)

>Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
>nächsten Oszi Start dann wieder weg?

Die ist beim nächsten Start wieder weg. Aber trotzdem vorsicht, da die 
Firmware trotzdem Einstellungen in den Flash speichert. Also vorher auf 
alle Fälle einen Backup ziehen. Da ist eine Sicherung der 
Config-Bereichs mit dabei.

Ich würde mir Perl installieren. Der WelecUpdater ist schnarch langsam. 
Ob .ram damit überhaupt geht, hat glaube ich, keiner mehr ausprobiert.

Gruß,
Stefan

Falk Willberg schrieb:
...
> Das diff für den PC-Teil bezieht sich auf die Version 0.2, wenn Niklas
> den entsprechend einpflegen könnte?

Hier das diff-file für 0.3.

Falk

Michael schrieb:
> ich würde auch gerne mal Eure neue FW testen, bevor ich allerdings etwas
> kaputt mache, will ich vorher nochmal kurz nachfragen.

Beides eine gute Idee... allerdings steht eigentlich so ziemlich alles 
in den Beipackzetteln die ich mit dazugetan habe. Trotzdem hier schnell 
noch ein Antwort auf Deine Fragen.

> Zum testen kann ich einfach die TomCat.ram verwenden? Die ist beim
> nächsten Oszi Start dann wieder weg?

So ist es. Aber wie Stefan schon anmerkte - die neue Version verwaltet 
die im Flash abgelegten Daten etwas anders. D.h. beim nächsten Start der 
alten Software kann es merkwürdige Nebenwirkungen geben, die sich jedoch 
mit Default Setup beheben lassen sollten. Auf jeden Fall solltest Du Dir 
mit dem Welecupdater ein Backup Deines Flash machen - Anleitung dazu 
liegt im Doku Ordner der Betaversion.

> Kann ich das unter Windows einfach mit der WelecUpdater.exe machen?

Nein! Der Welecupdater kann es nicht, und zwar einfach deswegen nicht, 
weil er die Endung .ram nicht unterstützt. Du müßtest die TomCat.ram 
einfach nur umbenennen in TomCat.flash (aber nicht mit der Richtigen 
verwechseln ;-) ), dann sollte es gehen.

> Oder muss ich mir vorher nen Perl-Interpreter zulegen,
> damit ich das mit dem Skript machen kann?

Wenn Du das öfter machen möchtest, kann ich das nur dringend empfehlen, 
da
der Unterschied 20 Minuten zu 3 Minuten doch schon gewaltig ist.

Gruß und viel Spaß

Hayo

@Falk

> Als erste Fleißarbeit habe ich meine neue Baustelle aufgeräumt:

Sehr schön, wenn wir so weitermachen schrumpft das File noch unter 1,2 
MByte trotz neuer Funktionen ;-)

Auf jeden Fall wird der Code langsam immer übersichtlicher und 
strukturierter.

Gruß Hayo

Hallo,
nachdem ich euren Thread jetzt eine Weile verfolgt habe, habe ich mir 
auch ein Welec bestellt, das nächste Woche eintrudeln müsste. Zur Zeit 
bin ich noch im Prüfungsstress, danach möchte ich mich aber auch an der 
Verbesserung des Gerätes beteiligen.

Achja, was mir noch aufgefallen ist: können die Dinger wirklich nur bis 
zu 5V/div nach oben? Mein jetziges Oszi lässt sich auf bis zu 50V/div 
schrauben und zumindest 10V/div und 20V/div habe ich auch schon 
desöfteren benutzt.
Mir fehlt noch der Überblick über Hard-/Software des Welec - kann man 
die Messbereiche noch hinzufügen oder steht dem etwas entgegen?

Viele Grüße,
Michael

Hayo W. schrieb:
> @Daniel
> SFN könnte man natürlich machen, aber ich fand das immer recht zäh und
> langsam. Die Bedienung ist nicht sonderlich komfortabel. Die Möglichkeit
> eigene Foren einzurichten ist natürlich nicht übel.

Erstmal gehts ja nur um das Forum. Das ist ein phpBB und entspricht 
somit wohl dem de-facto-Standard für Forensoftware. Die Antwortzeit ist 
wesentlich besser als bei diesen Mega-Threads hier im Forum

> Zudem bestünde wohl auch die Möglichkeit überlaufende Threads in
> regelmäßigen Abständen zu archvieren und zu bereinigen, so dass nicht
> immer neue Treads nötig sind.

Das können wir bei SF auch. Da gibts vollen Zugriff auf die übliche 
phpBB-Administration. Allerdings sollte sowas garnicht nötig sein, denn 
meiner Meinung nach sollte für das, wofür hier Threads verwendet werden, 
im phpBB ein Unterforum angelegt werden, in dem dann für 
unterschiedliche Gedankengänge unterschiedliche Threads genutzt werden 
;) Aber das ist sicherlich Geschmackssache (des Moderators =)

> Ich habe da jetzt einfach mal einen Thread zum Thema screendump
> aufgemacht.
> Wenn sich das nicht bewährt, kann ich auch ein Forum bereitstellen.

Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das 
andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich 
(wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet 
werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen. 
Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit 
dem Google Groups Kram).

Aktuelles:
- Die Option -c <serial-port> geht auch unter Linux
- Mit einer kleinen Firmwareänderung wird der Dump vom Programm
  gestartet
- Man kann die Option "-m" für einen monochromen screendump angeben 
(10s)
- Mit "-d" werden die Daten als CSV ausgegeben (7s).
- Ohne Optionen -c oder -m wird ein farbiger screendump ausgegeben (30s)
Die entsprechenden Patches kommen morgen...

Die Grafik zeigt die Ausgabe, die "kst" aus dem CSV-file erzeugt.

Falk

Daniel H. schrieb:

> Wenn überhaupt sollten wir einfach mal beschließen, das eine oder das
> andere Board zu benutzen und dann hier "Schilder" aufstellen ähnlich
> (wie im alten Welec-Thread, dass nun hier und im HW-Thread gepostet
> werden soll), dass Diskussionen in Zukunft woanders stattfinden sollen.

Gute Idee. Ich werde meine Änderungen künftig in SFNET ablegen und hier 
darauf hinweisen.

Dieses Forum ist nicht schlecht, aber mit Themen, Unterthemen etc. ist 
SFNET einfach besser geeignet.

> Ich möchte nicht noch eine weitere Aufspaltung auslösen (wie schon mit
> dem Google Groups Kram).

Ich werde den Google-Groups-Kram bald zumachen und einen Hinweis hierhin 
und nach SFNET anbringen (wenn ich herausfinde, wie das geht).

Falk

@Stefan

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


Hayo

@Stefan

Nochmal kurz zur Abstimmung - ich schmeiße die bei einigen 
Anzeigefunktionen die sich wiederholenden switch() Anweisungen raus und 
ersetze sie durch indizierten array fetch. -> Display::MEASURETIME(), 
CALCCURSORDATA(), CALCPRETRIGGER(), CALCTIMEBASE()

Hayo

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

Niklas O. schrieb:

Hallo Niklas,

> @Kurt:
> [Nicht alle Planes uebertragen]
>
> Daran hab' ich auch schon gedacht.  In der Tat sind ein paar der 16
> Planes ueberhaupt gar nicht benutzt, zudem kann man wie Du beschreibst
> noch weitere ausschlieszen.  Da das DSO ohnehin da "Ewigkeiten"
> pro Plane braucht liesze sich da deutlich Zeit einsparen.

Im aktuellen Stand werden ja so weit ich das überblicke sämtliche Planes 
übertragen und dann auf dem PC genauso wie auf dem Oszi mit Farben 
versehen und übereinandergelegt. Bei der Übetragung der Planes geht viel 
Zeit drauf. Wäre folgender Weg nicht besser?

Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane 
ist:

Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt 
ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der 
Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist 
wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält 
dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen). Wenn der 
Pixel auch in Plane B nicht gesetzt ist, dann wird Plane C geprüft. Wenn 
der Pixel hier gesetzt ist, erhält dieser Pixel den Wert "3" wenn nicht, 
erhält der Pixel den Wert "0" (für transparent bzw. schwarz).

Das Bild, das übertragen wird, entspricht dann 1:1 dem auf dem Oszi 
dargestellten Bild und die zu übertragende Datenmenge reduziert sich auf 
ein Viertel, da nun pro Pixel (bei 16 Planes) statt bisher 16 Bits (1 
pro Plane) nur noch vier Bits (2^4 == 16 Planes) übertragen werden 
müssen.
RLE funktioniert hier natürlich immer noch, da man ja statt einzelner 
Bits auch 4-Bit Sequenzen zusammenfassen kann. Auch auf dem Oszi dürft 
sich auch einiges an Laufzeit sparen lassen. Für das Überlagern der 
Planes im Oszi geht zwar etwas Zeit drauf, aber statistisch müssen nur 
noch 50% der Plane-Daten gelesen werden, da die "hinteren" Planes nach 
einem Match gar nicht mehr gelesen werden müssen.

Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben, 
aber schnelle Screenshots sind noch schöner.

Gruß,
Bernd

Bernd O. schrieb:
>
> Hallo Niklas,

Ich bin zwar nicht Niklas, habe aber seine Routinen bearbeitet.

...

> Beispiel für drei Planes (A, B, C) wobei A die oberste (dominante) Plane
> ist:
>
> Man startet bei ersten Pixel und prüft, ob dieser Pixel Plane A gesetzt
> ist. Wenn ja, wird abgebrochen und als Wert für den ersten Pixel der
> Wert "1" gemerkt/übertragen. Wenn der Pixel in Plane A nicht gesetzt ist
> wird geprüft, ob der Pixel in Plane B gesetzt ist. Wenn ja, dann erhält
> dieser Pixel den Wert "2" und wird gemerkt (bzw. übertragen).
...
Klingt gut! Sollte sich einfach implementieren lassen.

> Für die Entwicklung ist es zwar schön, die einzelnen Planes zu haben,
> aber schnelle Screenshots sind noch schöner.

Auf 30s sind wir schon, mit Deinem Vorschlag könnte das noch schneller 
werden.

Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke 
ich mal...

Gruß,
Falk

Hallo Hayo,

die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen 
ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick 
reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal 
eingestellt, auch mit SourceForge "relativ" fix.

Gruß,
Stefan

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

Das VN steht vermutlich für virtual network oder?

Gruß Hayo

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

Michel

http://de.wikipedia.org/wiki/Subversion_(Software)

Dieser geht:

http://de.wikipedia.org/wiki/Svn

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

Gruß Hayo

Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich 
perfekten Client wie z.B. Tortoise unter Windows. Bei mit leistet "eSVN" 
noch am wenigsten Widerstand. KSVN geht bei mir mit SF nur sehr träge.

Gruß,
Stefan

Stefan E. schrieb:
> Leider gibt es, meiner Meinung nach, unter Linux keinen wirklich
> perfekten Client wie z.B. Tortoise unter Windows.

Im alltäglichen Umgang braucht man eigentlich nur eine Handvoll
Kommandos:
  svn checkout
  svn update
  svn status
  svn commit
  svn add
damit sind 95% aller Tätigkeiten abgedeckt.
Dafür kann man gut, auch als nicht Kommandozeilen-Freund, mit
der Kommandozeile leben.

Gruß,
Günter

Falk Willberg schrieb:

> Ich muß jetzt mal das protected flash zurückspielen :-( aber dann gucke
> ich mal...

Leider hilft ein Flash-Update nicht gegen kalte Lötstellen oder 
Wackelkontakte. Jedenfalls startet die Firmware nur noch bis

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

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

@Roberto

Was du bemängelst (und misst) ist das typische Antialiasing das bei 
allen DSO's auftritt. Es ist dem Anwender überlassen die richtige 
Zeitbasis einzustellen (wenn das Signal nicht bekannt ist einfach mit 
einer möglichst hohen sample-rate beginnen und runtergehen bis das 
Signal richtig dargestellt wird).

Martin

>Leider schaut das 1kHz Signal bei 1ms/div noch immer so aus wie bei
>200ms/div
>Vielleicht wäre es sinnvoll, dieses Problem voranging zu beheben, damit
>man damit auch richtig messen kann

Das ist nur eine "optische Täuschung" (Aliasing), die durch das Abtasten 
bei zu geringer Frequenz entsteht.

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

Macht nichts ist schon gefixed.

Hayo

Hab gerade die 1.2.82 eingespielt. Funktioniert leider erstmal gar nicht 
gut.

Im Math Menü habe ich beim FFT-Softkey ein Rufzeichen drinnen. Wen ich 
in ein anderes Menü wechsle bleibt dieses Rufzeichen erhalten. 
Zusätzlich im Softkey "1+2" ein paar Artefakte.

Das Math-Menü reagiert bei mir gar nicht. Auf keinen Tastendruck.

Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht 
gar nichts mehr.

Die violette Math-Linie, die angezeigt wird sobald der Math-Modus aktiv 
ist, durchbricht Menüs. Zb das Quick-Measure Menü. Wobei das eher ein 
Minor Bug ist.

Ich denke, das Beste ist wenn ich den Komplett-Dump neu einspiele.

lg Robert

@Robert

Wenn sich das Problem durch Default Setup, Drehen an der Timebase und 
Neustart nicht beheben läßt, ist das Einspielen eines Dumps in der Tat 
die beste Lösung. Bei mir war das auch schon mal nötig, danach ist dann 
aber alles wieder in Ordnung.

Hayo

Robert S. schrieb:

...

> Wenn ich "Quick-Print" drücke hängt sich das Oszi komplett auf. Es geht
> gar nichts mehr.

Das ist normal, sollte aber nach ca. 30s vorbei sein.

Falk

@Falk

> spurious interrupt number: .................

die gleiche Fehlermeldung hatte ich beim versehentlichen Überschreiben 
des Stacks als ich eine Assemblerroutine mit falschen Parametern 
versorgt habe. Bist Du sicher, dass es sich um einen Hardwarefehler 
handelt?

Hayo

Hallo,

Da ich auf meinem Windowsrechner keinen Platz für ein zweites 
Betriebssystem habe konnte ich bisher den Source nicht selbst 
compilieren.

Jetzt habe ich jedoch auf dem ftp server von altera die cygwin version 
des compiler's gefunden! (in der Version 3.2)

Mit dem ist es möglich auch unter Windows an der SW Entwicklung mit zu 
machen.

Anbei eine kleine Anleitung in englisch (sicherlich noch 
verbesserungswürdig).

Martin

Hi Martin,

das ist cool, dann kann ich auch im Urlaub in Italien weiterentwickeln, 
mein Lappy hat nämlich nur Windows drauf (meine Frau wird mich 
steinigen).

Ich werde das mal nach Deiner Anleitung versuchen.

Gruß Hayo

Wenn deine Frau den ersten Stein aufhebt, dann mach' ihr klar, wie viele 
arme kleine Wittig User sie ins Unglück stürzen würde. Vielleicht lässt 
sie dich dann uns zu liebe am Leben und zielt nur auf Körperteile, die 
nicht zur Firmwareentwicklung benötigt werden...

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

Gruß,
Stefan

Kurze Anfrage zum Organisatorischen:

Nachdem jetzt Google.Groups geschlossen ist, wo kann ich außer hier noch 
das komplette Firmwarepaket hochladen? Gibt es da auf SFN eine 
Möglichkeit?

Hayo

Ja, die gibt es. Ich habe dir mal die Berechtigungen gesetzt, damit du 
Releases erstellen kannst. Hier ist alles erläutert: 
http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download
Falls es nicht klappen sollte, können wir das ja mal zusammen 
durchgehen, Skype-Daten von mir sind ja überall zu finden. Bin 
allerdings erst morgen abend wieder richtig zugegen (Prüfungsstress). 
Konkrete Fragen kann ich sonst auch hier oder per Mail/PN beantworten.

Hallo werte Gemeinde,

ab sofort gibt es die aktuellen Open Source Releases hier:

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

Zur Zeit ist noch die 0.82 das aktuelle beta Release, aber das Nächste 
ist schon in Arbeit und kommt hoffentlich zum Ende der Woche.

Gruß Hayo

Hallo,

ist ja einiges in den letzten paar Tagen in meiner Abwesenheit
passiert :)

@Falk:
Hab' Deine Patches gesehen und werde die die naechsten
Tage migrieren, wohl gar direkt ins SourceForge SVN
Repository, wenn ich das richtig sehe das ihr euch
entschlossen habt dieses zu nutzen.

Schoen das wir jetzt auf 30 Sekunden sind.  Wobei sich mir
jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
ist ja an sich etwas gestiegen). Hast Du schonmal probiert,
aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
ungeprueft davon aus dass der GCC die Funktion nicht inlined)

@Bernd:
Das was Du beschreibst ist in etwa das was bei dem S/W Dump
passiert, nur wird dort dann gleich auch noch die Farbe/dominante
Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
iirc. 10-15 Sekunden allein an Rechenzeit.  Ansonsten gebe ich Dir
wie Falk auch Recht.  Die Frage ist, ob jetzt Falks
Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
schneller waere oder Dein Neuansatz.  Erstere (alte) Loesung
waere flexibler und bereits implementiert, von daher wuerde
ich, sollte letztere nicht schneller sein, dabei bleiben.
@Falk:  Hast Du da diesbzgl. in der Zwischenzeit schon
weiter gemacht?

Niklas

Jürgen schrieb:
>> Findet, außer mir, noch jemand Gefallen daran, wenn Interpreter für
>> typische serielle Protokolle (SPI, I2C, ...) vorhanden wären ?
>
> Aber sicher wäre das Klasse!!

Ich finde die Idee auch gut, aber das sollten wir erstmal auf der 
Wishlist unterbringen und die Realisierung erst dann vornehmen wenn wir 
vom beta Status weg sind.

Gruß Hayo

@Niklas

Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht 
kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da 
dann die alten Programme nicht mehr kompatibel sind zum Datenformat.

Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen nur 
jetzt mit der SFN Releaseverwaltung

Gruß

Hayo

Niklas O. schrieb:
...
> @Falk:
> Hab' Deine Patches gesehen und werde die die naechsten
> Tage migrieren, wohl gar direkt ins SourceForge SVN
> Repository, wenn ich das richtig sehe das ihr euch
> entschlossen habt dieses zu nutzen.
>
> Schoen das wir jetzt auf 30 Sekunden sind.  Wobei sich mir
> jetzt die Frage stellt, ob da nicht auch die auf 1/8 reduzierten
> Funktionsaufrufe etwas dazu beigetragen haben (die Komplexitaet
> ist ja an sich etwas gestiegen).

Das frage ich mich auch. Leider habe ich keine Informationen, welche 
Operationen, wieviel Last erzeugen. Im Standardfall (Sehr viele gleiche 
Bytes), passiert aber ca. 60.000-mal nicht anderes als ein increment und 
ein 16-Bit Vergeich.

> Hast Du schonmal probiert,
> aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
> ungeprueft davon aus dass der GCC die Funktion nicht inlined)

Das dürfte die Code-Größe gewaltig steigern (640*480-mal die 
RLE-Funktion...)

> @Bernd:
> Das was Du beschreibst ist in etwa das was bei dem S/W Dump
> passiert, nur wird dort dann gleich auch noch die Farbe/dominante
> Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
> iirc. 10-15 Sekunden allein an Rechenzeit.  Ansonsten gebe ich Dir
> wie Falk auch Recht.  Die Frage ist, ob jetzt Falks
> Verbesserungen plus Planes aussparen (wie Kurt vorschlug)
> schneller waere oder Dein Neuansatz.

Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten 
Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist 
simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der 
Definition geändert werden.

>  Erstere (alte) Loesung
> waere flexibler und bereits implementiert, von daher wuerde
> ich, sollte letztere nicht schneller sein, dabei bleiben.
> @Falk:  Hast Du da diesbzgl. in der Zwischenzeit schon
> weiter gemacht?

Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.

Ich sage Bescheid, wenn ich weitermachen kann, bis dahin lasse ich den 
Kram in Ruhe.

Inzwischen mache ich mich auch mit SVN vertraut.

Vielleicht bastele ich inzwischen ein ppm2splashlogo.pl ;-)

Falk
P.S.: Ich finde es prima, daß wieder mehr Leute dazu beitragen, ein 
Scope so zu verbessern, daß Anwenderwünsche direkt berücksichtigt werden 
können.

Hallo Hayo,

> Die diffs von Falk werde ich in die nächste Beta einpatchen. Vielleicht
> kann ja jemand eine aktuelle Windowsversion (.exe) bereitstellen, da
> dann die alten Programme nicht mehr kompatibel sind zum Datenformat.

Ja das werde ich machen.  Den Sourcecode fuer die Tools wuerde ich dann
unter pc/screenshot/ einpflegen.

> Ich werde meine Releases wie gehabt als Komplettpaket bereitstellen
> nur jetzt mit der SFN Releaseverwaltung

D.h., (noch) nicht den Sourcecode im SVN Repository pflegen?  Haette
den Vorteil das wir alle direkt Aenderungen committen koennten ohne
dass Du die selbst einbauen muesstest.  Damit man sich nicht in die
Quere kommt koennten wir noch Branches machen, aber im Moment sollten
wir auch ohne auskommen.  Oben wurden ja schon ein paar SVN-Clients
genannt.  Ich faend's super wenn wir uns darauf einigen koennten
das SVN zu nutzen.  Kleine Bugfixes und Verbesserungen wie zuletzt
das charTOlMenuKey Array von Falk waeren so sofort eingebaut und auch
von allen Interessierten noch vor dem naechsten offiziellen Release
getestet.  Ich koennte auch etwas wie einen automatischen
"Nightly Build" bereit stellen, also eine fertige Firmware die den 
aktuellen Stand im Repository wiederspiegelt.

Niklas

Hallo Falk,

>> Hast Du schonmal probiert,
>> aus der RLE Funktion ein Makro zu machen?  (ich gehe mal
>> ungeprueft davon aus dass der GCC die Funktion nicht inlined)
> Das dürfte die Code-Größe gewaltig steigern (640*480-mal die
> RLE-Funktion...)

Stimmt, bloede Idee. (auch wenn man das auf 640*480/8 runter
dreht noch...)

>> @Bernd:
>> Das was Du beschreibst ist in etwa das was bei dem S/W Dump
>> passiert, nur wird dort dann gleich auch noch die Farbe/dominante
>> Plane mit weg geworfen.  Zeitlich waren das trotzdem noch
>> iirc. 10-15 Sekunden allein an Rechenzeit. [..]
>
> Wenn ich das richtig sehe, müssen wir einfach die Nummer der ersten
> Plane mit gesetztem Pixel (4 Bit) statt eines Bits übertragen. Ist
> simpel zu implementieren. Evtl. muß die Reihenfolge der Planes in der
> Definition geändert werden.

Ja, stimme ich Dir zu.  Waere 'ne simple Modifikation der B/W Funktion,
baue ich mal ein.

> Leider ist mein Scope defekt. Das geht morgen erstmal zur Reparatur.

:/  Bin mal gespannt wie der Service bei Wittig ist.

Niklas

Mit SVN muß ich mich erst noch näher auseinander setzen. Da ich momentan 
einiges zu tun hatte und gleichzeitig am nächsten Release dran war hatte 
ich da keine Zeit für. Deine Lösung mit dem Nightly Build klingt ganz 
Interessant, denn mir ging es in erster Linie darum nicht nur die 
Entwickler mit dem neuesten Stand zu versorgen, sondern auch den 
Benutzern die Gelegenheit zu geben die aktuellsten Versionen 
auszuprobieren.

Weiterhin möchte ich auch vermeiden meinen Verwaltungsoverhead zu groß 
werden zu lassen um möglichst viel Zeit für die Entwicklung zu nutzen.

Gruß Hayo

Hallo Zusammen,
ich arbeite gerade an einer "Hardwarelösung" für die Screenshots. Die 
Platine enhällt:
ATMega32/644, VNC1L, MAX232, 64kBit FRAM, SUB-D Anschlüsse für Oszi und 
PC, USB Anschlüsse für Stick und Oszi und eine Pinleiste um den Vinculum 
das erste mal zu programmieren. Größe ist 80x80mm einseitig mit einigen 
Brücken.

Ich werde noch Layout und Schaltplan etwas überarbeiten und dann hier 
reinstellen. Allerding befürchte ich, das der Vinculum etwas schwierig 
zu löten ist.

Sollte das Konzept funktionieren kann man aber immer noch auf ein 
fertiges Modul ausweichen. Der Flaschenhals ist definitiv nicht auf der 
Platine sondern die lahme RS232 vom Oszi.

Mfg,
Kurt

Hallo Kurt,

na deine Platine sieht ja echt gut aus. Vielleicht sollten wir, wenn 
feststeht das die Schaltung funktioniert, auch dafür eine professionelle 
Lösung in Betracht ziehen? Bei den meisten dieser "Produkte" drückt eine 
Herstellung von 30...50 Stck. ganz massiv den Preis.
Ich hätte da auf jeden Fall Interesse dran.

Gruß, brunowe

P.S.: mit Eagle3D gemacht?

Hallo Bruno,
ja, mit Eagle 3D.

Auch ja zur Professionellen Lösung. Leiterbahnen mit 8mil und Abstände 
mit 11mil sind nicht für jeden einfach zu ätzen. Außerdem soll die 
Platine später kleiner und doppelseitig werden damit man die 
Versorgungsspannungen ordentlich routen kann.

Sehr interessante Erweiterung, die dürfte weggehen wie warme Semmeln 
(ich bin z.B. ein Doppelabnehmer). Daher denke ich sollte eine größere 
Auflage zu Gunsten des Preises kein Problem sein.


Was Anderes: Um die ToDo-Liste zu komplettieren bin ich mal in Gedanken 
die wichtigsten Funktionen des DSO durchgegangen, dabei ist mir 
aufgefallen, dass ich noch nie die Speicherfunktion für die Signale 
benutzt habe. Hat das schon jemand ausprobiert? Ist das ein Feature das 
ausnahmsweise mal einfach so funktioniert, oder müssen wir da auch das 
Baustellenschild aufstellen?

Gruß Hayo

Hallo Hayo,

die Save/Recall Sachen funktionieren bei der Original-Firmware
einigermaszen, habe ich schon oefters benutzt wenn ich z.B. Signale
vergleichen wollte.  Dummerweise konnte ich die dann allerdings
nicht mehr mit der Welec Originalsoftware vom Oszi holen, da wurde
einfach eine neue Signalfolge aufgenommen.

Auch kann man die Funktion nutzen um Kanal- und Zeitachsen-
einstellungen zu sichern, die werden naemlich gleich mit
wiederhergestellt.

Bei der Beta-Firmware scheint da aber genau gar nichts zu
funktionieren. Habe da sehr absurde Effekte.  Genau genommen
ist wohl Reboot faellig nach einem Save gefolgt von Recall,
in benutzbaren Zustand habe ich mein Geraet zumindest nicht
wieder versetzt bekommen.

Waere schoen wenn wir das zum Laufen bekaemen, habe mich da aber
noch nicht umgeschaut.  Vermutlich werden die ADC-Daten samt
Parameter abgelegt und einfach neu gerendert, oder?  Die iirc.
80 Speicherplaetze die da Wittig vorgesehen hat sind aber IMHO
etwas uebertrieben.  Vllt. koennen wir das auch aufteilen, d.h.,
Recall Trace und Recal Settings.

BTW: Hast Du meine Nachricht auf SF wg. Devel schon gesehen?

Niklas

Nein ich schau mal kurz rüber.

Hayo

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

Hayo

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

Ist erledigt

Hayo

Ich hab mir die Save/Recall-Geschichte mal angesehen, ich glaube es 
liegt an den geänderten Parametern die im Flash abgelegt werden, da kann 
ich bei Gelegenheit mal beigehen.

Hayo

Hallo,

wenn sich einer dranmacht an der Save/ Recall Funktion rum zu basteln, 
dann sollte man direkt den Vorschlag von stendres aus der SF Wishlist 
mit einfließen lassen. Halte ich für nen guten Vorschlag.
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWwishlist

Gruß, brunowe

Hallo Bruno,

ja, das waere in der Tat sehr nuetzlich.  Koennte man dazu einfach
die (scheinbar) unbenutzten Memory-Planes hernehmen?  Sind allerdings
nur drei.

Wo ich gerade die Wishlist sehe finde ich den ersten Vorschlag
von michelwernersen auch wichtig.  Da ich (noch) die Original-Firmware
im Flash habe und die aktuelle Beta ins RAM lade bin ich staendig
am Justieren.  Das liesze sich sicher recht einfach realisieren,
ich werde da spaeter mal drueber schauen.

Niklas

Stefan E. schrieb:
> Hallo Hayo,
>
> die Änderungen gehen klar. Muss ich dadurch was an den QM-Funktionen
> ändern? Magst du dir mal einen SVN-Client zulegen. Dann würde ein Klick
> reichen und alle hätten gleich die aktuellste Version. Geht, wenn einmal
> eingestellt, auch mit SourceForge "relativ" fix.

Ich hab's mal ausprobiert:

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

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

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.

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

Stefan E. schrieb:
> Hallo,
>
> jo der src-Order unter src ist ein Unfall ;-) Muss ich mal versuchen,
> wieder zu löschen.

Könnte ich mit ksvn vielleicht schaffen. Die Dateien sind sowieso alle 
identisch.

> Der QM-Ordner sollte eigentlich mein Branch werden, in dem ich die
> QM-Funktion ändere und dann später wieder in die anderen sourcen
> einpflege.
>
> Ich komme selber noch nicht ganz mit svn zurecht. Also net gleich
> schlagen ;-)

Schade, hatte den Knüppel gerade geputzt ;-)

Stattdessen habe ich Version 0.4 von w2000a-screenshot committed. 
Vielleicht hat das ja geklappt...

Falk

sunny schrieb:
> hat denn schon mal jemand das compilieren unter windows getestet? ich
> hab es nicht hin bekommen. es kommt folgende meldung
...

>>make (e=2): Das System kann die angegebene Datei nicht finden.
>>make: *** [obj/TomCat.cpp.o] Error 2
> er findet also die tomcat.cpp.o nicht. kann er auch nicht weil die noch
> gar nicht existiert. hat jemand einen tip?

Er findet nicht die tomcat.cpp.o nicht (die will er ja gerade erzeugen), 
sondern die includes unter inc/. Die findest Du da: 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/welec/improved/inc/

Hat mich auch eine Weile gekostet, das herauszufinden.

Falk

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

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

Hallo nochmal,

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

Niklas

>so, habe gerade zu spaeter Stunde die 0.82 von Hayo sauber
>in fpga/firmware importiert und Falks letztes Diff eingespielt.
>Sollte so wie es da liegt und ausgecheckt werden kann kompilieren.

Sollte auch davor möglich gewesen sein, die Sourcen zu kompilieren. War 
eigentlich auf dem aktuellen Stand. Bis auf der zweite src-Ordner, der 
ein Versehen war.
Jetzt liegt es irgendwie bescheuert, da nich klar ist, für welches 
FPGA-Design die Firmware gedacht ist.

Gruß,
Stefan

Hallo Roberto,

Ist etwas unfair einen Rolls Royce mit einem Fiat zu vergleichen!

Aber zu deiner frage:

Die Darstellung hangt von der Samplerate ab, beim Welec (das uebrigens 
nur 4KB Samplespeicher hat) ist die bei 500ms/div nur 
500Samples/Sekunde, bei dieser Samplerate kann ein 1kHz Signal 
natuerlich nicht mehr richtig dargestellt werden (niquist sagt das die 
sample rate mindestens doppelt so hoch sein muss wie die hoechste 
Eingangsfrequenz, und ein Rechtecksignal enthaelt nicht nur die 1kHz 
sondern auch oberwellen). Das Agilent hat 2MB Samplespeicher und kann 
daher bei 500ms/div mit 400kSamples/Sekunde samplen!

Martin

Niklas O. schrieb:
> Hallo,
...
> @Falk:
> Das diff-Format ist bissl komisch gewesen, wie hast Du das erzeugt?
> Da fehlten die Header damit patch(1) den Kram alleine ohne manuelle
> Angabe jeder Datei findet.

Ich hatte einfach "diff" benutzt und manuell nacheditiert. Mit svn 
brauchen wir das ja nicht mehr.

Ich habe übrigens den PC-Teil nach 
https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/pc/w2000a-screenshot/ 
hochgeladen und ihn Version 0.4 genannt.

Falk

@Roberto

Die Sampletiefe ist immer 16k. Aber die real verfügbare Sampletiefe 
hängt vom Darstellungsfaktor ab. Den Zusammenhang hatte ich weiter oben 
schon mal im Zusammenhang mit Aliasing erklärt. Die genauen 
Zusammenhänge entnimmst Du der Timebasetabelle in den Programming Maps, 
die Du hier findest:

http://groups.google.com/group/welec-dso/files

Hayo

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

Sag mal Falk,

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

Hayo

Hayo W. schrieb:
> Sag mal Falk,
>
> wie machst Du eigentlich diese schicken Bilder? Hast Du da ein
> Datenauswertungsprogramm das Diagramme erstellt?

Ja: http://kst.kde.org/

Damit mache ich die meisten Auswertungen von geloggten Daten.

Falk

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

Kommt drauf an was man damit machen will. Für die Rekonstruktion das 
Bildschirmbildes reicht weniger. Um selbiges zu rekonstruieren muß man 
verschiedene Parameter kennen:

- mit welchem Offset beginnt das aktuelle Memory Window
- welcher Faktor wird verwendet (Timebasetabelle)

Bsp.: der Offset liegt bei 400, mit dem Faktor 5.

Dann müßte die Übertragung beginnend beim 400sten Wert jeden 5. Wert 
übertragen und zwar so viele wie das Grid breit ist (600 char Werte)

D.h. ausgewertet wird der Bereich von 400 - 3400

Ein Sonderfall sind die Ultra Slow Time-Bases, und die interpolierten TB 
da die Daten hier in separaten Speicherbereichen abgelegt sind und auch 
ohne Offset mit Faktor 1 ausgewertet werden.

Gruß Hayo

Hallo,

@Stefan:
tut mir Leid, das mit Deiner Namensgebung erschlieszt sich mir
erst jetzt mit Deiner Erklaerung.  Wobei das irgendwie auch
bloed ist, dass da sowohl C Code fuer den Nios Softcore und
VHDL vermischt liegt.  Koennte man (wenn man nicht wuesste
dass Welec das Design nicht hergeben will/kann wegen fremder
IP) auch so intepretieren, dass fpga/welec/improved das
verbesserte Design enthaelt.  Der Pfad sagt ja nicht aus,
ob es sich da um Softcore Code oder VHDL-Design handelt.
"Firmware" erschien mir da logischer, ohne natuerlich wie
Du schon richtig klarstellst zu beachten, dass es ja
parallel eine zweite Entwicklungslinie gibt.

Ich stelle mal die Frage in den Raum was man da tun sollte.
Da die importierte 0.82 Deine (@Stefan) Aenderungen enthaelt
kann fpga/firmware/ jetzt als aktuell angesehen werden.  doc/
und tools/ von fpga/welec/improved/ kann noch uebernommen
werden oder, vllt. besser, die PDFs koennten (wenn nicht schon
getan) im Wiki verlinkt werden.

@Falk:
[PC-Teil]
Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
Conditionals ungefragt neu eingerueckt habe, da sich
die Ebenen fuer mich einfach nicht mehr entschlossen.

Was ich noch einbauen wollte war die -l Loop Funktion,
angeregt durch das Standard-Verhalten der Windows-Versionen
von Kurt, wo automatisch eine neue Datei mit aufsteigender
Nummerierung erzeugt wurde.  Zudem noch eine kurze
deutschsprachige Anleitung.  Dann kann Hayo den Sourcecode
und die Windows-.EXE ja vllt. kuenftig in seinen Releases
direkt mitfuehren.

kst ist btw. sieht ja wirklich schick aus, muss ich auch
mal ausprobieren.  Ich haette jetzt einfach das diesbzgl.
unhandlichere gnuplot hergenommen.

Niklas

Niklas O. schrieb:
> Hallo,

...

> @Falk:
> [PC-Teil]
> Hab' ich gestern noch gesehen und schon etwas rumgefummelt.
> Ich hoffe es ist okay das ich Deinen Code insbes. bzgl.
> Conditionals ungefragt neu eingerueckt habe, da sich
> die Ebenen fuer mich einfach nicht mehr entschlossen.

Kein Problem. Schön, daß Du die Fehlerbehandlung eingebaut hast.
Ich sollte vielleicht aufhören, nach dem Motto zu verfahren "wenn es 
kompiliert, gib's frei, wenn es nicht läuft, versuche -Wall" ;-)

Falk,
derzeit Sope-los...

@Niklas

Da die ganze Versionsgeschichte hier im Augenblick etwas unübersichtlich 
ist eine schnelle Frage:

Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten 
gepatchten Stand, korrekt?

D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen, auch 
korrekt?

Nicht dass ich im nächsten Release den falschen Zwischenstand drin hab.

Zur Windows .exe - klar, die kann ich mit ins Release-Package tun.

Gruß Hayo

Hallo Hayo,

> Die Source die Du in SFN abgelegt hast ist schon auf dem neuesten
> gepatchten Stand, korrekt?

Ja, genau.

Ganz konkret ist's:
  BlueFlash_Build_0_62.zip
+ FW1.2.BF.0.82_beta.zip
+ FW1.2.BF.0.82_beta-dl3daz.diff
  (aus Beitrag "Screendumps" )
- *~ (vi (u.a.) Backup Files), obj/,
  WelecUpdater (ist woanders im SVN), usw.

(GERMSloader.pl ist jedoch drin, kann Hannes entscheiden
 ob er das im SVN verwalten will, woanders hinschieben usw..
 Bzgl. der WelecUpdater.exe:  Die sollte in den Files/Releases
 Bereich, da sie ja aus den Sourcen erzeugt werden kann und
 statisch ist.  Gleiches fuer die Windows Screenshot.exe.
 Oder wir sparen das und wir tun sie allein in die
 Firmware-Releases.)

> D.h. ich kann mir das Patchen sparen und die Sourcen direkt ziehen,
> auch korrekt?

Ja, genau.

Niklas

Da die Screenshot.exe unter Umständen (so wie jetzt) nur zu dem 
jeweiligen Release passen, ist es eigentlich keine schlechte Idee sie 
mit ins Paket zu tun, dann gibts keinen Frust wegen inkompatibler 
Versionen.

Hayo

@Falk & Niklas

Wenn ich das so richtig mitverfolge, ist ja auch ein reiner 
Datendownload in Arbeit.

Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software 
zurückzugreifen und das Datenformat auf DSO-Seite entsprechend 
anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal 
erfinden müßte. Ich denke da sowohl an Open Source Programme für 
verschiedene andere DSOs als auch evtl. Programme von den 
DSO-Herstellern, sofern das Datenformat bekannt ist.

Wie ist denn da Eure Meinung?

Bzw. @all

Wer kennt denn evtl. entspechende Programme?

Hayo

Mal eine Frage an die Experten:
Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten, 
kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?

Ich denke, wir sollten die gigantischen Monolithen sinnvoll in möglichst 
kleine Files aufteilen. Ich würde das übernehmen, wenn ich damit nicht 
hintenherum etwas anderes umwerfe...

@Niklas:
was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
Beim kompilieren werden die nicht angefasst...

@Hayo:
Ich halte es für eine gute Idee, das Datenformat für die 
PC-Kommunikation von einem anderen Scope zu kopieren, wenn es dafür 
ordentliche Software gibt, die auch unter Linux läuft.
Ich habe nur keine Idee, welches geeignet sein könnte.

Falk

@Jürgen

der XY-Grid Patch ist in der 0.83, die aber noch nicht released ist, da 
die neu aufgesetzte FFT noch unfertig ist. Mir ging es darum die 
gepatchte 0.82 mit meiner 0.83 abzugleichen bevor ich die jetzt zum 
Wochenende raushaue. Vielleicht sollte ich mit dem Abgleich auch noch 
bis zum Schluß warten falls noch Patches dazukommen.

Gruß Hayo

@Falk

Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind, 
d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen 
Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es 
ein heilloses durcheinander von Versionen, die nicht zueinander passen.

Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt 
machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt 
ist.

Hayo

Moin moin,

melde mich von der ersten Klausur des Semesters erfolgreich zurück ;)

Bzgl. SVN: Ich hatte hier: 
https://sourceforge.net/apps/trac/welecw2000a/wiki/Repository mal 
angefangen, die Struktur des Repositories zu dokumentieren. Ist nicht 
ganz aktuell wie ich gerade sehe, aber vll könnt ihr euch auch dran 
halten bzw. eure Zweige dort grob benennen. Die Struktur könnte noch 
optimiert werden, da es ja mittlerweile euren Branch gibt der auf dem 
NIOS basiert und auch noch den Kram von Slog, wobei ich bezweifle, dass 
da mal wieder was passiert... Ach ja, und die Originalsourcen...

Was mir aufgefallen ist ist dass der ein oder andere Commit der letzten 
Tage gut hätte zusammengefasst werden können, statt pro Datei ein 
Changeset zu machen. Man kann also durchaus mehrere Dateien in einem 
Rutsch (und mit einer gemeinsamen Lognachricht) einchecken. Aber ich 
glaube das habt ihr nun auch bemerkt ;)

Was die Sache mit dem src/src/ Ordner angeht: Wenn ich die Logs richtig 
im Kopf habe, sollte das ne "Branch" zum Entwickeln werden. Dazu 
vielleicht noch ein paar Worte:

1) Wenns geht, würde ich persönlich das Branch&merge gebastel bei SVN 
lieber vermeiden. Hab schon diversen Kram mit SVNs versioniert und bin 
auch bei größeren Gruppen nicht in die Verlegenheit gekommen, sowas zu 
machen. Aber wenn's jemanden gibt, der das Merging am Ende voll drauf 
hat, nur zu ;)

2) SVN unterscheidet nicht zwischen Branching, Tagging und Kopieren. 
Alles geschieht mittels svn copy, also sowohl release-tags anlegen als 
auch branching ist letztlich nix anderes als ne Kopie. Wobei 
Serverseitig natürlich nix dupliziert wird, solange es keine Änderungen 
gibt. Das mal im Hinterkopf behalten, wenn gebranched wird. Es empfielt 
sich also, eine Struktur anzulegen, wie man das in vielen öffentlichen 
SVN sieht, also "branches/ tags/ trunk/"-Ordner, wobei Trunk natürlich 
der Hauptentwicklungszweig ist.
Da wir hier mehrere parallele Projekte in einem Repo haben, sollte jedes 
Unterprojekt in seinem Unterprojekt-Ordner sowas anlegen.

3) ... hab ich gerade vergessen. Naja Vortrag beendet ;)

LG

Hayo W. schrieb:
> @Falk
>
> Mit dem Aufteilen warte mal bis wir auf einem konsolidierten Stand sind,
> d.h. wenn ich die 0.83 released habe. Dann können wir einen kurzen
> Entwicklungsstop machen und das Organisatorische klären. Sonst gibt es
> ein heilloses durcheinander von Versionen, die nicht zueinander passen.
>
> Bei solch umfangreichen Änderungen müssen wir einen sauberen Schnitt
> machen, da ja auch die Versionierung im SFN sonst nicht mehr korrekt
> ist.

Ok, ist das sinnvollste.

Siehe auch Daniels Beitrag.

Falk

Hallo,

@Falk:
> was hat es mit src/display_t_bak.cpp und src/fft/ auf sich?
> Beim kompilieren werden die nicht angefasst...

Die stammen offensichtlich aus dem 0.62.  fft/ habe ich glatt
uebersehen und ist dann wohl die alte FFT Implementation aus
der 1.2.  Beides kann dann weg.

> Wenn zwei Leute gleichzeitig bspw. die Datei display_t.cpp bearbeiten,
> kann es doch beim Commit zu Kollisionen kommen. Oder irre ich?

Kann es, ja, in der Regel geht das aber gut wenn nicht gerade genau
dieselbe Stelle im Code von beiden Bearbeitern modifiziert wird.
Wenn die Software das Problem nicht selbst loesen kann (Im Falle
von "Bearbeiter haben an verschiedenen auseinander liegenden Stellen
was geaendert" kann sie das) wird der commit verweigert und man
muss selbst Hand anlegen.  Wie das bei SVN konkret ablaeuft kann ich
Dir jetzt allerdings nicht sagen.

Ich stimme Dir zu dass die Dateien teilweise wirklich gigantische
Ausmasze haben und unuebersichtlich sind.  Vom Standpunkt der
Revisionsverwaltung muss das aber nicht unbedingt zu schweren
Kollisionen fuehren wie gerade gesagt.  Ich wuerde Deinem Vorhaben,
da aufzuraeumen voll zustimmen.  Da gerade Hayo aber schon an
0.83 dran war waere es aber sinnvoll, dass Hayo nen Diff zieht
und wir (oder er) das direkt einspielen und Du erst dann aufteilst,
so dass Hayo da spaeter nicht ein groszes Chaos hat.

@Hayo:
> Hier hatte ich ja mal die Idee geäußert auf vorhandene PC-Software
> zurückzugreifen und das Datenformat auf DSO-Seite entsprechend
> anzupassen. Das hätte den Vorteil, dass man das Rad nicht zweimal
> erfinden müßte. Ich denke da sowohl an Open Source Programme für
> verschiedene andere DSOs als auch evtl. Programme von den
> DSO-Herstellern, sofern das Datenformat bekannt ist.

Das sehe ich genau wie Falk und Du auch.  Ich hatte auch schonmal
nach Ausgabeformaten gefragt, leider kam diesbzgl. kein Vorschlag,
ist vllt. auch unter gegangen in der Fuelle von Posts.

Leider kenne ich keine anderen DSOs bzw. Programme dazu.  Jeden
Hinweis und Dokumentation gehe ich da gerne nach.

Leider komme ich im Moment zeitlich noch nicht dazu die von mir
angepeilten Dinge (Auto-Setup/Kalibrierung, -l in Screenshot
Programm, usw.) zu realisieren.  Wir haben aber ohnehin genug
Baustellen.  Wie sieht es btw. da nochmal mit einer immer aktuell
gehaltenen Liste "wer arbeitet gerade woran" aus?  SF Wiki
waere da nun die praedestinierte Stelle.

(btw:  Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
in einer vorhanderen Unterseite eine neue Seite verlinken.
Kann man das der Software irgendwie abgewoehnen?)

Update/Edit: Hab' den Satz in Klammern bzgl. Kollisionen mal
ausgeweitet damit klar wird, dass ich dort den automatisch
loesbaren Fall meinte.

Niklas

@Niklas

Der FFT Ordner stammt von mir. Da hatte ich mir mal einige 
Beispielsourcen reinkopiert und dann den Ordner vergessen zu löschen - 
kann also weg.

Ich hatte mal in der SFN Roadmap einige Entwicklungen eingetragen. 
Aktueller wärs natürlich wenn jeder seine momentanen Sachen selber 
einpflegt.

Hayo

Niklas O. schrieb:
> (btw:  Irgendwie ist das ziemlich unpraktisch, wenn nur Admins
> die Hauptseite des Wikis aendern duerfen, so kann man nur versteckt
> in einer vorhanderen Unterseite eine neue Seite verlinken.
> Kann man das der Software irgendwie abgewoehnen?)
Kann man, möchte ich aber nicht. Öfter mal bei letzten Projekt scheinbar 
automatisierten Frontpage-Vandalismus gehabt, deswegen die alte 
Gewohnheit, die Seite auf Read-Only zu sitzen. Wenn du mir dein Handle 
sagst, kannste gern die entsprechenden Bearbeitungsrechte bekommen.

Wär vll ne gute Gelegenheit, erstmal die Developer-Tabelle im Wiki zu 
aktualisieren, damit der Überblick erhalten bleibt ;)

Hallo,

@Hayo:
Roadmap habe ich gefunden :)

@Daniel:
Merke gerade auch, dass ich manche andere Seiten
auch nicht editieren kann (Developers, ...).
Mein Handle entspricht meinem vollen Namen.

Die Rechte beim Trac Wiki hab' ich noch nicht ganz
verstanden.  Kann man es so machen, dass alle
eingetragenen und aktiven Developer/Members
(die ja ohnehin manuell von einem Admin hinzugefuegt
werden muesen und damit "geprueft" sind) entsprechende
Rechte bekommen?  Im Repository konnte ich direkt
ohne weiteres "rumfuschen", btw..

Abgesehen davon, geht das nur mir so oder ist
das Webinterface bei SF irgendwie ziemlich lahm?
(hab' diverse Firefox Plugins (Ad-Blocker, NoScript, ...)
die das bei mir ausbremsen koennten, daher frage ich mal)

Niklas

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

Hayo

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

Ist hier auch so...

Einerseits gab es mehrere Angebote, einen eigenen Server aufzusetzen, 
andererseits gefällt mir, daß es nicht so viele verschiedene Orte gibt, 
an denen das Thema bearbeitet wird.

Noch was: Wie wäre es mit Unterverzeichnissen .../FW1.2.BF.0.82/ 
../FW1.2.BF.0.84/ etc?

Falk

@Niklas: Rechte gesetzt.

@Antwortzeit SF: Das schwankt bei mir stark, ist aber im Mittel gerade 
noch erträglich. Aber der Server bei SF ist unabhängig. Im letzten 
Projekt war plötzlich der Mensch mit dem Server nicht mehr erreichbar, 
nachdem kurz vorher alle Daten weg waren und plötzlich kein Backup 
existierte. Ob er sich geschämt hat?

@Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter 
trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release 
herausgebracht wird, ist der erste Schritt, trunk/* nach 
tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das 
dient ausschließlich der Konservierung von definierten Ständen. Falls 
ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das 
erledigen, ohne dass History verloren geht.

Daniel H. schrieb:
...
> @Falk: Üblich für SVN wäre, wenn ihr in eurem "Hauptverzeichnis" unter
> trunk/ die jeweils aktuellen Sourcen hättet. Wenn dann ein Release
> herausgebracht wird, ist der erste Schritt, trunk/* nach
> tags/FW1.2.BF.0.xy/* zu kopieren. Im tags/ Ordner wird nie editiert, das
> dient ausschließlich der Konservierung von definierten Ständen. Falls
> ihr euere Ordnung dahingehend ändern wollt: mit svn move kann man das
> erledigen, ohne dass History verloren geht.

Ich sehe schon, ich werde mich mal näher mit SVN beschäftigen müssen.
Da ich derzeit kein Scope habe und anderes zu tun ist, halte ich mich 
aus der Software ein paar Tage lang heraus.

Falk

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

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

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?

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.

Kurze Info für die Screenshot-Spezis.

Im Rahmen einer Fehlersuche habe ich mal schnell eine Colordemo 
gebastelt. hier zu sehen sind alle angezeigten Planes (13 Stück, 
UI-Plane 2 ist schwarz). Die Memory-Planes werden in der Tat nicht 
angezeigt, ebenso wie die Buffer-Planes.

Leider sieht man den Fehler den ich gesucht habe hier nicht. Dafür muß 
man kurz aus dem nächsten Beitrag...

...die TomCat.ram laden. Dann Sieht man den Fehler deutlich. Und zwar 
hat die UI-Plane 1 eine Macke (hatte Guido ja auch schon vermutet). Die 
gesamte Plane ist um 32 Pixel nach rechts verschoben, was dazu führt, 
dass die ersten 32 Pixel nicht gezeichnet werden, aber dafür die letzten 
32 Pixel auf der rechten Seite durchgeschoben werden und um eine Zeile 
nach unten verschoben auf der linken Seite wieder rauskommen.

Daher auch die komischen Linien bei dem ganz linken Funktions-Button.


Hayo

Nachtrag:

Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA 
liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem 
nicht haben??

Hayo

Hayo W. schrieb:
> Es ist durchaus möglich, das dieser Fehler im VHDL-Design des FPGA
> liegt. Ich vermute mal, das die alternativen VHDL-Designs dieses Problem
> nicht haben??

Ich sehe keinen Grund, warum diese Plane-Geschichte in HW realisiert 
sein sollte... Das würde ja bedeuten, dass es sozusagen für jede Plane 
einen Framebuffern gäbe, also in getrennten Speicherbereichen? Ich hätte 
jetzt vermutet dass die in Software zusammengeführt werden, habe aber 
noch nicht in den Source geschaut.

Wo steckt denn überhaupt der Framebuffer? Im SRAM oder im FPGA-Blockram? 
Kann man das evtl. an der Adressaufteilung sehen?

In der Firmware konnte ich den Fehler bislang noch nicht lokalisieren, 
in dem Bereich ist das Coding auch ziemlich unübersichtlich.

Kann gut sein, dass es auch eine reine Softwaresache ist. ich bin noch 
nicht dazu gekommen zu prüfen ob das Problem auch bei der originalen 
FW1.4 auftritt.

Wenn nicht, wäre die Frage geklärt.

Hayo

Du bist schuld! Bestimmt! :-P

duck

/Hannes