Hallo liebe Sternfreunde,
im zweiten Teil möchte ich näher auf den µC ATMega8, die Pinbelegung der Steuerung und schließlich auf die Programmierung in Interrupts eingehen.
Hier noch ein paar Kennwerte des µC: Der ATMega8 besitzt drei verschiedene Speicher. Einmal einen 8kByte Flash-ROM, das ist der Programmspeicher, wo aber auch u.a. die Montierungsdaten hinterlegt sind. Der Speicherinhalt bleibt nach dem Ausschalten permanent erhalten. Dann gibt es 1kByte SRAM (statischer RAM), der Speicherinhalt geht nach dem Ausschalten verloren. Und zum dritten gibt es 512Byte EEPROM, das ist ein elektrisch programmierbarer Festspeicher. Auch hier bleibt der Speicherinhalt erhalten. Die Speichergrößen hören sich sehr klein an, reichen aber für die vorgestellte Handsteuerbox völlig aus. Alle speicherintensiven Aufgaben (das ganze GoTo) läuft auf dem Konsolenprogramm am Laptop.
Das Bild unten zeigt die Pinbelegung des µC. Die PBx, PCx, PDx sind die I/O-Ports des Prozessors, die Fenster zur Außenwelt (daher Port). PD5 ist hier zu lesen: Port D, bit5 oder einfach PortD, 5. Der ATMega8 hat 4 I/O-Ports je 8bit. Wegen der begrenzten Anzahl von 28 Pins sind nicht alle Ports herausgeführt. Port A fehlt beispielsweise völlig. Den ATMega8 gibt es jedoch in vielen Varianten, auch mit 40 Beinen, wo dann alle Portbits herausgeführt werden.
Meine Steuerung verwendet alle herausgeführten Portbits. In der Tat hätte ich aber gerne genau ein Bit mehr gehabt. Das kann man daran erkennen, dass von der dreifarbigen LED nur zwei Farben angesteuert werden konnten. Das ist aber halb so schlimm.
Auffällig ist die krumme Quarzfrequenz von 7,372800MHz. Es handelt sich hier um einen sog. Baudratenquarz. Seine Frequenz muss ein ganzzahliges Vielfaches der Baudrate der seriellen Schnittstelle betragen. Diese habe ich auf 9600Baud eingestellt, was hier auch einer Datenübertragungsrate von 9600Bit/s zwischen Laptop und Handsteuerbox entspricht.
Eine Besonderheit kommt dem Pin1 zu (Reset - der Strich darüber sagt aus, dass hier ein Reset des Prozessors bei logisch 0 = 0V erfolgt). An diesem Pin hängt eine RC-Kombination. Der Kondensator wird nach dem Einschalten der Steuerung langsam aufgeladen, so langsam, dass nach dem Einschalten Pin1 sicher als 0 erkannt wird, und der µC einen Reset ausführt. Das ist für den Programmstart wesentlich.
Essentiell für den Betrieb der Handsteurbox war die Programmierung sog. Interrupt-Unterprogramme. Bestimmte Ereignisse im µC lösen einen Interrupt aus. Wenn das geschieht, wird das Programm unterbrochen und ein zum Interrupt gehöriges Unterprogramm aufgerufen. In meiner Steuerung werden fünf verschiedene Interrupts verarbeitet. Zwei von ihnen in Verbindung mit der Bedienung der seriellen Schnittstelle. Die übrigen drei sind Timer-Interrupts. Hier wird der Interrupt bei Überlauf eines 8bit-Timers, bzw. bei Erreichen eines bestimmten 16bit-Zählerstandes (sog. CTC-Timer) ausgelöst. Die Timer werden mit jedem Prozessortakt um Eins hochgezählt.
Die beiden 8bit-Überlauf-Timer werden für die (absolut notwendigen) Entprellung der Taster/Schalter, sowie für die Fokussiertakte verwendet. Durch großzügig einstellbare Vorteiler wird erreicht, dass die Interrupts in einer gewünschten Periodizität erzeugt werden.
Die Verwendung des CTC-Timers erwies sich als absolut notwendig für den Synchronlauf der Steuerung. Das zu diesem Interrupt gehörige Unterprogramm nimmt mehr als die Hälfte des gesamten Programmes ein. Die komplette Befehlsabarbeitung und die Taktgenerierung werden hier erledigt. Der CTC-Wert, bei dessen Erreichen im Zähler der Interrupt ausgelöst wird, ist getrennt für Stern- / Sonne- / Mondnachführung als Konstante in den Montierungsdaten hinterlegt.
Ich will versuchen, durch Vergleich der weiter oben stehenden Sollfrequenzen mit den durch den µC erzeugten Ist-Frequenzen eine Fehlerberechnung zu machen. Dazu muss aber noch Folgendes beachtet werden: Nicht jeder CTC-Interrupt generiert einen Motortakt. Das Taktsignal wird hier vielmehr lediglich alterniert, also von 0 auf 1 oder von 1 auf 0 usw. Jedoch nur die positive Taktflanke erzeugt den Motortakt. Es kommt also nur bei jedem zweiten Programmaufruf zu einer positiven Taktflanke. Und weiterhin ist in dem Interrupt-Programm noch ein zusätzlicher 1/2-Teiler eingefügt. Dieser Teiler kann genau in dem Fall übersprungen werden, wo Guiding West (doppelte Tracking-Geschwindigkeit) benutzt wird. Beim normalen Tracking wird dieser Zähler durchlaufen. Im Ergebnis erfolgt beim normalen Tracking nur bei jedem vierten Aufruf des Unterprogramms eine Motortaktgenerierung. Und schließlich (aller guten Dinge sind drei) muss der eingetragene CTC-Wert immer um eins geringer sein als der Rechenwert.
So, damit können wir den systematischen Fehler der Steuerung hinsichtlich der Periodizität des CTC-Unterprogrammaufrufs berechnen. Hierzu schauen wir in die Montierungsdaten und können fürs Sterntracking den hexadezimalen Wert "8F9A" entnehmen. Das ist dezimal 36762. Wir addieren eins und multiplizieren mit vier und erhalten 147052. Wenn wir die Taktfrequenz des µC durch diesen Wert dividieren erhalten wir als Ergebnis die gewünschte Motortaktfrequenz fürs Sterntracking. Sie beträgt 50,137366Hz. Zum Vergleich: Die Sollfrequenz ist 50,136895Hz. Wie hoch ist die Differenz der Motortakte je Tag (86400s)? Soll--> 4331828 Ist --> 4331868. Der Fehler liegt bei 40 Motortakten pro Tag, oder etwas weniger als 1 Sekunde. Damit kann man voll zufrieden sein.
Hier noch der Vergleich mit dem Fehler in der Quarzfrequenz: Ich habe einen einfachen 50ppm-Quarz verbaut. Eine einfache Berechnung führt auf einen Fehler in den Motortakten pro Tag von +/-216, oder etwa +/-4s/Tag. Ist also deutlich schlechter als die Programmgenauigkeit.
Ich wünsche euch viele schöne klare Nächte
Micha