Projektziel: C167-Basisboard für den Schulbetrieb   Team: Christian Bichler Bernhard Egger Thomas Negeli   Betreuer: Dipl.-Ing. Franz Parzer

Ende des Schuljahres 1998/99 hielt Wilhelm Brezovits an unserer Schule einen Vortrag über den Infineon C167 - Microcontroller, den zugehörigen Codegenerator DAvE samt Compileroberfläche. In diesem Rahmen wurden der Schule 4 C167 Starterkits übergeben. Daraufhin wurde ein Laborprojekt gestartet, in welchem die Realisierung einer Entwicklungsumgebung mit dem C167 für den Schulbetrieb erfolgen sollte. Wie sich wohl jeder vorstellen kann, ist es natürlich nicht möglich ein solches Projekt innerhalb eines Jahres abzuwickeln, daher wurde das Projekt des Vorjahres an uns weitergegeben.

Projektjahr 1999/2000:

• Erstellung eines Konzeptes und Entwicklung eines Schaltplanes
• Fertigung der Printplatten
• Grundstrukturen der Software

• Fertigstellung (Bestückung) der 10 Basisboards
• Inbetriebnahme und Kontrolle der Boards
• Softwareentwicklung der Treiberroutinen

Folgende Anforderungen entstammen den Vorgaben, die der geplante Einsatz als Schulsystem verlangt:

• Robustheit
• Standard I/O (RS232, Tastatur, LCD)
• Erweiterbarkeit
• Easy-to-use Entwicklungsumgebung

Entwicklungsumgebung
 

Die Platine lässt sich einfach und ohne spezielle Treiber in die Entwicklungsumgebungen der Firmen Keil und Tasking einbinden. Die compilierten Programme werden mittels eines Monitors zum Basisboard hinuntergeladen und lassen sich somit direkt an der Zielhardware ausführen und debuggen. Da die Platine kompatibel zum weit verbreiteten Evaluationsboard der Firma Phytec ist, lassen sich sowohl das dafür konzipierte Monitorprogramm als auch die Flashtools zum Speichern fertig getesteter Programme im Flash-Memory verwenden.

Hardware

Die Spannungsversorgung erfolgt mit einem PWM Schaltregler, der selbst bei der maximalen Eingangsspannung von 40V einen hohen Wirkungsgrad erzielt. Auf Wunsch kann alternativ ein herkömmlicher 7805 mit seinen bekannten Einschränkungen eingesetzt werden.

Ein zentrales Thema stellen die Schnittstellen zur "Außenwelt" dar. Neben der obligaten RS232 Schnittstelle, die der Prozessor als integrierte Peripheriekomponente bietet, ist ein zweiter serieller Kanal implementiert, der softwaremäßig emuliert wird und beispielsweise als Verbindung zu einem Terminal dienen kann. Dies hat sich zum Testen neu entwickelter Programme als sehr nützlich erwiesen.

Das CAN Modul des C167CR ist in verschiedenen Konfigurationen an den Bus anschaltbar. In einer galvanisch getrennten Variante kommen Optokoppler zum Einsatz. Wird auf diese Trennung verzichtet, so können diese entfallen und die Versorgung der gesamten Hardware kann optional über den CAN-Bus erfolgen.

Als Human Interface steht auf der Eingabeseite ein PS2 Keyboardanschluss zur Verfügung, an dem handelsübliche Tastaturen betrieben werden können.

Zur Visualisierung lassen sich Industriestandard LC-Displays (bis zu 40 Zeichen x 4 Zeilen) direkt an der dafür auf der Platine vorgesehenen Stiftleiste anstecken.

Für das richtige Timing sorgt ein DCF77 Modul, das Datum und Zeit via Funk von der Atomuhr in der Nähe von Frankfurt empfängt.

Alle Komponenten finden auf einer 2-Layer Europakarte Platz. Die Platine wurde komplett in AccelEDA v13 entwickelt und größtenteils mit 8mil schmalen Leiterbahnen entwirrt.

Erweiterbarkeit
 

