Feb 232011
 

Vor ein paar Tagen war ich bei meinem Freund Tobias Braeker. Er hat sich als Dipl. Ing. (Maschinenbau) einen Kindheitstraum verwirklicht und einen Radlader im Maßstab 1:12 nachgebaut. Der O&K L25 ist aus Edelstahl gefertigt, wiegt stattliche 12 kg und kann bis zu 9 kg heben. Das Modell ist sehr detailliert gearbeitet. Jedes Rad wird durch einen eigenen Glockenankermotor (Faulhaber) angetrieben, die Schaufel wird hydraulisch betätigt. Ein Soundmodul sorgt für Hörgenuss, denn das Motorengeräusch passt zu den gesteuerten Fahrkommandos. Natürlich ist das Modell auch vorbildlich mit Leuchten (Blinker, Rückfahrscheinwerfer, etc.) ausgestattet. Übrigens kann die Schaufel hydraulisch durch ein anderes Anbaugerät ausgewechselt werden.

Radlader

Die Steuerung ist ein waschechtes Embedded System. Sie beinhaltet den Empfänger, die Motorensteuerung, die Sound- und Lichtsteuerung. Der linke Steuerhebel bedient das Fahrzeug selbst, der rechte Steuerhebel bedient die Schaufel. Die Bedienung braucht natürlich Übung, denn meistens ist man es gewöhnt, mit links die Geschwindigkeit und mit rechts die Lenkung zu bedienen. Es macht aber in jedem Fall viel Spaß, Sand und Steine durch das Gelände zu transportieren.

Tobias verkauft das Modell als Bausatz oder als Fertigmodell. Die Preise können über seine Homepage erfragt werden. Auf YouTube können weitere interessante Filme mit dem L25 betrachtet werden. Für die Zukunft plant er die Konstruktion eines Kippers. Ich bin mal gespannt :-)

Jul 072010
 

Das Projekt der modell(-bau-)basierten Eisenbahnsteuerung ist ab sofort auf SourceForge als Open Source verfügbar. Die Startseite ist unter http://sourceforge.net/apps/trac/mrw/ erreichbar. Der Quellcode und die Schaltungen können aus dem Subversion-Repository heruntergeladen werden.

Viel Spaß!


Mrz 022009
 

Auf der Internetpräsentation der Firma itemis AG ist ein Artikel über die modellbasierte Entwicklung einer Eisenbahnsteuerung veröffentlicht worden. Zu diesem Zweck wurde eigens eine elektronische Steuerung auf Basis des ATmels ATmega32 Mikrocontrollers entwickelt. Es wird an zwei Stellen modellbasiert gearbeitet: Zum einen wird der Gleisplan durch ein EMF-basiertes Modell beschrieben. Dieses Modell wird in der Stellwerks-Software interpretiert, um Fahrstrecken zu ermitteln und die Eisenbahnanlage zu überwachen. An zweiter Stelle wird das Steuerungsprotokoll als Zustandsautomat der Mikrocontroller beschrieben. Daraus wird ein Teil der Firmware generiert, der für die Kommandoverarbeitung zuständig ist.

Die Modellierung des Gleisplans verwendet ein eigenes Metamodell, das mittels der oAW-Cartridge UML2ECore in einen EMF-Editor im Eclipse umgewandelt. Das Metamodell und der Zustandsautomat des Mikrocontrollers wurde mit MagicDraw modelliert.

Der gesamte Artikel kann hier eingesehen werden:

http://www.itemis.de/29970/

Nov 182008
 

Auf dem Yakindu-Tag wurde die modell(-bau-)getriebene Eisenbahnsteuerung vorgestellt. Dabei wurde der Gleisplan schon modellgetrieben generiert. Bisher war die Firmware der CAN-Knoten als Referenzimplementierung noch klassisch implementiert. Die Kommandoverarbeitung in der Firmware der CAN-Knoten war ein unschönes Stück Spaghetti-Code. Aus diesem Grund wurde ein Zustandsdiagramm gefertigt, das die Betriebszustände der CAN-Knoten enthält. Die eingehenden Kommandos sind als Zustandsübergänge modelliert. Aus diesem Diagramm wird mit Hilfe von openArchitectureWare der Code für die Kommandoauswertung generiert.

Zustandsdiagramm des CAN-Knotens

