DE9408298U1

DE9408298U1 - Controller-Board

Info

Publication number: DE9408298U1
Application number: DE9408298U
Authority: DE
Original assignee: PIETZSCH RUEDIGER
Current assignee: PIETZSCH RUEDIGER
Priority date: 1994-05-20
Filing date: 1994-05-20
Publication date: 1994-07-21
Anticipated expiration: 2004-05-21

Description

Anmelder: Rüdiger Pietzsch

CONTROLLERBOARD

Die vorliegende Erfindung betrifft ein Controllerboard insbesondere für ein Mikrocontroller-Lehrsystem, mit einem Controller, mit einem Adreßzwischenspeicher, mit einem von einem Teil der Controlleradressen angesprochenen ROM mit Betriebssystem und Monitorprogramm, mit einem von einem weiteren Teil der Controlleradressen angesprochenen RAM für das zu entwickelnde Controller-Programm, und mit einem Schnittstellenbaustein für die serielle Datenübertragung von und zu einem PC.

Derartige Controllerboards sind bekannt.

Controllerprogramme werden üblicherweise mit Hilfe spezieller Entwicklungssoftware auf einem PC erstellt. Anschließend wird der Programmcode über eine serielle Schnittstelle und unter Verwendung des im Nur-Lese-Speicher (read only memory, ROM) des Controllerboards abgelegten Betriebssystems in den Schreib-/Lesespeicher {random access memory, RAM) des Controllerboards transferiert (geladen). Die verwendete PC-Entwicklungssoftware ist grundsätzlich beliebig, jedoch muß ein an diese angepaßtes Betriebssystem im Controllerboard vorliegen.

Mit Hilfe des Betriebssystems und des ebenfalls im ROM-Bereich des Controllerboards abgelegten Monitorprogramms ist es dann

in einer Testphase möglich, das entwickelte Programm zu testen, wobei die Signalverlaufe der einzelnen Controllerein- und -ausgänge überwacht werden können (monitoring).

Im realen Einsatz sollte das entwickelte Programm ohne Betriebssystem und Monitorprogramm lauffähig sein, d.h. die gewünschten Funktionen übernehmen.

Dies kann auch durch einen erfolgreichen Test in dieser Form nicht sichergestellt werden, wofür es mehrere Gründe gibt.

Zum einen liegt der Programmcode nicht an der Adresse OOOO16, wie es für ein eigenständiges Programm notwendig wäre, weil der Controller nach jedem Neustart (reset) immer zuerst an dieser Adresse mit der Programmausführung beginnt.

Zum anderen sind prinzipiell auch Schreibzugriffe möglich, da sich das entwickelte Programm in einem RAM befindet. Als eigenständiges Programm wird es dagegen in einen Nur-Lese-Speicher "gebrannt", so daß keinerlei Schreibmöglichkeit mehr besteht und es auch ohne diese lauffähig sein muß.

Ein weiteres Problem ergibt sich daraus, das bei jedem Start des Controllers die notwendigen Voreinstellungen oder sogenannte Initialisierungen vom Betriebssystem vorgenommen werden. Diese Initialisierungen sollen jedoch letztlich durch das entwickelte Programm vorgenommen werden. Wenn die Initialisierungen richtig durchgeführt werden, ist nicht sichergestellt, ob diese von dem Programm oder, weil die Anweisungen zur Initialisierung im Programm vergessen wurden, von dem Betriebsystem durchgeführt worden sind. Solange das Betriebssystem aktiv ist, ist hierüber in einem Test keine Aussage möglich.

In der Praxis versucht man, diese Unzulänglichkeiten bekannter Controllerboards für Mikrocontroller-Lehrsysteme mit folgenden Verfahrensweisen zu beheben:

Entweder wird das erstellte Programm in ein ROM gebrannt oder in ein EPROM (erasable programable read only memory) geladen und anstelle des Betriebsystem-ROMs in das Controllerboard gesteckt. Stellt sich heraus, daß das Programm dennoch fehlerhaft ist, muß das ROM, das nicht mehr verändert werden kann, weggeworfen werden. Ein EPROM dagegen kann immerhin wieder unter UV-Licht gelöscht und neu programmiert werden.

