Das Interesse der CC1-OS-Projektteilnehmer ist leider verebbt. Aus diesem Grund ist das Projekt bis auf weiteres eingestellt. Eine lauffähige, nach bisherigen Rückmeldungen fehlerfreie Version des neuen Betriebssystems kann auf der Download-Seite des CC1-OS-Projekts heruntergeladen werden. Wer das neue Betriebssystem in einen Kontroller brennt und austestet, sollte seine Erfahrungen in das Forum zur C-Control-1 stellen.

Fähige Leute, die Interesse an einer verbesserten und erweiterten C-Control-1 haben, werden hiermit aufgefordert, die Hard- und Software der C-Control weiterzuentwickeln. Ein wenig Zeit und Lust ist allerdings Voraussetzung.

Im CC1-OS-Project geht es um die Verbesserung des Betriebssystems der C-Control-1. Ziel ist, allen Anwendern kostenlos ein bugfreies, erweitertes Betriebssystem zur Verfügung zu stellen, das mit Hilfe einer Programmerplatine in einen EPROM-Mikrokontroller gebrannt werden kann. Der gesockelte C-Control-Chip der Main-Unit kann dann durch den selbstgebrannten Kontroller ersetzt werden.

Das existierende Betriebssystem der C-Control soll von seinen Bugs befreit und durch einige zusätzliche Features (z.B. neue RS232-Befehle, mehr Geschwindigkeit, mehr Variablenspeicher) ergänzt werden. Darüberhinaus sollen einige Assemblerprogramme (Firmware) im zusätzlichen Speicher des EPROM-Mikrokontrollers untergebracht werden, die auf möglichst einfache Art in BASIC und eigenen Assemblerprogrammen benutzbar sind.

Conrad Electronic wurde über das Projekt informiert und hat gegen eine Verbesserung der C-Control nichts einzuwenden. Wer also Ideen und Wünsche zur neuen C-Control hat, kann mir eine e-mail schicken!

Mailing List

Alle Leute, die am Projekt teilnehmen möchten, können sich in die Mailing List eintragen.. Einfach eine leere Mail an cc1-os-project-subscribe@hs-control.de senden und auf die Bestätigungs-Mail antworten. Wir suchen immer noch Leute, die auf die eine oder andere Art am Projekt teilnehmen wollen.

Wer sich in die Mailing List einträgt, muß sich kurz vorstellen. Für die anderen Projektteilnehmer ist zum Beispiel interessant, welche Hardware jemand besitzt und in welchen Sprachen (CCPLUS, CCBASIC, Assembler, VisualBASIC, C, ...) Programmierkenntnisse vorliegen.

Aktualisierungen

Status des Projekts

Es folgt eine Liste, der Dinge, die bereits umgesetzt wurden und die noch programmiert werden müssen. Diese Liste kann sich noch erweitern, falls jemand noch eine gute Idee hat.

Folgende Dinge wurden bereits umgesetzt:

• RS232-Befehl zum Neustart des Mikrokontrollers (siehe FUTURE.TXT in der C-Control-intern-Sammlung)
• Lesezugriff auf den I²C-Bus beschleunigt (unter anderem für schnellere Befehlsausführung)
• Token-Interpreterroutine optimiert (vgl. FASTBAS auf der C-Control-intern-Site)
• IDLE-Loop optimiert (spart einen Hardwarestack-Eintrag)
• Aufrufoptimierung beim SYS-Befehl (spart einen Hardwarestack-Eintrag)
• Fehler in der Divisionsroutine behoben
• Probleme mit dem Wochentag behoben (zählt jetzt von 1 (Montag) bis 7 (Sonntag))
• Schaltjahres-Bug entfernt
• Programmierung des internen EEPROMs beschleunigt (Anpassung für übertaktete C-Controls erforderlich)
• I2C_ReadLastByte für Lesen vom I2C-Bus (kombiniert I2C_Read und I2C_ReadLast)
• die Tokenbefehle GOTO, ELSE, FOR..NEXT mittels I2C_ReadLastByte optimiert (für schnellere Befehlsausführung)
• Dump der Datendatei ermöglichen
• RS232-Befehl für Versionsabfrage
• RS232-Lese- und Schreibroutinen optimiert und verbessert
• zweiten Reset für Routine für B16 implementiert
• I2C-Schreibroutine des Betriebssystems optimiert
• RS232-Befehl für Memorydump
• RS232-Befehl zum Beschreiben von RAM2
• Stackroutinen: Push & Pop in Assembler; Realpop
• internes EEPROM intelligenter programmieren
• verbessertes INPUT mit Hexzahlen, half & full duplex, Editiermöglichkeit per Backspace und Defaultzahl
• Speicherkopierroutine
• Fehlerflags setzen, wenn Fehler wie Division durch Null, RS232-Empfangsfehler oder illegales Token auftritt
• Mysteriöse Probleme nach dem Neuprogrammieren der Unit behoben
• Userinterruptroutine für SCI- und SWI-Interrupt unterstützt
• RAM-Layout ändern, für mehr BASIC-Variablen; Augenblicklich ist das User-RAM größer/gleich 222 Byte groß
• Überlegungen zum Aufrufmechanismus von selbstgeschriebenen Interruptroutinen (kann man den verbessern?)
• Anpassung des 20-ms-Timers und der Programmierung des internen EEPROMs an unterschiedliche Taktraten (1 bis 24 MHz)
• Deaktivieren des Weiterzählens der Uhr und der Auswertung des DCF77-Signals ermöglichen
• PEEK- und POKE für CCBASIC

