c't-Lab

Hallo Leute,

ich freue mich bekanntgeben zu dürfen, daß die C-Portierung der DDS-Firmware soweit gediehen ist, daß wir sie in den öffentlichen Betatest schicken können. Entgegen der im Open-Source-Bereich sonst üblichen Understatement-Numerierung, nach welcher wir vielleicht bei der Version 0.1.0 oder so wären, haben wir uns auf 1.0beta festgelegt, weil hier bereits alle Funktionen der Originalfirmware (und einige interessante Funktionen mehr) enthalten sind.

Wie gesagt - die Originalfunktionen werden weiterhin unterstützt. Hier eine Liste von Neuigkeiten in der C-Firmware:
- Werteeingabe über Encoder ohne Umschaltung der Genaugikeit, da eine Beschleunigung implementiert wurde (langsames Drehen bewirkt kleine Änderungen, schnelles Drehen große Änderungen)
- Scrolling langer Parameternamen
- Frequenz bis 300 kHz am Panel einstellbar
- im Logikmodus: H- und L-Pegel getrennt einstellbar
- Burst-Modus: An- und Auszeit getrennt einstellbar
- Sweep-Modus (mit Sweep Up, Down, Up+Down, Startfrequenz, Endfrequenz und Sweepzeit)
- TRMSC: Autorange, zuschaltbare dauerhafte Messwertanzeige
- automatisches oder manuelles Speichern aller Einstellungen im EEPROM

Die EEPROM-Einstellungen sind momentan noch nicht kompatibel zur Originalfirmware. Wir arbeiten an einer Datenübernahmelösung. Also denkt bitte daran: Der EEPROM muß _vor_ dem Ausprobieren der neuen Firmware gesichert werden (z. B. über Ponyprog), sonst sind Eure evtl. eingestellten Kalibrierwerte hinüber!

Die Hexdatei habe ich angehängt. Es existiert auch eine Dokumentation als PDF-Datei, die durchaus lesenswert ist (Achtung: Das Forum schneidet leider den Link an den '*' ab, bitte den ganzen Link kopieren und in die Adresszeile einfügen): http://dcg-firmware.cvs.sourceforge.net ... german.pdf

Weiterhin haben wir eine Excel-Datei angelegt, welche alle unterstützten Paramter (über Optobus) dokumentiert: http://dcg-firmware.cvs.sourceforge.net ... xDDS-C.xls

Im CVS gibt es auch noch eine TODO-Datei, dort stehen unsere offenen Punkte drin.

Momentan werden alle nötigen Kalibrierwerte über Optobus unterstützt (WEN/SCL). Prüfsummen sind noch nicht implementiert, sind aber in Arbeit.

Geplante Features sind (ohne Rücksicht auf tatsächliche Realisierbarkeit):
- PWM (Hardwareausgang OC1B des ATmega an Ext. In)
- AM und FM
- evtl. Offsetmodulation
- vordefinierte Werte für Logikmodus (CMOS, ECL, TTL, 3.3 V, ...)

So, jetzt seid Ihr gefragt. Bitte probiert die Firmware aus und berichtet über Eure Erfahrungen. Wenn Ihr Probleme oder Fehler findet, dann versuchen wir die natürlich so schnell es geht zu beheben. Und wenn Ihr Verbesserungsvorschläge habt, dann natürlich auch her damit!

Viele Grüße
Thoralt (und, in Vertretung, Jörg)

Zum Thema EEprom übernahme:

1. Also einerseits sollte das ParamBackupRestore.vi nach dem Patch von psclab laufen.
2. Dann hat magic roomy eine Jlab version mit diesem Feature eingestellt (1.4). Kann man ja mal ausprobieren. (Würde ich eher machen, als mit den Vis)
3. UND für die LabView-Verweigerer:
Es sind ja derzeit nur 8 echte Parameter von denen 6 Kalibrierdaten enthalten. Deshalb hab ich diese Werte mit den Befehlen SCL0?; SCL1?; SCL10? SCL11? SCL12? SCL13? mit Hyperterm ausgelesen, in eine Notepad datei gepackt, ein Ausrufezeichen hinter die Antworten gesetzt, jeweils ein WEN=1! eingeschoben und das ganze wieder auf der neuen DDS-Firmware eingespielt. Erschien mir als das Sicherste, da man hier alles selber in der Hand hat.