Die genannten Verfahren sind jedoch zeitaufwendig und unpraktisch, da jedesmal das Controllerboard aus seinem Gehäuse gezogen, die Bauteile umgesteckt und das Controllerboard wieder in das Gehäuse eingeschoben werden muß.

Ein weiterer Nachteil der bekannten Controllerboards für Mikrocontroller-Lehrsysteme ist es, daß nicht geprüft werden kann, ob eine von-Neumann-Speicherverwaltung, bei der sowohl auf den Programmcode als auch auf die Daten über gemeinsame Steuersignale zugegriffen wird, bzw. eine Harvard-Speicherverwaltung, bei der auf den Programmcode und Daten über getrennte Steuersignale zugegriffen wird, im zu entwickelnden Programm korrekt berücksichtigt wird. Insbesondere deren eigenständige Funktion kann üblicherweise nicht getestet werden.

Vor allem für Lehr- und Unterrichtszwecke ist es wünschenswert, daß wahlweise eine Speicherverwaltung sowohl nach Harvard als auch von Neumann programmiert werden kann.

Aufgabe der vorliegenden Erfindung ist es daher, ein Controllerboard anzugeben, mit dem es möglich ist, für das erstellte Programm eine reale Umgebung, d.h. mit dem realen Adreßbereich, ohne Unterstützung durch ein Betriebssystem und mit dem realen Speichermedium (ROM) zu simulieren, wobei zwischen einer von-Neumann- oder Harvard-Speicherverwaltung unterschieden werden kann.

Zur Lösung dieser Aufgabe wird vorgeschlagen, bei einem Controllerboard der eingangs genannten Gattung die Zuordnung

der Controlleradressen nach Abschluß eines Entwicklungsmodus so veränderbar zu gestalten, daß das in dem ROM (IC3) abgelegte Betriebssystem und Monitorprogramm ausgeblendet und statt dessen simuliert wird, wie sich das entwickelte Programm ohne das Betriebssystem in einem ROM verhalten würde.

Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.

Vorteilhaft ist insbesondere die Ausbildung, bei der das Controllerboard so einstellbar ist, daß entschieden werden kann, ob das entwickelte Programm auf Daten und Code entsprechend einer Speicherverwaltung nach von Neumann oder entsprechend einer Harvard-Speicherverwaltung zugreift, wobei für die Daten bei Harvard-Speicherverwaltung ein weiteres RAM (IC5) vorgesehen ist.

Eine weitere bevorzugte Ausführungsform liegt vor, wenn mit einem ersten Schalter (E) das Betriebssytem/Monitorprogramm ausgeblendet werden kann und wenn mit einem zweiten Schalter (H) die verschiedenen Speicherverwaltungsmodi vorgegeben werden können, wobei die Schaltersignale der Schalter (E,- H), die Steuersignale (PSEN; RD; WR) und die Adreßsignale des Controllers durch einen programmierbaren Logikbaustein (IC7, GAL) geeignet verknüpft werden.

Besonders vorteilhaft ist es weiter, wenn mindestens ein Sonderfunktionsbaustein (IC6) vorgesehen ist, der von dem Controller (ICl) über den programmierbaren Logikbaustein (IC7, GAL) wie ein Datenspeicher ansprechbar ist, wobei zu diesem Zweck Adressen der möglichen Adreßbereiche der RAMs (IC4; IC5) für die memory mapped Adressierung des Sonderbausteins (IC6) freigehalten werden.

Wenn der Sonderfunktionsbaustein (IC6) ein vierfach Digital/Analog-Wandler ist (DAW) und vier Adressen der möglichen Adreßbereiche der RAMs (IC4; IC5) für die memory mapped Adressierung des Digital/Analog-Wandlers (DAW) _:,

• I I ^et ·· ··

freigehalten werden, liegt eine weiter bevorzugte Ausführungsform vor.

Eine bevorzugte Ausführung der Erfindung wird im folgenden anhand der Zeichnung erläutert, die folgendes zeigt:

Figur 1 zeigt ein Blockschaltbild eines erfindungsgemäßen Controllerboards,· und

Figuren 2a bis 2d zeigen die Speicher-Adreß-Zuordnung des erfindungsgemäßen Controllerboards bei unterschiedlichen Betriebsarten.