Diese Sachen stehen noch aus:

• Alle I2C-Routinen für Open-Drain-Ausgänge umschreiben
• I2C-Schreibroutine, die ACK zurückliefert
• I2C-Bus, der in BASIC problemlos ansprechbar und schnell ist (zwei normale I/O-Pins benutzen)
• SEEK-Funktion für Daten-Datei
• Page 0 User EPROM sinnvoll belegen
• Überlegungen zum Handshake der RS232
• Unterstützung mehrerer Geräte (Devices) durch PRINT, PUT, INPUT und GET
• DCF77-Empfangsroutinen des Betriebssystem so modifizieren, daß sie die Paritätsbits des DCF77-Signals auswerten; das spart einige Bytes im RAM
• ONGOSUB.ASM als Zusatzroutine ins Betriebssystem übernehmen und BASIC-Token dafür unterstützen (siehe BUGS.TXT)
• Assembler-Routinen (Firmware) im freien Bereich des OPTs unterbringen, die viele Anwender brauchen und die sonst Platz im internen EEPROM wegnehmen würden. Nach Möglichkeit sollen diese Routinen nicht erstellt werden, sondern existierende, getestete Lösungen übernommen werden.
• zusätzliche RAM2- oder EEPROM-Variablen; eventuell RAM2 als Array; wie wurde sowas im C3C programmiert?
• diverse I2C-Geräte (Portexpander, LC-Display, RAM) per Firmware oder BASIC-Token unterstützen
• eventuell einige Pins von PORTA nutzbar machen
• einen verbesserten, erweiterten CCBASIC-Compiler schreiben, der unter anderem neue Tokenbefehle unterstützt
• zusätzliche Dinge (was fällt Euch noch ein?); was bieten andere Systeme, wie C3C oder der Atmel-BASCOM?

Zusatz-Firmware

Die bisherige C-Control konnte man in BASIC und Assembler programmieren. BASIC-Programme werden bekanntlich im externen EEPROM gespeichert, Assemblerprogramme im internen EEPROM. Leider ist die Größe des internen EEPROMs eingeschränkt, so daß Assemblerprogramme nur maximal 255 Byte groß sein dürfen. Es gibt für die C-Control diverse, fertige Assemblermodule, die per SYSCODE-Befehl in ein BASIC-Programm eingebunden und per SYS aufgerufen werden. Zum Beispiel existiert ein Modul zum Zugriff auf das externe EEPROM (DeepXS) und LCD-Routinen. Leider kann man wegen der Größenbeschränkung des internen EEPROMs meist nur ein Modul verwenden. Da ein EPROM-Mikrokontroller wie der 68HC705B16 über rund 15 kB EPROM-Speicherplatz verfügt und das bisherige Betriebssystem nur 6 kB groß ist, können einige Module (rund 30) im zusätzlichen Speicher untergebracht werden.

Meine Frage daher: Welche Routinen bindet Ihr zur Zeit per SYSCODE in Eure Programme ein? Sind das nur Eigenentwicklungen oder auch fertige Routinen (z.B. DeepXS)? Falls jemand selbstgeschriebene Routinen besitzt soll er mir diese bitte inklusive etwas Dokumentation zusenden, damit sie in das EPROM der neuen C-Control übernommen werden können.

Geplantes Speicherlayout

Ein MC68HC705B16 kann 16 kB adressieren. Wir müssen uns Gedanken machen, wie wir die verschiedenen Speicherbereiche des Chips am sinnvollsten belegen.
 

$00-$1f: Die I/O-Ports (32 Byte)

$20-$4f: Page 0 User EPROM (48 Byte)   Dieser EPROM-Bereich liegt in der Zeropage, kann also sehr gut in Assembler angesprochen werden. Aus diesem Grund sollen hier Sprungbefehle zu in Assembler häufig benutzen Firmware und/oder Betriebssystemroutinen stehen. Diese lassen sich dann per kurzem JSR-Befehl aufrufen. Im internen EEPROM spart das ein Byte pro Aufruf . Frage an Alle: Welche Routinen werden in Assemblerprogrammen am häufigsten benötigt?

$50-$ff: RAM1 (176 Byte)   Hier wird aufgeräumt, um mehr Speicher zur Variablenspeicherung zur Verfügung zu haben. Außerdem wird der RS232-Empfangsbuffer und der Buffer zum Auswerten des DCF77-Signals hinter die Adresse $a1 gelegt, damit dieser Speicherbereich von Variablen belegt werden kann, wenn kein gebufferter RS232-Empfang und/oder kein DCF77-Zeitsignal benötigt wird.

$0100-$01ff: internes EEPROM (256 Byte)

$0200-$0250: Bootstrap ROM I (80 Byte)

$0250-$02ff: RAM2 (176 Byte)   eventuell als Array ansprechen oder zusätzliche BASIC-Variablen abspeichern; Assemblerprogramme aus dem I2C-EEPROM laden und hier ausführen; als RS232-Buffer benutzen; Vielzweck-Speicher; nur vom User benutzt

