Erfahrungsbericht: Hausbus mit Atmel AT90CAN Knoten

Projektrahmen und -konzept, Hardware, Benutzerschnittstelle

Einleitung
Projektzusammenfassung
Das vorliegende Dokument
Hardware: Netz und Knoten
Datenbus
Anwendungsknoten
Knotenrechner
Entscheidungskriterien für AT90CAN
Benutzerschnittstellen
Tasten und Tastenfelder
Touchpanel Display
Werkzeuge
Schaltungen, Entwicklung der Platinen
Programmentwicklung
Zusammenfassung, Erfahrungen

Einleitung

Projektzusammenfassung

Mein heutiger CAN (AT90CAN128 Knoten) basierter Hausbus ist die zweite Generation einer  bus-basierten Hauselektronik  Infrastruktur.  Sie wurde als Freizeitprojekt und für meine spezifischen Anforderungen in der Automation meines Heims (und Gartens) entwickelt. Wesentliche Kriterien waren und sind:
Als erste Generation verwirklichte ich vor ca 15 Jahren einen aus ganz wenigen Knoten bestehender RS485 Bus mit einem einfachen Protokoll mit seriellen Datenpaketen (Motorola HC11, Assembler programmiert). Die Entwicklung  der heutigen Lösung (CAN, avrlibc / avrdude) begann vor mehr als drei Jahren. Eine Vorstufe verwendete ausschliesslich Laborplatinen mit einer kommerziellen Huckepack-Platine, die den AT90CAN128 Mikroprozessor dem 1/10 Zoll Raster Raster anpasste (es war im wesentlichen eine Machbarkeitsstudie), die endgültige Version verwendet eine dafür entwickelte Knotenplatine (2-lagig), die sowohl als unabhängiger Knoten als auch als Huckepack-Platine für eine Laborplatine verwendet werden kann (Anwendungsschaltungen sind verdrahtungsmässig nicht sehr aufwändig, Herstellen anwendungsspezifischer Platinen wäre in Anbetracht der geringen Stückzahl übermässig teuer und aufwändig - bei der kleinen Vielzweckplatine mit dem TQFP-64 Prozessor liegt diese Überlegung genau umgekehrt). Eine Ausnahme hierzu ist die Rasenberegneranwendung - für sie habe ich eine Platine anfertigen lassen, denn sie ist sehr Verdrahtungsintensiv und ich brauchte mehrere Exemplare.

Zur Programmierung wurde von Anfang an C mit avrlibc eingesetzt, als Programmierer verwende ich einen JTAG MK II mit Avrdude. Ich habe Avrdude aber sehr schnell durch ein graphisches Benutzerinterface (Frontend) ergänzt - das hat das Vorgehen beim Entwickeln und Programmieren einer Vielzahl von ko-operierenden Knotenanwendungen wesentlich vereinfacht: eine leistungsfähige "Produktionsumgebung" ist ein ganz wesentlicher Hintergrund für den Erfolg meines Systems und dessen relativ kurze Entwicklungszeit.

Das vorliegende Dokument

Meine Busumgebung ist als Projekt "im Alleingang" angelegt (vor drei Jahren gab es zwar schon einige Hobby Hausbus Projekte, ihre Zielsetzungen entsprachen aber nicht meinen Anforderungen). Ich hatte von Anfang an reichlich interne Dokumentation geschaffen, aber nie eine Veröffentlichung oder eine Webseite ins Auge gefasst.  Zurzeit ist eine neue Generation von Projekten im Entstehen. Die für meine Anwendung entwickelten Konzepte und Erfahrungen können hier hilfreich sein, dazu soll die vorliegende Dokumentation beitragen. Dieses Dokument wurde in ein paar Stunden unter Benutzung bestehender interner Dokumentation erstellt, es ist eine Art Schnellschuss - ich habe wenig Zeit: die Gliederung des Dokuments ist wenig elaboriert, Photos wurden wenig gepflegt, und Texte wurden nicht von französisch auf deutsch übersetzt (meine Umgebung spricht französisch).

