Überflieg' bitte erst kurz meine Frequently Asked Questions, bevor Du mir eine E-mail schickst oder eine Anfrage in das Forum stellst. Hier sind einige Fragen aufgeführt, die mir andere Anwender bereits gestellt haben. Ein Blick in diese Liste kann Dir viel Wartezeit ersparen. Suchen kann man mit Ctrl+F.
Die folgenden Fragen werden hier beantwortet:
- Was versteht man unter C-Control?
- Welche C-Control-Varianten existieren?
- Ist die neue C-Control-I (1.2 und 2.0) die Weiterentwicklung der C-Control 1.1?
- Welche Programmiersprachen für die C-Control-I existieren?
- Ist die C-Control-I (Version 1.1) schnell genug für eine bestimmte Aufgabe?
- Was ist die "C-Control intern"-Sammlung?
- Wie aktuell sind diese FAQs?
- Auf welchen Internetservern ist die "C-Control intern"-Sammlung zur Zeit zu finden?
- Is your information collection about the C-Control microcontroller available in english language?
- NEU: Wie lassen sich MS-DOS-Programme unter aktuellen Windows-Versionen verwenden?
- Die serielle Schnittstelle kann nicht geöffnet werden!?
- Die Software sagt immer, daß sie keine Antwort von der Unit bekommt!?
- Kann man die erste C-Control Version 1.0 (vor 1996) umrüsten?
- Das Programm in der C-Control läßt sich nicht mehr überschreiben!
- Mein Rechner hat keine serielle Schnittstelle. Funktioniert auch ein USB-nach-Seriell-Adapter?
- Am Bildschirm erscheinen keine Ausgaben der C-Control!?
- Meine C-Control "verschluckt" einige Zeichen bei der seriellen Übertragung
- Wie muß ich auf dem PC die serielle Schnittstelle programmieren?
- Gibt es einen Unterschied zwischen der PLUS- und BASIC-C-Control?
- Ich komme mit meinem BASIC-Programm nicht weiter. Kannst Du mir helfen?
- Ich würde gern in Assembler programmieren. Kannst Du mir ein paar Tips geben?
- Kann man die C-Control in der Programmiersprache C programmieren?
- Gibt es noch einen anderen Assembler als den AS05?
- Sind mit der C-Control auch parallele Prozesse programmierbar?
- Wie programmiere ich eine Interruptroutine?
- Wie deaktiviere ich das Interruptsystem der C-Control?
- Kann man das Zählen der TIMER-Variable, bzw. den 20-ms-Interrupt beschleunigen?
- Wie programmiere ich den I2C-Bus?
- Wie frage ich das Drücken oder Loslassen einer Taste ab?
- Wie überwache ich mehrere Ports gleichzeitig?
- Wie programmiere ich eine Zeitschaltuhr in CCBASIC?
- Wie läßt sich ohne Programmunterbrechung nach einem bestimmten Zeitintervall eine Aktion ausführen?
- Kann die C-Control Kommazahlen verarbeiten oder ausgeben?
- Wie berechnet man den Mittelwert einiger Meßwerte?
- Wie kann man den Sinus oder Cosinus berechnen?
- Kann man auch den Logarithmus naturalis (LN) berechnen?
- Wie erstellt man eine Tabelle für mathematische Funktionen?
- In meinen Programmen funktioniert der TOG-Befehl nicht!
- Kann man ein größeres serielles EEPROM an die C-Control anschließen?
- Wie kann die FILEFREE-Funktion bei einem größeren EEPROM angepaßt werden?
- Daten aus der Datei gehen verloren und/oder Teile des Programms werden überschrieben.
- Ich habe ein größeres EEPROM, kann aber keine BASIC-Programme größer als 8 Kilobyte kompilieren!
- Wieso 8 KB? Ich kann nur BASIC-Programme bis etwa 6400 Byte kompilieren!?
- Was ist der High-Endurance-Block?
- Wieviele Speicherzyklen sind denn nun beim EEPROM möglich? 10.000, 100.000 oder 1.000.000?
- Der CCBAS2MC-Kompiler meldet den Fehler "Label unreachable by short branch"!?
- Meine C-Control stürzt manchmal ab oder spielt verrückt!
- Wie robust ist die C-Control?
- Laut "C-Control Anwendungen" ist die Ungültigkeit des DCF77-Signals am Beginn jeder Stunde gewollt!?
- Kann man die C-Control beschleunigen?
- Ich habe meine Unit übertaktet und jetzt läuft alles zu schnell!?
- Ist es möglich, die C-Control in einen Stromsparmodus zu versetzen?
- Gibt es eine Möglichkeit, daß die C-Control-Station nach Stromausfall automatisch startet?
- Mein Wochentagsregister (DOW) zeigt falsche Werte an.
- Gibt es die verschiedenen "Manuals" zum Mikrocontroller, EEPROM, u. ä. auch in Deutsch?
- Kennst Du weitere Software-Tools, die bei der Assembler-Programmerstellung nützlich sein könnten?
- Gibt es schon Erfahrungen zum Erstellen eines neuen Betriebssystems mittels EPROM-68HC05-Controller?
- Meine C-Control hat Probleme mit dem Empfang des DCF-Signals
- Ich habe Probleme beim Anschluß einer Hardware an meine C-Control. Kannst Du mir helfen?
- Wie übertrage ich die Programme, die sich augenblicklich in der C-Control befinden, zum PC?
- Wie kann ich in BASIC am einfachsten detektieren, ob ein gültiges DCF77-Signal empfangen wird?
- Gibt es irgendwo unbenutzten Speicher im RAM?
- Ich brauche in BASIC-Programmen mehr Variablenspeicher.
- Kann man Variablen in BASIC-Programmen einsparen?
- Ist die C-Control-I überhaupt noch aktuell? Arbeiten nicht schon alle mit der CC-2?
- Gibt es andere Mikrocontroller mit mehr RAM, mehr Ports, mehr Interrupts, Multitasking, Grafik, usw.?
- Ich habe eigene Software entwickelt. Möchtest Du sie auf Deine Site stellen?
- Was gibt es Neues von der C-Control-2?
- Wen kann ich noch fragen?
Ist Deine Frage nicht dabei? Dann schaue ins Forum oder schreib mir eine E-mail und hoffe, daß ich mich relativ schnell bei Dir melde. Achte aber bitte darauf, daß der Freemail-Provider "gmx.de" nicht in Deiner Ignore-Liste oder im Spam-Filter steht. Sonst wartest Du vergeblich auf meine mail und ich tippe mir umsonst die Finger wund! Wenn ich nach zwei Wochen noch nichts von mir hören lasse, darfst Du einmal höflich nachfragen...
Was ist C-Control?
Die C-Control-Familie besteht aus Mikrocontrollern, die von Conrad Electronic vertrieben werden, und mit denen besonders leicht und relativ preiswert Systeme zum Messen, Steuern und Regeln von Geräten jeder Art aufgebaut werden können. Die mehrfach von der Fachpresse gelobten und ausgezeichneten Controller wurden vor einigen Jahren im Conrad Technologie Center entwickelt. Zu unterscheiden sind hier die 8-Bit-Mikrocontroller der C-Control-I-Familie ("C-Control römisch 1") und die der C-Control-II, die auf 16-Bit-Technologie basieren. Außerdem gibt es als jüngstes Mitglied der Familie die C-Control-Pro auf Atmel-Basis.
Mitte 2004 wurde von Conrad Electronic eine neue C-Control-I-Generation auf den Markt gebracht, die nicht im Conrad Technologie Center entwickelt wurde. Die ältere, weitverbreitete Generation wird nun als C-Control-I Version 1.1 bezeichnet und kann wahlweise im C-Control-BASIC-Dialekt kombiniert mit Assembler oder mittels grafischer C-Control-Plus-Oberfläche programmiert werden. Es stehen auch zahlreiche alternative Programmiersprachen zur Verfügung. Die neue C-Control-I-Generation besitzt hingegen die Versionsnummern 1.2 und 2.0 und ist nur noch im Conrad-Basic und bedingt in Assembler programmierbar, da sie zur Original-C-Control-I maßgeblich inkompatibel ist. Außerdem erreicht das unter Verschluß gehaltene Betriebssystem, die offizielle Programmiersprache und das Zubehör dieser Controller nicht die von der bisherigen C-Control-I gewohnte Qualität. Dafür bietet die neue Generation eine bis zu 30-fach höhere Ausführungsgeschwindigkeit und in der Micro-Ausführung kleinere Ausmaße. Es war geplant, die Version 1.1 durch eine Version 1.2 mit den Einschränkungen der Version 2.0 zu ersetzen. Da sich das Interesse der Anwender jedoch in Grenzen hielt, wird diese Version vom Hersteller mittlerweile für keine neuen Projekte mehr empfohlen. Wegen der unter anderem hier in diesen FAQs aufgeführten Einschränkungen und Qualitätsmängel werden die C-Control-Versionen 1.2 und 2.0 im Forum zur C-Control-1 nicht mehr supportet. Die weitverbreitete Original-C-Control-I (Version 1.1) ist jedoch nach wie vor bei Conrad Electronic erhältlich. Sie kann beispielsweise im Online-Shop (Unit, M-Unit, Station - Update: Sind nicht mehr lieferbar!) bestellt werden.
Wer mit der Produktentwicklung auf Conrad-Seite unzufrieden ist, kann auf "alternative C-Controls" ausweichen. Es existiert ein C-Control-Betriebssystem, das während des CC1-OS-Project entwickelt wurde und bis zu 222 Byte Variablenspeicher und doppelte Ausführungsgeschwindigkeit bietet. Seit einiger Zeit gibt es die B-Control als privates Projekt. Außerdem wird die 1.1er-Linie mit Anleihen bei der 2.0er in der Open-Control fortgeführt. Bisher sind Open-Micro, Open-Mini, Open-Midi und Open-Macro als leistungsstarke Konkurrenz zur C-Control-Micro erschienen.
Die Entwicklung von Basic-Programmen für die C-Control-I kann sowohl unter DOS, als auch unter Windows erfolgen. Die Plus-Entwicklung ist dagegen nur unter Windows möglich. Die genannten Entwicklungsumgebungen können (mit Genehmigung von Conrad Electronic) kostenlos heruntergeladen werden (CCBASIC für Windows, CCBASIC für DOS, CCPLUS) und verfügen in den Windowsversionen über sehr gute Simulationsmöglichkeiten, die eine Programmentwicklung auch ohne C-Control-Controller ermöglichen. Aus diesem Grund ist besonders die C-Control-I Version 1.1 zum Einstieg in die Mikrocontroller-Welt interessant. Die anderen C-Control-Versionen haben mit der Original-C-Control außer dem Namen nicht viel gemeinsam, deshalb werden, sofern nicht anderes angegeben, auf dieser Internetsite nur die weitverbreiteten C-Control-I-Controller der Version 1.1 behandelt und kurz als C-Control oder CC1 bezeichnet.
Welche Varianten der C-Control existieren?
Mittlerweile ist es schwierig, sich im C-Control-Dschungel zurechtzufinden. Bei der folgenden Übersicht ist zu beachten, daß Conrad Electronic eine große Auswahl an Zusatzhardware anbietet, die nicht an jede C-Control-Version angeschlossen werden kann. Weiteres preisgünstiges Equiment für alle C-Control-Controller wird von André Helbig auf CCTools angeboten.
| Originale C-Control-I (Version 1.1) | |||||||
 Main-Unit |
 M-Unit |
 Station |
Das sind die drei weitverbreiteten Varianten der originalen C-Control, bestehend aus dem 8-Bit-Mikrocontroller 68HC05B6 von Motorola, einem 8 KByte großen seriellen EEPROM und einigen anderen Elementen. Programmiert wird diese Einheit wahlweise im C-Control-Basic-Dialekt (CCBASIC) kombiniert mit 6805-Assembler oder mittels grafischer C-Control-Plus-Oberfläche (CCPLUS). Außerdem existieren zahlreiche alternative Programmiersprachen (OCBASIC, mBasic, Basic++, C3C, CCCCC, ...). Interessant ist die M-Unit mit dem besten Preis-Leistungs-Verhältnis und die Station im Hutschienen-Gehäuse. Der Controller auf der Main-Unit ist gesockelt und läßt sich durch einen Controller mit besserem CC1-OS-Project-Betriebssystem ersetzen. | ||||
| Neue C-Control-I (Version 1.2, 2.0 und C-Micro) | |||||||
 M-Unit 2.0 |
 Micro (PCB und Chip) |
Diese C-Control-Versionen basieren auf 8-Bit-Controllern der 68HC908-Serie von Freescale. Bei der C-Micro handelt es sich um eine miniaturisierte Variante der M-Unit 2.0 mit geringerem Funktionsumfang. Die M-Unit Version 1.2 sollte die M-Unit Version 1.1 ersetzen. Der Vorteil der neuen M-Units ist eine bis zu 30-fach höhere Geschwindigkeit, aber leider sind diese zur originalen C-Control-I maßgeblich inkompatibel, so daß nur noch in Basic++ und eingeschränkt in Assembler (CCASM) und CCBASIC programmiert werden kann. Im Forum klagen außerdem etliche Anwender über nicht vorhandene Updatemöglichkeiten, Fehler in Basic++, im Zubehör und im Betriebssystem der Controller. Obwohl alle veröffentlichten Versionen der neuen C-Control-I Fehler enthalten, existieren nur für neuere Versionen OS-Updates. | |||||
| Open-Control (Open-Micro, Open-Mini, Open-Midi, Open-Macro und Open-Maxi) | |||||||
|
Nachdem immer mehr Fehler in der neuen C-Control-I entdeckt wurden, haben einige Anwender das Open-Control-Projekt ins Leben gerufen, um eine leistungsstarke Alternative zu den Conrad-Controllern zu entwickeln. Entstanden sind bisher die fünf preiswerten Mikrocontroller Open-Micro, Open-Mini, Open-Midi, Open-Macro und Open-Maxi, die zur C-Micro und zur Version 1.1 hochkompatibel sind. Bei der Entwicklung wurde größten Wert gelegt auf Anwenderkomfort, Fehlerfreiheit, maximalen Funktionsumfang, mehr Speicher und gute Dokumentation. Die OM-Controller lassen sich in CCPLUS, CCBASIC, mBasic, CCCCC, Assembler und dem neuen OCBASIC-Dialekt mit integriertem Assembler programmieren. Die Controller sind bei CCTools in verschiedenen Varianten und mit reichhaltigem Zubehör erhältlich. Zu Schulungszwecken dürfen sie kostenlos hergestellt werden. Auf der offiziellen Informationssite gibt es weitere Informationen, Neuigkeiten, Downloads, Anwenderprojekte, sowie zwei sehr umfangreiche Bedienungsanleitungen. | ||||||
| C-Control-Pro (Mega-32 und Mega-128) | |||||||
|
Die C-Control-Pro-Familie ist seit vielen Jahren am Markt, befindet sich aber noch immer in der Entwicklung. Die ersten veröffentlichten Versionen unterstützten noch nicht einmal eine gebufferte serielle Schnittstelle. Der Anwender muß deshalb zunächst ein Update durchführen, um die volle Funktionalität zu erhalten. Programmiert wird in eigenen C- und BASIC-Dialekten, die interpretiert ausgeführt werden. Etliche Anwender beklagen sich im Forum, weil sie es bereuen, diesen Controller eingesetzt zu haben. Im Katalog wurde irrtümlich behauptet, die Programmausführung wäre acht mal so hoch wie auf der M-Unit 2.03. Mittlerweile wurde dieser Wert auf Faktor zwei (!) korrigiert. Obwohl die CCPro unter anderem Fließkommazahlen und einen bis zu 110 kByte großen Programmspeicher unterstützt, schrecken die meisten Anwender vor den horrenden Anschaffungskosten von 170 bis 200 EUR zurück. | ||||||
| C-Control-II | |||||||
 CC2-Unit |
 CC2-Unit NV |
 CC2-Station |