Um die Anbindung an applikationsspezifische Hardware zu ermöglichen ist ein 96-poliger Stecker nach DIN-Norm angebracht, womit das Board den Kern eines Einschubsystems darstellen kann. Die wichtigsten Signale konzentrieren sich jedoch auf 2 Stiftreihen, wodurch einzelne Erweiterungskarten mittels Stift- und Buchsenleisten aufgesetzt werden können. Der Adress-/Datenbus inklusive Steuerleitungen wird über Transceiver an die Backplane geführt, welche die Prozessorports aktiv entlasten und sie vor der Zerstörung durch Überspannungen an der Erweiterungshardware schützt. Alle übrigen Signale am DIN-Stecker verfügen über eine passive Schutzbeschaltung, die kurzzeitig Überspannungen von 50V standhält. Ein Widerstand im Signalweg begrenzt die Anstiegsgeschwindigkeit der Ausgangssignale (bessere EMV) und lässt sich mit einem weiteren Widerstand zu einer Messbereichserweiterung für Analogeingänge konfigurieren.

Alle Dateioperationen in C benutzen als unterste Schicht die Funktionen _fopen, _ioread, _iowrite und  _fclose um mit den Streams zu arbeiten. Diese Funktionen mussten also für unsere Bedürfnisse abgeändert werden, was mit Ausnahme der Funktion _fclose schon unsere Vorgängergruppe erledigte.

In der Initialisierungsphase des µ-Controllers registrieren sich alle implementierten Treiber im Modul USRIO.C und geben dort ihre Routinen zum Öffnen, Lesen, Schreiben und Schließen des Streams bekannt.
Diesen Vorgang kann man sich so vorstellen, dass jedem Treiber bei der Registrierung eine eindeutige Nummer (=fileno)  zugewiesen wird. Diese Nummer und der zugehörige Treibername wird in eine Tabelle eingetragen.  In diese Tabelle werden weiters Verweise auf die mit dem Treiber zu verwendenden Routinen gespeichert. Durch die Abänderung der Funktionen _iowrite und _ioread werden anschließend immer die in dieser Tabelle eingetragenen Treiber verwendet.

Ein Beispiel zum Verständnis des Konzeptes

Im Hauptprogramm wird unter anderem die Funktion Display_Init() aufgerufen, welche für die Display Initialisierung zuständig ist und in der sich  folgende Zeile wiederfindet:

Das Modul register_drv ordnet nun die übergebenen Funktionen in einer Struktur einer eindeutigen Treibernummer zu.

Wird nun im Hauptprogramm mittels fopen("LCD","w") ein Kanal zum Display geöffnet, so versucht die Routine _fopen(...) eine open Funktion eines Treibers zu finden, der sich auf die Zeichenfolge "LCD" meldet, ist kein entsprechender registrierter Treiber vorhanden, wird NULL zurückgegeben.

Bei korrekter Öffnung bewirkt ein anschließendes fprintf(...) in letzter Instanz den Aufruf von _iowrite(...).

fileno(fout) ermittelt aus der Tabelle der initialisierten Treiber den zu LCD passenden Eintrag in Form eines Zeigers. Dieser weist auf eine Liste von 4 Funktionen, wobei die write Funktion der Ausgabe dient und mit den passenden Parametern aufgerufen wird. Die verwendete write Funktion ist in diesem Fall Display_Write(...).

Stand der Dinge

• Die Realisierung des Displaytreibers erwies sich als schwieriger als wir zu Beginn dachten. Da unsere Vorgruppe augenscheinlich nicht mehr genug Zeit für Tests hatte, mussten wir die vorhandenen Displayroutinen noch einmal gänzlich überarbeiten. Nach zahlreichen Hardwareproblemen mit kaputten (oder kaputt getesteten) LCD-Displays war es uns nun doch möglich einen funktionsfähigen Displaytreiber zu schaffen.
   
• Der Treiber für die zweite serielle Schnittstelle wird derzeit in Zusammenarbeit mit Wolfgang Heidl, einem Mitglied der Vorjahresgruppe, entwickelt und steht kurz vor der Fertigstellung.
   
