Neue Firmware DDS-C RC0

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

Neue Firmware DDS-C RC0

Beitrag von psclab38 »

Hallo c't-Lab und DDS-Freunde,

lange Zeit war's ruhig hier in Sachen C-Firmware für die DDS. Das heißt aber nicht, daß nichts passiert ist.

Ich möchte Euch heute mal den aktuellen Stand bei der C-Firmwareversion für das DDS-Modul vorstellen, den ich einfach RC0 genannt habe. Seit dem Start des letzten Threads für die 1.0beta hat sich viel getan und neben vielen Bugfixes sind unter anderem folgende Features hinzugekommen:


- Frequenzeingabe auch in Terzschritten per Menü

- Spannungseingabe auch in PeakPeak-Werten per Menü

- Standalone Sweep per Menü

+ lin / log
+ Eingabe mit Start/Stop oder Center/Span-Frequenzen
+ mit Markern im Log-Modus (relativ zur Centerfrequenz oder an den Terz- bzw. Dekadenfrequenzen)
+ Ausgabe des Syncsignals auf PL5

- Abhärtung des Kommandointerpreters gegen verstümmelte oder falsch formatierte Befehle

- Encoder läuft jetzt "runder"

- ... viele andere Details


Die Firmware findet ihr hier:
http://dcg-firmware.cvs.sourceforge.net ... -firmware/

und die dazugehörigen Quellen hier:
http://dcg-firmware.cvs.sourceforge.net ... mware/dds/

Wer sich für die Änderungsgeschichte interessiert, hier ist alles dokumentiert:
http://dcg-firmware.cvs.sourceforge.net ... ngelog.txt

Der Stand ist zwar zwei Monate alt, aber läuft zu meiner Zufriedenheit. Wilkeltus war so freundlich und hat neben eigenen Modifikationen auch immer mal wieder Platz geschaffen, damit ich wieder neue Funktionen dazufügen konnte (der Flash-Speicher ist fast voll, wir kämpfen mittlerweile um Bytes). Ompf hat sich als Betatester angeboten und prima Feedback geliefert. Vielen Dank an Euch beide an dieser Stelle!

Leider sind wir alle dann ab Oktober mit der Arbeitslast "im richtigen Leben" derart überfordert worden, so daß sich erst jetzt wieder Zeit finden ließ.


Bitte beachten, wenn Ihr die Firmware auf Euer Modul aufspielt:
1.) Rettet Eure alten Kalibrierdaten der Pascal-Firmware. M.W. sind die Kalibrierdaten leider nicht mit der C-Firmware kompatibel.

2.) Die C-Firmware braucht für die Optobus-Fernsteuerung IMMER (!) die Adressangabe (z.B. "#5:"). Der Hintergrund ist, daß bei Reihenschaltung von vielen Modulen ab und an gerne mal verstümmelte Kommandos weitergereicht werden, und dieser Sachverhalt wird dann damit erkannt. Das "Feature" läßt sich aber auch vor Kompilierung abschalten, wenn es stören sollte. Für die Fernsteuerung per LabView oder JLab ist es transparent und fällt nur im Handbetrieb im Terminalprogramm auf.

3.) Die Ausgabe des Sync-Signals für den Sweep erfolgt über den dafür vorgesehenen Anschluß PL5, der aber auf Logik-Masse liegt. Der Signal-Ausgang liegt aber auf der Offsetspannung und so kann es bei aktivertem Offset zu einem Kurzschluß der Offset-Treiberstufe kommen. Thoralt hat im letzten Thread schon mal eine Schaltung präsentiert, die das vermeidet. Ich habe mich dieser bedient und sie mal grob dimensioniert. Sie funktioniert wunderbar, nur der Z-Diode muß man noch einen Widerstand parallel schalten, damit die Abfallzeit im Rahmen bleibt. Schaltung siehe unten.


Über Euer Feedback würden wir uns sehr freuen!

Viele Grüße
Paul


P.S:: Ein ungelöstes Problem haben wir noch: es gab mal einen Absturz, wobei wir aber nicht sagen können, wie die Vorgeschichte dazu war. Wir zählen da auf Euch und Eure sachdienlichen Hinweise!
Dateianhänge
SyncOut.png
SyncOut.png (6.37 KiB) 9537 mal betrachtet
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Beitrag von thoralt »

Hallo Paul,