$0300-$3dfd: EPROM (15104 Byte)   $0300-$05ff: Einsprungadressen der Firmwareroutinen $0600-$07ff: Betriebssystem-Erweiterungen und/oder Firmwareroutinen $0800-$1fef: Normales C-Control-Betriebssystem mit einigen Patches $1ff0-$3dfd: Firmwareroutinen $3dfe:       Mask option register (auf $0 setzen) $3dff:       reserved

$3e00-$3fef: Bootstrap ROM II (496 Byte)

$3ff0-$3ff1: RESET2 (für B16)

$3ff2-$3fff: User vectors (Interruptvektoren; 14 Byte)

Ideen und Programme gesucht

Wer hat gute Ideen, was man integrieren könnte? Woran hakt es bei der C-Control am meisten? Macht die Implementierung von Fließkommazahlen Sinn?

Es gibt diverse Geräte für den I2C-Bus. Zum Beispiel RAM, EEPROM, Portexpander, LC-Displays, usw. Solche Geräte durch Firmwareroutinen (oder direkt über BASIC-Token) zu unterstützen macht bestimmt Sinn, da durch Verwendung des I²C-Busses keine Portleitungen belegt werden müssen. Nachteilig ist zwar eine geringere Verarbeitungsgeschwindigkeit, aber das sind wir von der C-Control ja schon gewohnt. LCDs belegen selbst im 4-Bit-Modus fünf Portleitungen. I²C-LCD würden keine zusätzlichen Leitungen belegen.

Sollte man die verbesserte C-Control vielleicht grundsätzlich mit 8 MHz Takt ausrüsten? Der Vorteil ist eine höhere Verarbeitungsgeschwindigkeit. Nachteilig ist allerdings der im gleichen Ausmaß ansteigende Leistungsbedarf. Außerdem könnten Probleme mit angeschlossener Hardware auftauchen.

Kennt jemand einen Softwareemulator für die 6805-CPU, bzw. für einen 68HC705-Mikrokontroller? Am Besten wäre ein Freewareprogramm. Die Demoversion von ZAP unterstützt ja leider nur recht kleine Programme.

Falls jemand selbstgeschriebene, getestete Assemblerroutinen besitzt soll er mir diese bitte inklusive etwas Dokumentation zusenden.

Teilnehmer gesucht

Wir müssen nach wie vor folgende Aufgabengebiete vergeben. Falls jemand Lust hat, eine oder mehrere Aufgaben zu übernehmen, soll er sich bitte melden.

• Internetrecherche: Ein Projektteilnehmer sollte im Internet nach bestehenden Softwarelösungen suchen. Es gibt eine Menge Seiten zur C-Control im Internet. Vielleicht findet man auf den diversen Seiten Anregungen oder gute, in Assembler geschriebene Softwaremodule, die wir als Firmwareroutinen benutzen könnten. Auf der Motorola-Site habe ich z.B. schon einmal gesucht und dort sogar Routinen für Fließkommazahlen gefunden. Die URL ist: http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=68HC05B6&nodeId=01M98633
• Assemblerprogrammierung: Wir suchen noch Leute, die sich in Assembler auskennen und bestehende Softwaremodule untersuchen und eventuell so modifizieren, daß sie in das EPROM als Firmwareroutinen integriert werden können. Auch stehen noch einige Modifikationen am Betriebssystem an. Unter anderem muß die DCF77-Routine umgeschrieben werden, damit sie die Paritätsbits auswertet und auf diese Weise weniger RAM-Speicher benötigt. Das Erstellen und Testen von Assemblerprogrammen kann im internen EEPROM einer normalen C-Control durchgeführt werden. Ein teures Entwicklerboard oder ein EPROM-Kontroller mit Fenster ist nicht erforderlich.
• CCBASIC-Kompiler: Falls jemand Erfahrung in der Programmiersprache C besitzt, sollte er die Aufgabe übernehmen, den CCBASIC-Kompiler zu erweitern. Zum Beispiel ist geplant, unser Betriebssystem mit neuen BASIC-Token auszurüsten, um z.B. Variablen im externen EEPROM abzulegen. Es wäre natürlich sinnvoll, wenn diese Zusatz-Tokens auch vom Kompiler unterstützt werden. Natürlich kann die Erweiterung des Kompilers richtig in Arbeit ausarten, wenn man z.B. (wie bei C3C) Funktionen, Subroutinen, Stringvariablen, etc. hinzufügen möchte. Aber einige kleinere Dinge sollten schon ohne größere Probleme zu integrieren sein. Die Entwicklung des Kompiler hat auch keine Eile. Es ist auch möglich, erst damit zu beginnen, wenn das Betriebssystem fertig ist. Solange müßte man dann die zusätzlichen BASIC-Token durch Tabellen im BASIC-Code austesten (siehe Tips&Tricks in meiner Sammlung).
• Dokumentation: Wenn unser Betriebssystem fertig ist, müssen wir einige Beispielprogramme herausgeben, die zeigen, wie man die von uns hinzugefügten Features benutzt. Auch eine tabellarische Übersicht der Veränderungen gegenüber der normalen C-Control (Bugs entfernt, zusätzliche BASIC-Token, neue RS232-Startbefehle, neues Speicherlayout, ...) erleichtert den Umgang mit dem erweiterten Kontroller.
• Betatest: Jemand muß Firmwareroutinen testen, bevor sie in unser erweitertes Betriebssystem integriert werden. Außerdem muß der (fast) fertige OTP auf Fehler überprüft werden. Dazu wäre eine Person geeignet, die über möglichst viel C-Control-Hardware verfügt. Auch Assemblererfahrung ist von Nutzen, aber nicht Voraussetzung. Am sinnvollsten sollten wir gleich mehrere Betatester im Team haben.
• Sonstiges: Gibt es etwas, das ich vergessen habe?

