Neue Firmware: DDS-C 1.0beta

Fragen zur Software des digitalen Funktionsgenerators und des True-RMS-Messaufsatzes bitte hier stellen.
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Hallo DDS-Freunde,

nach kurzem Nickerchen habe ich nochmal nachgedacht und würde für die Menüänderung folgende Änderung vorschlagen:

- Änderung der Sweep-"Formula" von "Linear, Octave, Decade" auf "Log, Linear"
(bezüglich der Formel ist Octave und Decade identisch)

Neue Menü-UnterPunkte im Sweep-Menüpunkt:
- "Marker" mit den Optionen "Off, Decade, Octave"
(weil sich nur die Markerpositionen unterscheiden, aber nicht die Funktion selbst)
- "Marker Size" mit den Optionen "0.0, 0.6, 0.8, 1.2, 1.4" oder freilaufend variabel zwischen 0 und 150%.
- "Marker Mode" mit den Optionen "absolut, relative"
(absolut ist für ...10,100,1000Hz... bei decade und ...55,110,220,440,880Hz... bei octave
relative bezieht sich immer auf die Startfrequenz, also jeweils ein Marker bei 10^x der Startfrequenz bzw. 2^x der Startfrequenz)

Der Einbau dürfte nicht allzu schwer sein, nachdem ich schon so weit gekommen bin.

