Mein Studienkollege und Freund Bernard und ich sassen eines Sonntags abends in unserer Stammkneipe, dem Roxi, und diskutierten über eine Sammelzeitschrift für Robotik.
Nach einigen Recherchen fand Bernard heraus, dass bis zu Heft 28 (oder so ähnlich) nur Hardware kommen sollen. Der zusammengebaute Roboter (ein Rug Warrior-Klon) kann zwar einige feste Programme ausführen, aber das war es dann schon. Ab Heft 28 soll dann nach und nach bis Heft 56 die Entwicklungsumgebung eingeführt werden. Bei einem Heftpreis von ca. 8 Euro käme man dann auf einen Gesamtpreis von ca. 440 Euro. Für diesen Preis kann ich zwei (!) Lego Mindstorms Baukästen kaufen und kann damit konstruieren, was ich will bzw. wozu ich fähig bin. Wir waren der Meinung, dass dies eine bessere Investition wäre.Worauf ich ihm auch die Nachteile des RCX (der Steuereinheit des Mindstorms-Systems) servierte, denn ich besitze einen Mindstorms-Baukasten und habe schon einige Projekte damit verwirklicht. Hauptproblem des RCX ist die geringe Ausstattung mit Sensoren- und Motorenanschlüssen sowie die Energieversorgung, die auch die Motoren betreiben muss.
Bernard meinte dann in seiner damaligen Weinlaune (Bier war diesmal keins involviert), man könnte doch eine solche Steuereinheit selbst machen. Das wäre ganz einfach. Nun ist Bernard ein versierter Hardwarebastler und angehender Informationstechniker (ein Elektrotechnikstudiengang) und findet das sehr leicht. Ich war zuerst erschrocken, jedoch faszinierte mich die Idee einer grösseren Steuerungseinheit sehr schnell, denn die Einschränkungen des RCX haben mich bisher von grösseren Projekten abgehalten. Das eine grosse Projekt war ein Roboter für das alte Robotikpraktikum der Informatik an der Uni Kaiserslautern. Die Vorführung ging kräftig in die Hose, weil wir mit zwei RCXen hantieren mussten und ich die selbstgestrickte Kommunikation zwischen beiden nicht rechtzeitig hinbekommen habe.
Also beschlossen wir beide das mal zu probieren. Bernard favorisierte eine Plattform auf der Basis der MC68000-Familie von Motorola, weil sie einfach zu benutzen und wohlbekannt sei.
Da haben wir noch nichts Konkretes, da wir erst in der Anfangsphase des Projekts sind.
Einige Eckdaten wären:
Grundsätzlich sind zwei Ansätze denkbar:
Der klassische Ansatz der Embedded Systems-Branche wäre es eine massgeschneiderte Software zu entwicklen, die alle Applikationen enthält. Das Softwareimage befindet sich dann beim Anschalten des Gerätes auf der Adresse des Resetvektors, so dass die Software nun ausgeführt wird und die Kontrolle vollständig übernimmt.
Dieser Ansatz ist für unser Hobbyprojekt jedoch etwas zu aufwändig.
Der etwas modernere Ansatz wäre es, ein für den Embedded-Einsatz angepasstes Betriebssystem, also fast zwangsläufig Linux, zu benutzen.
Hier scheint uClinux besonders geeignet zu sein, denn es ist für verschiedene Prozessoren der MC68000-Familie erhältlich, es ist frei und ist auf die Bedürfnisse eines MMU-losen Prozessors zugeschnitten.
Dieser Ansatz hat den Vorteil, dass Entwicklungssoftware und TCP/IP-Software schon vorhanden sind. Die Programme können ausserdem als ganz normale ELF-Binaries entwickelt werden und laufen auf dem System als ganz normale Prozesse.
Im Moment werde ich wohl mal uClinux evaluieren, um festzustellen, ob wir damit arbeiten können.
Ich habe es geschafft. Mit Eagle 4.0 habe ich den ersten Prototypen implementiert nach dem Vorbild des Home Automation Systems (s.u.). Es fehlt nur der 6522 VIA, der nicht in der Eagle-Bibliothek zu finden ist, aber auch nicht wirklich drauf passt.
Die folgenden Dateien stehen zur Verfügung:
Danke an Dominik für seinen Link zum Thema I2C
Ich habe ein paar Dokumente von Motorola zum Download vorbereitet sowie ein Dokument über eine selbstgebaute Hausgerätesteuerung (Danke Matthias).
Ich habe ein Diskussionsforum eingerichtet.
Ein erstes Thema gibt es schon. Viel Spass.
Bei unserem ersten Treffen gab es - wie sollte es anders sein - wilde Diskussionen und viel Ablenkung - Quatsch Comdy Club und Bully-Parade. Rausgekommen ist nicht viel:
Plattform. Nach Sichtung einschlägiger, aktueller (Achtziger!) Literatur zur 68k-Familie, haben wir entschieden, es mit dem MC68020 zu versuchen. Dieser Prozessor ist voll 32-bittig, unterstützt eine MMU, hat Pipelines und 256 Byte internen Cache.
Speicher. Wir einigten uns immerhin auf 16 MB Hauptspeicher, organisiert in vier Bänken. Ob dynamisch oder statisches RAM wurde diskutiert, aber die Entscheidung wurde verschoben, bis wir wissen, ob die Kosten für statischen RAM höher sind als der Controller für dynamischen RAM.
Als ROM soll Flash-RAM zum Einsatz kommen, denn (EE)PROM werden als zu problematisch eingestuft.
Da die 68K-Familie nur Speicher-I/O unterstützt, müssen zur Abbildung des Speicherbereiches auf die Peripherie (Sensoren und Aktuatoren) passende Peripheriebausteine benutzt werden. Die passenden Bausteine und ihre Eigenschaften müssen bewertet werden und dann eine Festlegung der gewünschten Ein- und Ausgangsanzahl getroffen werden.
Schnittstellen. Eine serielle Schnittstelle wurde gewünscht, um das Debuggen zu vereinfachen. Entsprechende Bausteine müssen gefunden werden.
Software. Auf ein "Betriebssystem" (Laut Bernard - jetzt ein Elektrotechniker, früher Informatiker - typisch Informatiker) konnte man sich nicht einigen. Ob Linux, Selbstgestricktes oder ähnliches wird wohl erst entschieden, wenn der Prototyp steht. Erst mal wird für den Prototyp ein kleines Programm entwickelt, dass die Funktionstüchtigekeit der Hardware testet.
