5. Mikrokontroller

Letztes Update: 17.12.2002

• 5. Einleitung
• 5.1 Hardware
  • 5.1.1 Übersicht
  • 5.1.2 Mikrokontroller
  • 5.1.3 Galvanisch getrenntes RS232 Interface
  • 5.1.4 Schnittstelle für Massen-Speicher
  • 5.1.5 Real Time Clock
  • 5.1.6 Acht-Kanal Digital Output (I2C)
  • 5.1.7 Acht-Kanal ADC für Housekeeping Sensoren (SPI)
  • 5.1.8 Temperatursensor (CPU-Temperatur)
  • 5.1.9 Steckerbelegung
  • 5.1.10 Schaltplan und Layout
• 5.2 Software
  • 5.2.1 Übersicht
  • 5.2.2 Datenspeicherung
  • 5.2.3 Befehlssatz
  • 5.2.4 Daten-Protokoll-Format

5. Einleitung

Es hat verschiedene Vorüberlegungen und Versuche zur Auswahl des Rechners und der Softwarestruktur gegeben.

1. Einsatz des IPC@CHIP

Dieser Chip zeigte jedoch ein sehr unzuverlässiges Verhalten. In 73% aller Fälle reagierte der Chip nicht auf einen Reset. Nach einen Umtausch des Chip reduzierte sich das Resetverhalten auf ca. 5%. Erste Versuche bei der Implementierung eines Multitasking Programms blieben jedoch erfolglos, sobald eine Task ausgeführt wurde, hängte sich der Prozessor auf. Alle Bemühungen und implementierte Beispiele blieben ohne Erfolg. Außerdem liegt der Strombedarf des Chips bei ca. 300mA, das ist ca. 10 mal so viel, wie der 68HC11 benötigt. Der Vorteil des geringen Hardwareaufwandes und der Programmiermöglichkeit durch TurboPascal läßt sich dadurch leider nicht ausnutzen.

2. Einsatz des 68HC11 Mikroprozessors

Zurück zu den Sachen, die funktionieren. Aber genauso komfortabel wie der IPC@Chip, d.h. Multitasking System und Ausgabe von physikalischen und bereits kalibrierten Messwerten. Zwei knifflige Bedingungen die leider nur mit sehr hohem Aufwand umzusetzen sind, besonders das Rechnen mit Floatingpoint Zahlen wenn keine FPU zur Verfügung steht. Die Berechnung der Grundoperationen erfordert das Zwischenspeichern diverser Parameter, d.h. bei einem Taskwechsel müssen auch noch viele Variable gesichert werden. Außerdem arbeiten diese Prozessoren nicht mit einer besonders hohen Geschwindigkeit. Floatingpoint Operationen 'zu Fuß' durchzuführen kostet eben Zeit. Und dann muß auch noch alles in Assembler programmiert werden.

Das Konzept sieht dafür aber sehr schön aus und wird vielleicht mal in einem anderen Projekt zum Einsatz kommen:

Die Aufgaben der Software sollten sich in drei Bereiche aufteilen

  1. Datenerfassung
      1a. Passiver Kanäle
      1b. Aktiver Kanäle
  2. Datenübetragung
  3. Bedienung

die durch jeweils eine Task bearbeitet werden.

Task 1 - Datenerfassung

• Scannt in zyklischen Zeitabständen alle passiven Sensoren.
• Erzeugt aus den Meßwerten einen Datenblock und benutzt dazu die Grundrechenarten des FPU-Packetes zur Umrechnung in physikalische Werte.
• Der Datenblock wird im Global RAM zwischengespeichert.
• Ist der Datenblock fertig, wird er im Massenspeicher abgelegt. Der Speichervorgang muß markiert werden, damit Task 2 und Task 3 während der Schreiboperation nicht zugreifen können (Synchronisation durch Semaphore 1).

Task 2 - Datenübertragung

• Diese Task hat die Kontrolle über den Sendeteil der RS232 Schnittstelle.
• Datensätze werden aus dem Massenspeicher  Datensätze gelesen und zur Station übertragen, aber nur wenn Task 1 und Task 3 nicht auf den Massenspeicher zugreifen (Synchronisation durch Semaphore 1)
• Wenn Task 4 Zeichen Senden will, werden sie an diese Task zur Ausgabe übergeben (Kontrolle über Semaphore 2).

Task 3 - Datenerfassung