• Zur Zeit befinden wir uns mitten in der Entwicklung eines Treibers für den vorhanden PS/2 Anschluss. Durch Messung der Datenübertragung an einer PS/2 Tastatur, deren Ergebnis mit dem Inhalt unserer Datenblätter nicht übereinstimmt, stehen wir vor einem weiteren Problem, das wir aber schnellstens zu lösen gedenken.
   
• Der Treiber für das CAN-Modul ist noch ausständig.

Fertigung

Bestellung und Kalkulation

Außerdem wurde eine vollständige Kalkulation der Kosten für ein Basisboard realisiert. Trotz Online - Hilfe diverser Kataloge kann es bei der Bestellung zu diversen Problemen kommen. Von der doppelten Bauteilbezeichnung über das Vorhandensein verschiedener Preise für ein Produkt bis zum fehlenden Lagerbestand kann man auf eine Vielzahl von Komplikationen treffen.  Auch auf den Preisunterschied, der zwischen den Herstellern bzw. Lieferanten besteht, ist zu achten!

Bestückung

Sämtliche Bauteile d.h. diskret und SMD, wurden gänzlich mit Hilfe von schuleigenen Einrichtungen bestückt. Unter Verwendung des „neuen“ Bestückungsautomaten in der Werkstätte von FOL König, mit dem es möglich war, sowohl die Lötpaste aufzutragen als auch die Bauteile zu bestücken, konnte eine saubere SMD-Bestückung ermöglicht werden. Das Verlöten der Bauteile erfolgte mit Heißluft.  Tipp: Zum Verlöten von SMD-IC’s eignet sich die Verwendung von Flussmitteln. Das Aufbringen des Flussmittels bewirkt eine besseren Fluss des Lotes und verhindert Kurzschlüsse zwischen einzelnen Pins der IC’s.

Hardwaretest

Fehleranalyse

• Bei der einen stellte sich nach einer Reihe von Überprüfungen heraus, dass sekundärseitig eine Spannung von 1,4V anstatt von 5V anlag. Die Ursache dafür lag in einem falsch gepolten Tantal - Elektrolytkondensator. 

• Bei der anderen wurde ein Kurzschluss zwischen Masse und Plus der Versorgung festgestellt, der so gut wie überall auf der Platine sein konnte. Nach langer optischen Kontrolle wurde dann ein Kurzschlussdetektor eingesetzt. Dieser ermöglichte es uns den Versorgungsstromkreis mit einem Sinussignal zu versorgen und die Platine in diesem Zustand mit einer Feldsonde abzutasten. So könnte festgestellt werden, wo sich der Kurzschluss befindet. In unserem Fall war die Leiterbahnführung der Versorgung jedoch derart kompliziert, dass kein aussagekräftiges Ergebnis ermittelt werden konnte. Daher begannen wir sämtliche Stütz- und HF-Kondensatoren auszulöten, welche eine mögliche Fehlerquelle darstellten. Als jedoch sämtliche Kondensatoren ausgelötet waren und der Fehler immer noch nicht behoben war, wurde auch der Festspannungsregler MAX727 ausgelötet, der, wie sich durch eine Messung herausstellte, die Fehlerquelle darstellte. Dieser wurde infolge ersetzt und die Hardwareinbetriebnahme konnte abgeschlossen werden.

Fehlerbehebung

Hier wird ein Softwaretest der Platine durchgeführt, indem ein funktionierendes Programm, in unserem Fall eine Routine zur Ansteuerung des LC-Displays, auf die Hardware downgeloaded wird! Zusätzlich wurde der Flash-Speicher mit einem speziellen Flash-Test-Programm getestet. Gingen die beiden Tests in Ordnung, so konnte die Platine als voll funktionsfähig betrachtet werden, war dies jedoch nicht der Fall, so musste die Platine erneut einem Hardwaretest unterzogen werden.

Laborgruppe 5AHE-00/01
 

Bichler Christian	cbichler@aon.at
Egger Bernhard	begger@gmx.at
Negeli Thomas	tnegeli@gmx.at

Abschließend hoffen wir, dass die nächste Laborgruppe ebensoviel Freude wie wir am C167-Basisboard hat und dieses im Rahmen der Laborprojekte des nächsten Jahres fertiggestellt.