vielen Dank für das Release! Ich wundere mich, dass nicht schon viele viele Kommentare geschrieben wurden, zumal die Firmware doch viele nette Erweiterungen gegenüber der 1.0beta hat... Entweder sind alle noch müde von der Silvesterfeier oder keiner traut sich :)

Inhaltlich kann ich noch kein Feedback geben, da mein DDS momentan nicht hier auf meinem Schreibtisch steht. Bei nächster Gelegenheit werde ich allerdings ein bißchen damit rumspielen.

Ich habe einige Experimente bezüglich der Codegröße unternommen. Vom avr-gcc 3.4.6 liest man im Netz häufiger, dass er meist kleineren Code erzeugen kann als die Versionen 4.x.x - daher habe ich mal einen Vergleich angestellt und war einigermaßen enttäuscht:
3.4.6: .text = 34454
4.3.2: .text = 33938
Wenn man noch einige Flags zum Aufruf von avr-gcc hinzufügt (-fno-inline-small-functions -fno-split-wide-types -fno-tree-scev-cprop -Wl,--relax), dann wird daraus:
4.3.2: .text = 32288

Nur mit dieser Einstellung bekomme ich also den Quellcode überhaupt unter 32 kB - mit welchem Compiler hast Du compiliert? Wir benutzen ja das gleiche Makefile, also sollte der Rest identisch verlaufen. Möglicherweise sparen die o. g. Optionen auch noch ein paar Bytes mehr bei Dir.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
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 »

thoralt hat geschrieben:Ich habe einige Experimente bezüglich der Codegröße unternommen. Vom avr-gcc 3.4.6 liest man im Netz häufiger, dass er meist kleineren Code erzeugen kann als die Versionen 4.x.x - daher habe ich mal einen Vergleich angestellt und war einigermaßen enttäuscht:
3.4.6: .text = 34454
4.3.2: .text = 33938
Wenn man noch einige Flags zum Aufruf von avr-gcc hinzufügt (-fno-inline-small-functions -fno-split-wide-types -fno-tree-scev-cprop -Wl,--relax), dann wird daraus:
4.3.2: .text = 32288
Ich kann da auch noch Werte liefern:

avr-gcc (GCC) 4.1.2 (WinAVR 20070525): Program: 32472 bytes (99.1% Full)

avr-gcc (WinAVR 20080512) 4.3.0: Program: 33806 bytes (103.2% Full)

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 »

Hi Thoralt,
hallo amd-65,

in der Tat habe ich den Compiler 2007-05-25 verwendet, auf den Tipp von amd-65 hin, aus dem letzten Thread. Da sind die Bibliotheken ein wenig schlanker als bei den neuen. DEN Hinweis hab ich leider beim Posting oben vergessen, weil ich schon so lange eben den alten Compiler verwende. ;-)

Danke für die Tipps bzgl. der Optionen. Ich hatte auf einer Linux-Maschine auch schon festgestellt, daß der Code u. U. noch ein wenig kompakter geht. Das war unter Verwendung des makefiles aus dem Repository. Ich hab bloß die Kurve noch nicht gekriegt, den resultierenden Code von der Maschine auch mal aufs Modul aufzuspielen.

Ja, ich kann auch nur alle Leser ermuntern, sich mit Bugreports oder anderem Feedback zu beteiligen. Die DDS-C-Firmware ist jetzt echt 'ne runde Sache...

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 »

psclab38 hat geschrieben:in der Tat habe ich den Compiler 2007-05-25 verwendet, auf den Tipp von amd-65 hin, aus dem letzten Thread.
Unterscheiden sich die Compiler in ihrer Optimierung, oder liegt's eher an den Bibliotheken? Es gab vor einem Jahr mal eine (anfangs sehr umstrittene) neue FP-Bibliothek. Die sollte wohl schneller und genauer sein als die alte, aber deutlich mehr Platz brauchen.

Vielleicht sollte man den Kram doch mal auf Integer umstricken. Intern gibt es ohnehin eine Quantisierung, daher müßte man nur an den Schnittstellen zu Mensch und Maschine eine Konvertierung vornehmen.


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

Beitrag von thoralt »

ompf hat geschrieben:Vielleicht sollte man den Kram doch mal auf Integer umstricken.
Das wäre in der Tat ein lohnendes Unterfangen. Damals, als wir die Firmware anfingen, habe ich jede zusätzliche Zeile mit Floating-Point-Operationen als Sprung in der Firmware-Größe gesehen. Ich bin nicht sicher, an wievielen Stellen momentan Fließkommaoperationen gemacht werden, aber das wäre sicher ein guter Ansatzpunkt.