Der generierte Code enthält zwar relativ viele Callbacks und switch/case-Anweisungen und bläht den Binärcode um ca. 1,5 KByte auf. Das ist aber nicht weiter schlimm, da jetzt noch Platz für ca. 18 KByte im Flash des ATmega32 vorhanden ist. Ein weiterer Vorteil ist, dass der generierte Code wesentlich übersichtlicher aussieht. Änderungen und Erweiterungen der Steuerkommandos lassen sich jetzt viel leichter einpflegen. Die Integration des generierten Codes in den bestehenden Firmware-Rahmen gestaltete sich als unproblematisch, da der restliche klassisch implementierte Teil nur aus Service-Methoden zur Ansteuerung der Hardware dient.

Jul 102008
 

Nach der Entwicklung der CAN-Controller, wird jetzt als nächster Schritt das Bauen der Prototypen angegangen. An ihnen kann man das erste Mal testen, wie sich mehrere CAN-Controller an einem Bus verhalten. Erwartungsgemäß funktioniert der CAN-Bus mit mehreren Teilnehmern gemäß Spezifikation. Auch das Flashen einer neuen Firmware funktioniert einwandfrei. Dabei wird ein Bootloader verwendet, der die Firmware über den CAN-Bus entgegennimmt.

Auf dem Bild kann man vier CAN-Teilnehmer erkennen. Man kann inzwischen auch von den itemis Hardware Labs Lünen sprechen.

itemis Hardware Labs Lünen

Als nächster Schritt wird ein Platinen-Layout entwickelt, um die endgültigen CAN-Controller zu erhalten. Desweiteren werden jetzt die Schaltungen für die Leistungselektronik entwickelt. Schließlich sollen die CAN-Controller ja eine Modellbahn steuern.

Mehr Komfort mit C++

 Eingebettete Systeme  Kommentare deaktiviert
Jun 212008
 

In der Elektronikpraxis ist ein Artikel von mir erschienen, der sich mit der Verwendung von C++ im Embedded Systems beschäftigt. Obwohl mit C++ schon seit über 20 Jahren entwickelt wird, hält diese Sprache nur langsam in die Mikrocontroller-Programmierung Einzug. Sie enthält aber viele Sprachkonstrukte die die Qualität der Firmware erheblich verbessern kann und dem Entwickler die Arbeit vereinfacht. Ein Grund für die zögerliche Nutzung liegt im höheren Ressourcen-Bedarf. Viele moderne Mikrocontroller haben diese Hürde aber nicht mehr.

Der gesamte Artikel kann hier eingesehen werden: http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/articles/120537/

Jun 052008
 

Seit geraumer Zeit programmiere ich mit einem Kollegen der itemis AG an einer Mikrocontroller-gesteuerten Modellbahnanlage. Im Großen und Ganzen ging die Entwicklung sehr zügig voran. Es kam aber zu einigen Fallstricken, über die ich hier gerne mal berichten möchte. Zuerst bleibt zu erwähnen, dass die Entwicklungsumgebung für die AVR-Mikrocontroller recht gut sind. Die Gesamtanlage ist ein relativ komplexes System. In der Kette wurden Stellwerkssoftware in Java, ein Übertragungskanal über RS232-Schnittstelle an ein CAN-Gateway mit ATmega32 und MCP2515 gekoppelt. Daran sind mehrere CAN-Knoten derselben Hardware miteinander gekoppelt. Die Firmware ist C programmiert. Die Entwicklung aller Komponenten kann sowohl unter Windows, als auch unter Linux erfolgen. Linux hat den Vorteil, dass auch mal Remote entwickelt werden kann.

Nachdem die erste Schaltung gesteckt war, wurde schnell deutlich, dass die Kommunikation zum CAN-Controller nicht mehr stattfand. Offensichtlich ist die Kommunikation über das SPI zusammengebrochen. Ein kurzes Kontrollprogramm zeigt mithilfe eines Oszilloskops, dass die Verbindung tatsächlich zusammengebrochen ist. Ein genauer Blick ins Datenblatt des ATmega32 zeigte schnell, woran es lag: Es gibt einen Pin names Slave Select, der das SPI-Interface von außen in den Slave-Modus versetzen kann. In diesem Fall war er als offener Eingang – also ohne Anschluss – konfiguriert und beschaltet. Die Lösung bestand darin, das /CS-Signal für den MCP2515 als Ausgang daran anzuschließen.