In Figur 1 ist ein Blockschaltbild des Controllerboards dargestellt. ICl bezeichnet dabei den eigentlichen Controller, der beispielsweise vom Typ 8053 7 sein kann. Mit dem Controller ist ein Interface IC7 elektrisch verbunden. Dieses Interface IC7 dient der seriellen Datenübertragung von und zu einem hier nicht dargestellten PC über die Signalleitungen 1. Auf dem PC wird das Controllerprogramm mit Hilfe spezieller Entwicklungssoftware erstellt.

Der Controller ICl weist weiterhin einen oder mehrere Ausgänge 2 zum elektrischen Anschluß der von dem Controller ICl zu steuernden (ebenfalls nicht dargestellten) Geräte auf. Die in bekannter Weise ausgebildeten Einrichtungen zur Spannungsversorgung sowie die Interfacebausteine zum externen Anschluß an die Portanschlüsse des Controllers ICl sind ebenfalls nicht dargestellt.

Man erkennt weiter einen Adressenzwischenspeicher IC2, der mit dem Controller ICl über einen Datenbus 3 und einen Adreßbus 4 elektrisch verbunden ist.

Der von dem Controller ICl ausgehende Datenbus 3 und der von dem Adressenzwischenspeicher IC2 ausgehende Adreßbus 4 ist weiterhin elektrisch mit den folgenden Bauteilen verbunden: Einem Nur-Lese-Speicher (ROM) IC3 mit dem Controller-

Betriebssystem und dem Monitorprogramm, einem Schreib-/Lesespeicher (RAM) IC4 zur Aufnahme des erstellten Controllerprogramms, einem weiteren RAM IC5 zur Speicherung von unter Harvard-Struktur verwalteten Daten {kurz: Harvard-Daten) und einem Sonderfunktionsbaustein, hier ein 4-fach Digital/Analog-Wandler (D/A-Wandler) IC6 mit vier Ausgängen zur Steuerung nicht dargestellter angeschlossener Geräte.

Normalerweise werden derartige Sonderfunktionsbausteine von dem Mikrocontroller ICl über I/O-Adressen angesprochen. Falls der Controller ICl jedoch nicht über diese Adressen verfügt, muß der D/A-Wandler wie ein Datenspeicher angesprochen werden. Damit es nicht zu Adressen-Konflikten mit den Speichern kommt sind zu diesem Zweck vier Adressen der möglichen Adreßbereiche der Speicher IC4 und IC5 als Speicheradressen gesperrt und werden für die sogenannte "memory mapped"-Adressierung der externen Sonderbausteine verwendet.

Von dem Controller ICl gehen weiter drei Signalleitungen für Steuersignale PSEN (program select enable), RD (read) und WR (write) zu dem programmierbaren Logikbaustein (gate array logic, GAL) IC7. Dieser programmierbare Logikbaustein IC7 steuert die Freigabe bzw. Sperrung der Speicheradressen der angeschlossenen IC3, IC4_; IC5 und IC6. Die Steuerung erfolgt aufgrund einer in dem programmierbaren Logikbaustein IC7 gespeicherten Verknüpfung in Abhängigkeit von den an seinen Eingängen anliegenden Steuersignalen PSEN, RD, WR und der Adressen des Controllers ICl sowie der ebenfalls anliegenden Signale der Schalter E und H. Die Erstellung der logischen Verknüpfung für den Logikbaustein IC7 erfolgt anhand der unten näher beschriebenen Funktionen in üblicher Weise, wobei Änderungen der Funktionen durch Änderung der Verknüpfung möglich sind.

Der Schalter E dient dabei der Umschaltung zwischen einem Modus, in dem ein Controllerprogramm geladen und entwickelt werden kann und einem Modus, in welchem ein Programmlauf unter realen Bedingungen durchgeführt werden kann.

Der Schalter H dient dazu, die Speicherverwaltung nach von Neumann bzw. Harvard durch Umschalten vorzugeben.

Im folgenden wird eine typische Entwicklungsphase vom Laden des auf einem PC erstellten Programms bis hin zu dessen Test unter realen Bedingung erläutert. Dabei ist insbesondere die Größe der Speicherbausteine und deren Aufteilung prinzipiell beliebig, in der beschriebenen Ausführungsform jedoch deshalb besonders zweckmäßig, da sie die bekannten Speicherbausteine optimal nutzt:

