Embedded-CAN-Steuerung Fortschritte bei der internen Kommunikation

Die Kompatibilität von Maschinen untereinander und der Datenaustausch zwischen industriellen Antrieben und ihren Steuerungseinheiten ist heute ein wichtiges Thema. Immer mehr ist auch eine Integration in Fertigungssysteme auf Ethernet-Basis mit hohem Echtzeit-Verhalten sowie in Enterprise-Systeme gefragt.

Anbieter zum Thema

PFLITSCH GmbH & Co. KG

compmall GmbH

MicroControl GmbH & Co. KG

Renesas Electronics Europe GmbH

Die Embedded-Kommunikation innerhalb der eigentlichen Maschine wird oft übersehen, da sie offensichtlich eine zu profane Rolle spielt und – anscheinend vor allem – weil die Kommunikation innerhalb der Maschine keinerlei Verkaufsargumente liefert. Falls die Embedded-Kommunikation zur Sprache kommt, bewerben die Halbleiterlieferanten diese mit frei verfügbaren Softwarepaketen (Stacks/Profile), die auf den eigenen Mikrocontrollern ausgeführt werden. Letztendlich stellt sich die Frage, ob es sinnvoll ist, mindestens 30 KByte wertvollen Codespeichers bereitzustellen, um mit einem anderen Aktuator oder einem Sensor zu kommunizieren? Für weitere Optimierungen muss der Entwickler die Feinheiten dieses Protokolls erlernen. Und ist dann diese Software wirklich kostenlos, wenn man so weit vordringt, dass man den Quellcode benötigt?

Das sollte bei Standardschnittstellen wie CAN, I²C oder UARTs nicht der Fall sein, die überall auf 8-, 16- und 32-Bit-Mikrocontrollern verfügbar sind, so dass eine kostengünstige und codeeffiziente Kommunikation zwischen mehreren Knoten möglich wird. Natürlich teilen sich all diese seriellen Standardschnittstellen keinen standardisierten Application Layer, wodurch potenzielle Stolperfallen für den Austausch von Daten zwischen mehreren Knoten entstehen. Nun müssen die Entwickler entscheiden, ob sie ihr eigenes proprietäres Protokoll entwickeln wollen und die beträchtlichen Herausforderungen beim Netzwerkdesign in Kauf nehmen, die sich dabei unweigerlich ergeben. Oder sie setzen eine standardisierte Anwendungsschicht wie DeviceNet oder CANOpen ein, die auf die Anforderungen der eigenen Anwendung zugeschnitten werden kann. Bei diesen besteht sogar die Möglichkeit, spezifische Anforderungen der Anwendung exakt passend zurecht zu schneiden, also ungenutzte Elemente zu entfernen, wie dies beispielsweise bei MicroCANOpen der Fall ist.

Exakt an dieser Stelle sticht CAN unter den seriellen Schnittstellen heraus, denn hier gibt es Standards. In der Praxis bedeutet das, dass die Hausaufgaben bereits gemacht wurden, dass Garantien verfügbar sind bezüglich der Compliance (Übereinstimmung) des Produkts und seiner Interoperabilität mit Produkten von Drittanbietern. Der vielleicht wichtigste Aspekt für den Entwickler ist jedoch die Tatsache, dass Entwicklungswerkzeuge sowie Unterstützung durch Experten von den unteren Ebenen bis ganz hinauf zur Anwendungsebene (Application Layer) verfügbar sind.

Standard-Protokolle setzten sich durch

Derartige Standard-Protokolle haben eine immer größere Bedeutung bekommen seit CAN vor mehr als einem Jahrzehnt begann, sich ausgehend vom Automobil auch in industriellen Anwendungen zu verbreiten. Mittlerweile ist CAN in einer Vielzahl von Anwendungen zu finden: von Antrieben über Fahrstühle bis zu Druckmaschinen reicht das Spektrum und selbst in Kaffeemaschinen ist CAN anzutreffen, denn überall dort sind mehrere Mikrocontroller vorhanden, die miteinander kommunizieren müssen.