• Aktive Sensoren senden nur bei Bedarf einen Meßwert, z.B. ein Blitz, deswegen wird in unvorhersehbaren Zeitabständen ein Datenblock erzeugt.
• Der Datenblock wird im Global RAM zwischengespeichert.
• Ist der Datenblock fertig, wird er im Massenspeicher abgelegt. Der Speichervorgang muß markiert werden, damit Task 2 und Task 1 während der Schreiboperation nicht zugreifen können (Synchronisation durch Semaphore 1).

Task 4 - Bedienung

• Diese Task hat die Kontrolle über den Empfangsteil der RS232 Schnittstelle.
• Befehle werden von der Station angenommen und ausgeführt.
• Sind Antworten notwendig, müssen sie über Task 2 gesendet werden (Kontrolle über Semaphore 2).

Scheduler

• Der Scheduler verwaltet die Taskaufrufe und wird über den höchsten, nicht maskierbaren Interrupt aufgerufen (XIRQ). Dadurch ist sichergestellt, das nichts und niemand der Scheduler stören kann (außer natürlich die Fehler des Programmierers).
• Alle Tasks werden grundsätzlich in der Reihenfolge 1, 2, 3 und 4 abgearbeitet.
• Jede Task wird immer aufgerufen. Wenn eine Task nichts zu tun hat, sollte sie sich sofort selbst beenden, damit die nächste Task aufgerufen werden kann.

3. Entgültige Auswahl: 68HC11F1

Bevor ein größeres Assembler Programm geschrieben wird, wird das Programm erst mal unter Delphi entwickelt, um eine vernünftige Struktur zu entwerfen und natürlich durch die Bestimmung aller Variablen und sonstigen Zwischenspeichern den Speicherbedarf zu ermitteln. Das Programm erfüllt den vollen Funktionsumfang und bietet halt die Möglichkeit mit den Debugger von Delphi zu arbeiten. Ein Funktionsfähiges Programm dann in Assembler umzusetzen geht relativ einfach, weil die großen dummen Überraschungen einfach nicht mehr auftreten.

Bei der Entwicklung wurden verschiedene Varianten umgesetzt. Hier wird jetzt nur die Letzte beschrieben:

1. Es werden keine Floatingpoint Operationen durchgeführt, d.h. die Umwandlung in physikalische Messwerte erfolgt im Anwenderprogramm auf der PC Seite.
2. Damit trotzdem Mittelwerte gebildet werden können, werden die ADC-Werte eines Kanals in einer 24 Bit Zahl aufaddiert. Ein Messzyklus kann sich bei einer Auflösung von 12Bit dann aus maximal 4096 Einzelmessungen zusammensetzen. Zusätzlich wird dann zum Messwert die Anzahl der Messungen übertragen. Bei einer internen Abtastrate von 10 Sekunden würde das einem Mittelwert aus ca. 11 Stunden entsprechen. Das sollte völlig ausreichen.
3. Durch den Verzicht auf die langwierigen Floatingpoint Operationen ist es nicht mehr notwendig ein Multitasking System einzusetzen, wenn gleichzeitig die seriellen Schnittstellen über eine Interruptroutine bedient werden. Mehr Interruptquellen gibt es nicht.
4. Die Softwarestruktur vereinfacht sich dadurch zu einer großen Endlosschleife mit folgendem Aufbau:

Repeat   Wenn interner Messzyklus erreicht Dann Scanne alle Sensoren   Wenn Hauptmesszyklus erreicht     Dann Speicher alle Datensätze   Wenn Befehl vom PC vorhanden      Dann Bearbeite Befehl   Wenn Aktiver Sensor sich meldet   Dann Speicher Datensatz   Wenn Datenübertragung aktiv       Dann Sende Datensatz Until forever

Die Übertragung der Daten paßt dabei in dieses Konzept, weil immer nur ein Datensatz zur Zeit gesendet wird, denn der nächste Datensatz wird erst dann übertragen, wenn er vom PC quittiert wurde. Es ist also eine neuer Befehl dafür notwendig. Das reduziert zwar die Übertragungsgeschwindigkeit, sorgt aber dafür, das ein Datensatz auf dem Kontroller erst dann gelöscht wird, wenn er korrekt im PC gespeichert wurde. Es können also keine Daten verloren gehen. Die Ausführungszeit aller anderen Kommandos ist dabei so kurz, das wahrscheinlich ein maximaler interner Messzyklus von 1 bis 2 Sekunden erreicht werden kann. Das wird aber erst die entgültige Programmierung zeigen.

Hardwareaufbau