kramann.info
© Guido Kramann

Login: Passwort:










Mikrocontroller
1 Einfuehrung
..1.1 Entwicklungsgeschichtliches
..1.2 Maschinensprache
..1.3 Assemblerbeispiel
..1.4 Sprachwahl
..1.5 Praxis
....1.5.1 Digital_IO
....1.5.2 Byteoperationen
....1.5.3 AVR_Studio
....1.5.4 Testboard
....1.5.5 Aufgaben
....1.5.6 Do_it_yourself
......1.5.6.1 Ampel
......1.5.6.2 Programmierer
..1.6 Literatur
..1.7 Programmierer
....1.7.1 Bauverlauf
....1.7.2 KurzreferenzLow
....1.7.2 Kurzreferenz_16PU
..1.8 Uebung1
..1.9 BoardAtHome
....1.9.1 Software
....1.9.2 Hardware
....1.9.3 Knoppix
....1.9.4 Aufbau
....1.9.5 LED
2 Oszillator
..2.1 Assembler
..2.2 Interner_RC
..2.3 Quarz
..2.4 Taktgenerator
3 DigitalIO
..3.1 Elektrische_Eigenschaften
..3.2 Pullup_Widerstaende
..3.3 Bitmasken_Eingang
..3.4 Bitmasken_Ausgang
..3.5 Tic_Tac_Toe
....3.5.1 DuoLEDs
....3.5.2 Schaltplan
....3.5.3 Spielfeld
....3.5.4 Anwahl
....3.5.5 Kontrolle
..3.6 Laboruebung2
..3.7 Laboruebung2_alt
4 PWM
..4.1 Prinzip
..4.2 Nutzen
..4.3 Generierung
..4.4 Programmierung
..4.5 Servos
..4.7 Laboruebung3
..4.8 LoesungUE3
..4.9 Uebung6
5 LichtKlangKugeln
..5.1 LED
..5.2 RGB
..5.3 Sensoren
..5.4 lautsprecher
..5.5 tonerzeugung
6 UART
..6.1 Bussysteme
..6.2 UART
..6.3 RS232
..6.4 Hardware
..6.5 Senden
..6.6 Hyperterminal
..6.7 Empfangen
..6.8 Broadcast
..6.9 Uebung4
7 Infrarot
..7.1 schalten
..7.2 seriell
..7.3 Uebung
8 OOP
..8.1 Probleme
..8.2 Konzept
..8.3 Statisch
..8.4 Datentypen
..8.5 RS232
....8.5.1 Prozedural
....8.5.2 Analyse
....8.5.3 Umsetzung
....8.5.4 Vererbung
....8.5.5 Statisch
....8.5.6 Performance
..8.6 Fahrzeug
9 ADW
..9.1 ADW
..9.2 Zaehler
10 Peripherie
..10.1 RS232Menue
..10.2 ASCIIDisplay
..10.3 Tastenmatrix
..10.4 Schrittmotor
..10.5 Zaehler
..10.6 Uebung7
11 SPI
..11.1 Testanordnung
..11.2 Register
..11.3 Test1
..11.4 Test2_Interrupt
..11.5 Test3_2Slaves
..11.6 Laboruebung
12 EEPROM
13 I2C
..13.1 MasterSendByte
..13.2 MasterSend2Bytes
..13.3 MasterReceiveByte
..13.4 MasterReceive2Bytes
14 Anwendungen
..14.1 Mechatroniklabor
....14.1.1 Biegelinie
....14.1.2 Ausbruchsicherung
....14.1.3 Einachser
....14.1.4 AV
....14.1.5 Vierradlenkung
....14.1.6 Kommunikation
..14.2 Sinuserzeugung
....14.2.1 Variante1
....14.2.2 Variante2
....14.2.3 Variante3
....14.2.4 Variante4
..14.3 Laboruebung8
..14.4 Loesung_Ue8
..14.5 SPI_Nachtrag
20 Xubuntu

8.1 Gegenanzeigen: Was spricht gegen eine Verwendung von C++ und wie kann man den Schwierigkeiten begegnen?

  • Mikrocontroller sind verhältnismäßig langsam und haben einen sehr kleinen Programm- (ATemga32: 32 Kilo-Bytes) und einen noch kleineren Arbeitsspeicher (ATemga32: 2024 Byte).
  • Das läuft gegen die OOP, da diese eine noch höhere Abstraktion gegenüber der Maschinensprache darstellt und dadurch die Gefahr besteht, dass der Compiler aus einem C++-Quellcode weniger effizienten Maschinencode generiert, als dies bei einem Assembler-Quellcode, aber auch bei einem C-Quellcode der Fall ist.
  • In welchem Maße diese Befürchtungen berechtigt sind, soll im Verlauf der Vorlesung auch experimentell ermittelt werden.
  • Es gibt aber bestimmte Maßnahmen, die die Gefahr ineffizienten Codes eindämmen:
Kein Allokieren von dynamischem Speicher
  • Absolut fatal ist es bei einem Mikrocontrollerprogramm zur Laufzeit Speicher zu allokieren.
  • Bei objektorienteirten Programmier-Techniken werden häufig dynamisch Objekte erzeugt und wieder zerstört. - Gerade darauf sollte man von vorn herein verzichten, indem man Objekte nur am Beginn der main-Methode anlegt und sonst nirgends, insbesondere nicht innerhalb von Funktionen.
Intensive Nutzung von #define-Statements
  • Die Lesbarkeit von Programmen kann man durch die Verwendung sprechender Variablen- und Funktionsnamen erhöhen.
  • Jedoch verbrauchen Variablen Speicher und der Aufruf einer Funktion Rechenzeit (merken des aktuellen Programmzustands, Sprung in die Funktion, Ausführen der Funktion, Rücksprung, Wiederherstellung des aktuellen Programmzustands).
  • Keinerlei Speicher verbraucht die Verwendung von #define-Statements. Mit ihnen kann man Code lesbarer machen. Zur Erinnerung: VOR dem eigentlichen Kompiliervorgang, führt der Precompiler die in den #define-Statements vordefinierten Ersetzungen durch. "#define MEINPI 3.14" ist wohl gemerkt keine Deklaration und Initialisierung der Variable MEINPI, sondern es wird einfach VOR dem Kompilieren überall, wo MEINPI im Programm steht 3.14 eingefügt.
Nutzung von Kommentaren
  • Der Anreiz ist groß, alles zu automatisieren und zu kapseln, um sich mit möglichst wenigen komplizierten Einstellungen z.B. beim Starten des AD-Wandlers befassen zu müssen.
  • Jedoch läuft dieses Bestreben kontraproduktiv was Speicherbedarf und Bearbeitungsgeschwindigkeit betrifft.
  • Es ist eine Ermessensfrage, wann statt eines aufwändigen Konfigurations-Apparats mit Switch-Anweisungen im Konstruktor, einem einfachen Kommentar für den Benutzer vorzuziehen ist.
  • Im Vordergrund soll keine Prinzipienreiterei auf den Paradigmen der OOP stehen, sondern die Benutzerfreundlichkeit der entwickelten Programmkomponenten.
Nutzung von Vererbung
  • Das Erstellen von Klassen verleitet dazu, jede Eventualität zu berücksichtigen und ein großes Bündel an Methoden dafür bereitzustellen.
  • Beispielsweise ist es nützliche in einer Klasse RS232 eine Methode zum Senden ganzer Text, oder von Fließkommazahlen zu haben, aber nicht immer werden diese Methoden wirklich im Programm gebraucht.
  • Hier bietet es sich an mit Vererbung zu arbeiten und höhere Methoden in abgeleitete Klassen zu packen.