Dieses html Dokument ist der erste von zwei Teilen, ein zweiter Teil über die entwickelte Software ist geplant.

Diese Beschreibung ist als eine web-fähige Dokumentation ausgelegt, die ich ohne gegen Regeln zu verstossen auf unseren Institutsserver legen kann. Falls darüber eine Diskussion anfängt, sollte sie im Hausbusforum von http://www.mikrocontroller.net/ geführt werden.

Hardware: Netz und Knoten

Datenbus

Die Verdrahtung meines Netzes benützt Kategorie-5 Kabel, die beim nachträglichen Einbau einer Einbruchsmeldeanlage als Reserve mitverlegt worden waren. Diese Verdrahtung geht in die Nähe aller "strategisch wichtigen" Punkte des Hauses, geht aber nicht direkt zu den 235V Einrichtungen (ausser in Nebenräumen in Keller Dachgeschoss und Garage). Die genaue Länge im Haus habe ich nicht gemessen (der Bus geht ziemlich zick-zack und durch drei Stockwerke), sie wird etwas über 50 Meter betragen, mit zusätzlich ca. 50 Meter für den Sekundärbus im Garten.

Anwendungsknoten

Die Hausbusknoten sind als kleine Subzentren konzipiert (Relais, Schütze, optoelektronische Schalter), von denen traditionelle Verdrahtung zu den kontrollierten Geräten geht - beim nachträglichen Einbau eines Hausbusses wahrscheinlich die einzige gangbare Lösung.

Eine Busverlängerung zu einem Schuppen im Garten (Steuerung von Gartenlampen und Pumpen für ein Biotop) ist mit einem CAN-CAN Koppler angehängt (AT90CAN129 - SPI -MCP2515): dies erlaubt den Gartenbus galvanisch mittels Optokoppler zu trennen. Diese Trennung hat ihre Probe bravourös überstanden: ich hatte einen Blitzeinschlag, der HiFi Anlage und Fernsehapparat getötet hat, der Bus überlebte ohne Schaden (es war noch der alte serielle Bus, die verwendete Schaltung habe ich beibehalten).

Der Bus (auch der Gartenbus) läuft mit 100 kBps. Die Stromversorgung für die Knoten erfolgt im allgemeinen von den vom am Knoten angehängten Geräten, bei Knoten ohne Spannungsversorgung (DCF Empfänger, Temperatursonde, LED/Tastereinheiten) wird 12V über das entsprechende Hausbussegment angeboten (die Knoten selber brauchen 5V, das erlaubt Spannungsabfall und Störungen bei der Busverzweigung zum so versorgten Knoten herauszuregeln). Zur Zeit gibt es 11 solche Knoten - jeder Knoten versorgt im Mittel 5 geschaltete Element und im Mittel 2 Taster.

Die folgende Abbildung illustriert ein paar Verbraucher im Garten - von rechts nach links der Anschluss für einen Springbrunnen im Biotop, ein Tastenfeld, und eine Leuchte; der dazugehörige Hausbusknoten ist in einem Schaltschrank (IP61) in einem ca 5 Meter entfernten Schuppen untergebracht.


Hier ist ein Bild des Inneren des Schaltschrankes im Gartenschuppen:

Die Trägerplatine mit dem Busknoten ist rechts oben (waagrecht) - sie ergänzt den Knotenrechner durch den 24V -> 5V Regler, einen 74HC541 zum Puffern der binären Eingänge, und den nötigen Schraubklemmenleisten. Der Ringkerntransformator erzeugt die 35V für eine Elektroventil für den Wasserzulauf ins Biotop, ganz unten links ist das Vorschaltgerät für die Gartenleuchte (ihr Vorgänger war im Leuchtenfuss - starb durch Verrosten).