Gute Arbeit, Respekt! Soviel Freizeit müßte man nochmal haben

Hierzu allerdings noch ein Hinweis: kein Mensch braucht einen linearen Sweep. Zur Messung von Frequenzkennlinien sweept man entweder oktavisch (d.h. Faktor 2 pro Zeiteinheit) oder dekadisch (d.h. Faktor 10 pro Zeiteinheit). Entsprechend wird als Parameter nicht die Zeit für den kompletten Sweep vorgegeben, sondern die Zeit für eine Oktave oder Dekade.


Gruß
Patrick

Wow auch von mir ein "fetter Respekt" !
Das Lesen der Featureliste zündet sofort einige Ideen für JLab.
Ich werde mir mal ein Variantenkonzept überlegen, dann kann ich die verschiedenen Varianten von Firmware mit unterschiedlichen Features besser unterstützen, ohne zu viel Code duplizieren zu müssen.
Das unterbricht natürlich meine ersten Überlegungen für mein neues Projekt ... JLab auf meinem Handy über Bluetooth... Das Leben ist hart.

Gruss Magic Roomy

Hi,
erstmal vielen Dank!!! Das finde ich richtig gut!

Das unterbricht natürlich meine ersten Überlegungen für mein neues Projekt ... JLab auf meinem Handy über Bluetooth... Very Happy Das Leben ist hart.

Wenn du schon dabei bist: Dann mach das direkt fuer Android
http://code.google.com/android/


Gruesse
LiS

Android.... pfffffffffffffff... inkompatibles proprietäres Zeuch

Noch!! Google wird das alles freigeben

Hi,
beim Versuch die Software zu kompilieren habe ich folgenden fehler erhalten:

Compiling: parser.c
/usr/bin/avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -DUART_BAUDRATE=38400 -DUART_2X -I /usr/include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Werror -Wstrict-prototypes -Wa,-adhlns=parser.lst -std=gnu99 -MD -MP -MF .dep/parser.o.d parser.c -o parser.o
parser.c:1: error: target system does not support the "dwarf-2" debug format
make: *** [parser.o] Error 1

Koennt Ihr damit etwas anfangen?

Compiling: parser.c
/usr/bin/avr-gcc -c -mmcu=atmega32 -I. -g -DF_CPU=16000000UL -DUART_BAUDRATE=38400 -DUART_2X -I /usr/include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Werror -Wstrict-prototypes -Wa,-adhlns=parser.lst -std=gnu99 -MD -MP -MF .dep/parser.o.d parser.c -o parser.o
cc1: warnings being treated as errors
parser.c: In function 'SerPrompt':
parser.c:51: warning: implicit declaration of function 'printf_P'
make: *** [parser.o] Error 1

Passiert, wenn ich das Debugflag auskomentiere...

Gruesse Lis

Hallo,

linux-is-sexy hat geschrieben:parser.c:1: error: target system does not support the "dwarf-2" debug format

Welche Version von avr-gcc und binutils setzt Du ein? Klingt nach einem veralteten Compiler.

parser.c:21:26: error: avr/pgmspace.h: No such file or directory
parser.c:22:24: error: avr/eeprom.h: No such file or directory
parser.c:51: warning: implicit declaration of function 'printf_P'
parser.c:51: warning: implicit declaration of function 'PSTR'

Das ist merkwürdig: avr/pgmspace.h und avr/eeprom.h werden doch auch von main.c eingebunden. Gibt es dort keine Fehler? Diese Dateien gehören bei einer ordentlichen AVR-Toolchain zwingend dazu. Bist Du sicher, daß Deine Toolchain auf dem neuesten Stand ist?

Viele Grüße
Thoralt

avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../build-tree/gcc-4.1.0/configure -v --enable-languages=c,c++ --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --disable-libssp --build=i486-linux-gnu --host=i486-linux-gnu --target=avr
Thread model: single
gcc version 4.1.0