Konventionen für Firmwareroutinen

Alle Firmwareroutinen sollen auf einfache Art und Weise aus einem Assemblerprogramm aufrufbar sein. Aus diesem Grund sollten (nach Möglichkeit) nur der Akkumulator (A) und das Indexregister (X) benutzt werden, um Parameter an eine Firmwareroutine zu übergeben. Auch Rückgabewerte sollen nach Möglichkeit nur im Akku oder Indexregister zurückgeliefert werden.

Um unsere Firmwareroutinen von BASIC aus aufzurufen, plane ich eine Art "Konverterroutine", die die von BASIC auf den Stack hinterlegten Übergabeparameter in den Akkumulator und in das Indexregister kopiert, anschließend die gewünschte Firmwareroutine aufruft und die Rückgabewerte wieder auf den Stack schreibt. Beispiel: Wenn der Einsprung für eine Firmwareroutine auf Adresse $303 liegt und im Akku der Wert 123 übergeben werden soll, schreibt man in BASIC "SYS CCE_CALL &h303,123". Auf diese Weise kann von BASIC aus jede beliebige Betriebssystemroutine aufgerufen werden. Für Firmwareroutinen, die in BASIC sehr häufig benutzt werden müssen, könnte man eine zusätzliche Einsprungadresse unterstützen, die die Aufgabe der Konverterroutine übernimmt.

Bitte beim Entwickeln von Firmwareroutinen, die bestimmte Ports belegen, immer beachten, daß die Kompatiblität zur Original-Hardware (z.B. Starter-/Applicationboard) gewahrt bleibt.

Glossar

 Wir brauchen noch ein Glossar, um einige Begriffe zu erklären, damit wir nicht aneinander vorbeireden:

• C-Control: Die C-Control-1 gibt es in drei Varianten: Als Main-Unit (Conrad-Electronic-Bestellnummer 950572), M-Unit (Bestellnummer 950556) und als Station (Bestellnummer 125113). Die C-Control, auch C-Control-Minicomputer genannt, besteht aus einem MC68HC05B6-Mikrokontroller mit maskenprogrammierten Betriebssystem ("C-Control-Chip"), einem I²C-EEPROM, einem Quarz, bzw. Schwinger und einer Platine mit einigen Zusatzbauteilen und Steckverbindungen.
• neue C-Control: Bei der Main-Unit steckt der C-Control-Chip in einem PLCC-Sockel. Wir entwickeln in unserem Projekt ein neues, erweitertes Betriebssystem für die C-Control. Dieses wird in einen EPROM-Kontroller gebrannt, der in den Sockel der Main-Unit gesteckt werden kann. Zur Zeit ist nicht geplant, den Chip der M-Unit zu ersetzen, da dieser direkt auf die Platine gelötet ist. Die neue C-Control wird also "nur" einen neuen Mikrokontroller mit neuem Betriebssystem erhalten. Weitere Hardwareveränderungen an der Platine der Main-Unit oder der M-Unit sind nicht geplant.
• EPROM-Kontroller: Bei der normalen C-Control steht das Betriebssystem im ROM und kann nicht verändert werden. Bei den EPROM-Kontrollern ist dieser Bereich als EPROM ausgeführt und kann mit Hilfe einer Programmerplatine beschrieben ("gebrannt") werden. Die Programmerplatine wird von Karl-Heinz Eglseder und Gerhard Strini entwickelt und soll später fertig aufgebaut plus Software und einem OTP für rund 50 EUR an jeden interessierten C-Control-Anwender verschickt werden, damit dieser einen gesockelten C-Control-Chip durch einen selbstgebrannten Chip ersetzen kann.
• OTP: Ein One-Time-Programmable-Mikrokontroller enthält ein EPROM (z.B. 15 kB groß), das man nur einmal beschreiben kann. Zur Entwicklung besser beeignet sind Kontroller, bei denen das EPROM durch UV-Licht wieder gelöscht werden kann. Aber diese Kontroller sind deutlich teurer (bei Spörle bekommt man sie schon für 23,30 EUR, wenn man 20 Stück abnimmt).
• Betriebssystem: Damit ist das Original-Betriebssystem von Conrad Electronic gemeint, das bei Adresse $0800 startet und bis Adresse $1eff reicht.
• erweitertes Betriebssystem: Von den Teilnehmern des CC1-OS-Projekts wird das erweiterte Betriebssystem erstellt, das sowohl das bugfreie Original-Betriebssystem, als auch einige zusätzliche Firmwareroutinen enthält.
• Patch im Betriebssystem: Darunter versteht man eine neue Routine, die eine (z.B. fehlerhafte) Betriebssystemroutine ersetzt. Die neue Routine steht an derselben Adresse wie die alte Routine und muß daher kleiner oder gleich lang sein.
• Erweiterung des Betriebssystem: Eine neue Routine oder Funktion, die im Original-Betriebssystem nicht enthalten war. Meist stehen diese Routinen außerhalb des Betriebssystem und werden (im Gegensatz zu reinen Firmwareroutinen) vom Betriebssystem verwendet. Eine Erweiterung sind z.B. die zusätzlichen RS232-Befehle.
• Token: BASIC-Quellcodeprogramme werden vom CCBASIC-Compiler in sogenannten tokensierten Programmcode umgewandelt. Dieser baut sich aus diversen Tokenbefehlen auf. Tokenbefehle können im allgemeinen mehrere Bytes lang sein. Sie enthalten dann ein Token und zusätzliche Datenbytes, die im Programm hinter dem Token folgen. Diese Token sind nichts anderes als Bytes, deren Wertigkeit zwischen 0 und 84 liegen darf. Nachdem der Programmcode tokensiert wurde, wird er vom PC zur C-Control übertragen und im I²C-EEPROM gespeichert. Während der Befehlsausführung holt die C-Control ein Token aus dem EEPROM und ruft die zugehörige Betriebssystemroutine auf. Diesen Vorgang nennt man Interpretieren. Falls der interpretierte Tokenbefehl Datenbytes enthält, werden diese von der Betriebssystemroutine aus dem EEPROM geholt und ausgewertet. Nachdem die Routine ihre Arbeit verrichtet hat, wird die Interpretierung solange fortgeführt, bis das END-Token, mit der Wertigkeit 84, erreicht wird. Übrigens werden auch mit Hilfe der Plus-Entwicklungsumgebung entwickelte Programme in dieselben Tokenbefehle umgesetzt, wie sie auch bei der BASIC-Programmierung üblich sind.
• Änderung im RAM-Layout: Um mehr RAM-Speicher für BASIC-Variablen freizumachen, könnten (moderate) Veränderungen am RAM-Layout vorgenommen werden. Zum Beispiel den Bereich, der hinter Adresse $b9 beginnt, an eine andere Stelle verschieben. Oft werden auch alte Betriebssystemroutinen durch neue ersetzt (siehe Patch im Betriebssystem), die weniger temporäre RAM-Variablen benutzen. Dadurch können vom Betriebssystem nicht benutzte Bereiche entstehen, die anderweitig belegt werden könnten.
• Firmwareroutine: Firmwareroutinen sind Zusatzroutinen, die im freien EPROM-Speicher eines OTPs untergebracht werden. Sie sind unabhängig vom Betriebssystem, d.h. sie werden nicht vom Betriebssystem aufgerufen (sind also keine Betriebssystemerweiterungen), sondern werden vom User in BASIC- oder Assemblerprogrammen benutzt. Firmwareroutinen werden (voraussichtlich) im EPROM-Bereich zwischen $1f00 und $3dfd gespeichert. Die Lage einer Firmwareroutine kann sich von einer C-Control-Version zur nächsten verändern, darum dürfen sie nicht direkt aufgerufen werden.
• Startadressen einer Firmwareroutine: An diesen Stellen kann man eine Firmwareroutine aufrufen. Allerdings werden sich diese Adressen von einer C-Control-Version zur nächsten verändern. Der Name des Labels zu einer Startadresse muß im Assemblersourcecode immer mit "COPFW_" beginnen.
• Aufrufadresse einer Firmwareroutine: Die Aufrufadressen (auch als Einsprungadressen bezeichnet) aller Firmwareroutine liegen im Bereich zwischen $0300 und $05ff. In diesem Bereich liegen unbedingte Sprungbefehle, die auf die eigentlichen Startadressen der Firmwareroutinen verzweigen.
• User: Damit ist die Person gemeint, die den neuen C-Control-Chip später einsetzen wird.

Hardware

Jeder Anwender, der eine neue, verbesserte C-Control einsetzen möchte, braucht eine C-Control-Main-Unit, ein Programmerboard, einen OTP-Mikrokontroller, ein 15-Volt-Netzteil und eine Programmiersoftware. Das Programmerboard wird gerade von zwei Projektteilnehmern entwickelt und soll für unter 50 EUR (also zum Selbstkostenpreis) an alle Interessierten verschickt werden. Es kann für diverse OTP-Mikrokontroller, bis hinauf zum B32, verwendet werden. Einen OTP (MC68HC705B16CFN) gibt es bei Conrad Electronic unter der Bestellnummer 170298 für EUR 15,31. Eventuell werden wir noch einen günstigeren Anbieter finden oder das Programmerboard mit einem (unprogrammierten) OTP ausliefern. Als Programmiersoftware kommt die Freeware PGMR5 Version 1.5 von Ralf Stockmann in Frage.

Bilder

Zur Verdeutlichung folgen ein paar Bilder. Die meisten können durch anklicken vergrößert werden.
 

EPROM-Kontroller mit Fenster		Programmerplatine (Vorserienmodell)		C-Control-Chip von Conrad Electronic
Nahaufnahme	in der Main-Unit	Oberseite	Unterseite	MC68HC05B6	MC68HC705B16

FAQs

Hier folgen einige Frequently Asked Questions, also häufig gestellte Fragen zum Projekt