Ein weiterer Punkt war, dass ein CAN-Knoten nach kurzer Betriebszeit nur durch einen Kaltstart wiederzubeleben war. Die Ursache war schnell gefunden: Als Takt wurde der Taktausgang des MCP2515 verwendet. Der Taktausgang ist nach einem Reset per Default eingeschaltet, kann aber per Software ausgeschaltet werden. Wenn der Takt erst einmal aus ist, besteht per Software keine Möglichkeit mehr, den Takt zu reaktivieren. Ein eigener Quartz für den ATmega32 bestätigte die Vermutung. Warum der Takt ungewollt ausgeschaltet wurde, wurde nicht geklärt. Vermutlich wurde durch eine Race Condition das entsprechende Register mit falschen Daten beschrieben. Ein ausführlicher Code Audit hat das Problem behoben, denn der CAN-Knoten funktioniert jetzt einwandfrei.

Zum guten Schluss haben wir noch ein Problem gehabt, dessen Lösung sich lange hingezogen hat: Es gingen CAN-Frames verloren. Das kann sehr unangenehm sein, denn es wird ein Messaging System vorausgesetzt, dass sich dadurch auszeichnen soll, dass nicht dauernd Informationen und Zustände abgefragt werden sollen (Polling). Es darf also keine Information verloren gehen. Interessanterweise ist dieser Effekt gehäuft beim Konfigurieren der CAN-Knoten aufgetaucht. In diesem Fall ist sporadisch ein Reset aufgetaucht. Ein Reset war nach der Konfiguration gewollt. Dieser hier tauchte aber während der Konfiguration auf. Die erste Vermutung, dass ein fehlkonfigurierter Interrupt eine nicht konfigurierte Interrupt Service Routine anspringt, hat sich nicht erhärtet. Woher kommt aber der Reset? Ein dummer Zufall brachte des Rätsels Lösung, als im Millisekunden genauen Logfile eine Pause von etwa 700 Millisekunden nach dem Ende der Konfigurierung auftauchte. Das ist gefährlich nahe am Timeout des Watchdogs, der mit einer Sekunde aktiv war. Laut Datenblatt dauert das Speichern eines Bytes im EEPROM 8.5 Millisekunden. Das Speichern einer Flash Page (128 Bytes) hingegen nur etwa fünf Millisekunden. In dieser Zeit kann kein Watch Dog Reset durchgeführt werden. Die Lösung bestand also darin, während dieser Zeit den Watch Dog zu deaktivieren. Eines hat die lange Suche aber noch gebracht: Der Code ist jetzt wesentlich effizienter und aufgeräumter.

Zusammenfassend kann man feststellen, wie eng gerade in Embedded Systems alle Komponenten miteinander abgestimmt sein müssen. Zwei scheinbar unabhängige Komponenten (Watch Dog und EEPROM) haben letztlich doch miteinander zu tun. Es lohnt sich immer, bei Problemen zuerst in Ruhe (!) einen Blick in die Datenblätter zu werfen. Wie bei der SPI-Schnittstelle kommt man dann schnell auf die Lösung. Wenn man mit Interrupts arbeitet, muss man ein Gespühr für Nebenläufigkeit (Threads) haben. So kann man das Zeitverhalten einschätzen und Race Conditions vermeiden. Dead Locks treten hierbei mit geringerer Wahrscheinlichkeit auf, sind aber nicht unmöglich. Dieser kann auf den ATmega Controllern wenigstens mit dem Watch Dog aufgelöst werden. Alles in Allem braucht man einen klaren Kopf und die Geduld, auf die Lösung des Problems hinzuarbeiten.

Mai 232008
 

Die Schaltung, um Weichen und Signale über Mikrocontroller zu steuern ist jetzt fertig entwickelt. An einem Steckbrett wurde ein Steuerungsknoten und ein Gateway zusammengebaut und programmiert. Das Gateway ist ein Protokollumsetzer. Die CAN-Frames werden vom PC über RS232 zu diesem Gateway getunnelt und von dort aus über den CAN-Bus weitertransportiert. Die Kommunikation ist dabei bidirektional. Dabei ist zu beachten, dass die Steuerungsknoten sich nicht untereinander unterhalten, sondern jede Information an das Gateway schicken. Das Schalten von Weichen und die Gleisbesetztanzeige werden auch schon korrekt im controller verarbeitet. Jetzt müssen die mehrere Prototypen auf testweise auf Laborplatinen gelötet werden.