Ich meine 4.1.0 sollte ok sein...

Mein avr-libc ist version 1.4.7-1, bin-utils 2.18!

Die sache mit den Libs habe ich einfach uebersehen, dass ich die net installiert hatte, habe die Fehlermeldung mit Debug auskomentiert und installierten libs ins vorherige Post gestellt.

Gruesse LiS

Welche Version von avr-gcc und binutils setzt Du ein? Klingt nach einem veralteten Compiler.

Da hattest du recht...Fehler behoben.

Jetzt kommt noch:

Compiling: main.c
/usr/bin/avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -DUART_BAUDRATE=38400 -DUART_2X -I /usr/include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Werror -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o
cc1: warnings being treated as errors
main.c:137: warning: implicit declaration of function 'FDEV_SETUP_STREAM'
main.c:137: error: '_FDEV_SETUP_WRITE' undeclared here (not in a function)
main.c:137: error: invalid initializer
main.c: In function 'main':
main.c:328: warning: implicit declaration of function 'sprintf_P'
make: *** [main.o] Error 1

Installiert ist: avr-gcc 4.2.2 & avr-libc 1.4.7

Gruesse LiS

linux-is-sexy hat geschrieben:Da hattest du recht...Fehler behoben.

Schön.

linux-is-sexy hat geschrieben:Jetzt kommt noch: [...]
main.c:137: warning: implicit declaration of function 'FDEV_SETUP_STREAM'
main.c:328: warning: implicit declaration of function 'sprintf_P'

Installiert ist: avr-gcc 4.2.2 & avr-libc 1.4.7

Das wundert mich. Normalerweise gehören diese Prototypen bzw. Makros in die <stdio.h>. Es sieht immernoch so aus, als würde Dein Compiler nicht die aktuelle avr-libc bzw. deren Headerdateien benutzen. Eins der Flags aus Deinem Compieraufruf ist "-I /usr/include" - auf meinem System (MacOS) liegen die AVR-Includes aber in einem Extra-Verzeichnis. Schau mal bei Dir nach, es sollte sowas wie /usr/avr/include oder /usr/include/avr sein. Da liegen die AVR-spezifischen Headerdateien. Du hast offensichtlich versucht, mit den Headerdateien für Linux-Executables zu compilieren.

Viele Grüße
Thoralt

Da liegen die AVR-spezifischen Headerdateien. Du hast offensichtlich versucht, mit den Headerdateien für Linux-Executables zu compilieren.

Jo hast recht, das habe ich voellig uebersehen da mal zu schaun, da waere ich glaub ich auch net drauf gekommen, weil ich gewohnt war: ./configure, make, make install zu machen und die Libs da eigentlich immer am selben Ort sind.

Danke fuer die Hilfe

LiS

Hallo Freunde,

ich bin ja fast sprachlos. Das nenne ich eine professionelle Beta: Allein schon für die bebilderte Doku habt Ihr einen Preis verdient!
Und die Firmware: Reinladen und läuft.

Ich bin jetzt noch nicht dazugekommen, mir alles im Detail anzusehen, aber sieht alles schon mal sehr schön aus.
Nur im TRMSC-Mode hat sich die Anzeige irgendwann verhakt und keine echten Meßwerte mehr angezeigt sondern immer nur das gleiche. Ich hab aber keine Ahnung, wie ich das provoziert hab.

Da fehlt nicht mehr viel. Nochmal großes Lob.

Das freut uns aber sehr! Schau doch bitte auch mal, ob Dein Optobus-Übertragungsproblem noch auftaucht.

Bei der TRMSC-Anzeige kann es ein Problem mit der Autorangefunktion geben. Der gleiche Messwert wird evtl. durch unbeabsichtigtes Hochschalten in den nächsten Gang schlechter gerundet dargestellt. Ich hatte das Problem auch schon und wir werden daran gehen. Abhilfe sollte schaffen, wenn Du in diesem Fall einen festen Range auswaehlst.

Nochmals vielen Dank für das Feedback!