C-Control

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Das Steuerungsmodul C-Control (CONRAD-Control) wird vom Elektronikfachgeschäft Conrad Electronic produziert und vermarktet. Die seit 1997 produzierte Modulreihe wird heute in verschiedenen Variationen vertrieben. Neben einem auf einem Motorola MC68HC05B6 basierenden Controller in einer Standard- (Basic) und Kompaktausführung (M Unit), wird seit Mitte 2004 nun auch die Nachfolgegeneration der M Unit im Form der M Unit 2.0 und C-Control Micro verkauft. Eine Weiterentwicklung der C-Control I stellt die C-Control II dar, die durch eine dritte C-Control Version, der C-Control Pro, Mitte 2005 ergänzt wurde. Die C-Control wird vorallem wegen des einfachen Handlings, dem zahlreichen Zubehör und dem großen Angebot an deutschsprachiger Literatur gern verwendet.

Versionen

Kommerzielle Controller

Vor 1996 gab es eine C-Control 1.0 Version, die allerdings nicht mit den noch heute erhältlichen Mikrocontrollern der Generation I kompatibel ist. Später kam dann die C-Control 1.1 auf den Markt, die nun nicht nur in der grafischen Programmiersprache CCPLUS, sondern auch in dem BASIC-Dialekt CCBasic programmiert werden konnte. Die C-Control 1.1 ist sowohl als BASIC Unit als auch M-Unit 1.1 verfügbar.

Zusätzlich gibt es seit Ende 2000 die C-Control II (auch C-Control 2 oder CC2 genannt) basierend auf einem Infineon-16-Bit-Mikrocontroller. Diese hat mit der C-Control I nur sehr wenig gemeinsam. Durch das Multithreading, die vorhandene Möglichkeit der Stringverarbeitung, sowie der 64-Bit-Fließkommaarithmetik und des für einen Mikrocontroller sehr großen Speichers, ist die C-Control II weiterhin die umfangreichste Variante. Durch CC2Net.de ist der Support zur C-Control II sehr gut, so dass man bei einem Problem schnell Hilfe findet.

Seit Mitte 2004 ist auch die Nachfolgegeneration der C-Control 1.1, die "C-Control M Unit 2.0" erhältlich. Um Verwechslungen zur C-Control II zu vermeiden später die offizielle Bezeichnung "C-Control I M-Unit V2" eingeführt. Ziel des neuen Controllers ist es eine weitesgehende Kompatibilität zur alten M Unit 1.1 zu halten. Die aktuelle Version des OS ist 2.05 (bzw. 2.06 für die "Station" Hutschienenvariante).

Seit 2007 gibt es eine erweiterte Variante der M-Unit I V2, die sogenn. "Advanced" Version. Im Unterschied zur "normalen" Version, die auf dem Freescale Prozessor MC68HC908GT16 basiert, enthält diese den MC68HC908GP32, der mit 32 KByte Flash den doppelten Speicherplatz zur Verfügung stellt. Die aktuelle Version des OS ist 2.29 (bzw. 2.28 für die "Station") und stellt zusätzlich (ab Version 2.26/2.27) Fließkommaarithmetik sowie (ab Version 2.28/2.29) Funktionen zur Sprachausgabe zur Verfügung. Es blieb auch noch Platz übrig, der dem BASIC Speicherbereich zur Verfügung steht. Das RAM wird zum Teil dynamischer verwaltet, so daß maximal 240 Bytes zur Verfügung stehen. Abgesehen von obengenannten Erweiterungen ist das Betriebssystem fast identisch zur Version 2.05/2.06. Es wurden kleinere Fehlerbehebungen und Korrekturen eingebaut, außerdem fällt die "Slowmode" - Funktion weg. Der Prozessor MC68HC908GT16 wurde vom Hersteller inzwischen mit "Last Order-Date" zum Oktober 2013 abgekündigt.

Abgesehen von Unterschieden, die durch die unterschiedlichen Autostarts bedingt zwischen der M-Unit und der Station herrschen, sind die OS Versionen von M-Unit und Station jeweils Funktionsidentisch. Marginale Differenzen und Verschiebungen im Code zeigen aber, daß die Binärcodes aus offenbar unterschiedlichen Quellzweigen stammen. Hier wirken sich unterschiedliche Optimierungen des C Compilers sowie manuelle Eingriffe in die Compilate aus.

