kramann.info
© Guido Kramann

Login: Passwort:










COACH2
1 Planung
2 Architektur
3 Anzeige
4 EEPROM
5 I2C
..5.1 MasterSendByte
..5.2 MasterSend2Bytes
..5.3 MasterReceiveByte
..5.4 MasterReceive2Bytes
6 UART
7 DFT
8 FFT
9 Planung2
10 Klassen
..10.1 AnzeigeTaster
..10.2 RS232
..10.3 MotorServo
..10.4 Drehgeber
..10.5 Sensor
..10.6 Funk
11 Adaption
..11.1 Programmiertechnik
..11.2 Evoopt
12 Fuzzy
..12.1 Uebungsaufgabe
..12.2 Fuzzygroesse
..12.3 Fuzzyset
..12.4 Lookuptable
13 Skript
..13.1 Funkkorrektur
..13.2 Skriptsprachen
..13.3 Anforderungen
..13.4 Agentensysteme
..13.5 Implementierung
..13.6 Experimente
14 Gesamtkonzept
..14.1 Skripterweiterung
..14.2 Makroverhalten
67 Echtzeitsysteme
..67.1 Einfuehrung
....67.1.1 Echtzeit
....67.1.2 Korrektheit
....67.1.3 Hardware
....67.1.4 Ziele
....67.1.5 Synchronprogramm
..67.2 Threads
....67.2.1 Java
....67.2.2 Synchronisierung
..67.3 COACH
....67.3.1 Kaskadenregler
....67.3.2 Zeitebene1
....67.3.3 Zeitebene2
....67.3.4 Zeitebene3
....67.3.5 Puck
....67.3.6 Puckschwarm
..67.4 RTAIlab
....67.4.1 Slax
....67.4.1 USB_Stick
....67.4.2 Sinus
..67.5 Semaphor
....67.5.1 Laufkatze
....67.5.2 Java
....67.5.3 Semaphor
..67.6 Audio
....67.6.1 wav
....67.6.2 Linux
..67.7 Lookup
....67.7.1 Fuzzy
....67.7.2 PWM
..67.8 NeuronaleNetze
....67.8.1 Neuron
....67.8.2 Backpropagation
....67.8.3 Umsetzung
....67.8.4 Winkelerkennung
..67.9 Internetprogrammierung
....67.9.1 Codegenerierung
....67.9.2 PHP_Programmierung
....67.9.3 PHP_OOP
....67.9.4 Java
....67.9.5 UDP
..67.10 DFT
..67.11 FFT
..67.12 Zustandsmaschine
..67.13 Fuzzy
....67.13.1 Fuzzylogik
....67.13.2 FuzzyRegler
....67.13.3 Uebung9
....67.13.5 Softwareentwicklung
......67.13.5.1 AgileSoftwareentwicklung
......67.13.5.2 FuzzyRegler
......67.13.5.3 Uebung
....67.13.6 Umsetzung
......67.13.6.1 FuzzyRegler
......67.13.6.2 Simulation
......67.13.6.3 Optimierung
......67.13.6.4 Uebung
....67.13.7 Haengependel
......67.13.7.1 Haengependel
......67.13.7.2 Simulation
......67.13.7.3 FuzzyRegler
......67.13.7.4 Optimierer
......67.13.7.5 Genetisch
....67.13.8 Information
....67.13.9 Energie

67.1.3 Hardware Plattformen

Der Mikrocontroller
  • Der Mikrocontroller ist nur eine von einer ganzen Reihe an Plattformen auf denen es möglich ist, Regler zu implementieren und andere erforderliche Prozesse ablaufen zu lassen.
  • Die Vorteile des Mikrocontrollers bei der Implementierung von Echtzeit-Prozessen liegen darin, dass...
  • ... beim Mikrocontroller die Verarbeitungsdauer einzelner Teilprozesse exakt bestimmt werden kann, da für jeden Befehl die Anzahl der benötigten Taktzyklen angegeben werden kann,
  • ... im Mikrocontroller Timer integriert sind, die wirklich parallel zu dem gerade ablaufenden Programm arbeiten, um z.B. ein PWM-Signal auf einen Ausgang zu senden.
  • ... externe Interrupts als interne Peripherie bereits integriert sind und so die Priorisierung der Reaktion auf ein äußeres Ereignis leicht umgesetzt werden kann.
Der PC
  • Das Hauptproblem bei der Verwendung eines PCs für Echtzeitanwendungen ist, dass im normalen Betrieb kein sicheres Gewährleistungsintervall für irgendeinen Prozeß angegeben werden kann.
  • Das heißt im Klartext: Es kann nie mit Sicherheit vorhergesagt werden, dass ein beliebiges Programm zu einem bestimmten Zeitpunkt wirklich seine Aufgabe beendet hat.
  • Das liegt daran, dass moderne Betriebssysteme beliebig viele Prozesse quasi parallel ablaufen lassen können, indem die verfügbare Prozessorzeit auf diese Prozesse automatisch in Zeitscheiben verteilt wird.
  • Die Verteilung der Prozessorzeit auf die gerade laufenden Prozesse wird durch den so genannten Scheduler geregelt.
  • Und auf den Scheduler hat man in der Regel keinen direkten Einfluß.
  • Zwar läßt sich die Priorität von Prozessen festlegen. Jedoch kann eben nicht mit Sicherheit gesagt werden, wie der Scheduler mit diesen Priorisierungen umgeht.
  • Sind die Echtzeitanforderungen nicht allzu streng, kann man auch mit PCs mitgewöhnlichen Betriebssystemen (UNIX, Linux, Windows, ...) Echtzeitanwendungen realisieren.
  • Zudem sorgt der Trend zu einer immer größeren Anzahl an Prozessoren dafür, dass immer seltener Performance-Engpässe gibt.
  • So führt heutzutage dann z.B. doch nicht mehr das Bewegen der Maus dazu, dass ein anderer Prozeß dadurch in seiner Performance stark nachläst.