Ein Knoten verdient ein paar Bemerkungen: ich verwende einen DCF Empfänger als Zeitbasis. Der Knoten der, diesen Empfänger betreibt, setzt alle Sekunden eine Meldung mit Zeit und Datum auf den Bus. Ich habe beobachtet, dass - z.B. im Sommer bei grossräumiger Gewitterlage - der Empfang für längere Zeit (Stunden) stark gestört sein kann. Die in diesem Knoten generierte Uhrzeit wird daher primär vom Quarz des Prozessors erzeugt, sie wird nach Empfang eines korrekten DCF Signals synchronisiert (gleitend: keine Sprünge). Um ein Davondriften der quarzgenerierten Zeit bei längeren Pausen der Synchronisierung zu vermeiden, eiche ich den Quarz: ich verwende ein Eichpolynom, mit dem - gewichtet nach dem jeweiligen Bit in der Echtzeituhr - ich Bits zusätzlich einspeise, bzw. unterdrücke. Das Eichpolynom ist im EEPROM des Knotens gespeichert und wird bei Neuprogrammierung nicht geändert (die gleiche Lösung verwende ich auch in anderen Knoten, bei der die Uhrzeit eine wichtige Rolle spielt - dadurch macht es nichts aus, wenn Timerknoten für eine Programmänderung kurz vom Netz geht).

Knotenrechner

Alle Knoten verwenden die gleiche Platine (44,5 x 55.5 mm - das passt gerade noch in eine Unterputz Dose). Diese Platine wurde als Vielzweckplatine konzipiert: die Hauptbestimmung ist ihre Verwendeung als Knoten für den Hausbus, sie soll aber auch als unabhängiger Mikroprozessor zur Steuerung noch nicht vorgesehener Anwendungen (nicht unbedingt am CAN Bus) dienen. Um die Flexibilität zwischen verschiedenen Einsatzarten zu gewähren, wurde beim Grossteil der Bestückung auf SMD Technik verzichtet. Ein- und Ausgabe geht über Pfostenleisten - diese sind im 1/10 Zoll Raster angeordnet um die Knotenplatine als Sekundärplatine auf einer Laborplatte einsetzen zu können. Es gibt Pfostenleisten für
Die Platine braucht eine geregelte 5V Speisung (entweder von der Pfostenleiste oder von der standard parallel Pfostenleiste - die Wahl der Quelle ist zu stöpseln - S1, links oben); die neueste Version (fertig, aber noch nicht getestet) hat Platz für einen zusätzlichen Speicher mit SPI (FRAM - gleich beschaltet wie ein externer EEPROM Speicher), ich  möchte  einige Anwendungen mit 64  kBit FRAM betreiben. Hier ist ein Photo der vorgestern gelieferten und bestückten neuen Version  der Platine (30 Stück für 228 Euro). Die Programmierung und Inbetriebnahme des FRAM - der SMD links oben - ist noch nicht in Angriff genommen.

Der Platz für einen DIL IC (U3) dient zur optionalen Aufnahme eines ULN2803 als Treiber für - z.B. - Relais und Schütze. Wenn solch ein Treiber eingebaut wird, müssen vorher die Verbindung zwischen Ein- und Ausgang getrennt werden (weiss umrahmt).

Entscheidungskriterien für AT90CAN

Die Entscheidung von Motorola (HC11 oder 12 Familie) auf Atmel umzusteigen wurde nach langem Suchen im Netz gefällt. Der ausschlaggebende Grund für diese Wahl war die Qualitäte und Intensität des Austausches von Erfahrungen und Ratschlägen zwischen Benutzern, (Avrfreaks, avr-chat@nongnu.org und avr-gcc-lst@nongnu.org) und die Unterstützung von avrlibc durch - ich nehme an Atmel. Zweiter wichtiger - aber erst zweiter - Grund war der Umfang und die Qualität der Funktionen, die ich gratis vom Prozessor bekomme. Meine ersten Gehversuche mit CAN machte ich allerdings mit einem MCP2515, sah aber schnell, dass ich mit einem AT90CAN besser fahre (ich habe auf den AT90CAN128 "standardisiert" weil ich mich auf eine einzige Knotenausführung beschränken will; der etwas höhere Preis der grossen Ausführung war mir den Luxus wert, keine Kapazitätssorgen zu haben - vor allem für RAM). Meine Anwendungen verwenden maximal 1/4 des verfügbaren FLASH Speichers. RAM ist theoretisch knapp, aber durch bewusstes Berücksichtigen dieser Grenze habe ich auch hier noch ziemlich grosse Reserven.