Neben der C-Control M Unit 2.0 wurde auch die C-Control Micro veröffentlich. Die Micro ist ein einzelner Chip, der ohne äußerliche Beschaltung lauffähig ist. Es gibt eine Ausführung in 8 poligem DIL-Gehäuse als auch einen etwas kleineren "Chip" im Schrupfschlauch mit kurzen Anschlußdrähten.

Inzwischen sind die Familien C-Control I v1.x und v2.x wohl technisch überholt. Auch wenn viele Anfänger sich daran versuchten, sind sie durch die Unhandlichkeit und die Seltsamkeiten des Basic-Dialektes heute nicht mehr relevant. Abgelöst wurden sie wohl durch die Arduino-Familie, für die ein breites Spektrum an Open Source Software existiert.

Seit Mitte Mai 2005 gibt es daher die dritte Variante, die C-Control Pro (auch CC-Pro genannt). Diese Variante der C-Control hat wiederum wenig mit den vorherigen beiden gemeinsam. Deren Prozessorfamilie ist die ATMega-Serie der Firma Atmel, die in den verschiedenen Arduino-Boards eingesetzt wird. Conrad hat über die C-Control PLUS wohl versucht auf diesen Zug aufzuspringen, aber insgesamt hat sich dieses Konzept nicht so durchgesetzt.

Alternative Controller

Es gibt auch einige alternative Controller, die zumindest in Teilen auf das BASIC-System der C-Control I Version 1 zurückgreifen:

Anfang 2004 wurde das Projekt CC1-OS eingestellt. Das Projekt verfolgte das Ziel die C-Control I zu erweitern.
Das Projekt B-Control (verwendet ATmega32 oder ATmega128 und eigenen "m-Basic"-Interpreter)ist auf dem Stand 3.5.2006 eingeschlafen (http://www.nettypes.de/b-control/os/os.html) (DEAD LINK!).
Als weitere Alternativen stehen Open Mini und Open Micro zur Auswahl.

Anwendungen

Mit der C-Control lassen sich einfache Automatisierungsvorgänge für den privaten, aber auch semiprofessionellen Bereich realisieren. Durch die C-Control M Unit I Version 2 wird eine im Vergleich zur Vorgängerversion 38 mal höhere Ausführungsgeschwindigkeit erreicht. Auch der Umgang mit dem I²C-Bus, externen Komponenten oder LC-Displays wurde vereinfacht. Es wurde versucht, das Betriebssystem gegen Auslesen zu schützen. Das Fehlen eines Monitors ist insofern gefährlich, als nach einem Reset direkt die Laderoutine aktiv ist. -Sofern nicht Autostart aktiviert wurde. Das führt dazu, daß über die serielle Schnittstelle übertragene Daten direkt und unmittelbar den Basic-Speicher überschreiben.

Die C-Control II wird sehr häufig im professionellen Bereich eingesetzt. Je nach Anforderung kann dabei auf die unterschiedlichen Fähigkeiten der jeweiligen Controller zurückgegriffen werden.

Programmierung

C-Control I

Hochsprachen

Programmiert wird die C-Control I mit dem speziellen Basic-Dialekt BASIC++ oder dem Vorgänger CCBasic. Die Speicherverwaltung und Umsetzung der Hochsprachenkommandos (z.B. Strings, Tabellen, Schleifen) in einen primitiven Tokencode geschieht durch eine Art Präcompiler. Komplexe Konstruktionen wie sog. "Extended Objekte", Stringoperationen, Funktionen etc. werden in Subroutinen und Macros zerlegt. Dieser Code wird in der Unit dann von einem einfachen Stackorientierten Interpreter ausgeführt. Hieraus ergibt sich auch der eingeschränkte Wertebereich vom Word-(16 Bit) und Byte-(8 Bit) Zahlen sowie Einzelbits. Word-Variablen werden in den Mathematischen Funktionen ausschließlich als Vorzeichenbehaftete Integerwerte behandelt, dadurch verschiebt sich der Wertebereich auf -32768 bis 32767. In der Verarbeitung auf dem Basic-Stack werden allerdings alle Typen als Word behandelt, hierdurch verbraucht auch eine Bit-Variable 2 Bytes Stack. Die Workbench++ unterstützt auch "Projekte" aus mehreren Basic-Moduldateien, sowie ein Kommando "SYSCODE" der automatisch Assemblerroutinen auf der Adresse $FD00 überträgt.

Es gibt jedoch weder Hilfen zum Debugging einer programmierten Unit, noch keinerlei Emulation oder einen Simulator für Programme, die noch nicht auf eine Unit übertragen wurden. Obwohl das Betriebssystem der "Standard-Unit" (aktuelle Version 2.05 bzw. 2.06) eine undokumentierte Funktion beinhaltet, um über word[2] einen Breakpoint zu setzen und ggf. damit auch ein Single-Stepping möglich wäre, fehlen hierzu nötige Assembleroutinen. Gerade bei größeren Projekten ist ein Debugging hierdurch stark erschwert.

Die offizielle Dokumentation zu Hardware incl. OS und Basic++ ist in verschiedenen Versionen nicht immer eindeutig und mit wechselndem Inhalt über Bücher des Autors des Compilers (Tappertzhofen), Webseiten mit Online-Tabellen, Hilfeseiten und PDF-Dokumenten auf verschiedenen Webseiten verstreut. z.B. Fehlen die u.A. die Stringoperationen wie MID() und LEN(): 

IF ENDE > LEN(ReadString) Then ENDE = LEN(ReadString)
FOR Zaehler = Anfang to Ende
   Writestring = Writestring & MID(ReadString,Zaehler)
NEXT Zaehler

Beispiel der BASIC++ Operationen LEN() und MID()

Ebenso ist die Token-Tabelle in ISBN 978-3-7723-5488-5 unvollständig: Es fehlen u.A. die Token 68,69,78,79 (INC/DEC WORD und BYTE). Stattdessen sind Token angegeben, die keine Funktion haben und zum "hängen" des Systems führen (CLR, END). (Im Falle von "END" ist insofern korrekt wiedergegeben, daß das Programm "beendet" wird. Dies erfolgt allerdings nicht durch ein definiertes Token, sonder durch die Tatsache, daß kein Token größer 84 erlaubt ist und jeder höhere Wert, -wie auch jedes undefinierte Token- zum "hängen" führt.) Dem Autor des Betriebssystemes Uwe Spies sei Dank, ist die mögliche Erweiterung des Tokensatzes um bisher undefinierte Token bis max. 84 zwar vorbereitet, jedoch nicht dokumentiert.

Leider gibt der Basic++ Compiler in der Debug-Version der Map-Datei die Token 252 als "DEBUG PNT", 253 als "DEBUG EOL" und 254 als "DEBUG PROC" aus, was aus oben angegebenen Gründen Unsinn ist. Auch einige inzwischen ungültige Token der C-Control I V. 1.0/1.1 werden fälschlich noch ausgegeben, obwohl sie teilweise mit den zusätzlichen Token der ADV-Units kollidieren.

Weiterhin ist im OS keinerlei Fehlerbehandlung enthalten, Parameterfehler im Assemblercode führen entweder direkt zum "hängen" in einer Endlosschleife, oder es wird sich darauf verlassen, daß der Compiler nur erlaubte Werte liefert. Überschreiten eines Wertebereiches führt zu undefinierten Sprüngen oder undefiniertem Überschreiben von Speicherstellen im System-RAM (z.B. bei "PUSH AD", "POP DA").

Alternativ kann man auch auf die Programmiersprache mBasic (DEAD LINK!) oder die C-ähnliche Sprache C3C zurückgreifen. 

Main() ' Dies ist ein Kommentar
 
FUNCTION Main()
 DEFINE i AS BYTE
 DEFINE MeinString AS STRING * 10
  
 LCD.INIT
 LCD.CLEAR
 FOR i = 1 TO 10
  MeinString = "Wert von i = " & STR(i)
  LCD.PRINT MeinString
 NEXT i
 LCD.OFF
END FUNCTION

Beispiel in BASIC++ mit dynamischen Strings und LC-Display-Ausgabe

Assembler

Programmierung in Assembler ist ab der M-Unit I 2.0 nur mit dem speziellem Assembler CCASM möglich, der auch Bestandteil der Workbench++ ist. Die M-Unit akzeptiert nur den mit einer 'Signatur' versehenen Code, um ein Auslesen und Reengineering des Betriebssystems zu verhindern. Hierzu werden weiterhin bestimmte Assemblerbefehle und Adressierungsarten durch Macros ersetzt, die die Gültigkeit des "erlaubten" Adressbereiches überprüfen und den Befehl ggf durch ein "NOP" ersetzen. Dadurch fehlen offiziell z.B. wichtige Befehle wie "PSH" und "PUL", "LDA ,X" ist reglementiert etc. Tatsächlich funktionieren manche Befehle durchaus, die eingesetzten Macros sind jedoch teilweise versteckt, d.h. sie werden selbst in der Debuggingausgabe nicht angezeigt. Es fällt jedoch auf, daß Verschiebungen zwischen augegebenem Code und ausgegebenen (public-)Labels entstehen. (z.B. wird PSHA zu NSA + PSHA, in der .dat Datei steht weiterhin nur "PSHA".) Die Befehle JMP und JSR funktionieren nur in Bezug auf definierte Labels. Werden durch .EQU definierte Variablen oder absolute Adressen angegeben, erhält man eine Fehlermeldung und das Sprungziel wird zu $fd00 resp. $fc00 (Basis der Assemblerpage). Per Label definierte Sprungziele werden ausschließlich als direkte 16 Bit Adresse angesprungen.

Im Assembler sind zudem (-trotz Demonstration in der Dokumentation-) Tabellen nicht sinnvoll nutzbar, da zum Einen innerhalb von ".DATA"-Segmenten keine Labels funktionieren (-was nicht dokumentiert ist-), andererseits jedes ".DATA"-Segment mit unterschiedlich vielen "RET" umgeben ist. -Was ebenfalls nicht in der Debuggingausgabe sichtbar ist!

Eine direkte Parameterübergabe zwischen Basic und Assembler ist nicht möglich; es müssen Basic-Variablem auf feste RAM-Adressen definiert werden, die dann in Assembler gelesen bzw. beschrieben werden können.

Weiterhin steht der Hauptteil des freien Flash-Speichers ab $d800 nur Basic-Programmen zur Verfügung, für Assemblerroutinen stehen lediglich die zwei Bereiche $fd00-$fdff und $fc00-$fcff zur Verfügung. Diese stehen nicht durchgehend zur Verfügung und werden jeweils durch eine 3-Byte Signatur zu Beginn geschützt. Das Basic "SYS"-Kommando wird nicht ausgeführt, wenn diese Signatur nicht korrekt ist oder der Aufruf in nicht erlaubte Speicherbereiche führt. Die weiteren 6 Bytes sind für undokumentierte IRQ Sprünge und Behandlung unbekannter Basic-Kommandos reserviert, so daß offiziell erst die Bereiche ab $fd09 bzw. $fc09 tatsächlich verfügbar sind. Im Übrigen verdient diese 'Signatur' der Assemblerbereiche ihren Namen nicht, da lediglich einige wenige Bytewerte an festgelegten Adressen zusammengezählt werden.

Eine weitere Schutzfunktion soll wohl auch die Verschlüsselung des Assemblercodes in den gespeicherten Binärdateien darstellen, die so nur durch das in der Workbench++ enthaltene Übertragungsprogramm CCTRANS32 lesbar sind. -Allerdings erfolgt die Übertragung zur Unit -wie auch bei Basic-Programmen- völlig unverschlüsselt. Das Übertragungsprotokoll erlaubt direkt anschließend an ein Basic-Programm, ein Assemblermodul an die Adresse $fd00 zu übertragen, dessen Quelle auch die unverschlüsselte Basic- "Binär"-Datei sein kann. Dies erlaubt zum Einen, beliebigen Code zu übertragen, zum Anderen auch die Adressen $fd00 bis $fd08 zu beschreiben. Dadurch ist es doch möglich, durch andere Programme erzeugte Basic-Dateien anschließend beliebigen Assemblercode anzuhängen und an beliebige Speicherbereiche zu schreiben. -Letztlich ist das genau die Funktion mittels der auch die Firmware-Updates eingespielt werden. Die 'Codierung' der Basic-Datei ist nichts anderes als die dezimale Schreibweise der einzelnen zu übertragenen Bytes. Der "Schlüssel", um aus der Hexadezimal-Zeichenkette der System-Tokens (die vom Compiler bpp.exe veränderten .bin Daten des Assemblers ccasm.exe) die dezimale 'Codierung' zu erhalten, lässt sich aus der Fehlermeldung von CCTrans32.exe direkt ablesen, wenn eine .dat-Datei mit "SCU 0000..." übertragen wird.

Als Ausgleich für die oben erwähnten nicht erlaubten Kommandos stehen im CCASM zusätzliche Pseudo-OP Codes zur Verfügung: (Siehe auch ".ccasm Referenz Rev 8 Nov. 2007", -www.tappertzhofen.eu-)

TAX, TXA, THX, TXH: Transfer zwischen den Registern, wird durch eine Folge von PSH und PUL ausgeführt.
LSA, SSA: Lade bzw. speichere Systemvariable nach/in A. Dies sind tatsächlich die LDA und STA Kommandos, bezogen auf die Namen ausgewählter Systemvariablen, die im RAM Bereich zwischen $4d und $9e angesiedelt sind.

Leider (!?!) erzeugt die angegebene Variable "StCnt" (Stack Counter), die eigentlich auf RAM-Adresse $90 zeigen sollte, den Fehler "Falsche Mnemonic[4]." -Womöglich hat der Autor sich "nur" verschrieben? -Oder doch aktiv die Parameterübergabe zwischen Basic und Assembler über den Stack verhindert...???

C-Control II

Die Programmierung der leistungsstärkeren C-Control II erfolgt dagegen mit der Programmiersprache C2. Weiterhin können hier auch Assemblerroutinen leicht eingebunden werden. 

thread main
{
  
 byte second;
 stports.init();
 stports.LCDlight(1);
 lcdext.init();
 lcdext.print("Hello World");
 second=system.second(); 
  
 loop
 {
  lcdext.line(2);
  lcdext.time(0);
  stports.togLED(1);
  sleep 490;
  stports.togLED(1);
  wait system.second()!=second;
  second=system.second();
 }
  
}

C2 Beispiel

Die C-Control Pro wird in (echtem) C und Basic programmiert.

Literatur

Die C-Control zeichnet sich durch ein großes Angebot an deutschsprachiger Literatur aus. Die Bücher und Internetseiten greifen dabei sowohl Themen für Anfänger als auch Fortgeschrittene auf.

Literaturliste

Sortiert nach Erscheinungsdatum:

  • Stefan Tappertzhofen: Messen, Steuern und Regeln mit C-Control M-Unit 2 - 2. aktualisierte Auflage, Franzis Verlag: Poing 2007, ISBN 978-3-7723-5488-5
  • Stefan Tappertzhofen: Messen, Steuern und Regeln mit C-Control M-Unit 2, Franzis Verlag: Poing 2005, ISBN 3-772-34165-9
  • Burkhard Kainka: Messen, Steuern, Regeln mit dem C-Control/Basic-System, Franzis Verlag: Poing 2003, ISBN 3-772-36735-6
  • Burkhard Kainka, Andre Helbig: Messen, Steuern, Regeln mit C-Controll II, Franzis Verlag: Poing 2002, ISBN 3-772-34054-7
  • B. Kluth/C. Kluth: C-Control-Station, Franzis Verlag: Poing 2002, ISBN 3-772-38165-0
  • Burkhard Kainka, Martin Förster: C-Control-Anwendungen, Franzis Verlag: Poing 1998, ISBN 3-772-35514-5

Weblinks

Forum

(Leider sind Programm und Sourcen verschollen.)

C-Control Pro

Abgerufen von „https://www.mikrocontroller.net/index.php?title=C-Control&oldid=89631“