CPU-Last-Darstellung.

Bild 67.1.3-1: CPU-Last-Darstellung.

  • Jedoch auch bei der Realisierung konkreter mechatronischer Aufgaben, macht es durchaus Sinn die Möglichkeit zu haben Prozesse quasi parallel ablaufen lassen zu können, da der Fall häufig auftritt dass mehrere Tasks gleichzeitig verarbeitet werden sollen.
  • Und es gibt ganz klar Aufgaben verschiedener Priorität, wobei dann auch die Rechenkapazität für niedrig priorisierte Prozesse genutzt werden können sollte, die frei wird, wenn gerade kein hoch priorisierter Prozeß abgearbeitet werden muß.
  • Aus diesem Grund ist es nicht in allen Fällen ein sinnvoller Weg, auf ein Betriebssystem wie DOS zurückzugehen, das nur einen Prozeß gleichzeitig abarbeiten kann, um Taskdauern exakt abschätzen zu können.

XPC-Target

  • Genau dies wird bei XPC-Target gemacht:
  • Ein mit Matlab auf einem Host-PC entworfener Echtzeitprozeß wird in ein C-Programm umgewandelt, kompiliert und auf einen Client-Rechner samt einem DOS-ähnlichen Betriebssystem geschickt und dort über eine Remote-Verbindung gestartet, Daten ausgetauscht und wieder gestoppt.

Realtime-Linux

  • Eine Alternative zu dem kommerziellen XPC-Target- und verwandten -Systemen stellt Realtime-Linux dar.
  • Auch hier kann Steuerung und Ablauf des Echtzeitprozesses auf unterschiedlichen PCs laufen.
  • Jedoch laufen hier die Echtzeitprozesse auf einer besonderen Linux-Variante, durch die das Einhalten von Gewährleistungsintervallen garantiert werden kann.
  • Als Sahnehäubchen gibt es in einer besonderen Version von Scicos (RTAI-Lab) die Möglichkeit die Echtzeitprograsmme über eine grafische Programmieroberfläche zu erstellen, in C-Code umzuwandeln und zu kompilieren.
  • Mit diesem Werkzeug werden wir innerhalb dieser Lehrveranstaltung in jedem Fall arbeiten.
  • Wie aber fünktioniert RTAI-Linux?
  • Wie wird hier das Problem gelöst, das die unkontrollierte Zuweisung von Prozeßzeit durch den Scheduler mitbringt?
  • Da Linux ein Open-Source-Betriebssystem ist, hatten Menschen, die Interesse an einem Echtzeitfähigen Betriebssystem hatten die Möglichkeit, den Kernel von Linux entsprechend zu verändern.
  • Bei RTAI-Linux gibt es einen Prozeß, der in einem festen Zeitintervall immer die gleiche Menge an Rechenzeit zugewiesen bekommt.
  • Schaut man sich diese Zuweisungen über die Zeit an, so sehen sie aus wie ein PWM-Signal mit immer gleicher Frequenz und Pulsbreite.
  • Alle anderen Prozesse bekommen ihre Prozessorzeit in den dazwischenleigenden Zeiten zugewiesen.
  • Das heißt, hoch priorisierte Prozesse mit harter Echtzeitforderung können in dem festen Segment der Prozessorzeit abgearbeitet werden, ohne dass die Möglichjkeit verloren geht, auch niedrig priorisierte Prozesse mit befriedigender Performance abarbeiten lassen zu können.
Verteilung der Prozessorzeit bei RTAI-Linux.

Bild 67.1.3-2: Verteilung der Prozessorzeit bei RTAI-Linux.

ARM-Prozessoren (Advanced RISC Machine)
  • In ihren Echtzeit-Eigenschaften irgendwo zwischen PC und Mikrocontroller angesiedelt sind die ARM-Prozessoren.
  • Sie bieten in der Regel die Möglichkeit einer Hierarchisierung von Interrupts und esgibt sowohl Varianten, die mit Betriebssystem betrieben werden und solche ohne.
  • Ansonsten besitzen sie eher mehr integrierte Peripherie als Mikrocontroller und warten oft mit höheren Taktraten auf.
Diskrete Schaltungen
  • Sind sehr hohe Anforderungen an die Performance eines Prozesses gegeben und ist nicht zu erwarten, dass sich die Struktur des Prozesses nicht ändert, so wäre es möglich die erforderliche Funktionalität mit diskreten Bauteilen durchzuführen.
  • Neben dem Einsatz von Operationsverstärker können auch hoch spezialisierte ICs zum Einsatz kommen, die beispielsweise bereits einen kompletten PID-Regler durch integrierte Operationsverstärker realisieren.
  • Jedoch verlangen sich ändernde Anforderungen oft einen kompletten Austausch der Schaltung.
FPGA
  • Eine Alternative die zwischen der Verwendung von Mikrocontrolern und diskreten Schaltungen liegt, ist die Verwendung von FPGA-Bausteinen.
  • Bei FPGA-Bausteinen, können Logische Gatter, aber auch Timer und sonstige und andere Komponenten durch ein Programm konfiguriert werden.
  • Das besondere an dieser Technik ist, dass diese Bausteine parallel arbeiten, wie ihre diskret aufgebauten Pendents, aber eben doch über Software konfiguriert werden können.
  • Wenn es darum geht, einen sehr schnellen, aber relativ komplexen Regler aufzubauen, sind sie das Mittel der Wahl.