Bei industriellen Antrieben und Regelungen bzw. Steuerungen hängt die Auswahl der MCU vor allem von der Konfiguration der Anwendung selbst ab. Diese Konfiguration kann durchaus von der Performance abhängen, die ein Motorsteuerungsprozessor und ein separater Systemprozessor jeweils benötigen. Hier wird der größte Teil der Anwendung ausgeführt sowie alle Funktionen der Anwenderschnittstelle und der Kommunikationssteuerung. Vereinfacht gesagt geht es hier darum, was die 32-Bit-MCU und was die 8-Bit-MCU erledigen soll – und zwar auf Basis der Funktionalität des Endprodukts sowie unter dem Gesichtspunkt, auf welche Art und Weise Leistungsmerkmale wie Softstart, Auto-Tuning, Überspannungsüberwachung, Eigendiagnose, HMI, Hilfs-I/Os etc. optimiert werden können.

All diese Wahlmöglichkeiten erfordern, dass der Halbleiterhersteller eine gewisse Flexibilität bietet sowie eine Auswahl von 8- bis 32-Bit-Bausteinen im Programm hat, die allesamt die Peripherieelemente enthalten, die für die Zielanwendung erforderlich sind. Bei NEC Electronics wird diese Auswahl im Bereich der Anwendungen auf CAN-Basis jetzt erleichtert – und zwar mit einer kompletten Palette von anwendungspezifischen MCU-Familien von 8 bis 32 Bit, die (Mehrfach-)CAN-Schnittstellen enthalten.

CAN-Komplettangebot

Die neuste Generation der CAN-MCUs bietet eine hohe Verarbeitungsleistung mit einer leichten Programmierbarkeit. Die Hardware-Registerstruktur der Schnittstelle CAN ermöglicht einen strukturierten Zugriff mit Hilfe der Programmiersprache C. Die internen Ablaufsteuerungen der CAN-Controller-Hardware und die vorhandene Bufferstruktur verringern auch effektiv die Belastung der CPU beim Senden und Empfangen von Nachrichten. Außerdem nutzen sie den lizenzierten Bosch Transfer Layer, so dass zusätzlich sicher gestellt ist, dass die Erfinder von CAN mit eingebunden sind.

Je nachdem welcher Mikrocontroller ausgewählt wurde unterstützen NECs CAN-Bausteine 16, 32 oder 48 Message-Buffer pro Kanal, während sie bei 8 MHz CAN-Taktfrequenz (mit 8 TQ/Bit) eine Busfrequenz von 1 MHz ermöglichen. Bild 1 zeigt die Architektur im Überblick. Softwarekompatibilität über Bausteinfamilien hinweg bedeutet aber auch, dass der gleiche strukturierte Zugang auf C-Ebene immer wieder von neuem verwendet werden kann. Für jede Zustandsänderung sind Interrupts verfügbar – und zwar inklusive aller Fehler- und Warnzustände des Protokolls, Aufwachen, Senden und Empfangen. Außerdem lässt sich mit Hilfe einer programmierbaren Abkürzung zwischen RX (Empfang) und TX (Senden) leicht ein Selbsttest implementieren.

Auf der Empfangsseite ermöglichen die Bausteine es, auf leichte Art und Weise ankommende Nachrichtensequenzen mit Hilfe der RHL (Receive History List) im Rahmen eines Trace-Vorgangs nachzuverfolgen, und ein MBRB (Multi Buffer Receive Block) sorgt dafür, dass die gleiche Nachricht mehrere Male empfangen werden kann ohne dabei die CPU zu stören. Jeder Pufferspeicher verfügt über einen Individual-Overwrite-Modus, wodurch das Software-Polling oder die Unterstützung für Reaktionen auf Interrupts für jeden Pufferspeicher individuell verfügbar ist.

Einfache Programmierung, verbesserte Diagnose