In ein CAN Hausbusprojekt zu investieren ist - was den persönlichen Zeitaufwand betrifft - eine einschneidende Entscheidung. Bei der Entscheidung für eine Architektur sollten bestehende Erfahrungen mit einer bestimmten Prozessorumgebung, aber auch ein paar Euro Unterschied beim Einkauf der Hardware als völlig sekundär abgetan werden.

Benutzerschnittstellen

Es gibt zwei Arten von Benutzerschnittstellen: (1) Tasten und Tastenfelder - auch mit LED Zustandsanzeige, und (2) Touchpanel LCD Bedieneinheiten. Ich habe bewusst die Steuerung durch einen PC ausgeschlossen: die Anlage muss ohne laufenden PC funktionieren (die PCs muss ich ausschalten können, ohne das Funktionieren des Hausbus zu beinträchtigen).

Tasten und Tastenfelder

Zu den Tasten ist wenig zu sagen - ausser dass ein gegebenes Gerät durch beliebig viele Tasten gesteuert werden kann, und dass Tastenkontrolle und Displaykontrolle einander nicht ausschliessen. Die folgende Abbildung zeigt ein als Unterputzdose aufgebautes Tastenfeld mit LED Statusanzeige (Selbstbau auf Basis Leerdose, die Knotenplatine ist in der Dose untergebracht).


Touchpanel Display

Die Displayeinheit besteht aus einem Knotenrechner und einem mittels SPI angeschlossenen eDIP 240 (240 x 128 Pixel mit Touchpanel). Dies ist eine ziemlich teure Lösung - aber ungeheuer angenehm zu nutzen - ich erwäge sogar den Ersatz durch die etwas grössere 320 x 240 Ausfḧrung (noch teurer) - es ist schwierig alle nötigen Schaltflächen und Texte in 240 x 128 Pixel unterzubringen. Auch wenn ich - aus Kostengründen - zurzeit nur eine Einheit verwirklicht habe, sieht das Konzept die Koexistenz mehrer solcher Einheiten vor (weil jede Einheit die Konfiguration ändern kann ist eine Token-basierte Exklusivitäts-Reglung vorgesehen). Da diese Einheit auch nur ein Netzknoten ist, kann sie während des Urlaubs leicht von ihrem normalen Standort im Haus in die Garage verpflanzt werden damit sie meine hilfreichen Geister bedienen können.

Die Displayeinheit hat drei wesentliche Aufgaben:
Ein paar Bildschirmphotos erläutern diese Schnittstelle. Das erste davon zeigt den Ruhebildschirm und die drei durch ihn zugänglichen Funktionsmodi: (1) Geräte ein- und ausschalten, (2) Programmierung, (3) Zustandsanzeige.


Die nächsten beiden Beispiele illustrieren die Schalterfunktion: das linke zeigt, dass nur die Schuppenlampe eingeschaltet ist (für eine Zustandsänderung muss zunächst eine Schaltfläche gewählt, und dann mit "On" oder "Off" ausgelöst werden), das rechte zeigt ein Gerät (Rasenberegnung), das sich nach einer bestimmten Zeit automatisch abschalten wird.


Die folgenden zwei Bilder erläutern der Programmierfunktion. Das linke zeigt, wie aus der Liste aller definierten Ereignisse eines zum Editieren ausgewählt wird (für jedes Ereignis erscheint der Zeitpunkt, die Aktion und der Name des Gerätes - ein "Minus" Zeichen bedeutet, das am gegenwärtigen Tag das Ereignis nicht geplant geplant oder unterdrückt ist - auswählen durch Berühren der entsprechenden Fläche); das rechte illustriert den Ereigniseditor:


Das letzte Bild zeigt eine Verwaltungsfunktion, mit deren Hilfe man abfragt, welche Knoten am Netz existieren (das Bild zeigt nicht alle Knoten, die ich momentan habe) und welche Programme jeweils geladen sind. Für normal haben die Knoten unterschiedliche Versionen und Erstellungsdaten - die hier sichtbare Uniformität ist Folge eine Diskussion im Mikrocontroller.net Hausbusforum: sie hat mich auf einen Fehler in meinem Protokoll aufmerksam gemacht (ein Fehler der sich bisher nie manifestiert hat, aber der mit sehr geringer Wahrscheinlichkeit auftreten könnte); dessen Behebung hat Neuladen aller Knoten erfordert. Dieses Bild zeigt auch, dass - ich verwende keinen Bootstrap über das Netz sondern lade mit JTAG - eine volle Neukonfigurierung aller Knoten ca. 1 Stunde Arbeit ist.

Dieses Thema muss dringend ausgebaut werden: ich möchte nicht nur die anwendungsbedingte logische CPU ID kennen (die wird angezeigt), sonder auch wissen welche physische CPU montiert ist, ich möchte den Stand eines Bootstrap-Zählers kennen und wissen wann der Knoten das letzte Mal hochgefahren ist - das sollte ich in den nächsten Tagen erledigen (aber Eile mit Weile: ich habe in einem langen Informatikerleben gelernt, dass Versionen Zeit brauchen bis man ihrer sicher ist - "Versionshektik" ist gefährlich).

Ähnlich - und das fehlt noch vollkommen- möchte ich gerne Aussagen über die Gesundheit des CAN-Bus haben: nicht erkannte Meldungen (Anwendungsebene) loggen, CAN Fehlermeldungen analysieren und loggen. Es ist zwar grossartig der Meinung sein zu können, dass mein System ohne jeden Fehler läuft, aber diese Aussage sollte nicht auf den Beobachtungen des Benutzers beruhen, sondern auf gemessenen Daten.

Werkzeuge

Schaltungen, Entwicklung der Platinen

Ich bin ein Linux Benutzer und verwende Geda Werkzeuge: gschem zum Zeichnen, PCB für den Entwurf der Platine (gschem liefert eine Datei mit einer "Netzbeschreibung", die von PCB gelesen wird und der Erkennung von Fehlern im Platinenentwurf dient) - sehr empfehlenswert: gut dokumentiert, leicht zu verwenden und zu lernen, kostet nichts, und die erzeugten Daten können direkt an Layoutfirmen geschickt werden.

Programmentwicklung

Ich habe mich für Programmieren in C und die avrlibc Bibliothek entschieden. Für das Laden der Objektdateien verwende ich einen JTAG MKII Programmierer und das avrdude Programm. Alle meine Knotenpogramme enthalten einen Uart Modul, damit können Meldungen - z.B. mittels printf - über die serielle Schnittstelle an einen Terminalemulator (ich verwende das Minicom) geschickt werden. Das ist ein wenig barbarisch, reicht aber (diese Methode ist allerdings in einer Echtzeitumgebung mit parallelen Ereignisabläufen mit Bedacht zu verwenden). Natürlich habe ich für die Entwicklung einen eigenen kleinen Bus (ca. 5 Knoten), Programmerweiterungen gehen nur nach sorgfältiger Prüfung "in Produktion".

Ich habe mich sehr schnell an den praktischen Grenzen eines zeilengesteuerten Programmierwerkzeugs (avrdude) gestossen und ein GUI Programm dafür geschrieben ("Avrgui", auf Basis Perl - Tk, Gliederung in Tk-Notebook Seiten). Das ist nicht nur ein Vergnügen beim Verwenden, es ist meiner Meinung nach eine ganz wesentliche Voraussetzung für die Produktivität bei der Entwicklung und das sichere Meistern der Programmierung mehrerer ko-operierender Prozessoren. Die folgenden Bilder illustrieren die Vorteile dieses Ansatzes.

Das erste Bild spricht für sich selbst: diese Notebook-Seite dient dem Laden und Holen von Objekt-Kode.