Danach muss die Leistungselektronik entwickelt werden. Diese übernehmen die eigentliche Ansteuerung der Weichen und Signale. Diese Aufgabe ist reine Fleißarbeit. Denn es müssen mindestens 15 Steuerungsknoten, vier Gateways und unzählige Module zur Ansteuerung gelötet werden.

schaltung.jpg

Das Bild zeigt links unten das unscheinbare Steckbrett. Auf der linken Hälfte des Bretts ist der Steuerungsknoten auf der rechten das Gateway. Dieses kommuniziert mit einer kleinen Zusatzplatine über die serielle Schnittstelle am PC mit der Steuerungssoftware. Die Steuerungssoftware kann man auf dem linken Monitor erkennen. Der rechte Monitor zeigt die Entwicklungsumgebung Eclipse. Am rechten Bildrand kann man ein MacBook erkennen. Auf diesem läuft die Entwicklungsumgebung, um die Firmware der Mikrocontroller über JTAG zu debuggen.

Die Steuerungssoftware kommuniziert bereits mit den Mikrocontrollern und kann schon Aufgaben verteilen. Die Steuerungsaufgaben werden in mehreren Stapeln verarbeitet. So dürfen erst Signale geschatet werden, wenn alle Weichen die gewünschte Fahrstraße eingestellt haben. Erst danach kommt die Gleisfreigabe.

Feb 282008
 

Kann man modellgetrieben eine Modelleisenbahnsteuerung aus Mikrocontrollern bauen? Dieser Frage gehen Entwickler des Yakindu-Projektes nach. Hintergrund ist, dass eine digitale Ansteuerung der Weichen und Signale über konventionelle Mittel sehr teuer ist. Eine digitale Steuerung hat aber den Vorteil, dass der Verdrahtungsaufwand minimiert wird. Dieser fällt deswegen unangenehm auf, weil ein Großteil der elektrischen Verkabelung kopfüber geschehen muss. Hier setzt die Idee an, die Mikrocontroller bequem an einem ergonomischen Arbeitsplatz zu bauen und nur die fertigen Module kopfüber zu montieren und anzuschließen. Als Mikrocontroller werden von ATmel die ATmega32 eingesetzt. Diese sind vielseitig einsetzbar und es gibt sehr viele fertige freie Tools, um diese Controller zu programmieren. Zusätzlich gibt es eine große Auswahl an weiteren Spezial-ICs, wie z.B. den CAN-Controller MCP2515.

An den Mikrocontrollern sollen spezielle Ansteuerungsmodule verwendet werden. So können unterschiedliche Aufgaben an die Microcontroller vergeben werden, ohne jeweils eine spezielle Hardware bauen zu müssen. Dazu erhalten die Microcontroller eine universelle Firmware. Diese wird dann so konfiguriert, wie der Anschluss der Ansteuerungsmodule erfolgt. Als Ansteuerungsmodule sind derzeit geplant:

  • Lichtsignal-Ansteuerung, im Prinzip eine einfache LED-Ansteuerung
  • Magnetartikel-Ansteuerung. Darüber werden Weichen und Formsignale angesteuert.
  • Gleisabschnitt-Steuerung mit Gleisbesetztmeldung
  • JTAG-Modul zum Debuggen

Die drei letzten Module werden direkt mit den einzelnen Ports des ATmega gekoppelt ein Port fällt für spezielle Aufgaben weg, da z.B. die Microcontroller untereinander kommunizieren müssen. Diese Kommunikation soll über CAN-Bus erfolgen. Dieser ist sehr robust gegenüber Störungen und gilt nach 20 Jahren als ausgereift. Es gibt günstige Bauteile, die die Kommunikation auf physikalischer Ebene übernehmen. Darin enthalten ist z.B. eine Fehlerkorrektur über CRC und das Protokoll-Handling. Bei einem ATmega32 bleiben so drei Ports für die Module frei, was den individuellen Verbau der Module ermöglicht.

stellwerk.jpg