Die C-Control-II ist mit ihrem 16-Bit-Controller 80C164CI die bisher schnellste C-Control-Variante. Sie besitzt ein Multithreading-Betriebssystem und einen sehr großen Speicher (64kB RAM) und ist daher selbst in komplexen Projekten einsetzbar. Sie ist allerdings nicht so einfach zu programmieren und für einen Mikrocontroller recht teuer. Programmiert wird in einem C-ähnlichen Dialekt, der wie bei der C-Control-I interpretiert ausgeführt wird. Auch Assemblerprogrammierung ist möglich. Die Site mit den neusten Informationen zur CC2 ist CC2Net.de von André Helbig. | ||||
Sind die C-Control-I-Versionen 1.2, 2.0 und C-Micro die Weiterentwicklung der C-Control-I 1.1?
Nein, die neueren C-Control-I-Versionen sind keine Weiterentwicklungen, sondern Neuentwicklungen, die mit der Original-C-Control (Version 1.1) weniger Gemeinsamkeiten haben, als deren Bezeichnungen vermuten lassen. Die ältere 1.1er basiert auf dem 68HC05B6-Controller. Da dieser vom Hersteller Motorola aus dem Programm genommen wurde, hat sich der Entwickler der neueren C-Control-I dazu entschlossen, den Flash-Controller 68HC908GT16 als Basis für die 1.2er und 2.0er zu verwenden. Dieser Controller bietet weniger Ports als der 68HC05B6 und unter anderem kein PWM-Modul. Das ist mit ein Grund, warum das bewährte Betriebssystem der 1.1er nicht übernommen, sondern komplett neu erstellt wurde. Durch das Neuschreiben des Betriebssystems bieten die neueren C-Controls zusätzliche Features und mehr Ausführungsgeschwindigkeit in BASIC-Programmen, aber durch unnötige Einschränkungen und teils eklatante Fehler werden viele Dinge unmöglich gemacht, die bei der C-Control 1.1 noch möglich waren.
Das merkt man am deutlichsten an der Anzahl der unterstützten Programmiersprachen. Die C-Control 1.1 konnte noch in CCBASIC, 6805-Assembler, in der grafischen Entwicklungsumgebung CCPLUS, in C3C, mBasic, Basic++, CCCCC, CCBAS2MC und OCBASIC programmiert werden. Auf der offiziellen Supportseite der neuen C-Control-I-Versionen werden hingegen nur noch Basic++ und CCBASIC aufgeführt. Wobei es mit der Kompatiblität zu CCBASIC nicht weit her ist. Die Benutzung von neueren CCBASIC-Erweiterungen, wie u.a. das Power-Line-Modem und Funktionen wird durch unnötige Inkompatiblitäten der neueren C-Control-I unmöglich gemacht. Aus dem gleichen Grund arbeitet diese C-Control-I auch nicht mehr mit den Programmiersprachen CCPLUS und mBasic zusammen. Nur Basic++ wurde auf die neuere C-Control-I optimiert.
Das Betriebssystem der älteren C-Control 1.1 wurde als Sourcecode und als ROM-Listing im Internet veröffentlicht. Einige Fehler konnten erst durch die Analyse dieser Informationsquellen gefunden werden. Da das Betriebssystem der neueren C-Control-I unter Verschluß gehalten wird und eine Veröffentlichung unter Strafandrohung verhindert wird, liegt die Vermutung nahe, das Betriebssystem der 1.2, 2.0 und C-Control-Micro könnte noch viele bisher unentdeckte Fehler (Bugs) enthalten. Zwar wurden mittlerweile einige Fehler in den verschiedenen Controllern auf der offiziellen Website zur neueren C-Control-I aufgelistet, um Anwendern langwieriges Herumprobieren zu ersparen. Zumindest der nachfolgend beschriebene schwerwiegende Fehler in der 1.2, 2.0 und Conrad-Micro ist aber bis heute nicht dort aufgeführt.
Vor mittlerweile über einem Jahr wurde der Entwickler der neueren C-Controls auf den sogenannten "Glitching-Fehler" aufmerksam gemacht. Obwohl der Fehler vom Entwickler bestätigt wurde, ist bis zum heutigen Zeitpunkt noch kein Betriebssystemupdate erschienen, um den Fehler zu beheben. Der Fehler kann zu Störungen beim Portumschalten führen. Also in der wichtigsten Funktion eines Mikrocontrollers! Der Entwickler des Betriebssystems hat entgegen den Warnhinweisen im vom Controllerhersteller Freescale (früher Motorola) herausgegebenen Controllermanual die Richtungs- vor den Datenregister gesetzt. Dadurch können diese Glitching-Störungen auftreten. Vor allem, wenn mit DEACT gearbeitet wird. Besonders heimtückisch ist, daß unter bestimmten Umständen keine Störungen auftreten. Ungefähr so wie ein Wackelkontakt, den man lange Zeit suchen kann, bevor man die Störquelle eingrenzen konnte. Die Störimpulse sind oft nur kurz und deshalb könnten sie z.B. bei langen Leitungen herausgefiltert werden. Und der Anwender wundert sich. Das neue Stackhandling der neueren C-Controls kann außerdem bewirken, daß bei einem Stackfehler unbemerkt Anwender- und Betriebssystemdaten überschrieben werden. Auf der ersten, nicht updatefähigen Conrad-Micro wurden unter anderem FOR..NEXT-Schleifen fehlerhaft ausgeführt. Überflüssig zu erwähnen, daß die C-Control 1.1 keine solchen kritischen Fehler und Probleme enthielt. Weitere Nachteile der neueren C-Control (vor allem Conrad-Micro) können im Online-Handbuch auf der offiziellen Website der Open-Micro nachgelesen werden.
Die Fehler im Betriebssystem der neueren C-Control mußten außerdem von normalen Anwendern gefunden werden. Obwohl das Betriebssystem updatefähig wäre, mußten diese Anwender oftmals einen neuen Controller kaufen, um an eine neue Betriebssystem-Version zu gelangen.
Welche Programmiersprachen für die C-Control-I existieren?
Für die verschiedenen C-Control-Versionen sind mittlerweile sehr viele unterschiedliche Programmiersprachen erschienen und es ist für den Anwender nicht einfach, eine passende auszuwählen. Ich versuche im folgenden, die verschiedenen Programmiersprachen der C-Control-I möglichst objektiv gegenüberzustellen.
Die erste Programmiersprache für die C-Control war C-Control/PLUS. Es handelt sich um eine grafische Programmiersprache mit Simulator, in der Blöcke angeklickt, verschoben und verbunden werden. Obwohl in CCPLUS viele umfangreiche Anwendungen erstellt wurden, haben sich die meisten Anwender gegen die grafische Programmierung entschieden und auf das leistungsstärkere und ebenfalls mit Simulator ausgestattete C-Control/BASIC gesetzt. Zumal nur von BASIC die auf Mikrocontrollersystemen wichtige Programmierung in Assembler unterstützt wird. CCBASIC orientiert sich an BASIC-Dialekten, die auf Homecomputern und auf PCs üblich waren und heute noch sind. Die CCBASIC-Syntax wurde absichtlich einfach gehalten und ist deshalb sehr schnell erlernbar. CCBASIC wurde mehrfach weiterentwickelt. In den neusten, noch von Conrad Electronic stammenden Versionen wurde die Möglichkeit geschaffen, Funktionen in das Programm zu integrieren. Die Rückgabe von Werten erfolgt dabei sehr speicherplatzsparend über den Rechenstack. Dann gibt es eine Weiterentwicklung in Form des CCBASIC-Parsers, der mehrzeilige IFs und andere Features ermöglicht. Der echte CCBAS2MC-Compiler ermöglicht das Übersetzen von CCBASIC-Quellcode in Maschinensprache. Die neuste Weiterentwicklung der CCBASIC-Linie ist der OCBASIC-Compiler. Er ist abwärtskompatibel zur bewährten CCBASIC-Syntax und fügt optional Erleichterungen wie mehrzeiliges IF, normgerechtes einzeiliges IF, WHILE..WEND, REPEAT..UNTIL, INCLUDE-Dateien, Subroutinen und Funktionen ein. Alle bekannten Fehler von CCBASIC wurden beseitigt und es lassen sich nun Programme bis 64 KB Größe übersetzen. Durch die CCBASIC-Kompatiblität lassen sich ohne große Mühe der Simulator und andere Ressourcen von CCBASIC nutzen. Es existiert eine sehr reichhaltige Auswahl an Beispielen im Internet, die in CCBASIC geschrieben wurde. Viele gute Webseiten behandeln ausschließlich die Programmierung in CCBASIC. Die neuen Controller der Open-Control-Familie und die B-Control sind ebenfalls in CCBASIC und OCBASIC programmierbar. Mit OCBASIC auf der Open-Control werden sogar Pointer, schnelle DBNZ-Schleifen, ein integrierter 6808-Assembler und viele Optimierungen zur besseren Ausnutzung des knappen Programmspeichers unterstützt.
Eine vollkommen neue Richtung wurde von Marc van Endert mit dem C-Control/C-Compiler C3C eingeschlagen. Mit diesem Compiler wurde die Programmierung der C-Control-I in der Programmiersprache C ermöglicht. Zwar wurde der C-Quellcode "nur" in C-Control-Tokens umgesetzt, die Ausführungsgeschwindigkeit war also nicht höher als in CCBASIC, aber der Compiler hat erstmals strukturierte Programmierung auf der CC1 offeriert. Obwohl nützliche Dinge wie EEPROM-Variablen unterstützt wurden, hat der Compiler aber nie einen größeren Anwenderkreis finden können. Die Weiterentwicklung wurde eingestellt. Seit neustem gibt es jedoch einen neuen C-Compiler namens CCCCC von Oliver Haag.
In letzter Zeit sind die zwei BASIC-Dialekte Basic++ und mBasic erschienen, die sich in der Syntax nicht an CCBASIC, sondern am heutigen Marktführer Visual Basic orientieren. Sie bieten die übliche strukturierte Programmierung, teils Stringfunktionen und in Ansätzen sogar objektorientierte Programmierung (OOP). MBasic bietet darüber hinaus einen Simulator und wie das CCBASIC/OCBASIC für DOS einen integrierten Assembler. Allerdings lassen sich bestehende Programme nicht ohne Änderung auf diese Compiler portieren. Darüber hinaus zielt mBasic in erster Linie auf die B-Control.
Leider wird in verschieden Foren von einem kleinen Anwenderkreis mit geradezu religiösem Eifer der Basic++-Dialekt forciert und konkurrierende Sprachen abgewertet. Behauptungen wie "Basic++ ist ein neuer Compiler mit erweiterten Möglichkeiten" sind sachlich falsch. Die Basic++-Entwicklungsumgebung kennt keinen Simulator, der gerade für Einsteiger sehr nützlich ist. Simulatoren existieren dagegen in CCBASIC, mBasic und CCPLUS. Eine weitere Einschränkung existiert in der Wahl der Entwicklungsplattform: Die Programmierung ist nur unter neueren Windows-Versionen möglich. Es kann also kein DOS, Linux, Windows 3.1, DOS-Emulator, etc. verwendet werden, wie es mit CCBASIC und OCBASIC möglich ist. Die Bezeichnung von Basic++ wurde mehrfach gewechselt (CCBASIC++, Basic++, Basic++ 1.0, Basic++ 2.0, Basic++ 2006) und gerade die Versionen mit "2006" im Namen wiesen Fehler auf, die in der 1.0er von Basic++ längst behoben waren. In den verschiedenen Foren wird immer wieder über Bugs berichtet. Zu beachten ist auch, daß Basic++ in erster Linie auf die C-Control-I Version 1.2 und 2.0 zielt. Andere Controller werden nur nebenher bedient.
Die Einführung von alternativen Sprachen hat zu einer Zersplitterung der Anwendergemeinde geführt, von der niemand profitiert. Ob eine streng strukturierte Programmierung ohne speicherplatzsparendes GOTO und GOSUB, lokale Variablen, Stringfunktionen und sogar OOP auf einem kleinen Mikrocontrollersystem wie der C-Control sinnvoll sind, auf der bestenfalls einige hundert Byte RAM und schlimmstenfalls weniger als 2 Kilobyte Programmspeicher zur Verfügung stehen, sollte sich jeder Anwender daher sehr genau überlegen. Wichtig ist dagegen zweifellos ein robustes und einfach zu programmierendes System und die uneingeschränkte Möglichkeit der Assembler-Programmierung. Viele Anwender haben sich aber von den neueren von Conrad stammenden C-Control-Systemen verabschiedet, da immer wieder Fehler im Controller und in der offiziellen Programmiersprache Basic++ gefunden werden und Assembler-Programmierung nur eingeschränkt oder gar nicht möglich ist. Daß gefundene Bugs zumindest in Basic++ recht schnell beseitigt werden, ist für den potentiellen Anwender, der üblicherweise ein verläßliches System sucht, kein echter Trost.
Ist die C-Control-I (Version 1.1) schnell genug für eine bestimmte Aufgabe?
Normalerweise kann jede Aufgabe mit der C-Control-I gelöst werden. Wenn nicht in interpretiertem C-Control/BASIC oder -PLUS, dann doch zumindest mit Hilfe des BASIC-Compilers CCBAS2MC, der aus BASIC-Code ein Maschinenspracheprogramm erstellt. Alternativ kann man in Assembler programmieren und ein Optimum an Geschwindigkeit erreichen. Im normalen, interpretierten BASIC oder PLUS werden maximal einige tausend Befehle pro Sekunde ausgeführt. In Assembler oder compiliertem BASIC ist die C-Control zwischen 7 und 200 mal schneller. Wenn sehr schnelle Signale verarbeitet werden sollen, ist häufig die interruptgesteuerte Abfrage am sinnvollsten. Sobald im Eingangssignal eine Flanke detektiert wird, kann ein Interrupt ausgelöst und eine Assembler- oder BASIC-Routine aufgerufen werden. Falls es sich beim Eingangssignal hingegen um ein schnell getaktetes Signal handelt, kann dessen Frequenz ohne großen Aufwand ermittelt werden. Diese Ermittlung erfolgt im Hintergrund während der normalen Programmausführung bis zu einer Frequenz von rund 32 kHz.
Grundsätzlich ist der C-Control gegenüber anderen Mikrocontrollern der Vorzug zu geben, denn nirgendwo wird man ein preiswerteres Mikrocontrollersystem bekommen. Die M-Unit kostet den Einsteiger nur 38,- EUR, inklusive drei Entwicklungsumgebungen für Windows, DOS und Linux und vier Programmiersprachen (BASIC, PLUS, C, Assembler). Auf diese Weise kann man preiswert in die Welt der Mikrocontroller hineinschnuppern. Das Informations- und Programmangebot für die C-Control und die weitverbreiteten 68HC05-Controller ist riesig. Es ist auch kein Problem, die C-Control durch Einsetzen eines anderen Quarz um mindestens Faktor zwei zu beschleunigen. Falls sich dennoch herausstellen sollte, daß die C-Control für eine bestimmte Aufgabe nicht geeignet ist, kann man vom bei Conrad Electronic üblichen 14-tägigem Rückgaberecht Gebrauch machen. Oder man setzt die C-Control in einem anderen Projekt ein. Denn Einsatzgebiete für ein einfach zu programmierendes, robustes Mikrocontrollersystem gibt es viele.
Häufig aufgeführte Konkurrenten der C-Control sind die Atmel-AVR-Mikrocontroller. Die reinen Controller sind zwar preiswerter und auch leistungsfähiger, aber die Einstiegskosten liegen deutlich höher. Man benötigt einen Programmer wie das STK-500 für rund 180,- EUR, als BASIC-Compiler kann man den BASCOM-AVR für rund 100,- EUR verwenden und ein Controller kostet nochmal rund 9 bis 15,- EUR.
Übrigens wird gerade von den Mitgliedern des CC1-OS-Projekts eine verbesserte C-Control entwickelt. Diese wird 176 Byte zusätzlichen Speicher besitzen, der von Variablen oder Assemblerprogrammen belegt werden kann. Außerdem wurde das Betriebssystem der C-Control erweitert und optimiert, wodurch unter anderem BASIC- und PLUS-Programme rund 20% schneller ablaufen. Weitere Informationen gibt es auf der CC1-OS-Project-Infosite.
Was ist die "C-Control intern"-Sammlung?
Die "C-Control intern"-Sammlung ist ein ZIP-Archiv, das in der Download Area heruntergeladen werden kann und jede Menge nützlicher Informationen, Hilfsprogramme, Tips und Tricks zum C-Control-I-Mikrocontroller enthält. Es werden besonders die bisher undokumentierten Bereiche der C-Control, wie der interne Aufbau des Betriebssystems, die Belegung des Speichers, die C-Control-Token, die Interruptprogrammierung und die diversen Bugs im Betriebssystem ausführlich beschrieben. Das Herzstück ist ein komplett disassembliertes und kommentiertes ROM-Listing des Betriebssystems im Assemblerformat. Zur Verdeutlichung der verschiedenen Aufgaben des Betriebssystems gibt es eine Beschreibung zum I2C-Busprotokoll, zum Aufbau des DCF77-Signals, zu den RS232-Befehlen und zum Interruptsystem der C-Control-Unit.
Vor Erscheinen dieser Sammlung gab es kaum derart geballte Information über die Interna des Mikrocontrollers, die insbesondere für den Assemblerprogrammierer sehr nützlich sind. Die Sammlung richtet sich zwar in erster Linie an erfahrene Anwender, doch gibt es auch für Einsteiger nützliche Informationen, Beispiele, Utilities und Tips. Schwierige Sachverhältnisse wurden, soweit dies möglich war, möglichst verständlich erklärt. Wer bisher noch nie in Assembler programmiert hat, findet in der Sammlung - neben einem guten Assembler - einen kurzen Einführungskurs zum Erlernen dieser nützlichen Programmiersprache. Zum Disassemblieren von Maschinenspracheprogrammen stehen außerdem zwei Disassembler zur Verfügung. Ergänzt wird das Angebot durch weitere Tools, Patches, Datenbücher, Tips und Tricks auf der C-Control-intern-Site, und natürlich durch diese FAQs, die alle Themenbereiche der C-Control behandeln.
Wie aktuell sind diese FAQs?
Der Großteil dieser Frequently Asked Questions und der Information auf der C-Control-intern-Site ist zu einer Zeit entstanden, als nur die Main- und M-Unit der heute als C-Control-I Version 1.1 bezeichneten C-Control existierten. Es würde viel Mühe machen, alle Daten an die neuen Controller-Versionen anzupassen oder darauf hinzuweisen, auf welche der C-Control-Varianten und in welcher Konstellation sie zutreffen. Meist ist das Anpassen überhaupt nicht möglich, da sich die neueren Varianten zu stark von den älteren unterscheiden. Bei der neuen C-Control-I-Familie ist eine Dokumentation der Systeminterna, wie in der C-Control-intern-Sammlung für die älteren Controller geschehen, auch überhaupt nicht sinnvoll. Da das Betriebssystem bei diesen Controllern im Flash steht, kann es jederzeit von Conrad Electronic ohne Vorankündigung verändert werden. Bei den maskenprogrammierten 68HC05-Controllern war das nicht möglich. Deshalb werden bis auf weiteres die später hinzugekommene C-Control-2 und die Versionen 1.2 und 2.0 der C-Control-I nicht behandelt. Die C-Control-2 wird bereits ausführlich auf CC2Net.de von André Helbig abgehandelt und Informationen zur Version 1.2 und 2.0 werden derzeit in den Foren ausgetauscht.
Auf welchen Internetservern ist die "C-Control intern"-Sammlung zur Zeit zu finden?
http://ccintern.de.vu (per Linkumleitung zur aktuellsten Site)
http://ccintern.dharlos.de (am aktuellsten)
http://www.cc2net.de/ccintern (Linkumleitung)
http://ccintern.mew.pl (Linkumleitung)
http://www.geocities.com/ccontrolintern (Linkumleitung)
http://computer.freepage.de/ccontrolintern (Linkumleitung)
Is your information collection about the C-Control microcontroller available in english language?
No, it isn't. I have not the time to translate it, but if you want to translate the collection, you're invited to do so.
Wie lassen sich MS-DOS-Programme unter aktuellen Windows-Versionen verwenden?
Fast alle Softwaretools, die auf meiner Website heruntergeladen werden können, sind MS-DOS-Programme. Da aktuelle Windows-Versionen keinen MS-DOS-Emulator mehr besitzen, lassen sich diese Tools nicht so ohne weiteres ausführen. Sie arbeiten nur bis Windows 7 32-Bit. Doch es gibt eine Lösung: Mit Hilfe des kostenlosen DOS-Emulators DOSBox lassen sich MS-DOS-Programme auch auf aktuellen Windows-Versionen ausführen. Als komfortable Alternative steht auch die L-Distribution zur Verfügung.
Die serielle Schnittstelle kann nicht geöffnet werden!?
Bei diesem Fehler handelt es sich offensichtlich um einen Windows-Bug. Wenn ein DOS-Programm in der DOS-Box die serielle Schnittstelle benutzt hat und anschließend in einem Windowsprogramm auf die selbe Schnittstelle zugegriffen wird, während das DOS-Box-Fenster noch offen ist, tritt dieser Ressourcenkonflikt auf. Sobald der Fehler aufgetreten ist, nutzt auch ein Schließen des DOS-Box-Fenster nichts mehr; Windows muß neu gestartet werden. Aus diesem Grund sollten sicherheitshalber alle DOS-Fenster geschlossen werden, bevor ein Windowsprogramm aufgerufen wird, das auf die serielle Schnittstelle zugreifen will.
Die Software sagt immer, daß sie keine Antwort von der Unit bekommt!?
Zuerst sollte man ein paar grundlegende Dinge überprüfen: Liegt eine stabilisierte, richtig gepolte 5-Volt-Spannung an der C-Control an; ist das mit der C-Control ausgelieferte Nullmodemkabel an der richtigen Schnittstelle angeschlossen und sind die richtigen Übertragungsparameter im Terminalprogramm, bzw. in der Übertragungssoftware eingestellt (COM1 oder COM2, 9600 Baud, keine Parität, 8 Datenbits, 1 Stopbit, kein Handshake, richtige Adresse und Interrupt in der Systemsteuerung)? Ansonsten sollte man prüfen, ob vielleicht der Startjumper der C-Control gesetzt ist. In diesem Fall startet die C-Control nämlich sofort nach dem Anlegen der Betriebsspannung oder nach dem Betätigen des Resetjumpers das BASIC- oder PLUS-Programm, das sich zur Zeit im Speicher befindet. Um ein neues Programm vom PC zur C-Control übertragen zu können, muß sich die C-Control im Programmiermodus (bzw. Befehlsmodus, Idle-Loop) befinden. Der Resetknopf der Main-Unit sollte nach jedem Einschalten nochmals gedrückt werden, um den Mikrocontroller sicher in die Idle-Loop zu versetzen. Auch sollte man prüfen, ob der RS232-Jumper (auf der Main-Unit) gesetzt ist. Eine weitere Fehlerquelle ist das Betriebssystem: Windows 95/98 soll teilweise Probleme mit dem Erkennen von Geräten haben, die an der seriellen Schnittstelle hängen. Man sollte testweise versuchen, die C-Control schon mit dem PC zu verbinden, wenn dieser abgeschaltetet ist. Oder testweise auch erst, nachdem Windows gestartet wurde. Bei Einsatz der DOS-Box kann es zu einem Ressourcenkonflikt kommen, der den Zugriff auf die RS232 bis zum nächsten Windows-Neustart verhindert. Die Erfahrung eines Anwenders zeigt, daß auch das Flachbandkabel, mit dem die C-Control-Unit mit dem Sub-D-Stecker verbunden ist, als mögliche Fehlerquelle in Betracht kommt. Dieses hatte an einer Lötstelle keinen Anschluß, was man erst auf den zweiten Blick sah. Dieser Flachbandkabel-Adapter sieht aus wie der Standard-Adapter, mit dem einige PCs ausgeliefert werden, trotzdem darf er nicht mit diesem vertauscht werden, da die Pins anders belegt sind. Falls sich die serielle Schnittstelle überhaupt nicht ansprechen läßt, sollte man im BIOS nachschauen, ob diese überhaupt aktiviert ist, denn einige Hersteller deaktivieren diese heutzutage im Auslieferungszustand. Falls die C-Control gebraucht gekauft wurde und noch nie eine Datenübertragung möglich war, kann es sein, daß es sich um eine uralte C-Control handelt. Siehe nächste Frage.
Kann man die erste C-Control Version 1.0 (vor 1996) umrüsten?
Vor 1996 gab es eine C-Control-Version, die sich nur in der damaligen CCPLUS-Sprache (v1.03b o.ä.) programmieren läßt. Es handelt sich um den Vorgänger der C-Control-I Version 1.1, die am Aufdruck XCTRL96A zu erkennen sein soll, aber ansonsten der heute erhältlichen Main-Unit entspricht. Weder mit dem aktuellen CCPLUS noch mit CCBASIC läßt sich dieser Controller verwenden. Beim Übertragen erhält die Downloadsoftware keine Antwort von der C-Control. Aber durch Auswechseln des Controller-Chips läßt sich das Problem beheben. Unter der Bestellnummer 950696 bietet Conrad Electronic einen einzelnen Chip an, der es ermöglicht, auch die aktuelle Software zu verwenden. Allerdings muß auf einigen Platinen eine kleine Hardware-Modifikation durchgeführt werden, damit der neue Chip funktioniert. Unterhalb des Quarzes sitzt der Kondensator C1, unterhalb diesem sind zwei Lötpunkte, die zu überbrücken sind. Anschließend kann der Controller-Chip vorsichtig mittels kleinem Schraubendreher ausgehebelt werden.
Das Programm in der C-Control läßt sich nicht mehr überschreiben!
Die C-Control speichert ihr BASIC-Programm zusammen mit der Datendatei im seriellen EEPROM 24C65. Dieses EEPROM-IC kann softwaremäßig in einen Schreibschutzmodus versetzt werden, was sich nicht rückgängig machen läßt. Bemerkbar macht sich dieser Umstand, indem bei der Übertragung eines neuen Programms in die C-Control kein Fehler auftritt, aber trotzdem das alte Programm erhalten bleibt. Ich habe bereits von mehreren Anwendern gehört, bei denen dieses Problem auftrat. Warum das EEPROM in den Schreibschutz versetzt wurde, kann ich leider nicht genau sagen. Ich vermute, daß die C-Control während des Lesens oder Schreiben in die Datei resettet wurde und das deshalb eine unglückliche Codefolge an das EEPROM gesendet wurde. Leider konnte ich bisher das Problem nicht nachvollziehen.
Bei der C-Control-Unit kann das EEPROM problemlos getauscht und durch ein neues 24C65-IC ersetzt werden. Einsetzbar ist auch das pinkompatible 24C64-EEPROM, das keinen softwaremäßigen Schreibschutz unterstützt; bei diesem IC kann das Problem also nicht auftreten. Durch einen Bug im Betriebssystem der C-Control (im Betriebssystem des CC1-OS-Project bereits behoben) gibt es allerdings Probleme, wenn die Dateifunktionen benutzt werden. Aus diesem Grund muß man ein Assemblermodul wie Deep-XS verwenden. Selbstverständlich ist es auch möglich, z.B. ein 24C256-EEPROM einzusetzen und dadurch den Speicher auf 32 Kilobyte oder mehr zu vergrößern.
Falls die Garantie noch nicht abgelaufen ist, rate ich allerdings, die C-Control samt defektem EEPROM bei Conrad Electronic zu tauschen, bzw. zurückzugeben. Vielleicht wird Conrad dadurch auf das Problem aufmerksam und untersucht das Phänomen.
Mein Rechner hat keine serielle Schnittstelle. Funktioniert auch ein USB-nach-Seriell-Adapter?
Gerade bei neueren Rechnern, die keine serielle Schnittstelle besitzen, kommt man nicht umhin, einen USB-nach-Seriell-Adapter zu verwenden, um die C-Control anzusprechen. Leider haben diese Adapter die Angewohnheit, Schwierigkeiten zu bereiten. Das Teil von Conrad Electronic (Bestellnr.: 982421, Preis: 40,88 EUR) ist nach Aussage des Conrad-Supports nicht in der Lage, eine Datenübertragung zur C-Control aufzubauen. Mit dem Adapter von Reichelt soll es dagegen keine Probleme geben. Trotzdem sollte man sich immer vor Augen halten, daß die Übertragungsstrecke durch einen solchen Adapter länger und störanfälliger wird. Vielleicht sollte man darum das Geld sparen und zur Programmierung der C-Control einen etwas älteren Rechner einsetzen.
Am Bildschirm erscheinen keine Ausgaben der C-Control!?
In der Beantwortung der vorherigen Fragen wurde auf grundlegende Dinge hingewiesen. Bitte erst dort weiterlesen, wenn nicht sichergestellt ist, daß überhaupt ein serieller Datenaustausch möglich ist. Anderes profanes Problem: Einige Anwender vertun sich, indem sie das "C-Control Ausgaben"-Fenster der Windows-IDE (Ausgabefenster des Simulators) mit einem Terminalprogramm verwechseln. Ein einfaches Terminalprogramm für Windows ist Hyperterminal. Übrigens dienen auch die anderen Fenster der Windows-IDE (überwachte Variablen, Ports, Datenaufzeichnung) nur zur Simulation. Ein weiteres Manko des Simulators ist, daß keine Assemblerprogramme getestet werden können. Doch zurück zu den Ausgaben der C-Control: Falls alle Stricke reißen, starte den Rechner einfach unter DOS (unter Windows 95 dazu F5 oder F8 drücken, unter Windows 98 Strg gedrückt halten) und benutze die DOS-IDE. Natürlich mußt Du wissen, an welcher Schnittstelle die C-Control hängt.
Meine C-Control "verschluckt" einige Zeichen bei der seriellen Übertragung
Wenn Du Datenblöcke zur C-Control senden möchtest, die mittels BASIC oder PLUS gelesen werden, dann kannst Du immer nur rund 8 Byte auf einmal übertragen, da der Empfangsbuffer der C-Control nur 8 Byte groß ist und BASIC oder PLUS relativ langsam abgearbeitet werden. Aus diesem Grund sollte der Senderechner nach jedem übertragenen Byte auf ein Echo der C-Control warten, falls größere Datenblöcke übermittelt werden sollen. Alternativ könntest Du überprüfen, ob sich der Senderechner bei einem vollen Buffer stoppen läßt, wenn Du das Handshake über die RTS- und CTS-Leitungen aktivierst (mittels HANDSHAKE ON). Dazu brauchst Du natürlich ein passendes Schnittstellenkabel, bei dem diese Leitungen konfektioniert sind. Und der Senderechner muß diese Leitungen abfragen. Bei der M-Unit wird dieses Verfahren allerdings nicht klappen, denn bei ihr sind diese Leitungen überhaupt nicht herausgeführt. Ansonsten könnte man die Reaktionsgeschwindigkeit der C-Control durch Assemblerprogrammierung oder Compilierung mittels CCBAS2MC erhöhen. Denkbar ist auch eine Implementierung des XON-/XOFF-Protokolls.
Wie muß ich auf dem PC die serielle Schnittstelle programmieren?
Falls Daten zwischen dem PC und der C-Control ausgetauscht werden sollen, bietet es sich an, die serielle Schnittstelle auf dem PC unter DOS zu programmieren. Sehr einfach geht das in QBASIC, das ab MS-DOS 5.0 bis Windows 95 zusammen mit dem Betriebssystem ausgeliefert wurde. Der Vorteil von DOS-Programmen ist, daß sie auf jedem Rechner und unter jedem Betriebssystem funktionieren. Die Programmiersprache QBASIC kann in der Download Area heruntergeladen werden.
' Einfaches Terminal in MS-DOS QBASIC 1.1
CLS : PRINT "Test-Terminal" : LOCATE , , 1
OPEN "COM2:9600,N,8,1,CD0,CS0,DS0,OP0,RS" FOR RANDOM AS #1
DO
IF LOC(1) > 0 THEN
i$ = INPUT$(LOC(1), #1)
FOR i% = 1 TO LEN(i$)
b% = ASC(MID$(i$, i%, 1))
IF b% = 13 THEN PRINT ELSE IF b% <> 10 THEN PRINT CHR$(b%);
NEXT i%
END IF
i$ = INKEY$ : IF i$ = CHR$(27) THEN EXIT DO
IF i$ <> "" THEN
COLOR 14 : PRINT i$; : COLOR 7 : PRINT #1, i$;
END IF
LOOP
CLOSE #1
LOCATE , , 0 : IF POS(0) > 1 THEN PRINT
PRINT "Programmende."
|
Worin unterscheiden sich die PLUS- und die BASIC-C-Control?
Die beiden Versionen der C-Control unterscheiden sich überhaupt nicht voneinander. Zwar wird die PLUS-C-Control mit der PLUS-Entwicklungssoftware (für Windows) ausgeliefert, sie läßt sich aber ebensogut wie die BASIC-Version in der BASIC-Sprache (unter DOS und Windows) programmieren. Ebenso läßt sich auch die BASIC-Version in PLUS programmieren. Die jeweils fehlende Entwicklungsumgebung konnte früher auf der offiziellen C-Control-Site kostenlos heruntergeladen werden. Das dazu passende Handbuch bekommt man auf dem Datenblatt-Server von Conrad Electronic; allerdings nur als PDF-Datei. Sehr interessant für alle Umsteiger, die von PLUS nach BASIC wechseln wollen, ist der Decompiler. Mit ihm können selbsterstellte PLUS-Programme in BASIC-Code umgewandelt werden.
Ich komme mit meinem BASIC-Programm nicht weiter. Kannst Du mir helfen?
Aus Zeitgruenden antworte ich nur auf E-mails, die sich direkt auf die Inhalte meiner Homepage beziehen. Alle anderen Fragen sollten in das Forum gestellt werden, sofern sie nicht schon hier in den FAQs beantwortet wurden.
Ich würde gern in Assembler programmieren. Kannst Du mir ein paar Tips geben?
Meiner C-Control-intern-Informationssammlung liegt ein kurzer Assemblerkurs bei, der einen kleinen Einblick in die Programmierung bietet. Es wäre nett, wenn Du mir schreiben würdest, wie Du den Crash-Kurs findest und an welchen Stellen eventuell Probleme auftauchen. Sehr gut fuer Einsteiger geeignet ist auch die Assemblerbeschreibung von Mario Boller-Olfert und die Site von Wolfgang Schmid.
Kann man die C-Control in der Programmiersprache C programmieren?
Der Buchstabe "C" von C-Control steht nicht, wie man vielleicht glauben mag, für die Programmiersprache C, sondern für Conrad Electronic ;-). Seit einiger Zeit kann in der Download Area die Vollversion des ehemals kommerziellen C-Compiler C3C heruntergeladen werden. Dieser Compiler erzeugt C-Control-Tokens, weshalb die mit ihm erstellten Programme nicht schneller abgearbeitet werden als BASIC- oder PLUS-Programme. Allerdings bietet dieser Compiler erheblich mehr Funktionalität. Der Autor von C3C ist nicht mehr zu erreichen und entwickelt seinen Compiler nicht mehr weiter.
Darüber hinaus gibt es neben der Entwicklung eines neuen Betriebssystem für die C-Control, für die man die Sprache C einsetzen könnte, für den Anwender nur geringe Möglichkeiten, in dieser Sprache zu programmieren: Die C-Control stellt ein internes EEPROM zur Verfügung, in dem Assemblerprogramme gespeichert und ausgeführt werden können. Mit einem geeigneten C-Compiler können statt Assembler- auch C-Programme verwendet werden. Allerdings ist das interne EEPROM nur 255 Byte groß, darum lassen sich hier nur recht kleine Routinen realisieren. Der Rest des Programms muß in CCBASIC geschrieben werden, oder alternativ kann man auch C3C verwenden. Infos zu einem geeigneten C-Compiler, mit dem Assemblerprogramme für die C-Control erstellt werden können, stehen übrigens in der ASSEMBLE.TXT-Datei des C-Control-intern-ZIP-Archivs.
Gibt es noch einen anderen Assembler als den AS05?
Der von mir verwendete Assembler AS05 unterstützt einige Instruktionen, die nicht zum von Motorola veröffentlichten Befehlssatz einer 6805-CPU gehören. Allerdings ist er "abwärtskompatibel" und unterstützt auch die Standard-Mnemonic anderer Assembler. Dieses Feature und der Umstand, daß er kostenlos benutzt und weitergegeben werden darf, waren der Grund dafür, daß ich ihn meiner Sammlung beigelegt und seinen Befehlssatz in jedem Assemblerprogramm benutzt habe. Außerdem läßt er sich hervorragend in die DOS-IDE einbinden. Ein Anwender, der unter Windows arbeitet, hat mir geschrieben, daß er statt dem AS05 lieber den Telemark Assembler (TASM) von Thomas N. Anderson benutzt. Der TASM kann wohl in Ultraedit eingebunden werden, wie wohl auch das gesamte andere CC-Basic-Umfeld. Allerdings handelt es sich um einen Shareware-Assembler.
Sind mit der C-Control auch parallele Prozesse programmierbar?
Standardmäßig ist das nicht möglich. Allerdings können Interruptroutinen in das System eingebunden werden. In Assembler ist das recht einfach möglich, in BASIC gibt es Probleme mit dem Stack, wie im C-Control-intern-ZIP-Archiv in der Download Area beschrieben wird. Seit einiger Zeit gibt es dafür aber einen Workaround. Mittlerweile gibt es auch einen Interpreter für Multitasking, bzw. Multithreading.
Wie programmiere ich eine Interruptroutine?
Informationen, wie eine Assembler-Interrupt-Routine in das System eingebunden werden kann, steht in meiner Infosammlung in den Dateien TIPSUTRI.TXT und INTERRUPT.TXT. Du kannst aber auch gerne eine Anfrage in das Forum stellen, wenn Du nicht damit klarkommst.
Wie deaktiviere ich das Interruptsystem der C-Control?
Es gibt in den Flags des Controllers das I-Bit. Nur wenn es gelöscht ist, können die drei maskierbaren Interruptquellen (External signal on the IRQ pin, Serial communications interface (SCI) und Programmable timer) den Mikrocontroller unterbrechen. Das I-Bit kann mit Hilfe des Assemblerbefehls SEI gesetzt (Interrupts deaktiviert) und mittels CLI gelöscht (Interrupts aktiviert) werden. Dabei ist allerdings zu beachten, daß das Betriebssystem der C-Control an etlichen Stellen CLI-Befehle enthält, die das per SEI deaktivierte Interruptssystem wieder aktivieren. Das geschieht nach Ausführen der CCBASIC-Befehle PAUSE, BEEP und SLOWMODE, außerdem beim Beschreiben eines Bit-, Byte- oder Wordports, beim Schreiben oder Lesen einer Systemvariable (TIMER, FREQ, YEAR, MONTH, usw.), außerdem beim Neuprogrammieren des internen EEPROM und natürlich nach einem Reset. Es gibt zu jeder Interruptquelle diverse Interrupt Enable Bits, so daß sich einige Interrupts unabhängig vom I-Bit gezielt deaktiviert lassen. Siehe Manual zum 68HC05.
Kann man das Zählen der TIMER-Variable, bzw. den 20-ms-Interrupt beschleunigen?
Es ist in der Tat möglich, den "20-ms-Interrupt", der für das Zählen der TIMER-Systemvariable, dem Rücksetzen der DCF77-OK-Signale, dem Weiterzählen der internen Uhr, dem Dekrementieren der PAUSE-Ticks und Generieren des TEST-Signal zuständig ist, zu beschleunigen. Man kann sich mittels Assemblerprogramm in den Timer-Output-Compare-Interrupt hängen, einen eigenen Handler für den Timer Output Compare 2 schreiben und in diesem festlegen, wann der Interrupt das nächste Mal ausgelöst werden soll. Anders macht es das Betriebssystem auch nicht. Wenn man die Zeitintervalle zwischen den Interruptauslösungen immer weiter verringert, kommt man allerdings an einen Punkt, an dem die C-Control nichts anderes mehr macht, als die Interrupts abzuarbeiten. In diesem Fall sollte man sich Gedanken machen, ob man die Interruptroutine von unnötigem Ballast befreien kann oder ob es nicht vielleicht doch noch eine andere Möglichkeit gibt, die Problemstellung zu lösen. Beispielsweise kann man den External Interrupt (IRQ) benutzen, um auf ein Ereignis von außen zu reagieren oder man taktet die C-Control höher. 8 MHz sind immer möglich. Im folgenden Assemblerprogramm, das mit AS05 assembliert, in CCBASIC eingebunden und mittels SYS &h101 aufgerufen werden kann, wird der Rest der Standard-Interruptroutine per JSR $0e89 aufgerufen. Es handelt sich um einen Teil des Timer-Output-Compare-2-Handler des Betriebssystems. Falls nur die TIMER-Variable benötigt wird, kann man das Inkrementieren der Variable von der eigenen Interruptroutine erledigen lassen und sich den Aufruf der Betriebssystemroutine sparen. In diesem Fall müssen auch OCR2HIGH und OCR2LOW von der eigenen Interruptroutine gesetzt werden (siehe Original-Routine). DCF77, PAUSE, die Uhrzeit und das TEST-Signal laufen dann allerdings nicht mehr.
org $101 initmytimercmp: lda #(mytimercmp-$100) ; eigene Interruptroutine fuer den sta $52 ; Timer Output Compare aktivieren rts ; Ruecksprung zu BASIC mytimercmp: brclr #6,$13,mytimercmp2 ; auf Timer Output Compare 2 testen lda #1 ; mit gesetztem Akku ins System rts ; zurueckkehren mytimercmp2: lda $1f ; festlegen, wann der naechste add #lo(2000) ; Timer Output Compare 2 Interrupt sta $84 ; ausgeloest werden soll lda $1e ; $83:$84 = OCR2 + #2000 adc #hi(2000) ; (4 * 2000 * 1/(2e6 Hz) = 4 ms) jsr $0e89 ; Rest der Standardroutine aufrufen clra ; mit geloeschtem Akku ins System rts ; zurueckkehren |
Wie programmiere ich den I2C-Bus?
In der Infosammlung gibt es eine Datei namens I2C.TXT, in der erklärt wird, was ein I2C-Bus ist und wie man den Geräten am Bus eine Lese- und Schreibkennung zuweist. In der Datei HIGHENDU.ASM stehen die Subroutinen "prolog" und "epilog", außerdem werden dort die Betriebssystemroutinen I2C_Read, I2C_ReadLast, I2C_Start, I2C_Write und I2C_Stop verwendet.
Bevor man ein anderes "Gerät" als das 24C65-EEPROM ansprechen kann muß man das EEPROM zuerst vom Bus abmelden (mit I2C_ReadLast) und anschliessend die Lese- oder Schreibkennung des neuen Gerätes übermitteln (mit I2C_Start). Was danach übertragen werden muß, ist je nachdem, was man ansprechen will, unterschiedlich: Bei einem RAM-Speicher wird die anzusprechende Adresse in einem Byte übertragen (mit I2C_Write); bei einem EEPROM ist diese Adresse zwei Byte lang. Bei Speicherbausteinen werden danach die eigentlichen Daten übertragen (mit I2C_Read oder I2C_Write). Bei einem Portexpander wie dem PCF 8574 werden diese Daten direkt nach der Kennung übertragen (keine Adresse nötig). Nach dem Lesen muß die Betriebssystemroutine I2C_ReadLast aufgerufen werden, um das Gerät wieder vom Bus zu trennen. Beim Schreiben übernimmt die Routine I2C_Stop diese Aufgabe. Zum Schluß darf man nicht vergessen, das 24C65-EEPROM wieder anzumelden (siehe "epilog"), da die C-Control-Unit sonst nicht mit der Ausführung des BASIC-Programms fortführen kann.
Wem das alles zu trocken war, der kann auf CC2Net.de von André Helbig vorbeischauen. Ich glaube, dort gibt es die beste Sammlung an Datenblättern, Programmen, etc. zum I2C-Bus.
Wie frage ich das Drücken oder Loslassen einer Taste ab?
In fast jedem Programm muß der Zustand eines Tasters oder eines anderen digitalen Signals erkannt werden. Es geht genaugenommen um die Erkennung von Veränderung an einem Eingangsport. Das hier gezeigte Verfahren ist also recht universell und kann nicht nur für Taster benutzt werden. Die einfachste Form der Abfrage ist mittels "WAIT taster=OFF". In diesem Fall wartet das Programm solange, bis der Taster "OFF" zurückliefert, also am Port 0 Volt liegen. Wenn gewartet werden soll, bis am Port 5 Volt liegen, kann einfach "WAIT taster=ON" verwendet werden. Dieses Verfahren hat aber den Nachteil, daß die Programmausführung während des Wartens stehenbleibt. Außerdem werden Zustandsänderungen nicht detektiert. Im Folgenden wird gezeigt, wie die Zustandsänderungen an einem Port detektiert werden können. Es wird eine Bitvariable benötigt, um den jeweils alten Zustand zu speichern, und eine zweite gegen Kontaktprellen.
define taster port[1] 'liefert ON oder OFF define alterzustand bit[192] 'speichert ON oder OFF define temp bit[191] 'speichert ON oder OFF #schleife ' Dieser Teil des Programms wird staendig durchlaufen temp=taster if temp=alterzustand then schleife alterzustand=temp ' Dieser Teil des Programms wird nur einmal bei jeder ' Zustandsaenderung am Port, in diesem Fall also dem ' Druecken oder Loslassen des Tasters, durchlaufen goto schleife |
Wie überwache ich mehrere Ports gleichzeitig?
Im vorherigen Abschnitt wurde gezeigt, wie die Zustandsänderungen an einem einzigen Port erkannt werden. Falls mehr als ein Eingangsport gleichzeitig abgefragt werden muß, kann man die Ports gemeinsam als BYTE- oder WORDPORT abfragen, in einer temporären Variable zwischenspeichern und die gewünschten Ports mit AND ausmaskieren. Verglichen und gespeichert wird in diesem Fall mittels BYTE- oder WORD-Variable.
define meinport byteport[1] 'entspricht PORT[1] bis PORT[8] define alterzustand byte define temp byte #schleife ' Dieser Teil des Programms wird staendig durchlaufen temp=meinport and &b00001110 'PORT[2], PORT[3] und PORT[4] beobachten if temp=alterzustand then schleife alterzustand=temp ' Dieser Teil des Programms wird nur einmal bei jeder ' Zustandsaenderung an einem der drei Ports durchlaufen goto schleife |
Wie programmiere ich eine Zeitschaltuhr in CCBASIC?
Vor diesem Problem stehen viele Anwender, wenn sie die C-Control zum Schalten einiger Geräte einsetzen möchten. Leider ist diese Aufgabe nicht so einfach zu lösen, wie man zunächst vielleicht glauben mag. Hier helfen die logischen Funktionen AND und OR weiter, mit denen die Uhrzeitvariablen der C-Control abgefragt und logisch verknüpft werden können. Man sollte allerdings auf eine genaue Abfrage einer bestimmten Anfangs- und Endzeit verzichten, da der Fall auftreten könnte, daß die C-Control diese Zeitpunkte aus irgendeinem Grund "verschläft". Denkbar ist zum Beispiel, daß die C-Control zwischen diesen Eckzeiten eingeschaltet wird.
Das folgende Programmsegment funktioniert anstandslos, allerdings sollte man bei der Abfrage der Uhrzeit immer beachten, daß sich die Uhrzeitvariablen während der Programmausführung ändern können. Problematisch ist beispielsweise eine Abfrage wie "IF HOUR=16 AND MINUTE>=0 THEN ...". Wenn HOUR=16 gegen 16:59, aber MINUTE>=0 gegen 17:00 Uhr abgefragt wird, würde sich das zu schaltende Gerät um 17 Uhr kurz anschalten. Umgehen kann man dieses Problem, indem man die Uhrzeitvariablen zwischenspeichert, anschließend überprüft, ob sie sich verändert haben und, falls ja, noch einmal einliest. Erst dann darf die Uhrzeit ausgewertet werden. Der Nachteil dieses Verfahrens ist allerdings der erhöhte RAM-Verbrauch.
Übrigens könnte man die Abfrage erheblich vereinfachen, wenn man die Uhrzeit grundsätzlich nur in Minuten auswertet. Da ein Tag genau 1440 Minuten lang ist, lassen sich im positiven Wertebereich einer Wordvariablen Zeitintervalle bis zu drei Wochen speichern. Am übersichtlichsten lassen sich Uhrzeiten darstellen, in dem man die Stunden mit 100 multipliziert und anschließend die Minuten addiert. Das Ergebnis zählt von 0 (für 24 Uhr) bis 2359 (für 23:59 Uhr).
' einfache Zeitschaltuhr fuer C-Control
' am 07.11.2002 in CCBASIC von Dietmar Harlos
' Signalisiert, ob das Geraet ein- oder ausgeschaltet ist
define status bit [192]
' Initialisierung des Geraets
status=on : gosub ausschalten
' Endlosschleife
#endlos
print "Stunde: ";hour;" Minute: ";minute
' man sollte beachten, dass sich HOUR und MINUTE waehrend der
' folgenden Abfrage aendern koennen
if (hour=16 and minute>=45) or (hour>=17 and hour<=19) or (hour=20 and minute<15) then goto true
gosub ausschalten
goto endif
#true
gosub anschalten
#endif
' man koennte an dieser Stelle abfragen, ob der Anwender
' eine Taste drueckt und das Geraet manuell ein- oder
' ausstellen moechte
goto endlos
' Subroutine zum Anschalten
#anschalten
' mehrfaches Anschalten verhindern
if status=off then status=on else return
print "anschalten"
return
' Subroutine zum Ausschalten
#ausschalten
' mehrfaches Ausschalten verhindern
if status=on then status=off else return
print "ausschalten"
return
|
Wie läßt sich ohne Programmunterbrechung nach einem bestimmten Zeitintervall eine Aktion ausführen?
Mit Hilfe der TIMER-Variablen geht das recht einfach. Allerdings darf man nicht abfragen, ob der End-Zeitwert, bis zu dem das Programm warten soll, größer oder kleiner als der aktuelle TIMER-Stand ist, sondern es sollte die Differenz zwischen den beiden Werten errechnet werden; also einfach subtrahieren. Dann spielen die diversen Überlaufe, die bei der Berechnung auftreten könne, keine Rolle mehr. Zu beachten ist allerdings, daß man dieses Verfahren nur für Zeitintervalle bis 32767/50=655.34 Sekunden, das sind 10 Minuten und 55 Sekunden, einsetzen darf, da die C-Control alle Berechnungen in 15 Bit plus Vorzeichenbit durchführt und die TIMER-Variable alle 20 ms inkrementiert wird.
print print "Ueberlauftolerante Timerabfrage:" print define ende word ende=timer+10 print "Soll-Ende: ";ende #warten pause 1 print timer if ende-timer>0 then warten print "Ist-Ende: ";timer end |
Kann die C-Control Kommazahlen verarbeiten oder ausgeben?
Im folgenden wird eine Division mit beliebig vielen Nachkommastellen im Ergebnis durchgeführt. Berechnet wird Dividend durch Divisor, der Quotient (das Divisionsergebnis) wird auf der seriellen Schnittstelle ausgegeben. Selbstverständlich kann man das Ergebnis auch Ziffer für Ziffer auf dem LCD ausgeben. Dann müßte allerdings der Vorkommaanteil noch in einzelne Ziffern zerlegt werden. Wer Kommazahlen auch im Dividend oder Divisor unterstützen muß, also beispielsweise 800 durch 12.5 teilen möchte, kann entweder den Divisor 12.5 zuvor mit 10 multiplizieren und erhält ein Ergebnis, das um Faktor 10 zu niedrig ist. Oder man multipliziert sowohl Dividend als auch Divisor mit 10, rechnet also 8000 durch 125, und erhält so gleich das endgültige Ergebnis. (In vorliegenden Fall könnte man übrigens auch mit 2 statt 10 erweitern.) Zu beachten ist in jedem Fall, daß im Ausdruck (a MOD b)*10 ein Überlauf auftreten kann, da die C-Control als größte Zahl 32767 verarbeiten kann. Auf der sicheren Seite ist man mit einem Divisor von maximal 3277. Ob ein Überlauf bei größeren Divisor-Werten auftreten kann, hängt aber vom Ergebnis des Ausdrucks a MOD b und somit auch vom Dividenden ab. Die Division arbeitet in der dargestellten Form nur mit positiven Zahlen. Falls auch negative Werte verarbeitet werden sollen, muß vor der Division das Vorzeichen von Dividend und Divisor abgefragt und deren Betrag gebildet werden. Sinnvoll ist auch eine Erweiterung, um auf einen Divisor von Null reagieren zu können.
DEFINE a WORD 'Dividend
DEFINE b WORD 'Divisor
DEFINE c BYTE 'Zaehler fuer Nachkommastellen
a=2006
b=1119
GOSUB ausgabeadurchb
PRINT
END
#ausgabeadurchb
PRINT a/b;".";
c=0
#schleife
a=(a MOD b)*10
PRINT a/b;
c=c+1
IF a AND c<10 THEN schleife
RETURN
|
Wie berechnet man den Mittelwert einiger Meßwerte?
Auf den ersten Blick eine recht einfache Aufgabe, doch in der Praxis nur mit einigem Gehirnschmalz zu lösen. Am einfachsten ist es natürlich, wenn man alle Meßwerte summiert und für die Auswertung durch die Anzahl der Meßwerte teilt. Doch gibt es hierbei das Problem, daß die Summe zu groß werden kann und es dadurch zu einem Überlauf kommt. Es gibt noch eine andere Art der Umsetzung, nämlich die sogenannte laufende Mittelwertbildung. Sie funktioniert nach der Formel "Mittelwert = Mittelwert + (Messwert - Mittelwert) / Anzahl", wobei "Anzahl" die Anzahl der aufgenommenen Meßwerte ist. Allerdings gibt es auch hierbei ein Problem: Wenn bereits eine große Anzahl Meßwerte aufgenommen wurde, ist der Term "(Messwert-Mittelwert)/Anzahl" kleiner 1 und somit 0, weil die C-Control ja nur mit Integerwerten rechnet. Aber auch sonst kommt es durch Abschneiden der Nachkommastellen zu Ungenauigkeiten. Um das zu verbessern, könnte man zum Beispiel den aufgenommenen Meßwert mit einem konstanten Faktor (z.B. 10 oder 100) multiplizieren, bevor er weiterverarbeitet wird. Oder bei der Division runden. Das folgende Beispielprogramm demonstriert die Summiermethode und die laufende Mittelwertbildung.
' Demonstration zweier Algorithmen zur Mittelwertberechnung ' am 07.11.2002 in CCBASIC von Dietmar Harlos define mittel word define anz word define summe word define wert byte mittel=0 : anz=0 : summe=0 #endlos anz=anz+1 print anz;". ";"Messwert: "; input wert print wert ' für den Simulator summe=summe+wert mittel=mittel+(wert-mittel)/anz print "Mittelwert: ";mittel print "Summe: ";summe print "Summe/Anzahl: ";summe/anz print goto endlos |
Wie kann man den Sinus oder Cosinus berechnen?
Es gibt mehrere Möglichkeiten, jede mathematische Funktion, also auch trigonometrische, auf der C-Control zu implementieren. Die simpelste Methode ist die Verwendung einer Tabelle. Etwas aufwendiger aber speicherplatzschonender ist es, die mathematische Funktion mit Hilfe einer sogenannten Taylorreihe (also eines Polynoms) anzunähern. Da die C-Control bekanntlich keine Fließkommazahlen verarbeiten kann, bleibt nur übrig, geeignet zu skalieren und die Taylorreihe mit Hilfe von Integerzahlen zu berechnen. Der Cosinus läßt sich übrigens leicht in einen Sinus überführen. Siehe Mathebuch.
' Cosinus-Funktion auf der C-Control-I mittels Integerzahlen ' am 01. September 2001 in CCBASIC von Dietmar Harlos ' Zwischen 0 und 88 Grad (bis 1.53 Radians) liegt der relative ' Fehler bei kleiner/gleich 3 Prozent.. define winkel word define temp1 word define temp2 word winkel=79 'der Winkel in Radians (skaliert mit 100) PRINT cosinus 'das Ergebnis ist mit 10000 skaliert #cosinus temp2=winkel*winkel temp1=10000-temp2/2 temp2=(temp2/200)*(temp2/100) return temp1+temp2/13 'eigentlich 12 aber mit 13 geringerer Fehler |
Kann man auch den Logarithmus naturalis (LN) berechnen?
Die Frage ist, mit welcher Genauigkeit und in welchem Wertebereich der Logarithmus zur Basis e benötigt wird. Natürlich läßt sich auch LN(x) als Taylorreihe entwickeln: ln(1+x) = x - 0.5*x^2 + 0.333*x^3 - 0.25*x^4 (mit x = -1..+1). Damit kann der Logarithmus zur Basis e also im Bereich zwischen ln(0) und ln(2) errechnet werden. Wie Du sicher weißt, kann man sich dann wie folgt "weiterhangeln": ln(a*b)=ln(a)+ln(b). Da die C-Control keine Fließkommazahlen verarbeiten kann, muß man wie beim COS(x) geeignet skalieren. Allerdings tritt auch bei genauster Berechnung das Problem auf, daß die Taylorreihe nie hundertprozentig die Originalfunktion nachbilden kann. Eigentlich bräuchte man nämlich ein Polynom mit unendlich vielen Termen. Bei Abbruch nach dem vierten Term gibt es bei ln(2) schon einen Fehler von rund 16%. Wenn x bis 0.75 geht, also ln(1+x)=ln(1.75) berechnet wird, liegt der Fehler bei "nur" 5%. Aus diesem Grund ist es beim Logarithmus besser, eine Tabelle zu benutzen. Sie liefert erheblich genauere Ergebnisse. Der Index in dieser Tabelle ist das x, der aus der Tabelle gelesene Wert ist das ln(x). Man muß x geeignet skalieren und die Größe der Tabelle hängt vom gewünschten Wertebereich für x und der gewünschten Genauigkeit ab.
PRINT "ln(x) fuer die C-Control-I" PRINT "ln(0.01) bis ln(2.56) kann errechnet werden" PRINT "das Ergebnis ist mit 5000 skaliert" PRINT "Hinweis: Berechnung von hoeheren Werten durch ln(a*b)=ln(a)+ln(b)" PRINT DEFINE x WORD DEFINE erg WORD PRINT "Beispiel 1:" PRINT "Berechnung von ln((0+1)/100)*5000 = -23026" PRINT " ln(0.01) = -4.605" x=0 LOOKTAB lnx, x, erg PRINT erg PRINT PRINT "Beispiel 2:" PRINT "Berechnung von ln((255+1)/100)*5000 = 4700" PRINT " ln(2.56) = 0.94" x=255 LOOKTAB lnx, x, erg PRINT erg PRINT END TABLE lnx -23026 -19560 -17533 -16094 -14979 -14067 -13296 -12629 -12040 -11513 -11036 -10601 -10201 -9831 -9486 -9163 -8860 -8574 -8304 -8047 -7803 -7571 -7348 -7136 -6931 -6735 -6547 -6365 -6189 -6020 -5856 -5697 -5543 -5394 -5249 -5108 -4971 -4838 -4708 -4581 -4458 -4338 -4220 -4105 -3993 -3883 -3775 -3670 -3567 -3466 -3367 -3270 -3174 -3081 -2989 -2899 -2811 -2724 -2638 -2554 -2471 -2390 -2310 -2231 -2154 -2078 -2002 -1928 -1855 -1783 -1712 -1643 -1574 -1506 -1438 -1372 -1307 -1242 -1179 -1116 -1054 -992 -932 -872 -813 -754 -696 -639 -583 -527 -472 -417 -363 -309 -256 -204 -152 -101 -50 0 50 99 148 196 244 291 338 385 431 477 522 567 611 655 699 742 785 828 870 912 953 994 1035 1076 1116 1156 1195 1234 1273 1312 1350 1388 1426 1463 1501 1537 1574 1610 1647 1682 1718 1753 1788 1823 1858 1892 1926 1960 1994 2027 2061 2094 2126 2159 2191 2223 2255 2287 2319 2350 2381 2412 2443 2473 2504 2534 2564 2594 2624 2653 2682 2712 2741 2769 2798 2827 2855 2883 2911 2939 2967 2994 3022 3049 3076 3103 3130 3156 3183 3209 3236 3262 3288 3313 3339 3365 3390 3415 3441 3466 3491 3515 3540 3565 3589 3614 3638 3662 3686 3710 3733 3757 3781 3804 3827 3851 3874 3897 3920 3942 3965 3988 4010 4032 4055 4077 4099 4121 4143 4165 4186 4208 4229 4251 4272 4293 4314 4336 4356 4377 4398 4419 4439 4460 4480 4501 4521 4541 4561 4581 4601 4621 4641 4661 4680 4700 TABEND |
Wie erstellt man eine Tabelle für mathematische Funktionen?
Die obenstehende Tabelle zur Berechnung des Logarithmus naturalis (LN) wurde mit Hilfe des folgenden QBASIC-Programms in der DOS-Box unter Windows erstellt. Die Ausgaben des Programms können markiert und in die Zwischenablage übernommen werden. Anschließend kann man sie bequem in das gewünschte CCBASIC-Programm einfügen.
' LN(x) als Tabelle für C-Control scalex = 100 scalelnx = 5000 PRINT "TABLE lnx" FOR x% = 1 TO 256 lnx = LOG(x% / scalex) / LOG(EXP(1)) t% = lnx * scalelnx PRINT t%; NEXT x% PRINT : PRINT "TABEND" END |
In meinen Programmen funktioniert der TOG-Befehl nicht!
Bestimmt hast Du vergessen, die Hilfe zur C-Control zu lesen. Dort ist nämlich erklärt, daß ein Port vor dem TOG-Befehl wenigstens einmal als Ausgang benutzt worden sein muß. Also erst "led=0", dann "TOG led". Siehe auch Online-Hilfe der IDE.
Kann man ein größeres serielles EEPROM an die C-Control anschließen?
Man kann statt dem 24C65 (8 Kilobyte Speicher), den 24C256 von ATMEL einsetzen. Dieser bietet 32 KB Speicherplatz. Zusätzliche Informationen zu diesem Thema gibt es auch unter http://home.t-online.de/home/B.Kainka. Bei der Main-Unit ist das EEPROM gesockelt und kann einfach durch eine DIP-Version ersetzt werden. Bei der M-Unit und der Station hat Conrad Eletronic allerdings ein SMD-Bauteil verwendet. André Helbig bietet auch hier ein passendes an. Allerdings muß dazu gelötet werden.
Das Betriebssystem schert sich beim Speichern in die Datendatei (mit den "OPEN# FOR ..."- und "PRINT#"-Befehlen) übrigens nicht um die Groesse des EEPROMs. Falls ueber die gueltige Bereichsgrenze des EEPROMs hinaus in dieses geschrieben (oder aus diesem gelesen wird) laeuft einfach der interne Adresszaehler im EEPROM ueber und es wird der Beginn des EEPROMs ueberschrieben. Nur die FILEFREE-Funktion benutzt zur Berechnung des freien Speichers des EEPROMs eine feste Groesse. Beim Einsatz eines anderen EEPROMs als dem 24C65 gibt es außerdem Probleme beim Überschreiben der sogenannten Page Boundary. Siehe übernächste Frage.
Wie kann die FILEFREE-Funktion bei einem größeren EEPROM angepaßt werden?
Das Betriebssystem der C-Control berechnet die Anzahl der Words, die im seriellen EEPROM noch zur Datenaufzeichnung zur Verfügung stehen (FILEFREE), folgendermaßen: "FILEFREE = (_24C65_LASTBYTE - filestart - filelen) / 2", wobei _24C65_LASTBYTE gleich 8180 ist, da es davon ausgeht, daß ein 24C65, bzw. 24C64 an die C-Control angeschlossen ist. Wenn Du dieses EEPROM z.B. durch ein 24C512 ersetzt, also ein EEPROM mit 65536 statt 8192 Byte Größe verwendest, mußt Du zum FILEFREE-Wert einfach (65536-8192)/2=28672 hinzuaddieren. Übrigens ist die Größe des I2C-EEPROMs auf 65536 Byte begrenzt, da der Speicher über eine 16-bit-Adresse angesprochen wird. Es macht also keinen Sinn, sich ein 24C1024-EEPROM zuzulegen, es sei denn, man möchte es selber in Assembler ansprechen oder das neue DeepXS 2.0.0 benutzen.
print myfilefree end #myfilefree return FILEFREE+28672 |
Daten aus der Datei gehen verloren und/oder Teile des Programms werden überschrieben.
Dieses Problem sollte nur dann auftreten, wenn das Original-24C65-I²C-EEPROM durch ein anderes, z.B. 24C64 oder 24C512 ersetzt wurde. Bei letztgenannen EEPROMs findet beim Überschreiten einer 32-Byte-Reihe im Page-Write-Modus ein Adreßüberlauf statt, wodurch Daten an falsche Stellen im Speicher geschrieben werden. Auf gut Deutsch bedeutet daß, wenn mehr als ein Byte am Stück ins EEPROM geschrieben wird, können Probleme auftreten. Da das Betriebssystem der C-Control beim Schreiben in die Datei mittels PRINT# ein Word, also zwei Bytes hintereinander, ins EEPROM überträgt, tritt das geschilderte Problem auf, wenn auf eine Adresse geschrieben wird, deren fünf niederwertigste Bits gesetzt sind. Dieser Fall kann allerdings nur dann auftreten, wenn die Größe des CCBASIC-Programms ungerade ist. Neuere CCBASIC-Compiler, bzw. Downloadtools hängen deshalb bei Bedarf ein zusätzliches END-Token an das Programm, um eine gerade Programmgröße zu erhalten. Beim 24C65 existiert dieses Problem nicht. Es besitzt einen 64 Byte großen Cache, der zunächst die zu schreibenden Daten aufnimmt, bevor sie in das EEPROM programmiert werden. Bedingt durch die Adressierung im Cache können mindestens 57 Bytes am Stück ins EEPROM geschrieben werden, bevor ein Adreßüberlauf stattfindet.
Ich habe ein größeres EEPROM, kann aber keine BASIC-Programme größer als 8 Kilobyte kompilieren!
Wenn Du ein BASIC-Programm mit mehr als 8 Kilobyte Größe von der C-Control ausführen lassen möchtest brauchst Du einen BASIC-Compiler, der die 8-KB-Größenbeschränkung nicht kennt. Für die Windows-IDE gibt es dafür eine neue "CCBAS32.DLL"-Datei. Diese kann auf Idel's Homepage heruntergeladen werden. Für die DOS-IDE habe ich den Original-CCBAS.EXE-Compiler etwas gepatcht. Diese Datei (CCBASBIG.EXE) befindet sich als ZIP-Archiv auf meiner Internetsite.
Wieso 8 KB? Ich kann nur BASIC-Programme bis etwa 6400 Byte kompilieren!?
Dieses Problem tritt nur auf, wenn die Windows-Entwicklungsumgebung zur Programmentwicklung benutzt wird. Der Windows-Compiler fuegt offenbar in jedes BASIC-Programm zusaetzlichen Code ein, damit dieses vom Simulator geladen und ausgefuehrt werden kann. Dadurch können nicht die vollen 8 Kilobyte des seriellen EEPROMs ausgenutzt werden. Mit der DOS-IDE, tritt dieses Problem nicht mehr auf und es können Programme bis 8100 Byte Größe kompiliert werden. Die DOS-IDE (CCE.EXE) kannst Du uebrigens auch unter Windows in einem DOS-Fenster sehr gut benutzen (50 Zeilen-Modus bei einer Schriftgröße von 7 x 12 und einer Screenauflösung von 1024x768 Bildpunkten oder 43 Zeilen bei 800x600 Punkten), nur das beiliegende Terminalprogramm MINITERM.EXE macht bei mir Probleme; doch dafuer kannst Du TERMINAL.EXE einsetzen. Das Programm ist in meiner erweiterten DOS-IDE bereits eingebunden.
Was ist der High-Endurance-Block?
Jede Speicherstelle im seriellen 24C65-EEPROM, das im C-Control-Minicomputer Verwendung findet, kann 100.000 bis 1.000.000 mal neu programmiert werden, danach ist die Speicherstelle hinüber. Es gibt aber einen verschiebbaren, 4096 Bit grossen Bereich, der bis zu 10.000.000 mal neu programmiert werden kann. Dieser Bereich heisst High-Endurance-Block und liegt von Werk aus (angeblich) am Ende des Speicherraums des EEPROMs. In meiner Sammlung findest Du ein BASIC- und ein Assemblerprogramm, mit denen der High-Endurance-Block verschoben werden kann.
Leider habe ich auf meiner M-UNIT kein 24C65-EEPROM, sondern ein 24C64. Dieses EEPROM hat keinen High-Endurance-Block, so daß ich die Programme leider noch nicht richtig testen konnte. Falls sie bei Dir laufen (oder auch nicht) gib' mir bitte Bescheid! Genauere Infos zum EEPROM und wie man den High-Endurance-Block verschiebt, findest Du übrigens im 24C65-Manual von der Firma Microchip.
Wieviele Speicherzyklen sind denn nun beim EEPROM möglich? 10.000, 100.000 oder 1.000.000?
Die C-Control besitzt zwei verschiedene EEPROMs. Das eine, was üblicherweise gemeint ist, ist das serielle EEPROM mit der Bezeichnung 24C65. Dieses "haengt" am I2C-Bus der Unit. Jede Speicherstelle in diesem EEPROM kann man 100.000 oder 1 Millionen mal neu beschreiben - mehr garantiert zumindest der Hersteller nicht. Welcher der beiden Werte richtig ist, kann ich leider nicht sagen, die Daten im Manual zum EEPROM von Microchip sind widerspruechlich. Ich vermute aber, daß 1 Millionen mal neu programmiert werden kann. Zusätzlich besitzt das 24C65 den weiter oben angesprochenen High-Endurance-Block.
Ausserdem besitzt die Unit - so wie jeder MC68HC05B6-Mikrocontroller - ein internes EEPROM. Dieses liegt im Speicher von Adresse $100 bis $1ff, und dient normalerweise dazu, Assemblerprogramme aufzunehmen. Dieses EEPROM hat (laut Motorola) eine Lebensdauer von nur 10.000 Loesch- und Schreibzyklen.
Der CCBAS2MC-Kompiler meldet den Fehler "Label unreachable by short branch"!?
Wie Du sicher weißt, ist der Platz, der zur Speicherung von Maschinenspracheprogrammen in der C-Control zur Verfügung steht, sehr begrenzt. Ein Maschinenspracheprogramm kann maximal 255 Byte lang sein. Der Kompiler geht darum möglichst sparsam mit diesem knappen Speicherplatz um. Aus diesem Grund wird jeder BASIC-Sprungbefehl (GOTO, GOSUB) in einen sogenannten "kurzen" Assembler-Sprungbefehl übersetzt. "Lange" Sprungbefehle würden 3 Byte im Speicher belegen, "Kurze" dagegen nur 2. Der Nachteil von den kurzen Sprungbefehlen ist aber, daß nur zu Speicherstellen gesprungen werden kann, die 126 vor, bzw. 129 Byte hinter dem Sprungbefehl liegen. Und genau aus diesem Grund meldet der Kompiler, genauer der Assembler, einen Fehler. Zwar könnte man den Kompiler veranlassen, grundsätzlich nur lange Sprungbefehle zu benutzen, doch würde das kaum Sinn machen, da Maschinenspracheprogramme ohnehin nur 255 Byte groß sein dürfen. Durch lange Befehle würde man also unnötigerweise Platz im Speicher verschwenden. So bleibt also nur, das Programm zu verkleinern. Das geschieht z.B. dadurch, daß man nur Bytevariablen benutzt, wodurch das Programm auch schneller ausgeführt wird. Alternativ könnte man ein GOTO oder GOSUB "zerlegen", also z.B. vom Beginn des Programms zuerst in die Mitte springen und von dort aus an das Ende des Programms, anstatt direkt vom Anfang an das Ende. Dadurch wird der Sprungbereich der "kurzen" Sprungbefehle nicht überschritten.
Meine C-Control stürzt manchmal ab oder spielt verrückt!
Zuerst sollte man abklären, ob ein Programmierfehler vorliegt. Einer der häufigsten Knackpunkte bei der C-Control ist das Überschreiben von User-Variablen durch das Betriebssystem: In CCPLUS stehen die letzten 4 Bytes des User-RAMs nicht zur Verfügung, wenn das LCD benutzt wird. In CCBASIC überprüft der Compiler nicht in jedem Fall, ob alle definierten Variablen auch in die 24 Byte des User-RAMs passen. Eventuell wird ein Assemblermodul per SYSCODE in das CCBASIC-Programm eingebunden, das einen Teil der User-Variablen benutzt.
Falls Programmierfehler auszuschließen sind, kann das Fehlverhalten durch EMV hervorgerufen werden. Sehr häufig tritt dieses Problem auf, wenn in der Nähe der C-Control große Lasten geschaltet werden müssen. Es handelt sich dann meist um elektrische Störungen, die sich durch die Luft oder durch Versorgungs-, bzw. Meßleitungen ausbreiten und die C-Control aus dem Tritt bringen können. Bei der M-Unit schafft oft ein großer Kondensator Abhilfe, der parallel zur C-Control in die Versorgungsleitung geschaltet wird. Dieser sollte möglich nahe am Controller sitzen. Auch mittels Induktivitäten, die seriell zur C-Control geschaltet werden, lassen sich Störungen verringern. Die Meßleitungen lassen sich entstören, indem ein einfacher Widerstand und eventuell ein kleiner Kondensator verwendet wird (Tiefpaßfilter). Insbesondere bei längeren Leitungen im Außenbereich einen Optokoppler verwenden. Auch sollte man beachten, daß die M-Unit keine Pull-Up-Widerstände, wie etwa die Main-Unit, besitzt. Manchmal wird die C-Control durch EMV gestört, die drahtlos einstreut. Dann hilft wohl nur ein Abschirmen oder ein Ortswechsel. Auch sollte auf guten und ausreichenden Massekontakt (Masseschleifen vermeiden) Wert gelegt werden.
Der Schuldige an dieser Misere ist bei der M-Unit häufig der Resetbaustein. Dieser löst oft schon bei kleiner Betriebsspannungsänderung einen Reset aus. Besonders, wenn große Verbraucher (z.B. Relais) geschaltet werden, sollte man darum getrennte Stromquellen verwenden. Bei allen C-Control-Versionen existiert außerdem ein Problem mit dem I²C-Bus: Da dieser nicht wie vorgeschrieben über Open-Drain-Ausgänge, sondern über Push-Pull angesprochen wird, kommt es regelmäßig zu Kurzschlüssen auf dem Bus, bei denen kurzzeitig ein Strom von rund 50 mA fließt. Wenn die M-Unit ohne Stützkondensator betrieben wird und die Versorgungsspannungquelle einen hohen Innenwiderstand besitzt, spricht der Resetbaustein an, erzeugt aber teilweise einen zu kurzen Reset-Impuls, so daß der Controller nicht resettet, sondern in einen undefinierten Zustand versetzt wird. In solchen Situationen ist es möglich, daß der Controller vollkommen zufällige Aktionen ausführt. Dieser Fall tritt vor allen Dingen immer dann auf, wenn die Betriebsspannung der C-Control ohnehin schon am unteren Level liegt. Festspannungsregler haben häufig eine Toleranz von 5 %, die Ausgangsspannung kann also durchaus bei nur 4.75 Volt liegen. Der Resetbaustein reagiert aber unter Umständen schon ab 4.7 Volt! Da die C-Control mit bis zu 5.5 Volt betrieben werden darf, sollte man in solchen Fällen die Ausgangsspannung also etwas nach oben korrigieren.
Bei der M-Unit wurden darüber hinaus einige Eingangsleitungen von PORTA aus Kostengründen nicht auf ein definiertes Potential gelegt. Ein Workaround zu diesem Problem steht in der Datei TIPSUTRI.TXT.
Eine professionelle Lösung gegen Hänger und undefinierte Zustände ist die Verwendung eines Watchdogs. Zwar besitzt jeder 68HC05-Mikrocontroller einen internen Watchdog, doch gibt es gute Gründe, einen externen einzusetzen. Informationen hierzu und zur Unterdrückung von EMV gibt es hier.
Wie robust ist die C-Control?
Obwohl der Mikrocontroller auf dem die C-Control basiert, recht robust ist, nimmt er doch einiges übel. Vermeiden sollte man auf jeden Fall ein Verpolen der Betriebsspannung. Außerdem wird der Controller laut Motorola zerstört, sobald mehr als 7 Volt Betriebsspannung angelegt werden. Ebenso verhält es sich mit dem I²C-EEPROM. Viel mehr wird wohl auch nicht möglich sein: Ein Anwender hat seine M-Unit durch Anlegen von 12 Volt innerhalb kürzester Zeit zerstört. Ein anderer User hat festgestellt, daß die C-Control inklusive LCD für mindestens 10 Sekunden auch mal 10 V verträgt. Der MAX232 geht laut Datenblatt hingegen schon bei über 6 Volt Betriebsspannung kaputt. Die Eingänge des Controllers können laut Spezifikation Spannungen ab, die maximal ein halbes Volt über der Betriebsspannung liegen. Wenn in der Schaltung, in der die C-Control betrieben werden soll, mit größeren Spannungen gearbeitet wird, sollte man daher als Vorsichtsmaßnahme die Eingänge der C-Control immer mit einem Vorwiderstand versehen. Das gilt besonders in der Experimentierphase. Kurzschlüsse an den Ports scheint der Mikrocontroller dagegen ganz gut verkraften zu können, obwohl Motorola empfiehlt, diese niemals mit mehr als 25 mA zu belasten. Auf Masse ziehen können die Ports einen Strom von maximal 45 mA. Allerdings handelt es sich bei allen Angaben um die "Absolute maximum ratings". Auf Dauer sollte man das seiner C-Control also nicht zumuten.
Laut "C-Control Anwendungen" ist die Ungültigkeit des DCF77-Signals am Beginn jeder Stunde gewollt!?
Im Buch "C-Control-Anwendungen" (erschienen im Franzis-Verlag) wird beschrieben, daß es notwendig ist, daß das DCF77-Signal in der ersten Minute jeder Stunde von der C-Control als "ungültig" angesehen wird. Meine Meinung dazu ist folgende: Dort steht zwar, daß dieses "Feature" erwünscht ist, doch hätte man die Paritätsbits des DCF77-Signals mitausgewertet und anhand dieser detektiert, ob das Signal gültig ist, würde sich auch das Problem mit der Sonntags-Anzeige in der ersten Minute nach Mitternacht an jedem Montag von selbst lösen. Außerdem hätte man einige Bytes mehr freien Arbeitsspeicher.
Kann man die C-Control beschleunigen?
Es gibt in der Download Area einen kleinen Assemblercode, mit dem man die Befehlsausführung von CCBASIC um rund 12% beschleunigen kann. Für noch mehr Speed kann man einige kurze CCBASIC-Routinen mit Hilfe des CCBAS2MC-Compilers in Maschinencode umsetzen. Alle Leute, die des Lötens mächtig sind, können die C-Control darüber hinaus problemlos mit einem 8-MHz-Quarz betreiben. Die ROM-Version des Mikrocontrollers (MC68HC05B6) läßt sich angeblich mit bis zu 24 MHz betreiben, wenn man ein schnelleres serielles EEPROM als das 24C65 benutzt. Dieses Standard-EEPROM macht leider schon oberhalb von 12 MHz schlapp. Geeignet ist beispielsweise das 24FC256. André Helbig von CCTools bietet EEPROMs von Atmel an, die bis zu 1 MHz I²C-Bus-Takt unterstützen. Übrigens wurde die C-Control von Conrad Electronic zeitweise mittels EPROM-Controller (MC68HC705B16) hergestellt. Diese lassen sich leider nicht oberhalb von 8 MHz betreiben. Dafür sollen sie aber unempfindlicher gegenüber Störungen (EMV) sein. Beim Einsatz eines neuen Quarzes ist aber auf jeden Fall zu beachten, daß einige Betriebssystemfunktionen der C-Control (interne Uhr, DCF77, Baudrate der RS232, BEEP, PAUSE, ...) schneller ablaufen und Probleme bereiten können. Siehe dazu die folgende Frage...
Ich habe meine Unit übertaktet und jetzt läuft alles zu schnell!?
Es gibt auf meiner Download-Seite zwei Programme, mit denen die zeitabhängigen Funktionen des Betriebssystems korrigiert werden können. Das Archiv mit der etwas falschen Bezeichnung "TURBOASM" stammt von Conrad Electronic und enthält ein kleines Assemblermodul, das sich in einen Interrupt hängt und nur noch jeden dritten Interrupt an das System weiterreicht. Damit kann die Unit mit 12 MHz betrieben werden. Dazu gehört auch ein Downloader für die DOS-IDE, der auf die 3-fache Baudrate eingestellt ist. Für andere Taktraten gibt es einen Patch von Giso Wittig. Wer hingegen mit Windows arbeitet wird auf Idel's Homepage fündig.
Ist es möglich, die C-Control in einen Stromsparmodus zu versetzen?
Am besten geeignet ist hierfür die M-Unit, da diese einen wesentlich niedrigen Leistungsverbrauch besitzt als die anderen C-Control-Versionen. Es gibt drei Betriebsmodi, in denen die C-Control wenig Strom verbraucht: den PAUSE-Modus in BASIC (bringt wenig), den WAIT-Modus (Software- und Hardwareinterrupts werden weiterhin bedient) und den STOP-Modus (kann nur durch Reset oder den IRQ-Interrupt unterbrochen werden). Da der Pin fuer den IRQ-Interrupt nur bei der M-Unit herausgefuehrt ist, kann der STOP-Modus nur bei der M-Unit problemlos verwendet werden. Laut Manual entfallen im STOP-Modus max. 20 µA auf den Mikrocontroller, weitere 20 µA auf den Spannungsueberwacher und ca. 5 µA auf das I2C-EEPROM. Die Stromentnahme ist also extrem niedrig. Im WAIT-Modus benoetigt der Mikrocontroller lt. Datenblatt hingegen typisch zwischen 350 µA (Slowmode aktiv) und 1 mA (Slowmode inaktiv). Unbedingt zu beachten ist, daß vor dem Wechsel in den STOP- oder WAIT-Modus das I2C-EEPROM abgemeldet werden muß, da sonst ueber die Pullup-Widerstaende des I2C-Bus ein Strom von rund 1 mA fliesst. Das folgende Assemblerprogramm kann mit AS05 assembliert, in CCBASIC eingebunden und mittels SYS &h101 aufgerufen werden.
org $101 prolog: ;I2C-EEPROM abmelden, I2C-BUS in Idle-State jsr $08BB ; I2C_ReadLast stromsparen: stop ;Mikrocontroller komplett stoppen, auf IRQ warten epilog: ;I2C-EEPROM wieder anmelden, Ruecksprung zu BASIC ldx #$A0 jsr $083C ; I2C_Start ldx $66 jsr $0846 ; I2C_Write ldx $67 jsr $0846 ; I2C_Write ldx #$A1 jmp $083C ; I2C_Start end |
Gibt es eine Möglichkeit, daß die C-Control-Station nach Stromausfall automatisch startet?
Auf der offiziellen C-Control-Homepage (siehe CC1 -> Programmierung -> Programme) ist beschrieben, welche Modifikationen an der Hardware durchgeführt werden müssen, damit die C-Control-Station nach Stromausfall automatisch startet. Es muß dazu ein 47 µF Kondensator richtig gepolt an zwei Lötpads der Platine gelötet werden.
Das Wochentagsregister (DOW) zeigt falsche Werte an.
Es gibt mehrere Fehler im Betriebssytem der C-Control, die im Zusammenhang mit dem Wochentagsregister stehen. Einfache Abhilfe: Wenn der DOW in einem BASIC-Programm benötigt wird, folgende Zeile vor jeder Abfrage des Wochentags einfügen: IF DOW > 6 THEN DOW = 0
Gibt es die verschiedenen "Manuals" zum Mikrocontroller, EEPROM, u. ä. auch in Deutsch?
Leider nein. Aber zum Glück sind diese meist in "Easy English" geschrieben, so daß es eigentlich kein Problem sein sollte, zumindest die wichtigsten Dinge zu verstehen. Es gibt ein Freeware-Tool namens Babylon Translator, mit dem sämtliche englischen Texte, die auf dem Bildschirm erscheinen, mittels eines einfachen Klicks mit der Maus ins Deutsche übersetzt werden können. Das funktioniert nach einem ähnlichen Prinzip wie OCR. Damit der Translator gut mit dem Acrobat Reader zusammenarbeiten kann muß beim Reader allerdings die Funktion "Text und Bilder glätten" ausgeschaltet sein.
Kennst Du weitere Software-Tools, die bei der Assembler-Programmerstellung nützlich sind? Gibt es einen besseren Simulator als den ZAP?
Es gibt von der Firma P&E Microcomputer Systems einen In-Circuit-Simulator namens ICS05B. Dieser Simulator ist in doppelter Hinsicht interessant. Es handelt sich hierbei um einen recht preisgünstigen Hardware-Simulator, mit dem Assemblerprogramme in-ciruit, also mit echten Portzugriffen, ausgeführt werden können. Allerdings werden die Portzugriffe nicht in Echtzeit durchgeführt, was den Simulator von einem sehr viel teureren Emulator unterscheidet. Wenn man den gesockelten C-Control-Chip aus der Main-Unit entfernt, kann man den Simulator mit Hilfe eines Adapters anschließen und jedes beliebige Assemblerprogramm (auch das Betriebssystem der C-Control) ausführen. Allerdings - wie gesagt - mit deutlich niedrigerer Geschwindigkeit.
Der ICS05B kostet rund 250,- DM, aber es geht sogar noch preiswerter: Die Software, mit der der Simulator ausgeliefert wird (ICS05BZ), kann im Internet kostenlos heruntergeladen werden und ermöglicht eine Simulation auch ohne Hardware (Pod). Bei Programmstart dazu einfach auf "Simulation only" klicken. Echte Portzugriffe sind so natürlich nicht möglich.
Übrigens wird der verbesserte C-Control-Chip, der im CC1-OS-Project entwickelt wird, einen In-System-Debugger enthalten, mit dem ein Assemblerprogramm Schritt für Schritt oder bis zum Erreichen eines Breakpoints ausgeführt werden kann. Leider wird das Assemblerprogramm dadurch rund 20 bis 30 mal langsamer ablaufen, aber alle Funktionen der C-Control, mit Ausnahme der Funktionen, die mit dem Interruptsystem zusammenhängen, lassen sich debuggen. Für BASIC- und PLUS-Programme ist ähnliches geplant, wobei die Geschwindigkeitseinbuße sehr viel geringer sein wird als bei Assemblerprogrammen. Bei Interesse bitte in die Mailing List zum Projekt eintragen.
Gibt es schon Erfahrungen zum Erstellen eines neuen Betriebssystems mittels EPROM-68HC05-Controller?
Seit März 2002 arbeiten die Teilnehmer des CC1-OS-Project an der Verbesserung des Betriebssystems. Die Entwicklung wird mit Hilfe von EPROM-Controller durchgeführt, die wieder löschbar sind, da sie mit einem Quarzglasfenster ausgestattet sind. Leider wird dieser Controllertyp nicht mehr hergestellt. Falls man sie noch bekommt, sind sie recht teuer (70 $). Fuer den Normalanwender kommen nur OTPs (One-Time-Programmable) wie der MC68HC705B16 in Betracht. Aber auch diese sind kaum unter 30,- DM zu beschaffen. Für eine vollwertige C-Control kommen dann natürlich noch I²C-EEPROM, Schwinger und eventuell ein Resetbaustein hinzu. Wer selber experimentieren will, kann sich aus dem Internet ein assemblierfähiges Listing herunterladen. Dort gibt es in der Beschreibung und im Listing allerdings folgenden Fehler: Die Startadresse der Interrupttabelle ist beim B16 $3FF2. Außerdem gehört an Adresse $3DFE der Wert $00. Damit die funktionserweiterte, modifizierte C-Control auch im Assemblercode kompatibel zur Original-C-Control bleibt, sollte man versuchen, dem Original-Code eigene Patches zu überlagern und in den freien Bereich des B16 zu verzweigen. Noch einen abschließenden Tip: Angeblich gibt es die C-Control-M-Unit in Polen deutlich günstiger als hierzulande.
Meine C-Control hat Probleme mit dem Empfang des DCF-Signals
Beim DCF77-Empfängermodul von Conrad Electronic ist zu beachten, daß der invertierte Ausgang verwendet werden muß. Selbstverständlich muß eine stabilisierte Spannungsquelle (ohne Brumm) verwendet werden. Außerdem scheinen die in letzter Zeit verkauften Module kein sauberes Signal auszugeben. Es soll helfen, einen 100-nF-Kondensator parallel zur C-Control an den Ausgang zu schalten.
Tip zum Aufstellen des DCF77-Empfängers: Die Stelle, die für den Empfänger vorgesehen ist, mit einem tragbaren Radio "abhören". Hört man an der Stelle Langwellensender (Langwelle von: 150-285 kHz, DCF = 77,5 kHz) ist schon fast sicher, daß man dort auch DCF77 empfangen kann. Durch Drehen um die Längsachse läßt sich hier die beste Stellung finden. Vermeiden sollte man die Nähe von Lautsprechern, Monitoren, Fernsehern, Computern und schaltenden Relais. In der Nähe von Fenstern hat man meistens einen guten Empfang. Bei Entfernungen über 1500 km von Frankfurt aus, wird es kritisch. Falls es tagsüber nicht klappt, sollte man es einmal nachts versuchen. Und falls es immer noch nicht kappt, kann es daran liegen, daß der DCF77-Sender augenblicklich gewartet wird. Das geschieht etwa 20 mal pro Monat und in der Zeit wird der Sender für 2 bis 10 Minuten abgeschaltet.
Ich habe Probleme beim Anschluß einer Hardware an meine C-Control. Kannst Du mir helfen?
Normalerweise helfe ich natürlich gern, doch bitte beachte, daß ich selbst nur eine einfache M-Unit ohne jegliche "Extra-Hardware" wie Tastatur, LC-Display oder ähnlichem besitze. Außerdem enthält meine "C-Control intern"-Sammlung in erster Linie Information zur Software der C-Control; also zum Betriebssystem, zur Assemblerprogrammierung und zu Tricks & Tips bei der Programmerstellung. Für Hardware-Fragen bin ich daher nicht der richtige Ansprechpartner. Da wendest Du Dich am besten an eine gute Suchmaschine oder stellst eine Anfrage in das Forum zur C-Control.
Hilfe! Ich habe die Quellcodes meiner Programme verloren. Gibt es eine Möglichkeit, die Programme, die sich augenblicklich in der C-Control befinden, zum PC zurückzuübertragen?
Seit neustem gibt es einen C-Control-Decompiler. Dieses Tool kann eine Verbindung zur C-Control aufnehmen und die tokensierten BASIC- oder PLUS-Programme auslesen und in BASIC-Code zurückcompilieren. Variablen- und Labelnamen gehen allerdings verloren und nicht alle PLUS-Konstrukte lassen sich eins zu eins in BASIC-Code umwandeln, darum sollte das generierte Programm anschließend nachbearbeitet werden.
Auch das in der C-Control befindliche Assemblerprogramm läßt sich wieder zum PC zurückübertragen. Dafür steht ein Hostkommando (RS232-Befehl) zur Verfügung, siehe BEFEHLE.TXT. Zur Rückcompilierung des Maschinensprachecodes kann anschließend der IDI05-Disassembler benutzt werden - liegt meiner C-Control-intern-Sammlung bei.
Wie kann ich in BASIC am einfachsten detektieren, ob ein gültiges DCF77-Signal empfangen wird?
Mit dem untenstehenden Programm kann das C-Control-Statusregister abgefragt werden. Das Register liegt an Adresse $7b und enthält zwei Bits, die zu diesem Zweck von Interesse sind: Bit 0 gibt an, ob in diesem Moment ein gültiges Zeitsignal empfangen wird und Bit 4 ist gesetzt, wenn die C-Control-Systemzeit wenigstens einmal vom DCF77-Signal oder über die RS232-Schnittstelle gestellt wurde. Wenn nur Bit 4 gesetzt ist, kann davon ausgegangen werden, daß die Systemzeit die richtige Ortszeit enthält (wenn auch eventuell mit einigen Sekunden Abweichung).
Durch eine kleine Änderung im Programm kann übrigens jedes beliebige Byte im RAM ab Adresse 1 abgefragt werden. Dazu muß man nur den Wert in der Tabelle "ccstatustab" umändern: 11*256+Adresse-1. So könnte man also für jede Adresse, die man auslesen möchte, eine eigene BASIC-Subroutine erstellen.
if (ccstatus and 1) then print "Es wird augenblicklich ein gueltiges DCF77-Signal empfangen." if (ccstatus and 16) then print "Die Systemzeit wurde mindestens einmal gestellt." if (ccstatus and 32) then print "Der Slowmodus ist aktiv." end #ccstatus table ccstatustab 2938 '11*256+$7b-1 tabend return |
Gibt es irgendwo unbenutzten Speicher im RAM?
Jawohl, so weit wie ich bisher die "Innereien" der C-Control untersucht habe gibt es folgende Möglichkeiten, etwas mehr RAM-Speicher als die 24 User-Bytes herauszukitzeln: Es gibt ein Byte an der Adresse $dc, dieses wird anscheinend von keiner Betriebssystemroutine verwendet. In Assemblerprogrammen können einige unbenutzte Bits des Statusregisters (an Adresse $7b) und die diversen temporären Bereiche (siehe ADRESSEN.TXT) eingesetzt werden. Bei letzterem muß dann allerdings vor dem Aufruf einer Betriebssystemroutine überprüft werden, ob die Routine den temporären Bereich nicht ebenfalls benutzt. Das kann am schnellsten im ROM-Listing kontrolliert werden (siehe "used"-Sektion im Header jeder Betriebssystemroutine). Wer kein Maschinenspracheprogramm mit vielen Unterprogrammaufrufen benutzt, kann ein Stück des Hardwarestacks (ab Adresse $e5 aufwärts) zur Datenspeicherung nutzen. Das RAND-Word auf Adresse $9f kann mißbraucht werden, wenn keine Zufallszahlen benötigt werden. Wenn der TCAP1-Pin auf ein festes Potential gelegt wird (an dem Pin hängt sonst ein DCF77-Empfänger), können sämtliche DCF77-Buffer benutzt werden. Es ist außerdem denkbar, einige Interrupts des Betriebssystems einfach auszuschalten (siehe Manual zum 68HC05-Mikrocontroller und ROM-Listing) oder durch eigene Assembler-Interruptroutinen zu ersetzen. Dadurch würde ein großer Teil des RAMs frei. Zum Beispiel könnte man den SCI ausschalten und so den RS232-Buffer für eigene Zwecke mißbrauchen. Der Empfang über die serielle Schnittstelle ist dann theoretisch immer noch möglich - allerdings ungebuffert. Hardcore-User schalten den TIMERCMP- Interrupt aus, oder ersetzen die entsprechenden Betriebssysteminterruptroutinen, und haben so ein wirklich großes Stück des RAMs zur freien Verfügung - siehe ADRESSEN.TXT.
Ich brauche in BASIC-Programmen mehr Variablenspeicher.
In der Download Area befindet sich ein ZIP-Archiv namens Mehrvars.zip das zeigt, wie sich zum Beispiel ein Teil des Hardwarestacks als Variablenspeicher mißbrauchen läßt. Damit lassen sich rund 12 Byte- oder 6 Wordvariablen Zugewinn erreichen. Die Funktion ist übrigens in der erweiterten integrierte Entwicklungsumgebung (IDE) für DOS bereits enthalten. Ansonsten könnte man sich einen eigenen C-Control-Chip mit dem CC1-OS-Project-Betriebssystem brennen und erhält dadurch mehr als 200 Byte User-RAM und eine bugfreie C-Control.
Kann man Variablen in BASIC-Programmen einsparen?
Der CCBASIC-Compiler enthält einen kleinen Bug, der es ermöglicht, in BASIC-Programmen direkt auf den Rechenstack der C-Control zuzugreifen und zum Beispiel Berechnungen ohne das Zwischenspeichern in Variablen auszuführen. Mittels PUSH werden zunächst alle Einträge auf dem 14 Byte großen Stack um zwei Bytes "nach hinten" geschoben, um anschließend auf dem frei werdenden Eintrag (Top-Of-Stack) ein Word zu speichern. Mittels POP kann das Top-Of-Stack ausgelesen und ausgegeben werden. Im Gegensatz zu anderen Computersystemen wird beim Auslesen allerdings nicht der soeben gelesene Wert vom Stack gelöscht und die Einträge wieder "nach vorne" geschoben. Diese Besonderheit der C-Control wird vom CCPLUS-Compiler sehr häufig eingesetzt, um Befehle einzusparen. Wie im Folgenden gezeigt, lassen sich mittels direktem Zugriff auf den Rechenstack beispielsweise Parameter an Subroutinen übergeben. Die Parameterübergabe über den Stack ist von Vorteil, da man dadurch die Variablen einsparen kann, die normalerweise zur Übergabe von Werten an die Subroutine verwendet werden müßten. Problemlos ist die Übergabe eines Wertes möglich. Bei mehreren Werten muß man allerdings etwas tricksen, wie folgendes Beispiel zeigt.
' Parameteruebergabe an eine BASIC-Subroutine (oder an Assembler) mit Hilfe
' des Stacks. Damit lassen sich Parameter an eine Subroutine uebergeben,
' ohne dass immer die gleichen Variablen zur Parameteruebergabe verwendet
' werden muessen. Im folgenden Beispiel kommt man sogar ganz ohne Variablen
' aus!
' Da das Betriebssystem normalerweise kein richtiges POP durchfuehrt, muss
' man in der Subroutine etwas tricksen, um mehr als einen uebergebenen Wert
' vom Stack zu lesen. Man sollte sich etwas im Rechenstack-Handling des
' C-Control-Betriebssystems auskennen.
' (c) Dietmar Harlos - 09. Februar 2002 bis 05. Februar 2005
define push ad[1] ' In einen A/D-Port kann man nicht schreiben,
define pop da[1] ' und einen D/A-Port kann man nicht auslesen...
print
push=123 ' ...darum erzeugt der CCBASIC-Compiler in den hier
push=456 ' angegebenen drei Faellen nur Code, der die Zahlen
push=789 ' 123, 456 und 789 nacheinander auf den Stack pusht.
gosub test
print pop
end
#test ' Das kann man nun in der Subroutine ausnutzen:
print pop ' Zuerst wird 789 gelesen, aber nicht vom Stack entfernt.
sys &h1499 ' Erst das SYS entfernt den Wert mit einem "echten" POP.
print pop+pop ' Und hier wird 123+456 berechnet und ausgegeben.
return 987 ' Dieser Rueckgabewert wird auf den Stack gepusht, das
' Unterprogramm beendet und der Wert wird im Haupt-
' programm (hinter GOSUB) per "PRINT pop" ausgegeben. |
Ist die C-Control-I überhaupt noch aktuell? Arbeiten nicht schon alle mit der CC-2?
Die CC-2 ist (leider) auch nicht so der Hit: Sie ist komplizierter in der Programmierung, wesentlich teurer und leider nicht sehr schnell, da auch die C2-Sprache nur interpretiert wird. Insbesondere Portzugriffe sind sehr langsam. Das ist unverständlich, denn der mit 20 MHz getaktete C164-Controller der CC-2 bietet mit seinen fast 20 MIPS einiges Leistungspotential. Wenn ich eine "D-Control" :-) entwickeln sollte, würde ich sehr viel Wert darauf legen, daß BASIC-Programme kompiliert, statt interpretiert ausgeführt werden. Wenn Du schon meinen CCBAS2MC-Compiler heruntergeladen hast, wirst Du wissen, daß kompilierte Programme auf der CC-1 bis zu 250 mal schneller ablaufen. Der Vorteil des 68HC05 ist die, meines Ermessens, gute CPU. Die läßt sich auch von Einsteigern gut in Assembler programmieren, da die Mnemonic ziemlich 68000-nah ist. Nachteilig ist der etwas knappe RAM-Speicher der 68HC05-Controller, und der relativ hohe Preis der OTPs (rund 30 DM). Dafür kann man diesen Controller aber auch bis zu 20 MHz takten. Dann sind Assemblerprogramme und kompilierte BASIC-Programme ganz sicher schneller als interpretiertes C2 auf der CC-2. Auch sollte man sich sehr genau überlegen, ob die zusätzlichen Features der CC-2 wirklich den hohen Preis rechtfertigen. Obwohl die C-Control-I in erster Linie für Einsteiger entwickelt wurde, dürfte in 70% aller Anwendungsfälle eine CC-1 vom Speicherausbau und der Geschwindigkeit völlig ausreichen. Zumal es heute, dank gepatchter Übertragungsprogramme, kein Problem mehr ist, die CC-1 mit einem höheren Takt zu betreiben. Auch Runtertakten macht im mobilen Einsatz Sinn, wenn besonders wenig Strom zur Verfügung steht. Nicht nur in solchen Fällen hat die CC-1 im Preis/Leistungsverhältnis eindeutig die Nase vorn. Das gilt vor allem für die M-Unit. Noch besser sieht es aus, wenn man das Betriebssystem etwas erweitern würde (mehr BASIC-Variablen, Zugriff auf I2C-Bus) und/oder mehr Platz für mittels CCBAS2MC kompilierte Programme zur Verfügung stände. Zu diesem Zweck könnte man die schon angesprochenen OTPs einsetzen, denn die haben deutlich mehr RAM-Speicher und das Betriebssystem kann mehr als doppelt so groß sein!
Gibt es andere Mikrocontroller mit mehr RAM, mehr Ports, mehr Interrupts, Multitasking, Grafik, usw.?
Wie waere es denn, wenn Du fuer umfangreichere Projekte einen PC einsetzt? So ein alter 386'er mit 40 MHz kann problemlos ohne Tastatur, Monitor, Grafikkarte, Festplatte, CD-LW, Gehaeuse und aehnlichem betrieben werden. Das Motherboard mit Speicher gibt's gebraucht fast fuer umsonst. Man braucht nur noch ein Netzteil, eine I/O-Karte und ein Diskettenlaufwerk; eventuell kann das Laufwerk sogar durch eine EEPROM-Disk oder eine Netzwerkkarte ersetzt werden. Der Vorteil ist der, daß dann Programme ganz problemlos unter DOS entwickelt werden koennten - egal, ob in BASIC, C, Pascal oder sonst einer Sprache. Das Freeware-Angebot ist riesig - selbst das Betriebssystem (z.B. OpenDOS, FreeDOS) gibt's für umsonst. Ausserdem koennen selbstentwickelte Karten in den ISA-Bus gesteckt werden. Allerdings ist eine PC-Lösung meist auf den stationären Betrieb beschränkt, da die Stromaufnahme relativ hoch ist (in etwa 1 A auf der 5-Volt-Leitung). Außerdem besteht das Problem, aus Batteriespannung ± 5 und ± 12 Volt zu erzeugen. Eine gute Fundgrube mit vielen Schaltungen, die den Einsatz des PCs in der Meßtechnik demonstrieren, ist Interfacing the PC / Beyond Logic.
Viele ehemalige User der C-Control schwören heute auf die in Bastlerkreisen weit verbreiteten AVR-Mikrocontroller von Atmel. Die sollen sehr leistungsfähig und preiswert sein. Es gibt einen guten BASIC-Compiler namens BASCOM, der sogar Assemblereinbindung unterstützt. Der Support der Programmautoren ist erstklassig, jede E-mail wird beantwortet. Zum Programmieren der Atmel-AT-90S- und Tiny-Controller gibt es neuerdings das STK-500-Starterkit. Um die größeren Atmega-Controller damit zu brennen, benötigt man zusätzlich den STK-501-Adapter. Das Board kostet bei Reichelt 128,- EUR, bei Ineltek gibt es das sogar für 90,- EUR (plus MwSt.). Allerdings beträgt der Mindestbestellwert bei Ineltek 125,- EUR. Der Atmega 103 wird übrigens gerade durch den Atmega 128 abgelöst. Letzterer kann mit bis zu 16 MHz getaktet werden, bei Atmel bedeutet das bis zu 16 MIPS! Die neueren Atmel-Controller unterstützen ein JTAG-Interface. Damit ist das Debuggen des Codes in-circuit, ohne teuren Emulator möglich. Allerdings benötigt man dafür ein Toolkit, das nicht ganz billig ist. Weitere Informationen, Tips und Tricks zu Atmel-Controllern gibt es im AVR Forum.
Dann gibt es natürlich noch die PIC-Controller. Diese gibt es in vielerlei Variationen und sie sollen in Assembler gut zu programmieren sein, da sie weniger als 40 Assemblerbefehle kennen. Sie können zudem leichter als die Atmel-Controller in-circuit programmiert werden. Im Manual zu diesen Controllern ist ein einfacher Programmer abgebildet, mit dem der FLASH-Speicher problemlos über die serielle Schnittstelle programmiert werden kann. Bei Atmel-Controllern benötigt man ein Interface am Parallelport. Es handelt sich bei den PICs, ebenso wie bei den Atmel-Controller, um RISC-Controller.
Bisher habe ich nur Controller vorgestellt, die auf 8-Bit-Technologie beruhen, aber natürlich ist die Entwicklung auch bei den Mikrocontrollern nicht stehengeblieben, und so verwundert es nicht, daß es mittlerweile auch 16- und 32-Bit-Controller gibt. Allerdings sind diese bei weitem nicht so verbreitet wie die 8-Bitter. Sie lassen sich deutlich schwieriger programmieren, sind teurer und lohnen sich darum kaum für den Hobbyisten. Selbst in der Industrie werden häufig noch 8-Bit-Controller eingesetzt, da sich diese bewährt haben und ein Umstieg auf 16-Bit oft nicht erforderlich ist. Übrigens ist der 68HC05 weltweit der am häufigsten verkaufte Mikrocontroller. Er wurde von Motorola schon über fünfmilliardenmal ausgeliefert!
Ich habe eigene Software entwickelt. Möchtest Du sie auf Deine Site stellen?
Wenn es sich um BASIC- oder Assemblerprogramme für die C-Control handelt, dann sollten diese möglichst übersichtlich, überschaubar und gut dokumentiert sein, so daß auch Newbies etwas damit anfangen können. Hilfsprogramme für die C-Control, die auf dem PC laufen (z.B. eigener Kompiler, Maschinensprache-Simulator, BASIC-Detokensierer, o.ä.), sollten möglichst in einer Sprache verfaßt sein, in der die Executables nicht allzu groß sind, oder Du schickst mir den Quellcode des Programms zu. Code für die C-Control stelle ich in die Software Projects und Programme für den PC in die Download Area. Wenn Du mir Deine Software zuschickst, teile mir bitte mit, ob ich Deine E-mail-Adresse veröffentlichen darf.
Was gibt es Neues von der C-Control-2?
Die neusten Infos zur CC2 gibt es auf CC2Net.de von André Helbig.
Wen kann ich noch fragen?
Wenn Du ein Problem hast, bei dem Du nicht weiter weißt und das so schnell wie möglich behoben werden muß, dann stelle doch eine Anfrage in das CC-1-Forum. Es ist zur Zeit das am besten besuchte Forum zur C-Control. Aber beachte, daß Du Dein Problem ausreichend genau beschreiben mußt! Mitunter helfen auch Postings des alten CC-1-Forums weiter. Diese können auf CC2Net.de online betrachtet werden.
Alles gelesen und immer noch Fragen? Dann schaue ins Forum oder schreib mir eine E-mail und hoffe, daß ich mich relativ schnell bei Dir melde!
Diese Seite gehoert zur "C-Control intern"-Internetsite von Dietmar Harlos.