Der Schalter E wird in die Entwicklungsstellung gelegt. Die Schalterstellung des Schalters H ist zunächst beliebig.

Man erkennt aus Figur 2a, daß die Controlleradressen OOOO16 bis 7FFF16 für die Ansteuerung des Nur-Lese-Speichers IC3 dienen, in welchem sich das für das Laden des auf dem PC erstellten Programms erforderliche Betriebssystem befindet. Mit Hilfe des Betriebssystems des Controllers wird das Programm in das RAM IC4 transferiert, und zwar in den Adreßbereich 8OOO16 bis FFFB16 des Controllers. Die verbleibenden vier Adressen FFFC16 bis FFFF16 bleiben für die memory mapped Adressierung der Sonderfunktionsbausteine frei. Das RAM IC5 bleibt in dieser Phase inaktiv.

Für den anschließenden Programmtest mit Hilfe des Betriebssystems und eines Monitors kann der Programmcode im Adreßbereich 8OOO16 bis FFFB16 des RAM IC4 vom Controller ICl gelesen werden, wie in Figur 2b dargestellt.

Sollen Daten entsprechend einer von-Neumann-Speicherverwaltung verarbeitet werden, können diese im selben Adreßbereich 8OOO16 bis FFFB16 des RAM IC4 geschrieben und gelesen werden, wie im oberen Teil der Figur 2b dargestellt. Man erkennt weiter, daß die D/A-Wandler unter den Adressen FFFC16 bis FFFF16 zugänglich sind, falls sie entsprechend einer von-Neumann-Speicherverwaltung programmiert werden sollen.

• ·

Für den Fall, daß die Daten entsprechend einer Harvard-Speicherverwaltung verarbeitet werden sollen, wird das RAM IC5 aktiviert und die Daten können in den Adreßbereich OOOO16 bis 7FFB16 des RAM IC5 geschrieben und gelesen werden, wie im unteren Teil der Figur 2B dargestellt. Man erkennt weiter, daß die D/A-Wandler unter den Adressen 7FFCi6 bis 7FFF16 zugänglich sind, falls sie entsprechend einer Harvard-Speicherverwaltung programmiert werden sollen.

Das Betriebssystem im ROM IC3 bleibt während dieser Phase aktiv.

Wird der Schalter E nun in die Stellung "Realer Modus" gelegt, wird das Betriebssystem durch den programmierbaren Logikbaustein IC7 unabhängig von der Schalterstellung des Schalters H abgeschaltet.

Wie aus Figur 2c ersichtlich, erscheint das RAM IC4 aufgrund der Signa!verknüpfung im programmierbaren Logikbaustein IC7 für den Prozessor jetzt im Adreßbereich OOOO16 bis 7FFB16, ersetzt also das Betriebsystem.

Aus Figur 2c ist erkennbar, daß die D/A-Wandler memory mapped unter den verbleibenden Adressen 7FFC16 bis 7FFF16 des IC4 erscheinen.

Befindet sich der Schalter H in der Stellung "von-Neumann-Speicherverwaltung" ist zum Lesen des Programmcodes vom gesamten Adreßbereich des RAM IC4 nur der Bereich OOOO16 bis 3FFF16 freigegeben, siehe Figur 2c. Da der Controller bei jedem Neustart (reset) grundsätzlich an der Adresse OOOO16 den Code zu lesen beginnt, muß ein eigenständiges Programm, d.h. ein Programm ohne Unterstützung durch das Betriebssystem, an dieser Adresse beginnen. Programmfehler hierbei, die in der Testphase noch von dem Betriebssystem behoben wurden, werden jetzt erkennbar. Dadurch, daß nur gelesen werden kann, wird ein ROM simuliert.

Zum Lesen und Schreiben von Daten steht der Adreßbereich 400016 bis 7FFB16 des RAM IC4 zur Verfügung, siehe Figur 2c.

Das RAM IC5 ist gesperrt.