Die zweite dem direkten Umgang mit dem Objekt-Prozessor gewidmete Seite dient dem Zugriff auf Speicher und auf Register des Prozessors


Alle anderen Seiten dienen dem Projektmanagement:
Der letzte Punkt (Parametrisierung) ist besonders wichtig: viele Aktoren sind einander sehr ähnlich, unterscheiden sich nur über ein paar Eigenheiten in der Eingabe/Ausgabe und in den Adressen der anzusteuernden Geräte und Bits. Für eine Gruppe ähnlicher Aktoren gibt es daher nur ein Programm und nur eine Projektdatei; vor dem Laden kann Avrgui eine Neugenerierung der Objektdatei aufrufen (mithilfe des Make Werkzeuges von Unix) und dabei Parameter zur Individualisierung festlegen und in den generierten und geladenen Kode einbauen. Das vereinfacht die Programmentwicklung ungeheuer, wäre mit dem zeilengesteuerten Avrdude (oder mit Skripts) sehr mühsam und anfällig auf Benutzungsfehler. Das folgende Bild zeigt, wie einfach das mit Avrgui ist:  der Parameter  "DEVICE_PARAM" wird auf "GARDEN_COUPLER" gesetzt, die automatische Programmgenerierung vor dem  nächsten Laden wird somit den Aktor mit dem so gewählten Parameter generieren (im Quellkode gibt es entsprechende #if - #endif Blöcke).


Zu diesem Konzept gehört natürlich auch eine vernünftige Strukturierung der Projektverzeichnisse - der Datei-Baum sieht bei mir so aus

.../canbus/code/share/...
hier liegt der Quellkode aller Bibiliotheksprogramme, sowie die Dateien für die Definitionen von Konstanten und Datenstrukturen (xxx.h Dateien), die für alle Knoten gleich sind;
.../canbus/code/timer/...
diese Datei enthält (a) alle für den Timer Knoten spezifischen Quellprogramme, (b) die Daten für die Individualisierung von Avrgui für diesen Knoten (.avrguirc) und (c) Verknüpfungen zu den relevanten Bibliotheksdateien und Definitionen im Verzeichnis "share";
und so fort für alle Knotendateien.

Diese Beschreibung geht (zu?) weit ins Detail, aber die Bedeutung eines soliden Konzepts erscheint mir sehr wichtig - und wird noch wichtiger wenn das Projekt wächst und mehrere Entwickler daran arbeiten. Diese Art Struktur eignet sich auch als Grundlage für eine Projektverwaltung mit z.B. cvs (ein Korsett das ich ungerne verwende).

Zusammenfassung, Erfahrungen

Meine Anwendung läuft in ihre jetzigen Form seit mehr als 2 1/2 Jahren zu voller Zufriedenheit. Ich hatte nie ernsthafte Probleme gehabt (ganz wenige Male - z.B. in der Display Einheit - sind Programmierfehler erst im Betrieb sichtbar geworden). Abgesehen vom Echtzeitrahmen (siehe unten) wüsste ich nicht, wie es besser zu machen wäre; die Wahl der Hardware ist richtig (wenn ich morgen neu anfinge, würde ich genau die gleiche Wahl treffen). Ich habe nie Hinweise auf Dysfunktionen des Netzes (z.B. Neustart von Knoten, schlechte Antwortzeit) beobachtet, nach Störungen in der 235 V Versorgung gab es nie Probleme - aber, wie weiter oben erwähnt, sollte ich hierzu ein paar Daten sammeln.

Der grosse Punkt, der mich besorgt macht, ist der Ein-Mann Rahmen: was passiert, wenn ich morgen einen schweren Autounfall habe? Ein paar Fragen haben heute positive Antworten: kann ich einen TQFP-64 auflöten? (Antwort: ja, bisher gab es keinen Verschnitt), komme ich ohne ein Oszilloskop aus (Antwort ja, ein Vielfachmessgerät und und ein paar Prüf-LEDs tun es auch).

Natürlich gibt es eine lange Wunschliste von zu machenden Erweiterungen:

juergen.harms@unige.ch
10. 2. 2011