Funktionsprinzip der Software

[magicroomy]

Hallo Thoralt,
ich spiele mit dem Gedanken auch mal ein kleines Hardware Modul für das Lab zu bauen. Im Moment schwebt mir ein Frequenzzähler vor.
Nagel mich da aber bitte nicht fest. Im Moment geht es mir drum einen Entwicklungsbasissatz zu haben, auf dem ich dann verschiedene Module aufbauen könnte, weil vieles ja gleich ist (Firmware Parser z.B.)

Was mich dabei brennend interessiert ist:
Gibts eine Minidoku zur DDS Firmware (Funktionsabläufe)?
Wie funktioniert es intern? Was fangt ihr alles über Interrupts ab?
Wie funktioniert der Parser? Kann ich den für mein Modul adaptieren?
Wenn ja, wie?
Wie ist der Kontrollfluß im Programm? Wird irgendwas überhaupt noch in der Main Methode abgehandelt?

Fragen über Fragen

Gruss
Magic Roomy

[HSiebrecht]

Hallo Volker,

ich spiele mit dem Gedanken auch mal ein kleines Hardware Modul für das Lab zu bauen. Im Moment schwebt mir ein Frequenzzähler vor.

kennst Du den Thread von "Rasieel" ? Wenn ja, vergiss den Rest.

http://thoralt.ehecht.com/phpbb/viewtopic.php?t=103

Da gibt es schon mal ein "bisschen" Hardware und die Firmware in C für einen ATmega 16. ( Frequenzzähler bis 70 MHz, hat doch schon mal was. )

CM hat ja auch noch einen Frequenzzähler in der Pipeline.

[magicroomy]

Hi nochmal,

wie gesagt, ob es ein Frequenzzähler wird weiss ich noch nicht sicher.
Was mir prinzipiell vorschwebt ist folgendes:

1. Eine Platine mit einem Lochrasteranteil. Im "Standardteil" der Platine ist ein ATMega 32 (z.B.) mitsamt der Gluelogik für den Optobus, ein PM8 und dem Stromanschluss per PS3 oder IFP.
Auf dem Lochrasterteil sind dann die freien Ports des ATMega verfügbar und man kann basteln wie man will.

2. Eine "Rumpf Firmware". Da sollte ein Parser enthalten sein, dem man dann "nur noch" die Kommandos oder Subchannels+ die notwendigen Funktionen für die neue Platine beibringen muß.

Für 1. kann man ja irgendein Modul hernehmen und abstrippen. Sollte nicht schwierig sein.
Für 2. brauchts ein wenig mehr Info. Auf die war ich scharf. Sofern ihr die rausgeben wollt.

Gruss
Volker

[amd-65]

Was mich dabei brennend interessiert ist:
Gibts eine Minidoku zur DDS Firmware (Funktionsabläufe)?
Wie funktioniert es intern? Was fangt ihr alles über Interrupts ab?
Wie funktioniert der Parser? Kann ich den für mein Modul adaptieren?
Wenn ja, wie?
Wie ist der Kontrollfluß im Programm? Wird irgendwas überhaupt noch in der Main Methode abgehandelt?

Es gibt eine Reihe von SW-Modulen, die sind unabhängig vom einzelnen HW-Modul, teilweise auch komplett unabhängig vom ctLab. Das sind im einzelnen:
- encoder.c / encoder.h
- i2c.c / i2c.h und i2creg.c / i2creg.h (bzw. i2creg16.c / i2creg16.h)
- lcd.c / lcd.h
- parser.c / parser.h
- uart.c / uart.h
- debug.h

Den SW-Modulen, die spezielle Funktionen für ein HW-Modul implementieren, habe ich ein 'dcg-' bzw. 'edl-' im Namen mitgegeben. Bei timer.c/timer.h ist mir mit dem Namen ein Ausrutscher passiert.

Für eine Minimalfunktionalität kannst Du Dir mal die edl-SW anschauen. Die kann fast nichts. Es gibt einen angepaßten Parser und ein paar Initialisierungsfunktionen.

Gruß
amd-65

[thoralt]

Hallo magicroomy,