Wofür stehen die Abkürzungen RAM, ROM, PROM, EPROM und EEPROM?
Es handelt sich um verschiedene Arten des Speichers. Ein Speicher setzt sich aus Speicherzellen zusammen, die jeweils ein Byte, also Werte zwischen 0 und 255 speichern können. Jede dieser Speicherzellen kann eindeutig über ihre Adresse angesprochen werden. Die C-Control hat zum Beispiel einen Adressraum der bei Adresse 0 startet und bis Adresse 8191 reicht. Sie kann demnach 8192 verschiedene Speicherzellen ansprechen. Ihr Speicher ist also 8 Kilobyte (8 kB) groß. Allerdings stetzt sich der Speicher aus verschiedenen Speicherarten (RAM, EEPROM und ROM) zusammen, und auch die I/O-Register belegen ein Stück des Adreßraums.
 

Festwertspeicher	Es handelt sich um Speicher, der im normalen Betrieb nur ausgelesen werden kann. Man unterscheidet einige Varianten (ROM, PROM, EPROM, EEPROM) danach, ob der beliebig oft lesbare Inhalt irreversibel (nicht umkehrbar) oder reversibel (umkehrbar) eingeschrieben wird und auf welche Weise dies geschieht. Festwertspeicher sind nichtflüchtige Speicher, das heißt, ihr Inhalt bleibt auch bei Stromausfall und nach dem Abschalten erhalten.
ROM	Die Abkürzung ROM steht für read only memory. Dieser Speicher wird vom Hersteller maskenprogrammiert. Ähnlich wie bei einem Fotonegativ liegen die Daten in einer Maske und werden bei der Produktion fest in der Halbleiterstruktur abgelegt. Die Daten können weder elektrisch noch optisch gelöscht werden. Das Betriebssystem der C-Control steht üblicherweise in einem solchen ROM.
PROM	Jedes Bit im Programmable ROM ist nur einmal programmierbar. Das Programmieren wird vom Anwender mit Hilfe spezieller Programmiergeräte durch „Einbrennen" der Schaltwege mit kurzen, kräftigen Stromstößen durchgeführt. Dieser Vorgang ist irreversibel. Nach dem Programmieren verhält sich der PROM wie ein ROM.
EPROM	Beim Erasable ROM nutzt man die selbe Technik zum Programmieren, wie bei den PROMs. Das EPROM benötigt eine Programmierspannung, die meist um ein Vielfaches höher liegt als die Betriebsspannung. Zum Programmieren wird ein Zusatzgerät, der sogenannte EPROM-Programmer verwendet. Durch Ausnutzung der Eigenschaft von Halbleitern bei Einfall von UV-Licht mit Ladungsverschiebungen zu reagieren, lassen sich die Daten auch wieder löschen. Deshalb beinhalten diese Speicherbausteine ein Quarzglasfenster, durch das der Chip zum Löschen mit hartem UV-Licht betrahlt wird. Der Löschvorgang dauert einige Minuten. Es können einige Tausend Programmierzyklen erreicht werden. Die Kontroller mit der Bezeichnung MC68HC705 enthalten allesamt EPROM-Speicher. Allerdings besitzen nur besondere Versionen das angesprochene Fenster. Deshalb läßt sich der EPROM-Speicher meist nicht löschen. Es handelt sich darum eigentlich um PROM-Speicher, dessen Speicherzellen im unprogrammierten Zustand mit Nullbits gefüllt sind.
EEPROM	Beim Electrical Erasable ROM besteht die Möglichkeit die Speicherzellen durch Spannungsimpulse sowohl zu programmieren, als auch zu löschen. Die Programmierzeit ist relativ lang und die Anzahl der Programmierzyklen ist begrenzt (rund 10000 bis 1 Million). Im Gegensatz zu EPROM-Speicher können die EEPROMs aber meist in der Schaltung (In-Curcuit) programmiert und gelöscht werden. Die C-Control besitzt zwei EEPROMs: Das interne EEPROM liegt im Adreßraum zwischen Adresse $100 und $1ff, das serielle EEPROM ist über den I²C-Bus mit der C-Control verbunden und speichert das BASIC- oder PLUS-Programm und die Datendatei. Unprogrammierte Speicherstellen werden als $FF ausgelesen.
Flash	Flash-Speicherchips sind nichtflüchtige Bausteine für Schreib-/Lesespeicher mit sehr geringen Zugriffszeiten (zwei Millisekunden). Sie sind funktionell mit einem EEPROM vergleichbar, müssen aber blockweise (mindestens 256 Bytes) beschrieben und gelöscht werden, während sich ein EEPROM byteweise löschen läßt. Flash-Speicherchips sind mit „Schreib-Lese-ROMs" vergleichbar und können die gespeicherten Daten 100 Jahre lang ohne Stromzufuhr halten. Die meisten Flash-Speicher können allerdings nur 1000 mal wiederbeschrieben werden. Es gibt einige neuere Mikrokontroller, bei denen der Bereich, der bei den 68HC05-Kontrollern aus ROM oder EPROM besteht, als Flash ausgeführt ist. Bei der C-Control-2 oder bei den ATMEL-Kontrollern ist das beispielsweise so. Diese Kontroller können dann meist in der Schaltung neu programmiert werden. Dieser Speichertypus wird von Motorola leider erst ab dem 68HC08 eingesetzt.
RAM	Beim Random Access Memory handelt es sich um flüchtigen Speicher, das heißt der Inhalt geht bei Stromausfall verloren. Nach dem Einschalten ist der Inhalt in der Regel undefiniert und muß initialisiert werden. Die Speicherzellen des RAMs können sehr schnell ausgelesen und beliebig oft verändert werden, darum handelt es sich um den Speichertypus, auf den am meisten zugegriffen wird. Bei der C-Control steht der Programmcode im nichtflüchtigen Festwertspeicher (ROM, EPROM, EEPROM). Theoretisch ließen sich Programme auch im RAM ausführen, aber da Kontroller mit viel RAM teuer in der Herstellung sind und die C-Control darum nur recht wenig von diesem Speichertyp besitzt, ist der wenige Speicher für Daten reserviert. Die normale C-Control besitzt 176 Byte RAM, davon können 24 Byte in BASIC-Programmen zur Variablenspeicherung benutzt werden.

 
Kann man statt dem B16-Mikrokontroller auch den MC68HC705B32 einsetzen? Dieser Kontroller hat mehr EPROM-Speicher.
Augenblicklich ist nicht geplant, den B32 zu unterstützen. Es stimmt zwar, daß der B32 dem B16 stark ähnelt, aber er ist nicht vollkompatibel. Der B32 hat kein Page 0 User EPROM und besitzt mehr RAM2-Speicher, wodurch sich die Einsprungadressen der Firmwareroutinen (geplant für Adresse $0300-$05ff) verschieben. Den Kontroller gibt es außerdem nicht in der High-Speed-Variante (FN, siehe unten). Es kann sein, daß sich der B32 deshalb nicht so gut übertakten läßt, wie man es von der C-Control gewohnt ist. Das müßte man erst austesten.