Beim Sendevorgang fällt die Belastung der CPU ebenfalls geringer aus, indem sämtliche für die effektive Übertragung großer Datenblöcke erforderlichen Interventionen entfernt werden. Eine THL (Transmit History List) stellt auch hier sicher, dass sämtliche ausgehenden Nachrichtensequenzen im Rahmen von Trace-Vorgängen leicht nachverfolgbar sind. Einige CAN-Varianten unterstützen auch eine verbesserte Diagnose. Dabei besteht die Möglichkeit, Nachrichten von einem wählbaren Kanal auf einen neuen Kanal zu spiegeln sowie Nachrichten zu überwachen.

Sämtliche MCUs von NEC Electronics, die über einen CAN-Controller verfügen, sind in Bezug auf ihre ISO-16845-Konformität zertifiziert und weisen in vielen Automotive- und Industrie-Anwendungen eine erprobte Stabilität auf. Die folgende Liste beschreibt die aktuellen Mikrocontrollerfamilien, die diese CAN-Schnittstellen enthalten:

• S-Serie

32-Bit-MCU-Familie, 32 MHz, 43,5 MIPS mit bis zu zwei CAN-Schnittstellen. Diese Bausteine enthalten bis zu 1 MByte Flash, 60 KByte RAM, einen 10-Bit-A/D-Wandler mit bis zu 16 Kanälen sowie synchrone und asynchrone Schnittstellen. Versorgungspannung: 2,8 bis 3,6 V.

• R-Serie

32-Bit-MCU-Familie, 64 MHz, 73,5 MIPS mit bis zu zwei CAN-Schnittstellen. Diese Bausteine enthalten bis zu 256 KByte Flash, 16 KBit RAM sowie bis zu acht unabhängige DMA-Kanäle. Versorgungspannung: 4,0 bis 5,5 V.

• F-Serie

a) 8-Bit-MCU-Familie, 20 MHz, eine CAN-Schnittstelle, 128 KByte Flash, 7 KByte RAM und ein 10-Bit-A/D-Wandler mit bis zu 16 Kanälen. Großer Versorgungspannungsbereich von 1,8 bis 5,5 V.

b) 32-Bit-MCU-Familie, 32 MHz, 43,5 MIPS mit bis zu fünf CAN-Schnittstellen. Die Bausteine enthalten bis zu 1 MByte Flash und 60 KByte RAM sowie einen 10-Bit-A/D-Wandler mit bis zu 24 Kanälen. Versorgungsspannung: 3,5 bis 5,5 V.

• D-Serie

32-Bit-MCU-Familie, 24/48/64 MHz, max. 73,5 MIPS mit bis zu zwei CAN-Schnittstellen sowie maximal 2 MByte Flash und 60 KByte RAM, ein 10-Bit-A/D-Wandler mit bis zu 16 Kanälen, ein LCD-Controller sowie maximal sechs dedizierte Schrittmotor-Treiber.

NECs 0,15-µm-Flash-Prozesstechnologie unterstützt die Selbstprogrammierung. Emulatoren sowie eine auf dem Chip integrierte Debugging-Einheit verkürzen die Entwicklungsdauer. Die Technologie bietet unterschiedliche Spannungsbereiche von 1,8 bis 5,5 V und ermöglicht den Einsatz bis Temperaturen von 125 °C unter den gesetzten Qualitätsanforderungen. Bekannte Peripherieelemente wie Universal-Timer, D/A-Wandler, Sicherheitsfunktionen, andere Kommunikationsschnittstellen sind selbstverständlich mit integriert. Flexibilität, Geschwindigkeit, Übertragungssicherheit und codeeffiziente Übertragung mit Hilfe des CAN-Protokolls sind ein gemeinsamer Nenner aller CAN-MCUs von NEC Electronics als Mitglied von CiA (CAN in Automation). Das Unternehmen ist auch zertifiziert, um CAN-Konformitätstests nach ISO 16845 in Kooperation mit dem CAN-Testhaus C&S durchzuführen.

*Steve Norman ist Assistant Manager Industrial Application Marketing bei NEC Electronics Europe, Düsseldorf.

(ID:206723)