[...] Im Moment schwebt mir ein Frequenzzähler vor.

siehe auch das Projekt von klaus_phi, welches er im Forum vorgestellt hat: http://thoralt.ehecht.com//phpbb/viewtopic.php?t=73. Dieses Gerät scheint auch mit CM abgestimmt zu sein und wird vielleicht einmal in der c't veröffentlicht. Also wenn Du einen Frequenzzähler baust, dann mach ihn "quick&dirty" und stecke nicht zuviel Arbeit rein

Das von Dir angestrebte "Universalmodul" halte ich für eine gute Idee.

Was mich dabei brennend interessiert ist:
Gibts eine Minidoku zur DDS Firmware (Funktionsabläufe)?

Nein.

Wie funktioniert es intern? Was fangt ihr alles über Interrupts ab?

Im DDS-C wird nur der Timer-Interrupt genutzt. Er wird alle 500 us aufgerufen und dort werden alle möglichen Timervariablen verändert (z. B. Burst, Sweep, Pausen). Außerdem wird hier der Inkrementalgeber periodisch abgefragt. Des strengen Timings wegen wird der Burst-Modus direkt aus dem Timer-Interrupt heraus gesteuert. Die anderen Sachen werden global in Variablen geändert und dann in der Idle-Schleife (main) regelmäßig in die Hardware geschrieben, falls sich Werte ändern.

Wie funktioniert der Parser? Kann ich den für mein Modul adaptieren? Wenn ja, wie?

Sieh Dir dazu am besten den Quelltext an. Es existieren momentan bereits Quelltextzweige für DCG, DDS und EDL (alle im Projekt dcg-firmware auf sourceforge.net). Dort siehst Du die Unterschiede der verschiedenen Parser.

Wie ist der Kontrollfluß im Programm? Wird irgendwas überhaupt noch in der Main Methode abgehandelt?

Ja. Es gibt einen zentralen JobLoop(), dort werden alle nicht zeitkritischen Sachen abgehandelt: TRMSC-Messung, Autorange, Aufruf der LCD- und Button-Funktionen (jobPanel()). Weiterhin wird regelmäßig der Parser aufgerufen (jobParseData()) und die Hardware ggf. neu eingestellt (jobExecute()).

Über die genaue Funktionsweise von Parser- und Panel-Routinen solltest Du Dich in den Sources schlaumachen. Es existieren in beiden Modulen umfangreiche Datenstrukturen (struct), welche jede Menge Pointer auf Funktionen und Werte enthalten. Dies macht die Routinen extrem flexibel und einfach erweiterbar.

Konkrete Fragen beantworten wir natürlich jederzeit gerne, nur waren Deine Fragen sehr allgemein und ich will jetzt hier auch keine Romane schreiben

Viele Grüße
Thoralt

[linux-is-sexy]

Ist ein kleinwenig off topic, aber: WARUM HABT IHR (NUR) CVS?????


Gruesse LiS

[amd-65]

Ist ein kleinwenig off topic, aber: WARUM HABT IHR (NUR) CVS?????

Ganz einfach, ich bin ein Newbie in Project-Management bei SF.

Man könnte die Frage auch anders stellen: Warum benutzt Ihr nicht BitKeeper, Source Integrity, Mercurial, Git, Visual Source Safe oder was auch immer?

Gruß
amd-65

[linux-is-sexy]

Sorry, das war nicht boese gemeint. Im allgemeinen ists so, dass svn cvs abloest und ich mich halt sehr gewundert habe, warum ein recht junges projekt cvs nimmt.

Ich z.B. habe 1.8gb quelltext auf meinem Rechner und cvs gar nicht installiert gehabt, weil es inzwischen so selten geworden ist...aber wie gesagt nichts fuer ungut...

Gruesse
LiS

[magicroomy]

Danke für die Antworten. Werde mir jetzt mal die Sourcen komplett laden und mich dann mal vertiefen, sobald ich dazu komme.
War nur mal eine erste Anfrage für das grobe Verständnis. Bei konkreten Fragen quäle ich euch wieder

Gruss
Magic Roomy