Jetzt muß ich aber erst mal ab ins Büro, ich hab heut Kunden da. Also nix mit erholsamem Büroschlaf :(

Viele Grüße
Paul
Viele Grüße
Benutzeravatar
ompf
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 168
Registriert: 19.01.2008, 13:03
Wohnort: Dortmund

Beitrag von ompf »

Hallo Paul,

da hast Du wohl recht, Logarithmenbasis und Zeitbasisregler ergänzen sich schon ganz gut. Irgendwie hatte ich bei der Idee ans Oszilloskop gedacht, dann aber doch ein beschriftetes Koordinatensystem vor mir gesehen. So übersieht man schonmal die Mathematik...

Was die Marker angeht: eine (fest oder stufig) einstellbare Überhöhung macht sicherlich Sinn. Während ein Verstärker die volle Bandbreite durchläßt und damit dort 10% völlig ausreichen, dürfte ein steilflankiger Tiefpaß eher 200% brauchen.

Der "absolute" Markermode passt gut für Frequenzgangmessungen. Den "relativen" nimmt man jedoch zum Durchwobbeln von Filtern, da wäre eine Symmetrie zur Mittenfrequenz besser. Oder genau eine Marke an der Mittenfrequenz. Und damit man nicht so viel rechnen muß, erfolt die Sweep-Definition dann über Mittenfrequenz und Bereich.

Also vielleicht drei übergeordnete Modi:

* Sweep mode absolute: StartFreq, StopFreq, Lin/Log, Marker dec/oct/off
* Sweep mode relative: CenterFreq, Span, (Lin/Log - macht Lin hier überhaupt Sinn?), Marker 1.1x/2x/10x/off
* Sweep mode off: Freq, Burst length, Burst pause (bzw duty cycle)


Gruß
Patrick
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Hallo Patrick,

ich sehe, Du bist ein Mann der Praxis. :D
ompf hat geschrieben:Was die Marker angeht: eine (fest oder stufig) einstellbare Überhöhung macht sicherlich Sinn. Während ein Verstärker die volle Bandbreite durchläßt und damit dort 10% völlig ausreichen, dürfte ein steilflankiger Tiefpaß eher 200% brauchen.
Ein guter Punkt, das macht Sinn.
ompf hat geschrieben:Der "absolute" Markermode passt gut für Frequenzgangmessungen. Den "relativen" nimmt man jedoch zum Durchwobbeln von Filtern, da wäre eine Symmetrie zur Mittenfrequenz besser. Oder genau eine Marke an der Mittenfrequenz. Und damit man nicht so viel rechnen muß, erfolt die Sweep-Definition dann über Mittenfrequenz und Bereich.
Das ist eine gute Ausgangsbasis für die anstehende Implementierung. Finde ich auch schlüssig.
ompf hat geschrieben:Also vielleicht drei übergeordnete Modi:

* Sweep mode absolute: StartFreq, StopFreq, Lin/Log, Marker dec/oct/off
* Sweep mode relative: CenterFreq, Span, (Lin/Log - macht Lin hier überhaupt Sinn?), Marker 1.1x/2x/10x/off
* Sweep mode off: Freq, Burst length, Burst pause (bzw duty cycle)
Macht Lin überhaupt Sinn? Ich meine, die meisten Generatoren unterstützen den Mode, aber technisch gesehen, ist Log doch eigentlich der wichtigere. Ich meine, den Lin-Mode würde ich schon drin lassen, klarer Fall, aber erstmal sehe ich keine Markereinblendung vor. Das hat erstmal nix mit meiner Faulheit zu tun, sondern damit, daß ich in der Interruptroutine nicht so unnötig zusätzlich double multiplizieren will.

Fürs erste sehe ich mal die Marker nur für den kombinierten Mode Up+Log vor. Alle anderen Modi haben erstmal keine Marker, auch wenn der Mode eingeschaltet ist. Wenn später noch Platz im Flash ist, dann können wir das auch noch einbauen.

Warum hast Du den Markerfaktor 1.1 aufgeführt? Wie kommst Du auf den Wert?

Ach ja, der Faktor: Beim Eingabemode Center/Span würde ich Span als Spanfaktor nehmen, dann ist das konform zum Log-Mode.
Aber noch was anderes: sollen die Werte nach Eingabe im Center/Span-Mode nach Umschaltung in den Start/End-Mode entsprechend umgerechnet werden?
Oder sollen die Werte für Start/End-Mode und Center/Span getrennt verwaltet werden?

Viele Grüße
Paul
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Hallo DDS-Freunde,

[quote=""psclab"]Aber noch was anderes: sollen die Werte nach Eingabe im Center/Span-Mode nach Umschaltung in den Start/End-Mode entsprechend umgerechnet werden?
Oder sollen die Werte für Start/End-Mode und Center/Span getrennt verwaltet werden?
[/quote]
Beim Implementieren habe ich jetzt mal beide Wertesets verkoppelt. D.h. ändere ich an der Centerfrequenz. bleibt der Span gleich, aber Start und Ende werden automagisch angepaßt. Ist eigentlich so ganz nett und spart mir im "alten" Code die Notwendigkeit, wieder Fallunterscheidungungen einzubauen.

Apropos "einbauen": Die Wanne ist voll: 8 Byte frei derzeit im Flash, bei bester Optimierung durch den Compiler.:shock:

:?: Hat von Euch jemand Erfahrung mit dem C-Compiler für diese AVRs? Ich weiß von früher, als ich mal 8051 in C eingesetzt hatte, daß die zusätzliche Angaben, wo die Variablen im Speicher liegen (RAM, iRAM, XRAM, CODE), den Codeballast extrem reduziert haben, weil der Compiler nicht jedesmal alle Möglichkeiten berücksichtigen muß. Die AVRs sind neu für mich, aber vielleicht hat ja jemand von Euch ein paar Tips auf Lager, abgesehen von "Redundanzen eindampfen". Der Compiler macht bei der Optimierung nämlich einen recht guten Job, als ich doppelte Aufrufe in eine Funktion ausgelagert habe, war's am Schluß nicht weniger, sondern etwas mehr.

Die neuen zusätzlichen Menüpunkte hab ich jedenfalls mal drin, es fehlt noch die Berechnung der Marker für den Relativmodus und wohl noch ein paar Kleinigkeiten. Naja, werde ich schon reinkriegen.

Aber nach meiner Ansicht, sieht das alles schon recht schick aus. Ich hatte zwar erwartet, daß durch die Menüumbauten und die Umstellung der Philosophie einige Dinge klemmen, aber ein Kurztest gestern abend sah schon recht ermutigend aus, daß die Dinge alle wieder an ihrem Platz sind.

Wird ja fast ein Entwicklungstagebuch hier. :lol:

Viele Grüße
Paul
Benutzeravatar
ompf
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 168
Registriert: 19.01.2008, 13:03
Wohnort: Dortmund

Beitrag von ompf »

Hallo Paul,
psclab38 hat geschrieben:Macht Lin überhaupt Sinn?
Beim absoluten Sweep von A nach B würde ich LIN drinlassen. Hier auch mit Marken, die waren ja ohnehin auf festen Positionen. Das frißt kein Brot und vielleicht kann man es mal brauchen. Beim relativen Sweep um die Mittenfrequenz kannst Du Dich imho problemlos auf log beschränken.
psclab38 hat geschrieben:Warum hast Du den Markerfaktor 1.1 aufgeführt? Wie kommst Du auf den Wert?
Um neben den Boxenbauern auch an die Nachrichtentechniker zu denken. Es gibt ja durchaus Systeme mit etwas höherer Schwingungsgüte, wo Du mit der doppelten und halben Frequenz schon weit außerhalb bist. Daher hatte ich an 10% gedacht.
psclab38 hat geschrieben:Aber noch was anderes: sollen die Werte nach Eingabe im Center/Span-Mode nach Umschaltung in den Start/End-Mode entsprechend umgerechnet werden?
Meine Antwort kommt zu spät, Du hast es ja schon drin. Halte ich auch für eine gute Idee, denn so hat jemand, der sich unter 1kHz +/-1 Oktave nichts vorstellen kann, die Möglichkeit, 500..2000Hz direkt einzukurbeln.

Langsam wird es Zeit, die hardwarenahen Teile des Codes auf Assembler umzustellen. Oder wir bauen uns alle einen Satz ATmega644P rein, dann ist wieder eine Weile Ruhe.



Gruß
Patrick
Benutzeravatar
ompf
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 168
Registriert: 19.01.2008, 13:03
Wohnort: Dortmund

Beitrag von ompf »

psclab38 hat geschrieben:Hallo DDS-Freunde,

Aber nach meiner Ansicht, sieht das alles schon recht schick aus. Ich hatte zwar erwartet, daß durch die Menüumbauten und die Umstellung der Philosophie einige Dinge klemmen, aber ein Kurztest gestern abend sah schon recht ermutigend aus, daß die Dinge alle wieder an ihrem Platz sind.
Das ist ja auch eine feine Sache, was Ihr hier abliefert. Kann man ruhig nochmal erwähnen.

Was ich nur irgendwie schade finde, ist diese Doppelarbeit. cm liefert eine Firmware ab, schiebt sogar noch ein paar Bugfixes nach, und dann fangt Ihr wieder bei Null an. Wenn die c't das Lab direkt als open source aufgezogen hätte (so wie den Bot) dann wäre ein deutlich besseres System rausgekommen. Und der einzige Entwickler in Hannover wäre nicht komplett abgesoffen.


Gruß
Patrick
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

Hallo Freunde,
ompf hat geschrieben:Was ich nur irgendwie schade finde, ist diese Doppelarbeit. cm liefert eine Firmware ab, schiebt sogar noch ein paar Bugfixes nach, und dann fangt Ihr wieder bei Null an. Wenn die c't das Lab direkt als open source aufgezogen hätte (so wie den Bot) dann wäre ein deutlich besseres System rausgekommen. Und der einzige Entwickler in Hannover wäre nicht komplett abgesoffen.
das liegt an der Aversion von CM gegenüber C. Er hat ja schon mehrfach mit Ausdrücken wie "das sieht aus, als hätte jemand ein Gürteltier über die Tastatur gewälzt" seinen Standpunkt klargemacht. Ich finde es allerdings merkwürdig, dass er hier gegen den Strom schwimmt. Klar, es gibt AVR-Basic (in mehreren Varianten), AVR-Pascal (dito) und noch andere Sprachen. Aber unumstritten wird C am häufigsten eingesetzt. Und, wenn man mal von einigen Abkürzungen wie "(x>0)?0:1" absieht, ist C nicht wirklich kryptisch. Wenn man es ordentlich formatiert im Editor eingibt, ist es sogar ziemlich übersichtlich. Und das Hauptargument für unsere Sache: Es existiert ein freier Compiler (gcc), welcher zwar noch nicht ganz an die kommerziellen Produkte heranreicht was Codegröße und/oder Geschwindigkeit angeht, aber er macht das private Entwickeln von (C-)Code überhaupt erst möglich.

@Paul: Vielen Dank für Deine Arbeit am Projekt! Ich bin von den implementierten Features beeindruckt. Auch der Center-Sweep scheint mir eine sehr sinnvolle Sache zu sein.
Apropos "einbauen": Die Wanne ist voll: 8 Byte frei derzeit im Flash, bei bester Optimierung durch den Compiler.
Das ist natürlich bitter. Als ich mit Jörg an dem Projekt arbeitete, war uns klar, dass noch einiges vom Code in main.c optimiert werden muss (besonders die Initialisierung und Bereichsprüfung). Dort ist noch einiges an Redundanz vorhanden. Allerdings werden da, selbst bei sorgfältiger Optimierung, nur viele hundert Bytes, bestenfalls 1-2 KB frei. Langfristig ist zwar der Vorschlag von Patrick, einen ATmega644P einzubauen, die einzig richtige Lösung, aber das sperrt leider alle User aus, welche sich den Umbau nicht zutrauen. Und dauerhaft zwei Varianten parallel zu pflegen (eine für den ATmega32 mit weniger Features) ist wohl auch recht anstrengend. Man sollte aber mal drüber nachdenken.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Hallo DDS-C-Freunde,

ich hab heute abend in der C-Firmware noch ein wenig gestaucht und gedrückt, da sind dann hier und dort noch ein paar Byte freigeworden. Aber die gleiche Aktion, die hier was gebracht hat, war an anderer Stelle kontraproduktiv. Naja, hat vielleicht damit zu tun, daß der Compiler schon in der höchsten Kompressionsstufe arbeitet, da ist dann der Assemblercode auch kaum mehr zu verstehen.
@Paul: Vielen Dank für Deine Arbeit am Projekt! Ich bin von den implementierten Features beeindruckt. Auch der Center-Sweep scheint mir eine sehr sinnvolle Sache zu sein.
Thoralt, vielen Dank für das Lob. Aber ihr habt ja die Grundlagen gelegt und ich hab mich halt "nur" in die noch ausstehenden Punkte reingefräst. Macht wieder richtig Spaß, so an einer Firmware rumzuschrauben. War mir bislang nicht so richtig wohl bei dem Gedanken, daß ich an der PascalVersion nicht im Notfall selbst rumschrauben kann. Ich stehe mit Jörg in Kontakt und wir werden demnächst besprechen, wie wir (nach ein wenig Qualitätssicherung) meine Änderungen im CVS einpflegen, sofern sie mehrheitsfähig sind.:oops:

Die Marker im Center-Mode sind jetzt auch an Ort und Stelle, nur ein Problem hab ich noch nicht gelöst: Die Menustrukturdefinitionen sind statisch, können also zur Laufzeit nicht geändert werden. Damit dürfte es schwierig werden, das SweepMenü zur Laufzeit so ändern, daß es mal Sweep-Start und -Ende (absolut-Mode) und im anderen Fall Sweep-Center und -Span (relativ-Mode) anzeigt. Momentan ist beides gleichzeitig aktiv, was zwar auch brav funktioniert, aber eigentlich nicht das ist, was ich wollte. Den absoluten oder relativen Mode stellt man jetzt nämlich im Hauptmenü ein, damit sollten im Untermenü auch nur die jeweiligen Punkte vorhanden sein, weil sonst mehr verwirrt (und man sich bei Schreiben des Manuals im Kreis dreht).

Mal sehen, vielleicht finde ich noch eine Möglichkeit. Im Moment kann ich mich wieder auf 384 Byte austoben. :?

Viele Grüße
Paul
amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 »

psclab38 hat geschrieben:
Mal sehen, vielleicht finde ich noch eine Möglichkeit. Im Moment kann ich mich wieder auf 384 Byte austoben. :?
Wenn es mit dem Speicher eng wird, kanns Du ja mal ein Compiler-Downgrade machen. Für das DDS ergibt sich dann:

GCC 2007-05-27 27996 Bytes
GCC 2008-06-10 28752 Bytes

Der eigentliche Übeltäter ist die libc. Für einen speziellen Boot-Loader verwende ich GCC 2005-02-14. Mit allen neueren Compilern wird der Code zu groß.

Gruß
amd-65
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Hallo amd-65,

danke für den Tipp. Daß der Compiler mit den Jahren immer fetter wird, ist bei Microcontrollern keine soo schöne Entwicklung. Aber ich hab mir mal die alten Stände, die Du erwähnt hast, runtergeladen.

Ich hab sie aber noch nicht installiert, das geht wohl nur exclusiv, und nicht parallel... Bislang habe ich noch so einige Byte durch Hinsehen und Redundanzvermeidung rauskitzeln können, insgesamt wohl so ca. 750Byte. Aber fast alles wieder verbraucht :?

Es gibt wohl noch einige Ansatzpunkte, Platz zu sparen, aber irgendwann wird's dann mühsam und der Code wird dann u. U. kaum mehr lesbar.

Das mit dem dynamischen Menü hab ich noch nicht geknackt, vielmehr hab ich alle Panel- und Displayfunktionen nachgezogen, die noch gefehlt haben. Und: die Sweepfunktionen sind jetzt auch alle im Onlinemodus verfügbar, obwohl sie eigentlich bevorzugt für den Standalonebetrieb da sind.

Jetzt stehen noch einige Aufräumarbeiten und ein kleines Codereview an. Ich melde mich wieder...

Viele Grüße
Paul
amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 »

psclab38 hat geschrieben:Hallo amd-65,
Ich hab sie aber noch nicht installiert, das geht wohl nur exclusiv, und nicht parallel...
Du kannst die einzelnen Versionen parallel installieren (zumindestens unter Windows). Bei der Installation gibst Du das Installationsverzeichnis an und sagst irgendwo, daß die Environment-Variablen nicht aktuallisiert werden sollen.

Im AVR-Studio kannst Du unter Project->Configuration Options->Custom Options den Compiler und das Make-Tool angeben. Wenn Du das Makefile direkt verwendest, ist es noch einfacher. Du must nur TOOL_PREFIX auf das gewünschte Verzeichnis mit dem Compiler setzen.

Gruß
amd-65
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Beitrag von psclab38 »

Vielen Dank, das ist ein guter Hinweis. Hätt ich gar nicht gedacht, daß das doch geht.
Werd' ich ausprobieren...

Viele Grüße
Paul
Antworten