Wird der Schalter H in die Stellung "Harvard-Speicherverwaltung" umgelegt, gibt der programmierbare Logikbaustein IC7 zum Lesen des Programmcodes den Adreßbereich 000016 bis 7FFB16 des RAM IC4 frei, vergleiche Figur 2d, rechte Seite. Auch hier gilt, daß der Controller bei jedem Neustart (reset) grundsätzlich an der Adresse &Ogr;&Ogr;&Ogr;&Ogr;16 den Code zu lesen beginnt, so daß ein eigenständiges Programm, d.h. ein Programm ohne Unterstützung durch das Betriebssystem, an dieser Adresse beginnen muß. Auch in dieser Schalterstellung werden Programmfehler aufgedeckt.

Zum Lesen und Schreiben von Daten steht der Adreßbereich &Ogr;&Ogr;&Ogr;&Ogr;16 bis 7FFF16 des von dem programmierbaren Logikbaustein IC7 aktivierten IC5 zur Verfugung, vergleiche Figur 2d, linke Seite.

Aus Figur 2d ist erkennbar, daß die D/A-Wandler jetzt memorymapped unter den verbleibenden Adressen 7FFCi6 bis 7FFF16 des IC5 erscheinen.

Wie anhand des vorstehend bevorzugten Ausführungsbeispiels eines Controllerboards beschrieben, ist es damit in besonders einfacher und zeitsparender Weise möglich, entwickelte Programme daraufhin zu testen, ob sie eigenständig, d.h. ohne Unterstützung eines Betriebssystems, ab der Startadresse des Controllers und in einem ROM lauffähig wären. Dabei kann insbesondere auch festgestellt werden, ob das Programm Daten und "memory mapped" Peripheriebausteine entsprechend einer von-Neumann-Speicherverwaltung oder einer Harvard-Speicherverwaltung korrekt bearbeitet.

Claims

Anmelder: Rüdiger Pietzsch Schutzansprüche

1.) Controllerboard insbesondere für ein Mikrocontroller-Lehrsystem, mit einem Controller, mit einem Adreßzwischenspeicher, mit einem von einem Teil der Controlleradressen angesprochenen ROM mit Betriebssystem und Monitorprogramm, mit einem von einem weiteren Teil der Controlleradressen angesprochenen RAM für das zu entwickelnde Controller-Programm, und mit einem Schnittstellenbaustein für die serielle Datenübertragung von und zu einem PC,

dadurch gekennzeichnet, daß die Zuordnung der Controlleradressen nach Abschluß eines Entwicklungsmodus so veränderbar ist, daß das in dem ROM (IC3) abgelegte Betriebssystem und Monitorprogramm ausgeblendet und statt dessen simuliert wird, wie sich das entwickelte Programm ohne das Betriebssystem in einem ROM verhalten würde.

2.) Controllerboard nach Anspruch 1,

dadurch gekennzeichnet, daß es so einstellbar ist, daß entschieden werden kann, ob das entwickelte Programm auf Daten und Code entsprechend einer Speicherverwaltung nach von Neumann oder entsprechend einer Harvard-Speicherverwaltung zugreift, wobei für die Daten bei Harvard-Speicherverwaltung ein weiteres RAM (IC5) vorgesehen ist.

3.) Controllerboard nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß mit einem ersten Schalter (E) das

Betriebssytem/Monitorprogramm ausgeblendet werden kann und daß mit einem zweiten Schalter (H) die verschiedenen Speicherverwaltungsmodi vorgegeben werden können, wobei die Schaltersignale der Schalter (E; H), die Steuersignale (PSEN; RD; WR) und die Adreßsignale des Controllers durch einen programmierbaren Logikbaustein (IC7, GAL) geeignet verknüpft werden.

4.) Controllerboard nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß mindestens ein Sonderfunktionsbaustein (IC6) vorgesehen ist, der von dem Controller (ICl) über den programmierbaren Logikbaustein (IC7, GAL) wie ein Datenspeicher ansprechbar ist, wobei zu diesem Zweck Adressen der möglichen Adreßbereiche der RAMs (IC4; IC5) für die memory mapped Adressierung des Sonderbausteins (IC6) freigehalten werden.

5.) Controllerboard nach Anspruch 4,

dadurch gekennzeichnet, daß der Sonderfunktionsbaustein (IC6) ein vierfach Digital/Analog-Wandler (DAW) ist und daß vier Adressen der möglichen Adreßbereiche der RAMs (IC4; IC5) für die memory mapped Adressierung des Digital/Analog-Wandlers (DAW) freigehalten werden.