Kann ich in den von mir gebrannten neuen C-Control-Chip eigene Firmwareroutinen integrieren?
Das ist solange möglich, wie sich die von uns erstellten Firmwareroutinen nicht mit den selbstgeschriebenen adreßmäßig überschneiden. Idealerweise sollte man die Einsprungadressen von eigenen Routinen ans Ende des Adreßbereichs $0300-$05ff legen. Die Routinen sollten ans Ende des Bereichs $1ff0-$3cff gelegt werden. Die Bereiche $2fe0-$2fff und $3de0-$3dfd sind für zukünftige Erweiterungen reserviert und dürfen nicht belegt werden.

Warum liegen die Einsprungadressen von Firmwareroutinen im Bereich $0300-$05ff? Warum wird die Firmware nicht direkt angesprungen?
Falls sich ein Softwaremodul (Firmware) nach dem Einbrennen in einen OTP als fehlerhaft erweist, kann man das Modul nicht einfach löschen, da man jeden EPROM-Bereich eines OTPs ja nur einmal beschreiben kann. Genauer: Der Speicher des EPROMs ist im unprogrammierten Zustand mit Nullbytes gefüllt, deren Bits durch das Brennen gesetzt, aber nicht wieder zurückgesetzt werden können. Die Sprungtabelle im Bereich $0300-$05ff ermöglicht es, trotz dieser Einschränkung, fehlerhafte Module in "verbrannten" OTPs zu deaktivieren und durch ein neues Modul zu ersetzen. Dazu ein Beispiel: Im Basicprogramm wird durch den Befehl "SYS &h0303" ein Befehl in der Sprungtabelle aufgerufen. Dieser sei "jmp $26c0". Durch diesen Sprungbefehl wird also zum Modul an Adresse $26c0 verzweigt. Falls sich herausstellen sollte, daß dieses Modul fehlerhaft ist, muß man versuchen, den Sprungbefehl durch Setzen von zusätzlichen Bits dermaßen zu patchen, daß er eine andere Adresse anspringt, in die das gleiche, nun aber hoffentlich fehlerfreie Modul eingebrannt wird. Man könnte den Sprungbefehl zum Beispiel in "jmp $27c0" umändern. Das Ersatzmodul muß dann also auf die Adresse $27c0 gelegt werden. Natürlich ist dieses Verfahren nur eine Notlösung, da das fehlerhafte Modul weiterhin im EPROM steht und Platz belegt. Außerdem sind dem Patchen der Sprungadresse enge Grenzen gesetzt, da dies ja nur durch Setzen von Nullbits geschehen kann. Aus diesem Grund sollte der Bereich $2fe0-$2fff und $3de0-$3dfd freibleiben, da diese Bereiche durch Patchen meist zu erreichen sind. Dort könnte dann ein weiterer Sprungbefehl plaziert werden, der in die Ersatzroutine verzweigt.

Ich habe ein Programmierboard und einen OTP zum Experimentieren übrig. Kann ich ein Betarelease Eures Betriebssystem bekommen?
Das ist kein Problem. Wenn Du Dich in die Mailing List einträgst, erhältst Du ein Paßwort für eine Internetseite, auf der Preview-Versionen des Betriebssystems heruntergeladen werden können. Wenn Du diese Versionen in einen OTP brennst, käme uns das sehr gelegen. Du könntest Dich als Betatester am Projekt beteiligen. Bitte informiere uns über Erfolg oder Mißerfolg!

Soll die "neue" C-Control zusätzliche Hardware unterstützen?
Das Original-Betriebssystem der C-Control soll in erster Linie von seinen Bugs befreit und nur leicht erweitert werden. Unter eine leichte Erweiterung fällt zum Beispiel ein Befehl zum Starten der C-Control über die serielle Schnittstelle, Ansprechen von Variablen, die im I²C-EEPROM oder im zusätzlichen RAM eines EPROM-Kontrollers liegen, die Möglichkeit, eigene Assemblerprogramme in den SWI- oder SCI-Interrupt einzubinden und ähnliches. Neue Hardware soll dagegen nur durch Firmwareroutinen unterstützt werden. Auf diese Weise läßt sich von BASIC aus z.B. die Analogtastatur oder das LC-Display durch SYS-Befehle ansprechen. Solche Firmware direkt ins Betriebssystem einzubinden, würde kaum Sinn machen, da nicht alle Anwender diese Hardware besitzen.