Gibt es Freiwillige? Falls nicht, und falls niemand anderes zur Zeit große Änderungen am Code macht, könnte ich mich in den nächsten Wochen mal drum kümmern. Allerdings muss ich erstmal mein DDS zum Laufen bekommen. Mein ursprüngliches DDS habe ich meinem Vater geschenkt, und für das zweite fehlt mir noch ein Relais (gab's nicht bei Reichelt)...

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 »

..., habe ich jede zusätzliche Zeile mit Floating-Point-Operationen als Sprung in der Firmware-Größe gesehen.
Das kann ich nur bestätigen. Bei den Erweiterungen und insbesondere bei den Einsparmaßnahmen hab ich immer versucht, die FloatingPoint-Operationen gering zu halten bzw. zu verringern. Allerdings ist so ein Umbau auf Integer schon ein großes Unterfangen, bis wieder alles richtig tickt. Wenn Du aber die Muße hast, dann wäre wieder Platz für die nächsten Features.. :lol:
Ansgard
Beiträge: 4
Registriert: 28.05.2008, 10:13

Beitrag von Ansgard »

Hallo,

tolle Arbeit.

Noch eine Bitte, könntet Ihr bei der nächsten Release folgende Terzschritte 10Hz 12,5Hz und 16Hz hinzufügen und die Werte 31Hz 120Hz 310Hz 1.200Hz 3.100Hz 12.00 kHz auf 31,5Hz 125Hz 315Hz 1.250kHz 3.15kHz sowie 12.50kHz ändern (Standartwerte).

Vielen Dank

Gruß Ansgard
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 »

Noch eine Bitte, könntet Ihr bei der nächsten Release folgende Terzschritte 10Hz 12,5Hz und 16Hz hinzufügen und die Werte 31Hz 120Hz 310Hz 1.200Hz 3.100Hz 12.00 kHz auf 31,5Hz 125Hz 315Hz 1.250kHz 3.15kHz sowie 12.50kHz ändern (Standartwerte).
Oh aua aua! Sehr gut, daß Du das gesehen hast; vielen Dank! War natürlich nicht beabsichtigt, hat u. a. mit den Platzspar-Verrenkungen zu tun gehabt.
Ich hab den Code dazu aber ein wenig umbauen müssen, damit Nachkommastellen auch erlaubt sind. Vorteil, theoretisch geht's jetzt bis runter zu einem Hertz und auch über 20kHz.

Der neue Code und ein neues Hexfile ist eingecheckt... mit Terz-Bereich zwischen 10Hz und 25kHz

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 »

Der neue Code und ein neues Hexfile ist eingecheckt... mit Terz-Bereich zwischen 10Hz und 25kHz
Hallo DDS-Freunde: Sind in der Zwischenzeit irgendwelche anderen Befunde aufgetaucht?

Übrigens, die Adapterschaltung, die ich am Anfang des Threads gepostet habe, funktioniert sehr ordentlich, lediglich bei sehr negativem Offset bricht der Highpegel des Sync-Impulses auf ca. 4.2 V ein. Das ist aber m. E. keine echte Einschränkung.

BTW: Ich hasse Drahtigel, außer zum Ausprobieren. ;-) Ich hatte mir zu einem anderen kleinen Projekt Platinen machen lassen und habe die Schaltung da einfach mit drangeflickt und dann wieder abgesägt. Siehe Bild. Die Widerstände sind 0805 SMD.

Jetzt hab ich fünf unbestückte Leiterplättchen über (bei den Mindestbestellmengen gibts immer ein paar mehr) die ich zum Selbstkostenpreis von 5€ incl. Bauteilen in der angegebenen Dimensionierung (zzgl Porto) abgeben könnte, quasi als Bausatz. Wäre schade, wenn die ungenutzt rumliegen würden. Bitte PM, wenn ihr Interesse habt.

Viele Grüße
Paul
Dateianhänge
img_1304s.jpg
img_1304s.jpg (134.99 KiB) 9251 mal betrachtet
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,

einen "Bausatz" für den Sync-Out-Adapter hätte ich noch übrig. Ist so klein, daß man ihn hinten an die BNC-Buchse anlöten kann.

Bevor ich den jetzt im Ordner abhefte, wollte ich nochmal rumfragen, ob noch jemand Interesse hat. Dann bitte PM 8)

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 »

So, der letzte "Bausatz" für den Sync-Out-Adapter ist dann auch weg. Nix mehr da.