Als zweite Software-Komponente neben der Microcontroller-Firmware gibt es das Frontend. Diese GUI-Applikation ermöglicht die bequeme Ansteuerung der Microcontroller mit einer Visualisierung als Stellwerk. Insbesondere ist hier die Fahrstraßenschaltung zu nennen. Durch Anklicken von Stützpunkten welche die Route definieren und anschließender Auswahl von Rangieren oder Fahrt, wird eine freie Gleisroute vom Anfangspunkt über die Stützpunkte zum Endpunkt gesucht, danach die Weichen und Signale geschaltet und die Gleisabschnitte unter Fahrstrom gesetzt. Diese Applikation ist mit Eclipse und dem SWT/RCP-Framework umgesetzt. So kann das Stellwerk plattformunanhängig eingesetzt werden.

Zum Schluss bleibt die Frage offen, was daran modellgetrieben ist? Die gesamte Modellbahnanlage wird in einem EMF-Modell nachmodelliert. Daraus wird die Gesamtkonfiguration für die Microcontroller generiert sowie die GUI für das Stellwerk. Das generierte Gleisschema wird dann durch den universellen Router-Algorithmus für die Fahrstraße ergänzt. Dieser wertet noch Informationen aus, wie Langsamfahrstellen und bevorzugte Fahrwege an Weichen. In der Zukunft ist geplant, die Modellierung mittels GMF zu erreichen, weil die Eingabe über EMF gerade bei einer Modelleisenbahn wenig intuitiv ist.

Feb 272008
 

Seit Neuestem bietet ATmel auch eine Variante ihres erfolgreichen ATmega Mikrocontrollers mit integriertem CAN-Controller an. Laut Dokumentation ist die Spezifikation zwar noch vorläufig, es ist aber erkennbar, dass ATmel weitere Unterstützung im Automotive-Bereich liefern will. Derzeit sind drei Varianten (AT90CAN32, AT90CAN64 und AT90CAN128) aufgelistet, die sich in der Größe des Flash-Speichers, EEPROMs und des SRAMs unterscheiden. Der Mikrocontroller ist im 64-Pin TQFP lieferbar und hat sechs 8-Bit-IO-Ports zur Verfügung. Ansonsten enthält der Mikrocontroller die üblichen Baugruppen, die man von den bekannten ATmels gewohnt ist: Timer, PWM, JTAG, ISP, UART, um nur einige zu nennen.

Hier ist die (vorläufige) Spezifikation zu finden:
http://www.atmel.com/dyn/resources/prod_documents/doc7682.pdf

Mikrokopter

 ATmega, Eingebettete Systeme  Kommentare deaktiviert
Feb 172008
 

Der Mikrokopter ist ein Beispiel dafür, was man mit den ATmel ATmega Microcontrollern machen kann. Vier überkreuz positionierte Propeller geben den Auftrieb. Die Lagereglung wird über Beschleunigungssensoren an die drehzahlgeregelten Motoren für die Propeller weitergereicht. Als Bonbon ist noch ein GPS-Positionsmelder eingebaut. So kann ein Mikrokopter relativ ortsfest im Rahmen der GPS-Genauigkeit gehalten werden. Zusätzlich ist noch ein Kompass und ein Drucksensor zur Höhenmessung eingebaut. Eine lagegeregelte 3D-Kamera samt Brille runden das Gesamtbild ab. Jeder Motor hat seinen eigenen ATmega, der die Solldrehzahl umsetzt. Ein zentraler ATmega übernimmt den Rest der Lageregelung.

Unter http://www.mikrokopter.com/ucwiki/ sind mehrere beeindruckende Videos untergebracht.

Feb 172008
 

Heute wurde bekanntgegeben, dass ab der Linux-Version 2.6.25-rc1 Unterstützung für den CAN-Bus aufgenommen wurde. Die Unterstützung sieht derzeit so aus, dass CAN als zusätzliches Protokoll benutzt wird. So wird die schon bekannte Schnittstelle mittels socket(), read() und write() angesprochen. Die Unterstützung für Devices sieht im Moment leider ein wenig mager aus: Außer einem virtuellem Device steht im Moment kein Treiber zur Verfügung. Es wäre vielleicht denkbar, eigene Hardware unter Benutzung des CAN-Controllers MCP2515 zu bauen, die man z.B. über USB anspricht.

Interessanterweise wurde die Implementierung von Volkswagen beigesteuert. Ob allerdings ein “Treiber für Autos” entwickelt wird, oder Embedded Linux in VWs Einzug hält, ist derzeit offen.

Heise-Meldung:
http://www.heise.de/newsticker/meldung/103552

Nähere Erläuterung zur CAN-Integration
http://lwn.net/Articles/253425/