Könnt Ihr mir einen neuen C-Control-Chip brennen und verkaufen?
Nein. Wir haben von Conrad Electronic nicht die Genehmigung bekommen, den fertigen Chip zu verkaufen. Das verbesserte Betriebssystem kann, wenn es fertig ist, auf dieser Internetsite kostenlos heruntergeladen werden. Dieses kann dann mit Hilfe der Programmerplatine in einen OTP-Kontroller gebrannt werden. Dieser Vorgang ist nicht kompliziert und kann von jedem Anwender, der sich zutraut, einen Chip im PLCC-52-Gehäuse in einen Sockel einzusetzen und herauszuziehen, durchgeführt werden. Programmerplatinen an Anwender zu verschicken hat außerdem den Vorteil, daß jeder User "seine" C-Control durch Assembler-Firmwareroutinen erweitern kann. Selbst wenn man sich nicht zutraut, eigene Assemblerprogramme zu erstellen, so werden bestimmt früher oder später Patches und Erweiterung im Internet zum Download angeboten, die bei Bedarf in den EPROM-Speicher gebrannt werden können.

Gibt es eine Möglichkeit, auch die M-Unit mit einem verbesserten Chip auszustatten?
Theoretisch ginge das. Man müßte den Mikrokontroller der M-Unit auslöten und durch einen selbstgebrannten OTP ersetzen. Für diese Aktion braucht man aber einen SMD-Lötkolben und eine ruhige Hand. Alternativ könnte man eine Platine erstellen, die kompatibel zur M-Unit-Platine ist und einen PLCC-Sockel enthält. Da der Platz für den Sockel beschränkt ist, muß man ihn eventuell auf die Rückseite der Platine setzen.

Wofür stehen die diversen Buchstabenkürzel hinter den Namen der Chips?
Wir befassen uns nur mit den Kontrollern MC68HC05B6 und MC68HC705B16. Beide haben ein 52-pin PLCC-Gehäuse und die unterschiedlichen Versionen der Kontroller werden durch die Buchstabenanhängsel N, FN und CFN voneinander unterschieden:
 

MC68HC05B6 FN	Die Kontrollerbezeichnung 68HCx05 besagt, daß es sich um einen Kontroller handelt, der eine 6805-CPU enthält. Die Endung 05B6 bedeutet, daß es sich um einen ROM-Kontroller (keinen EPROM-Kontroller) handelt und daß dieser rund 6 kB ROM-Speicher besitzt. Das Kürzel FN steht für "High Speed Operation". Das heißt, dieser Chip darf (laut Motorola) mit 8 MHz Takt betrieben werden, statt mit dem 4-MHz-Standardtakt. Für die von Conrad Electronic hergestellte ROM-Version der C-Control wurde dieser Chip verwendet. Auf der C-Control ist die Bezeichnung "ZC441199FN" aufgedruckt. Wenn ich das FN nicht vollkommen falsch interpretiere, dann darf die C-Control also tatsächlich mit 8 MHz betrieben werden. Vielleicht ist so zu erklären, daß bis 16 MHz keine Probleme auftauchen!?
MC68HC705B16 CFN	Die 705B16-Kontroller haben EPROM- statt ROM-Speicher, und zwar rund 15 kB davon. Das C besagt, daß dieser Chip einen erweiterten Temperaturbereich besitzt. Er kann von -40 bis +85°C eingesetzt werden. Ohne das C sind nur Temperaturen zwischen 0 bis 70°C zulässig. Wiederum steht FN für "High Speed Operation" - siehe oben. Diese Version des Kontrollers bietet im Vergleich zur 05B6-Version 176 Byte zusätzlichen RAM-Speicher. Auch dieser Chip wurde von Conrad Electronic benutzt. Es gab einmal einen Lieferengpaß bei Motorola und so wurde die C-Control sozusagen in Einzelfertigung gebrannt. Leider wurde der nicht benutzte EPROM-Speicher mit $ff überschrieben. Er kann also vom Anwender nicht mehr genutzt werden.
MC68HC705B16N CFN	Es handelt sich wiederum um einen EPROM-Kontroller mit erweitertem Temperaturbereich und höherer Geschwindigkeit. Das zusätzliche N steht für eine besondere Version des 705B16. Die normale Version, ohne N, enthält einen Bug, weshalb sie zweimal resettet werden muß. In der N-Version wurde dieser Fehler behoben. Leider hat Conrad den Bug nicht beachtet, so daß mit der C-Control, die auf einem 705B16 basiert, eventuell Probleme auftauchen können.

Bestimmt hat jeder C-Control-Anwender etwas Konstruktives zum Projekt beizutragen. Nicht vergessen: Die verbesserte C-Control kann später von jedem Anwender benutzt werden. Also alle Vorschläge, Ideen und Wünsche an mich schicken. Natürlich ist mir eine aktive Teilnahme noch lieber. Es darf auch diskutiert werden!

 (c) Dietmar Harlos ADPC - ab 01.03.2002