Viele Grüße
Paul
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: Neue Firmware DDS-C RC0

Beitrag von kadun »

Hallo pcslab38,http://thoralt.ehecht.com/phpbb/posting ... f=13&t=224#
mein Kompliment für die Implementierung der DDS-Firmware in C, meine Programmierkentnisse sind leider nur rudimentär und -wie ich selber-veraltet, damit sind solche Ergebnisse für mich unerreichbar. Vielen Dank.
Die Firmware lief auf meiner neu aufgebauten DDS auf Anhieb und ich habe bisher nur einen Schönheitsfehler entdeckt den ich kurz beschreiben möchte:
Wenn man die DDS mit einem Terminal-Programm vom PC aus ansteuert kann man zwar mit "ADR:BST=1!" den Burst-Mode einschalten, aber man kommt mit "ADR:BST=0" nicht wieder in den "Normalbetrieb" zurück, am Ausgang ist dann kein AC-Signal meßbar, obwohl der Befehl zumindest teilweise verarbeitetet wird (sieht man am Panel-Display). Der AD9833 beginnt erst dann wieder zu arbeiten, wenn man über den Drehknopf am Panel den Burst-Mode ein und ausschaltet.
Eine Frage habe ich noch: Kann man die Kommandos zur Fernsteuerung über PC für die die neuen Funktionen der DDS offenlegen oder sind diese wegen Platzmangel im ATmega32 nicht realisierbar?

Gruß
kadun
Wilkeltus
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 36
Registriert: 29.11.2007, 10:06
Wohnort: Bad Soden / Ts.

Re: Neue Firmware DDS-C RC0

Beitrag von Wilkeltus »

kadun hat geschrieben:Wenn man die DDS mit einem Terminal-Programm vom PC aus ansteuert kann man zwar mit "ADR:BST=1!" den Burst-Mode einschalten, aber man kommt mit "ADR:BST=0" nicht wieder in den "Normalbetrieb" zurück, am Ausgang ist dann kein AC-Signal meßbar, obwohl der Befehl zumindest teilweise verarbeitetet wird (sieht man am Panel-Display).
Hi, das Problem geht nicht auf Paul zurück, sondern auf die alten Implementierungen von Thoralt und mir. Es gab hier das Problem, zu dem alten BST-Befehl von cm abwärts kompatibel zu bleiben. BST=1 hat eine Doppelfunktion und ist nicht primär für das Einschalten des Burst gedacht gewesen. Wenn ich mich recht erinnere, kann/konnte die Pascal Firmware nur gleiche BurstOn-Zeiten und BurstOff-Zeiten. Dieses Verhalten ist auch weiterhin gültig, wenn BST > 1 gesetzt wurde. BST = 1 erlaubt unterschiedliche ON/OFF-Zeiten und nutzt 10ms/10ms als Default (auch abwärtskompatibel). Damit wurde der Code oft mit einer Abfrage BST > 1 versehen.
So wie es aussieht, dummerweise auch, um zu bemerken, dass der Burst über UART abgeschaltet wurde. Ein >=1 anstelle von >1 in main.c an dieser Stelle sollte den Fehler fixen. Ich habe Paul das wohl nie erzählt und werde mich mit ihm einigen, wer das fixed. Ich glaube, er muss zum flashen der Testversion nicht das Gehäuse aufschrauben. Bei mir kostet das immer eine gewisse Überwindung. ;-)
kadun hat geschrieben: Eine Frage habe ich noch: Kann man die Kommandos zur Fernsteuerung über PC für die die neuen Funktionen der DDS offenlegen oder sind diese wegen Platzmangel im ATmega32 nicht realisierbar?
Keine Ahnung, ob ich die Frage richtig verstanden habe, aber es gibt auf sourceforge eine Datei DDS-Syntax.XLS, die die neue Syntax beinhaltet (bis auf die nachgezogenen OPT-Befehle der neuen cm-Firmware. Die steht noch aus, weil gleichzeitig noch eine Erweiterung unterwegs war)

Danke für den Bug!
kadun
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 14
Registriert: 09.11.2008, 12:07
Wohnort: Baden-Württemberg

Re: Neue Firmware DDS-C RC0

Beitrag von kadun »

Hallo Wikeltus
Vielen Dank für die schnelle Reaktion und den Hinweis auf die DDS-Syntax.XLS; genau das habe ich gesucht.
mit freundlichen Grüßen
kadun
Antworten