Entwicklung einesEthernet-auf-CAN-Adapters auf Basis des

Atmel ATmega128 Microcontrollers

Projektarbeit an der Universität Kassel

Fachbereich Elektrotechnik/InformatikFachgebiet Verteilte Systeme

Abteilungsleiter: Prof. Dr. Kurt Geihs

vorgelegt von:Andreas Witsch und Florian Seute

Kassel, den 13.02.2008

Betreuer:Dipl. Inf. Philipp BaerDipl. Inf. Roland Reichle

Zusammenfassung:

Einen Schwerpunkt der Forschungsaktivität des Fachgebietes Verteilte Systeme an derUniversität Kassel bilden autonome verteilte Systeme. Zur Evaluierung neu entwickelterAnsätze dient ein Team von Fußball-Robotern, das im Rahmen des RoboCups auch an in-ternationalen Wettbewerben teilnimmt. Da ein Roboter während eines Spiels häufig Stößenund anderen Einflüssen wie z. B. elektrostatischer Aufladung ausgesetzt ist, ist eine mög-lichst unempfindliche und zudem effiziente Anbindung der Hardware-Steuereinheiten andie zentrale Recheneinheit unbedingt erforderlich.Im Rahmen dieses Projektes wurde deshalb eine Platine entwickelt, die es ermöglicht,mittels eines verbindungslosen Protokolls (UDP) via Ethernet mit Steuereinheiten überController-Area-Network(CAN) oder eine serielle Schnittstelle zu kommunizieren. Dabeiwurde besonders auf Latenzzeiten, sowie auf hohe elektrische Unempfindlichkeit gegen-über äußeren Einflüssen Wert gelegt. Durch diese Kommunikationsschnittstelle ist es auchmöglich, unkompliziert weitere Hardware anzubinden.

Abbildung 0.1: 3D Platinenmodell

ii

Inhaltsverzeichnis

1 Einführung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Verfügbare Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Lösungsansatz 42.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Die wichtigsten Bauteile . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Verschaltung der Bauteile . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Platinenlayout und Herstellung . . . . . . . . . . . . . . . . . . . . . 72.1.4 Verwendung im Roboter . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Erforderliche Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Netzwerkstack uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 CAN-Anbindung mit MCP2515 . . . . . . . . . . . . . . . . . . . . . 132.2.4 Lösungsweg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Ergebnisse 163.1 Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Versenden von Daten via UART . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Versenden von CAN-Nachichten . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Statusprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Tests 234.1 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Zusammenfassung und Ausblick 25

6 Anhang 26

I

1 Einführung

1.1 Motivation

Der Carpe-Noctem-Fussball-Roboter besitzt im Wesentlichen zwei Aktuatoren: einen Ki-cker und den Antrieb. Der Antrieb wird von einem Motorcontroller gesteuert, welcher dieMotoren der Räder regelt und über eine serielle Schnittstelle angesprochen wird. Da derals Steuereinheit verwendete Laptop nicht über eine serielle Schnittstelle verfügt, wird einUSB Adapter benötigt. Mit Hilfe eines geeigneten Treibers kann dieser Adapter wie einekonventionelle serielle Schnittstelle verwendet werden.Der zweite Aktuator ist der Kicker. Zur Ansteuerung dient ein Kickercontroller, der da-für verantwortlich ist, zunächst den drehbar gelagerten Pneumatik-Zylinder an die rich-tige Position zu bewegen und anschließend über Magnetventile die Luftzufuhr zu einemPneumatik-Zylinder und damit die Schussstärke zu regeln. Da auch der Kickercontrollerüber eine serielle Schnittstelle angesprochen wird, kommt hier ein zweiter USB-Adapterzum Einsatz.

Abbildung 1.1:USB-Seriell-Adapter

USB-Adapter haben jedoch zwei wesentliche Schwächen. ZumEinen ist ein USB-Stecker relativ empfindlich. Bei Erschütte-rung ist es möglich, dass die Verbindung unterbrochen wird.Der Treiber muss dann neu geladen werden, was zu einemStillstand des Roboters führt, da die Kommunikation mit derMotorsteuerung unterbrochen ist. Zum Anderen können dieUSB Adapter durch elektrostatische Aufladung, die sich auf-grund der Reibung der Räder auf dem Untergrund ergibt, unddie dadurch entstehenden Spannungsspitzen beschädigt wer-den. Eine Erdung des Roboters, die diesem Problem entgegen-

wirken könnte, ist jedoch nicht möglich.Eine weitere Motivation für diese Arbeit ist die Tatsache, dass sich neue Peripherie sehrleicht über einen Controller Area Network(CAN)-Bus ansteuern lässt und auch viele mo-dernere Motorcontroller über eine CAN-Anbindung verfügen.

1

1 Einführung

1.2 Aufgabenstellung

Wie im vorherigen Abschnitt diskutiert wurde, wird ein Adapter benötigt, der unempfind-lich gegenüber Erschütterungen und elektrostatischer Aufladung ist. Zusätzlich soll dieserfinanziell in das Budget des Teams passen. Dabei muss berücksichtigt werden, dass sechsRoboter mit jeweils einem Adapter ausgestattet werden müssen und mindestens zwei Er-satzadapter verfügbar sein sollen.Das bei diesem Projekt eingesetzte Notebook (Lenovo X60/X61) verfügt über verschiedeneSchnittstellen, die eine Ansteuerung ermöglichen würden. Aufgrund ihrer Unempflind-lichkeit gegenüber Erschütterungen und der Toleranz gegenüber kurzzeitigen Unterbre-chungen der Verbindung erscheint die Netzwerkschnittstelle als geeignet. Mit einer galva-nischen Trennung kann zudem auch ein guter Schutz gegen elektrische Einflüsse erreichtwerden. Die zu entwickelnde Platine wird demnach über eine Ethernet-Schnittstelle ange-steuert und bedient dahinterliegende Geräte über CAN-Bus oder eine serielle Schnittstelle.

1.3 Verfügbare Lösungsansätze

Es existieren bereits andere Entwicklungen mit Netzwerk-, UART1- und CAN-Unterstützung.Beispiele sind Ethernut [2] oder auch das AVR Ethernet Board [3].Speziell für das Ethernut-Board wurde ein eigenes Betriebssystem entwickelt, das bereitsüber Threads verfügt. Es hat jedoch den Nachteil, dass es relativ teuer und in der aktuellenVersion 3.0 nicht mehr verfügbar ist; die früheren Ausführungen verfügen zudem nichtüber eine CAN-Anbindung. Ein Problem beider Lösungsansätze ist, dass diese Platinennur begrenzt an die Größenbeschränkungen im Roboter angepasst werden können. Dar-über hinaus verfügen beide Platinen über Bauteile, die für unsere Aufgabenstellung nichtrelevant sind, wie z.B. einen SD-Karten-Leser. Dies zeigt, dass die Eigenentwicklung einerPlatine offenbar der beste Lösungsansatz ist. Es stehen verschiedene Bauteile für die Plati-ne sowie die Realisierung von Netzwerk-Stacks zur Verfügung.Für diesen Zweck gibt es ein breites Spektrum von Microcontroller-Familien. Die wich-tigsten Hersteller sind hier Texas Instruments, Atmel und Microchip. Die Wahl fiel auf den

1Universal Asynchronous Receiver Transmitter, bezeichnet das Datenübertragungsverfahren der seriellenSchnittstelle

2

1 Einführung

ATMega128 von Atmel, da dieser zum Einen über die notwendige Rechenleistung verfügt,zum Anderen auch auf den Ethernut- und AVR-Boards verbaut wurde. Dadurch standenbereits Schaltplanvorlagen sowie Beispielimplementierungen für Ethernetkommunikationzur Verfügung.Für die Ethernetverbindung kommen zwei erprobte Bauteile in Frage: Der Microchip ENC28J60und der Realtek RTL8019AS. Der ENC28J60 hat den Vorteil, dass er über den SPI-Bus (Seri-al Peripheral Interface Bus) angesteuert werden kann, wodurch lediglich drei Verbindun-gen notwendig sind. Leider sind nur recht wenige Beispiel-Projekte im Internet verfüg-bar, weshalb dem RTL8019AS der Vorzug gegeben wurde, der ebenfalls auf dem AVR-Ethernet-Board verwendet wird.Dies vereinfachte auch die Wahl des IP-Stacks. Es gibt einige Implementierungen für Mi-crocontroller, allerdings nur zwei Stacks, die auch schon mit einer Hardwareconfigurationgetestet wurden, die unserer ähnlich ist. Dabei handelt es sich um Nut/Os [2], das Be-triebssystem des Ethernuts. Jedoch ist dieses relativ groß und viele Funktionalitäten wieThreads sind für unsere Zwecke nicht notwendig. Für die Alternative, den uIP [8], gibt esbereits einen fertigen Treiber für den RTL8019AS, sowie Beispiel-Implementierungen füru.a. kleine Web- oder DNS-Server.

3

2 Lösungsansatz

2.1 Hardware

Im Folgenden wird die Hardware, ihre einzelnen Komponenten und deren Verschaltungbeschrieben. Sie lässt sich in vier Teile gliedern: Den Prozessor, Ethernet, CAN und serielleSchnittstelle.Anfänglich sollte die Platine noch über drei serielle Schnittstellen verfügen, um die Mög-lichkeit zu haben, drei Motorcontroller ansteuern zu können. Der ATMega128 kann je-doch nur zwei serielle Schnittstellen betreiben, weshalb ein weiterer Microcontroller –ATMega48 – verwendet wird, der bei Bedarf aufgelötet und programmiert werden kann.Im Laufe der Entwicklung wurde jedoch deutlich, dass diese zusätzlichen Schnittstellennicht mehr benötigt werden, da die Roboterperipherie per CAN-BUS kommuniziert.

2.1.1 Die wichtigsten Bauteile

ATMega128

Wichtige Kriterien für die Auswahl des Prozessors ist die Taktung, der Speicher und dieAnzahl der Ein-/Ausgänge. Da die Größe des finalen Programmcodes bei der Wahl derBauteile noch unbekannt war, war es hilfreich, sich an der Codegröße des uIP-Stacks zu ori-entieren, der etwa 8kB Speicher benötigt. Der Flashspeicher sollte daher mindestens 16kBumfassen, um genügend Spielraum zu lassen. Auch der Bedarf des Arbeitsspeichers warschwer abzuschätzen. Zum Betreiben des RTL8019AS sind 20 I/O-Pins notwendig, sechsI/O-Pins sind für den CAN-Bus und vier für die RS232 Schnittstelle eingeplant worden.Darüber hinaus ist eine Status LED, zur einfachen Überwachung des Controllers vorge-sehen. Großzügig abgeschätzt werden ca. 32 I/O-Kanäle benötigt. Der ATMega128 bietethierfür genügend Ressourcen. Es stehen zudem ausreichend Reserven zur Verfügung, umeventuelle Änderungen realisieren zu können. Ohne die seriellen Schnittstellen würdensogar die Ressourcen des ATMega32 ausreichen, der nur noch ca. vier Euro kostet.

4

2 Lösungsansatz

RTL8019AS

Der RTL8019AS ist ein NE2000-kompatibler1 Netzwerkchip, der in vielen ISA-Netzwerk-karten zum Einsatz kam. Dieser Netzwerkchip bekam, gegenüber den im Abschnitt 1.3beschriebenen Alternativen, den Vorzug, weil es schon viele andere Projekte mit diesemChip gibt. Diese können als Hilfestellung herangezogen werden. Der RTL8019AS ist zwarnoch im Internet erhältlich, wir haben uns aber aus Kostengründen dafür entschieden, ihnvon gebrauchten ISA-Netzwerkkarten zu abzulöten.Um solche SMD-Bauteile möglichst einfach von einer anderen Platine herunter löten zukönnen, sägt man sie großzügig heraus und legt sie auf ein altes Bügeleisen. Nach nur we-nigen Sekunden lassen sich die Bauteile mit einer Pinzette herunternehmen.Der Chip eignet sich besonders gut, weil er noch den ISA-Bus unterstützt. Neuere Chipsverwenden den neueren PCI-Bus, der von einem Microcontroller nicht ohne weiteres an-gesteuert werden kann.Der ISA-Bus besteht aus 20 Adressleitungen, acht Datenleitungen und deren Steuerlei-tungen. Somit ist die Ansteuerung des RTL8019AS sehr einfach. Es genügen uns für dieVerwendung des RTL8019AS die ersten fünf Addressleitungen. Um Ein-/Ausgänge amMicrocontroller zu sparen, sind die restlichen Adresspins des RTL8019AS an GND an-geschlossen und so immer auf „0“, d.h. es können nur die unteren 32 Byte addressiertwerden. Da sich hier aber alle benötigten Register des RTL8019AS befinden, ist dies zurAddressierung ausreichend.Zusätzlich ist noch das READ-, WRITE- und RESET-Signal des RTL8019AS, sowie die achtAddressleitungen mit dem Microcontroller verbunden. Der RTL8019AS benötigt zudemeinen Takt von 20MHz, der mit einem SMD-Quarz erzeugt wird und ebenfalls extern an-geschlossen werden muss.

MCP2515

Die Wahl des CAN-Controller-Bausteins fiel auf den MCP2515, weil einerseits schon Pro-jekte2 mit diesen Controller zu finden sind und er andererseits sehr einfach über den SPI-Bus an den ATMega128 angeschlossen werden kann, wie in Abbildung 2.1 zu sehen. Dafürsind nur vier Leitungen nötig. Außerdem ist der MCP durch Interrupt- und Reset-Pin mitdem ATMega verbunden.

1http://de.wikipedia.org/wiki/NE20002http://www.kreatives-chaos.com

5

2 Lösungsansatz

Abbildung 2.1: SPI Stern VerbindungQuelle: http://de.wikipedia.org/wiki/Serial_Peripheral_Interface

Der SPI-Bus ist ein synchroner, serieller Datenbus und arbeitet nach dem Master-Slave-Prinzip. Bei diesem Prinzip hat der Master exklusive Schreibrechte auf den Bus, wärendSlaves nicht untereinander kommunizieren können. Es werden zwei Datenleitungen ver-wendet: Master-Out-Slave-In (MOSI) und Master-In-Slave-Out (MISO), was eine Full-Duplex-Kommunikation ermöglicht. Zusätzlich wird ein Taktsignal (SCK), sowie ein Chip Select-bzw. in diesem Fall ein Slave Select-Signal (SS) benötigt, mit dem der aktive Teilnehmer amSPI-Bus ausgewählt wird. Der MCP benötigt zur Pegelwandlung seiner Ausgangssignalefür den CAN-Bus einen Treiberbaustein. Dafür wurde auf der Platine der PCA82C250 ein-gesetzt.

6

2 Lösungsansatz

MCP2515RS232

ATmega128ATmega128 RTL8019ASRTL8019AS

8 Datenbits

5 Adressbits

RD, WR, RST

MISO, MOSi, SCK, CS, RST, INT

RXD0, TXD

0

RXD1, TXD

1

Abbildung 2.2: Verschaltung der Bauteile

2.1.2 Verschaltung der Bauteile

Der Schaltplan wurde zum großen Teil nach den Beispielschaltungen für CAN [14] undRTL8019AS [15] angefertigt und nach unseren Bedürfnissen angepasst. Dabei muss mandarauf achten, keine Pins doppelt zu belegen. Der RTL8019AS ist das einzige Bauteil, dasnicht auf bestimmte Ausgänge, wie den SPI-Bus angewiesen ist. Die verwendete Verschal-tung besteht daher aus der Minimalbeschaltung und verzichtet auf einen EEPROM oderzusätzlichen Speicher. Eine EEPROM-Emulation des RTL8019AS war zunächst zur Sicher-heit vorgesehen, da sie sich mit drei weiteren Widerständen ergänzen lässt. Es zeigte sichim Projektverlauf, dass die EEPROM-Emulation nicht benötigt, sondern die Hardware-adresse im Speicher des Microcontrollers abgelegt wird. Der Aufbau des Schaltplans ist inAbbildung 2.2 vereinfacht dargestellt.

2.1.3 Platinenlayout und Herstellung

Mit Kai Baumgarts Unterstützung erstellten wir den Schaltplan und das Layout wobei dieFolgenden Kriterien eingehalten wurden: Leitungen dürfen nicht in der Nähe von Quar-zen verlegt werden, da Quarze durch ihre hohe Frequenz elektromagnetische Störungenhervorrufen. Außerdem darf nur eine Seite der Platine mit Bauteilen bestückt werden, umein passendes Gehäuse finden zu können.Auch bei der Wahl der Stecker müssen verschiedene Möglichkeiten in Betracht gezogenwerden. Es ist möglich entweder Standardstecker für die entsprechenden Busse oder eige-

7

2 Lösungsansatz

Abbildung 2.3: Pinbelegung RS232

ne Verbinder einzusetzen. Die Standardstecker haben den Nachteil, dass drei platzeinneh-mende Sub-D Stecker auf der Platine untergebracht werden müssen. Stattdessen wird nurein Stecker verwendet, dessen Pin-Belegung jedoch keinem Standard3 mehr entspricht. DiePinbelegung des verwendeten Sub-D Steckers ist in Abbildung 2.3 dargestellt. Diese Dar-stellung zeigt auch die Belegung der dritten seriellen Schnittstelle. Beim Entwurf des Pla-tinenlayouts sind Fehler unterlaufen: Die Programmierschnittstelle des ATMega128 darfnicht mit dem SPI-Bus, sondern mit den gleichen Pins wie der ersten seriellen Schnitt-stellen verbunden sein. Zum Programmieren des Microcontrollers muss ausserdem derTreiberbaustein der seriellen Schnittstelle vom ATMega128 getrennt sein. Zur Umgehungdes Problems verwenden wir einen Jumper, bis ein neues Layout erstellt wird. Um denATMega128 zu programmieren, muss die Jumperverbindung getrennt sein, während dieVerbindung der seriellen Schnittstelle nur mit verbundenem Jumper funktioniert.Für den CAN-Bus wurde ebenfalls keiner der üblichen Stecker verwendet. Um andere

CAN-Teilnehmer mit Stromversorgen zu können muss der Stecker vierpolig sein für CAN-High, CAN-Low sowie Versorgungsspannung und Masse. Außerdem muss der Stecker er-schütterungsfest sein.Das Layout basiert größtenteils auf SMD-Bauteilen4, da der RTL8019AS nur als SMD-Bauteil lieferbar ist und die Platine so mit geringeren Abmessungen auskommt. Das Er-stellen des Schaltungslayouts erwies sich unerwartet schwer, da der Autorouter des Eagle-

3http://de.wikipedia.org/wiki/RS2324http://de.wikipedia.org/wiki/Surface_Mounted_Device

8

2 Lösungsansatz

RTL8019ASLaptop

ETH2CAN

Netzw

erk

CAN

Uart1

KickerMotion

Abbildung 2.4: Beispiel Anschlussmöglichkeit

CAD-Programms, mit dem die Schaltung und das Layout entworfen wurde, leider nichtdie gewünschten Ergebnisse liefert. Die Autoroutefunktion ermöglicht es nicht, alle Ver-bindungen überschneidungsfrei auf die beiden Seiten der Platine anzuordnen. Die gene-rierten Verbindungen sind nicht optimal verlegt und Bauelemente werden nicht automa-tisch verschoben. Das Fachgebiet Verteilte Systeme verfügt über kein anderes Werkzeug,dass diese Operationen automatisiert durchführen kann.

2.1.4 Verwendung im Roboter

Abbildung 2.4 zeigt eine mögliche Anschlusskonfiguration. Es können mehrere CAN-Teil-nehmer, sowie zwei serielle Schnittstellen benutzt werden. Die Platine wird mit einem Pat-chkabel am Laptop angeschlossen und mit den in Abschnitt 2.1.3 beschriebenen Kabeln andie Roboterperipherie. So dient die Platine als Datenrouter zwischen Laptop und Periphe-rie.

9

2 Lösungsansatz

2.2 Software

2.2.1 Erforderliche Software

Zunächst geben wir einen Überblick, mit welcher Software der Microcontroller program-miert und in Betrieb genommen werden kann. Alle folgenden Komponenten sind kosten-los verfügbar.

avr-gcc - Der avr-gcc ist ein Opensource-Compiler für Microcontroller der AVR Serie vonAtmel. Dieser steht, sowohl für Windows als auch für Linux, unter http://winavr.sourceforge.net/ zur Verfügung. Alternativ ist eine Version im AVR Studio eingebet-tet, das als Windowsversion von der Atmel-Webseite5 bezogen werden kann.

avr-libc - Bei der avr-libc handelt es sich um eine Version der libc, die für AVR entwickeltwurde. Sie bietet z.B. eine Implementierung der printf-Methode, sowie Definitionen für dieVerwendung von Ports und Registern. Diese kann unter folgender URL heruntergeladenwerden: http://www.nongnu.org/avr-libc/.

avr-binutils - Dieses Paket enthält u.a. den Linker zur Erstellung der AVR Hexfiles, dieauf den Controller geladen werden müssen. Das Paket ist ebenfalls auf http://www.nongnu.org/avr-libc/ erhältlich.

avrdude - Dieses Tool ist notwendig, um das vom avr-gcc compilierte Programm übereinen üblichen In-System-Programmer (ISP)6 in den Flashspeicher des Microcontrollers zuladen. Außerdem kann Avrdude verwendet werden, um die „Fusebits“7 des Microcon-trollers auszulesen bzw. zu beschreiben. Diese dienen zur Parametrierung der Microcon-trollerfeatures. Avrdude ist zu finden unter: http://download.savannah.gnu.org/releases/avrdude/

Burn-o-mat - Beim Burn-o-mat handel es sich um eine Java-GUI für Avrdude. Diese hilft,Fehler beim Setzen der „Fusebits“ zu verhindern, da ein falsches Setzen der Fusebits (z.B.auf eine falsche Taktquelle) den Microcontroller unbrauchbar machen kann. Der Burn-o-mat ist unter http://avr8-burn-o-mat.aaabbb.de/ zu finden.

5http://www.atmel.com/6http://de.wikipedia.org/wiki/In-System-Programmierung7http://www.wiki.elektronik-projekt.de/w/index.php/AVR_Fusebits_Tutorial

10

2 Lösungsansatz

2.2.2 Netzwerkstack uIP

Als IP-Stackimplementierung haben wir Adam Dunkels uIP ausgewählt. Dieser ist in derLage, IP-Pakete zu erzeugen und unterstützt das TCP-Protokoll und bringt auch ein Grund-konzept für das UDP-Protokoll mit. Der uIP Quelltext kann unter folgender URL herun-tergeladen werden: http://www.sics.se/~adam/uip/index.php/Main_Page/.Die Hauptziele bei der Entwicklung des uIP sind für den Entwickler Adam Dunkel, einer-seits geringen Speicherbedarf zu benötigen, um dadurch mit wenig Ressourcen einsetzbarzu sein. Andererseits sollen, nach seinen Angaben, dennoch die wichtigsten Standards desRFC 11228 eingehalten werden. Er betont jedoch auf seiner Webseite, dass er sich nur anden Standards orientiert hat. Das bedeutet zwar, dass die Protokolle grundsätzlich kom-patibel sind, aber, um Speicher zu sparen, erweiterte Architekturen nicht verwendet wur-den. Beispielsweise werden Checksummen nicht berücksichtigt. Außerdem ist das TCP-Protokoll nicht verbindungsorientiert aufgebaut, wie im RFC vorgesehen. Der IP-Stack istweitestgehend hardwareunabhängig und beinhaltet keine Implementierung für das Hard-warelayer. Das bedeutet, dass ein Treiber zum Versenden der generierten Pakete notwen-dig ist.Jedoch existiert bereits eine Implementierung, die wir für unsere Architektur verwendenkonnten. Dieser steht inklusive einer Beispiel-Webserver-Anwendung auf folgender Web-seite zur Verfügung: http://www.laskater.com/projects/uipAVRdownload.htm.Es muss die modifizierte Treiberversion von Volker Troyke verwendet werden, da die ur-sprüngliche Version des Treibers für die Verwendung von externem RAM vorgesehen war,der auf unserer Platine nicht vorgesehen ist.Um Speicher und Leistung zu optimieren, ist es möglich, den uIP-Stack weitgehend an dieeigenen Anforderungen anzupassen, z.B. durch Setzen der maximal Verbindungsanzahloder Weglassen von UDP Verbindungen.Der uIP weisst folgende Dateistruktur auf:uip.h, uip.c / uip_arch.h, uip_arch.c - Diese stellen die grundsätzlichen Funktionen zurGenerierung eines IP Paketes und der Logik von TCP, UDP und ICMP zur Verfügung.uip_arp.h, uip_arp.c - Hier sind die Funktionen für das ARP-Protokoll zu finden, ebensowie die Funktionen zur Verwaltung der ARP-Tabellen. Dieses löst IP- in MAC-Addressenuipopt.h - In dieser Datei ist festgelegt, welche Features des uIP eincompiliert werden sol-len. Weiterhin ist hier die IP-Addresse einstellbar.nic.h, nic.c - In diesen Dateien sind die Funktionsrümpfe des Hardwaretreibers deklariert,

8http://rfc.net/rfc1122.html

11

2 Lösungsansatz

dazu werden dort die entsprechenden Funktionen der rtl8019.c und rtl8019.h aufgerufen.main.c - Die „main.c“ beinhaltet die Mainfunktion mit der Hauptschleife sowie die Initia-lisierungsaufrufe und das zyklische Abprüfen der Datenschnittstellen.app.h, app.c - Hier befindet sich die eigentliche Applikation. Nachdem in der MainloopPakete des Netzwerkchips verarbeitet wurden, wird eine Funktion zu dessen Abarbeitungaufgerufen, die in der Datei „app.c“ zu finden ist. Weiterhin werden hier die Datenverbin-dungen den Schnittstellen zugeordnet.Die Verbindung ist unterbrechungsunempfindlich gestaltet, dazu wird das verbindungslo-se UDP-Protokoll verwendet. Da das Roboterframework die Eigenschaft hat, dass einzelnePaketverluste das Roboterverhalten nur minimal beeinflussen, wird kein verbindungsori-entiertes Protokoll benötigt. Allerdings bietet der uIP in der verwendeten Version 0.9 nureine rudimentäre UDP Unterstützung. Es ist nicht möglich, auf eingehende UDP Paketezu warten, daher funktioniert UDP nur im Client-Modus. Um einen Servermodus verfüg-bar zu machen wurde eine UDP-Clientverbindung von Hand erzeugt, und eine Routinehinzugefügt, die auf eintreffende Pakete prüft. Die UDP-Gegenstelle muss bei jeder Über-tragung den Antwort-Port mit übermitteln. Die uIP Architektur lässt nicht zu, diesen Portbeim Empfangen eines Paketes anzupassen. Daher werden Daten auf dem selben Port ver-sendet, auf dem sie zuvor empfangen wurden.Zu Verbesserung der Latenzzeiten ist eine Optimierung des uIP-Stacks notwendig. ImWesentlichen können dazu alle Codesegmente auskommentiert werden, die nicht zwin-gend für die UDP Verbindungen notwendig sind. Daher wurde das TCP-Protokoll ent-fernt. Zwei Verbindungen sind für die beiden UARTs vorgesehen, eine Verbindung für einStatusprotokoll und eine Verbindung für die CAN-Verbindung. Dadurch konnten wir dieVerbindungszahl auf vier limitieren. Zur Reduzierung von Verwaltungsaufwand kann derARP-Cache auf eine Zuordnung gesetzt werden.Die MAC-Adresse muss im EEPROM des ATMega128 gespeichert werden um es mög-lich zu machen, die Notebooks der Roboter beliebig zu vertauschen. Das Notebook kannanhand der MAC-Adresse der Platine erkennen, zu welcher Hardwarekonfiguration es zu-geordnet wurde.Die Speicherposition wurde in der Datei „uipopt.h“ auf 0x02 festgelegt. Beim Bootvor-gang der Platine wird diese EEPROM Adresse ausgelesen und die folgenden sechs Byteals MAC-Addresse verwendet.

12

2 Lösungsansatz

2.2.3 CAN-Anbindung mit MCP2515

Der MCP2515 ist, wie in Abschnitt 2.1 beschrieben, über den SPI-Bus mit dem Microcon-troller verbunden. Dieser Bus funktioniert nach dem Master/Slave-Prinzip. Zur Übertra-gung eines Datenbytes verfügt der Microcontroller über ein Register, dessen Daten er au-tomatisch sequenziell und bitweise auf den Bus schreibt. Wenn alle Bits des Registers ge-sendet wurden, so wird ein Statusflag gesetzt, welches eine vollständige Übertragung si-gnalisiert.Über den SPI-Bus kann jedes Register des MCP2515 angesprochen werden. Dazu musszunächst ein Statuswort auf den Bus geschrieben werden, woraufhin die Addresse für dasentsprechende Zielregister folgt. Abschließend werden die Daten versendet, die in das Re-gister geschrieben werden sollen. Während des Vorgangs muss die CS(Chipselect)-Leitungdes MCP2515 gesetzt sein. Um Registerinformationen vom MCP2515 abzurufen, muss zu-nächst ein Lese-Statusbyte und anschließend die Adresse auf den Bus geschrieben werden.Daraufhin kann das Empfangsregister des SPI-Busses ausgelesen werden. Auch bei dieserProzedur muss der CS-Pin auf „Highpegel“ gesetzt sein.Es ist dem Datenblatt [7] zu entnehmen, welche Register an welcher Adresse anzuspre-chen sind. Die Register zum Senden von Daten sind: TXB0SID, TXB0EID und TXB0DLC.In diese Register muss der Header des CAN-Paketes geschrieben werden. Die beiden ers-teren Register sind 16 Bit groß und daher in zwei Schreibvorgängen über den SPI-Bus mitDaten zu befüllen. Sie beinhalten die CAN-ID der zu versendenden Nachricht, sowie In-formationen, ob es sich um einen Extended- oder Normal-Frame handelt. Mit dem RegisterTXB0DLC kann die Datenlänge oder die Remoteinformation festgelegt werden. Die Regis-ter TXB0D(0-7) dienen als Datenregister der CAN-Nachricht. Sind diese Register mit denDaten für die CAN-Nachricht beschrieben, so wird diese mit einem SPI-Kommando ver-schickt.Das folgende Schaubild zeigt den Aufbau eines CAN-Paketes, wie es vom MCP2515 gene-riert und versendet wird:

Der MCP2515 erzeugt selbständig die CRC-Checksumme und führt deren Überprüfungdurch. Sollten Fehler bei der Übertragung entdeckt werden, so wird vom MCP2515 selbst-ständig versucht, das Paket erneut zu verschicken. Weitere Register des CAN-Bausteins

13

2 Lösungsansatz

sind EFLG, TEC und REC, diese beinhalten Fehlerinformationen.Zum Datenempfang verfügt der MCP2515 über zwei Datenpuffer. Wenn Daten empfan-gen wurden, so wird ein Interrupt-Pin auf High gesetzt. Ist ein Interrupt-Signal gesetzt,muss man zunächst überprüfen, welcher Puffer verwendet wurde und kann anschließenddie Daten auslesen. Jeder Puffer besteht aus acht Datenregistern, sowie aus zwei 16 Bitgroßen CAN-ID-Adressregistern. Ein weiteres Register enthält die RTR-Information, so-wie die Datenlänge.Bei der Ansteuerung eines MCP2515 wurde ein Opensource-Projekt als Vorlage verwendetdass unter der URL „www.kreatives-chaos.com/“ mit einem Tutorial zu finden ist.In den Beispielquelltexten fehlt die Möglichkeit Extended-Frames zu übertragen. Da derRoboter-Laptop das Packen der CAN-Pakete übernehmen soll, um die Leistung der Pla-tine möglichst hoch zu halten, konnte eine Funktion zum Senden von Paketen entwickeltwerden, die lediglich das sequenzielle Füllen der Register durchführt. Eine entsprechendeFunktion zum Packen der Pakete wurde bereits für das Roboterframework in C# geschrie-ben.

2.2.4 Lösungsweg

Interaktion der verschiedenen Schnittstellen

Entsprechend der Aufgabenstellung soll der Microcontroller alle Daten, die auf dem CAN-Bus oder der UART eintreffen, über den RTL8019AS versenden. Außerdem soll der ATMe-ga128 alle über UDP-Verbindungen empfangenen Daten entsprechend ihres Ports überCAN-Bus oder UART verschicken.Kommunikation von UART zum CAN-Bus und umgekehrt sind in der momentanen Im-plementierung nicht vorgesehen. Via UART empfangene Daten, werden zeilenweise ein-gelesen. Da die UART Daten zeichenweise versendet, wird ein Puffer erzeugt, in dem alleempfangenen Zeichen, bis zur Übertragung eines Zeilenumbruches, abgelegt sind. Darauf-hin wird der komplette Inhalt des Puffers über die zugehörige UDP-Verbindung versendet.Dieser Puffer ist 256 Zeichen groß. Nach jedem Versenden von Daten, wird der Puffer ge-leert, und kann neue Daten empfangen.Wenn über die UDP-Verbindung Daten für die UART empfängt, legt die Implementierungebenfalls ein Puffer an. Die UART löst, jeweils nach dem versenden eines Zeichens, einenInterrupt aus, dessen Interruptroutine das nächste Zeichen des Puffers versendet.Via CAN zu versendende Daten, erreichen die Platine auf einer separaten UDP-Verbindung.Diese Daten müssen bereits, entsprechend der Register des MCP2515, formatiert sein. Dies

14

2 Lösungsansatz

ermöglicht die Daten byteweise per SPI-Bus9 in die Register des MCP2515 zu schreiben.Beim Empfangen von Daten über den MCP2515, löst dieser einen Interrupt aus. In derInterrupt Service Routine wird ein Flag gesetzt, welches die Hauptschleife regelmässigüberprüft. Wenn dieses Flag gesetzt ist, können die Register des MCP2515 ausgelesen undper UDP versandt werden.Um die verschiedenen Verbindungen unterscheiden zu können, steht für jede der beidenUARTs und den CAN-Bus jeweils ein eigener UDP-Port zur Verfügung. Ein weiterer Portist vorgesehen, um Statusdaten abzufragen und setzen zu können. Mit diesem Statuspro-tokoll kann z.B. der ARP Cache gelöscht, ein Hard- oder Softreset des Controllers durch-geführt, sowie die MAC-Adresse gesetzt oder ausgelesen werden.

Probleme

Softwareseitig sind bei der Entwicklung verschiedene massive Probleme aufgetreten. ZumEinen war zunächst keine Netzwerkfunktion möglich. Dies rührte daher, dass verwendeteTreiber des RTL8019AS nicht funktionierte. Dieser Treiber versuchte Daten auf externenRAM abzulegen, über den die Platine jedoch nicht verfügt. Das Auswechseln des Treiberslöste dieses Problem.Ein weiteres Problem waren die hohen und schwankenden Latenzzeiten von 20 bis 400ms.Auch nach den Optimierungsbemühungen verbesserte sich dies nur unerheblich. Es stelltesich heraus, dass es sich um einen Fehler im Treiber der Notebooks handelte. Ein einfa-ches Treiberupdate der Notebooks löste das Problem. Dieses Update erschien nur kurz vorProjektbegin und ist bis zum Projektende noch nicht in der aktuellen Stableversion des Li-nuxkernels enthalten. Nach dem Treiberupdate konnten Pingzeiten von knapp unter einerMillisekunde erreicht werden. Da der Motorcontroller des Roboters eine Zykluszeit von 10ms besitzt, sind solche Latenzzeiten in einer angemessenen Größenördnung.

9http://de.wikipedia.org/wiki/Serial_Peripheral_Interface

15

3 Ergebnisse

3.1 Inbetriebnahme

Zur Vervielfältigung der Platine ist im Subversionssystem eine Bestellvorlage zu finden.Beim zusammenlöten der Bauteile ist darauf zu achten, keine Bauteile zu vertauschen.Dies muss besonders bei SMD-Kondensatoren, sowie -Widerständen beachtet werden. BeiDioden und sonstigen Bauteilen muss zusätzlich die Ausrichtung beachtet werden. Aufder Platine sind alle Polungen und Ausrichtungen markiert.Uns sind Designfehler beim Platinendesign unterlaufen. Der ATMega128 wird nicht überden SPI-Bus programmiert, sondern über die UART-Pins. Daher dürfen die entsprechen-den Pins des UART Treiberbausteins nicht verbunden sein. Stattdessen muss eine Draht-brücke mit Fädeldraht zur SPI-Stiftleiste erstellt und ein Jumper an die entsprechendenPins des MAX232 Bausteins gelötet werden. Dadurch ist es möglich, die zweite UARTzu verwenden. Außerdem ist ein Pulldown-Widerstand am RTL8019AS Chip zu groß ge-wählt. Dadurch funktioniert der Chip nur bei einer Versorgungsspannung von ca. sechsVolt. Dieser Fehler kann behoben werden, indem man diesen Widerstand ersetzt. Es han-delt sich dabei um den AEN-Pin (Pin 34), an dem ein 2,7k Ohm Widerstand anstatt eines27k Ohm angelötet werden muss. Im Abbildung 3.1 ist zu sehen, wo diese Modifikationendurchzuführen sind. Es empfielt sich beim Löten zunächst die SMD-Bauteile mit vielenBeinen zu löten, anschließend alle kleinen Teile und zum Schluss die großen Bauteile, dadiese am leichtesten zu löten sind. Nachdem die Platine montiert ist, muss die Stromver-sorgung hergestellt werden. Hierzu muss eine 6V - 24V Gleichstromquelle am entsprechen-den Stecker angeschlossen werden. Nun kann mit einem ISP-Programmieradapter eineVerbindung mit dem Microcontroller aufgebaut werden, um die Fusebits zu setzen. Dazueignet sich avrdude oder die Java-GUI „Burn-o-Mat“. Mit diesem müssen die Fusebits wieim Abbildung 3.2 gesetzt werden.

Ein falsches setzen der Taktquelle führt dazu, dass der Microcontroller unbrauchbar wird.Bei Änderungen an den ISP- und Reset-Flags, lässt sich der Controller nichtmehr in denProgrammiermodus setzen. Die Funktionen der einzelnen Fusebits sind im Internet zu fin-

16

3 Ergebnisse

Abbildung 3.1: Korrekturen an der Platine

17

3 Ergebnisse

Abbildung 3.2: ATmega Fuses

18

3 Ergebnisse

den.1

Wenn auch dieser Schritt durchgeführt worden ist, kann der Controller programmiert wer-den. Dazu muss die im Abschnitt 2.2.1 beschriebene Software installiert sein. Dann kannmit dem „make“-Befehl im Quelltextverzeichnis der entwickelte Quelltext vom avr-gcc ineine .hex-Datei übersetzt werden. Mit dem Befehl „make program“ wird der übersetzteQuelltext über den ISP-Programmieradapter auf den Microcontroller übertragen. Das Ma-kefile ist für einen „stk200“ Programmieradapter konfiguriert, der das Device „/dev/parport0“verwendet.Nach dem Programmieren des Microcontrollers wird der EEPROM gelöscht. Da die Plati-ne ihre MAC-Adresse aus dem EEPROM des Microcontrollers liest, ist deshalb die DefaultMAC-Adresse „ff:ff:ff:ff:ff:ff“. Diese kann jedoch, über das Statusprotokoll, mit dem Befehl’M’ gesetzt werden.

3.2 Versenden von Daten via UART

Zum Versenden von Daten via UART muss die korrekte Polung des Kabels eingehaltensein. Die Anschlussbelegung des Steckers ist in dem Schaltplan der Abbildung 2.3 zu fin-den.Die Platine verfügt über zwei UART Schnittstellen, die über ein Kabel angeschlossen wer-den können. Für die Verwendung von UART1 muss der Jumper überbrückt sein. Für denDatentransfer muss eine UDP Verbindung geöffnet sein. Die Netzwerkgegenstelle solltedazu die IP-Adresse „192.168.0.5“ verwenden, da die Platine mit dieser Konfiguration ge-testet wird. Die Platine verwendet die IP-Adresse „192.168.0.2“. Die UART0 ist auf demPort 10001 zu erreichen, UART1 auf Port 10002. Dazu muss sowohl Sende-, als auch Emp-fangsport des verwendeten Sockets auf diesen Port gesetzt sein.Um Daten per UART zu verschicken, sendet man lediglich die zu sendende Datenzeileüber die UDP-Verbindung. Es ist dabei sinnvoll, diese Datenzeile mit einem Zeilenum-bruch zu terminieren, da die meisten UART Geräte ihre Befehle zeilenweise empfangen.Wenn die Platine via UART eine Datenzeile empfängt, so wird sie diese per UDP-Paketauf der zur UART gehörenden Verbindung wegschicken. Die Platine nimmt die Daten wiedie meisten Geräte zeilenweise an. Das bedeutet, dass Daten per UDP versendet werden,sobald ein Zeilenumbruch auf der UART empfangen wurde. Es kann passieren, dass daserste Datenpaket verloren geht, da dieses verwendet wird, um die ARP Tabelle für die

1http://www.microcontroller.net/

19

3 Ergebnisse

Laptop-IP zu vervollständigen. Allerdings sendet die Platine beim Initialisieren bereits einsolches Paket. Sollte sie dort eine Antwort erhalten haben, wird kein Datenverlust auftre-ten.Ein Beispiel C# Programm, welches Daten per UART versenden kann, ist im Robocup Sub-versionssystem unter „robocup/trunc/src/Tests/net.cs“ zu finden. Zum Starten des Bei-spielprogramms ist folgender Aufruf zu verwenden:./net.exe udp://192.168.0.5:10001 udp://192.168.0.2:10001

3.3 Versenden von CAN-Nachichten

Vor dem Versenden von CAN-Nachrichten ist zu prüfen, ob das Kabel korrekt belegt ist.Auch hier kann man die genaue Belegung dem Schaltplan aus Abbildung 6.2 entnehmen.Wie bei der UART muss eine UDP-Datenverbindung per Ethernet geöffnet werden. Vordem Verschicken von Daten muss zunächst ein CAN-Paket erzeugen werden. Ein solchesPaket besteht aus vier ID-Bytes, einem Byte aus Längen bzw. RTR Information[17] und biszu acht Datenbytes. In den ersten vier ID-Bytes ist jedoch zusätzlich die Information ent-halten, ob es sich um ein Extended-Frame handelt, wobei die entsprechenden Bits mittenim ersten Byte liegen. Die genaue Formatierung ist den Beispielquelltexten des Carpe Noc-tem Repository zu entnehmen.Um CAN-Nachrichten erzeugen zu können, existieren bereits Funktionen, die solche CAN-Pakete erzeugen können. Diese sind im folgenden Beispielprogramm zu finden:robocup/trunk/src/Tests/net-can.cs

Dieses Beispielprogramm kann verwendet werden, um Daten von einer voreingestelltenCAN-ID zu versenden, oder Daten von einer beliebigen CAN-ID zu empfangen.Der Programmaufruf ist äquivalent zu dem des UART-Beispiels. Der Port der CAN-UDP-Verbindung ist 10003. Zum Erzeugen eines CAN-Paketes verwendet man folgende Funk-tion:

public static Byte[] generateCanMessage(Byte[] id,Byte length, Byte[] data, bool extended, bool rtr);

Mit dem ersten Parameter übergibt man vier Byte CAN-ID, auch wenn es sich um einenNormal-Frame handelt. Zusätzlich muss das „extended“ Flag der Funktion passend ge-setzt werden, sofern ein extended Frame versendet werden soll. Der dritte Parameter bein-haltet ein Bytearray mit den zu sendenden Datenbytes. Dessen Länge muss im zweitenParameter korrekt festgelegt worden sein.Sollte man einen Remote-Frame[17] senden wollen, so muss das RTR-Flag gesetzt sein.

20

3 Ergebnisse

Als Rückgabewert erhält man ein Bytearray, welches das generierte CAN-Paket enthält.Dieses Array kann man nun über die UDP Verbindung versenden, um es über CAN zuverschicken.Darüberhinaus zeigt das Programm in der Funktion „OnMessageEvent“, wie man empfan-gene Daten entsprechend parsen kann, um die CAN-Header Informationen zu erhalten.

3.4 Statusprotokoll

Zur Konfiguration ist ein Statusprotokoll implementiert, über das man mit möglichst ge-ringem Datenaufwand einige Operationen auf der Platine durchführen kann. Das Sta-tusprotokoll kann auf dieselbe Weise wie die UART-Kommunikation getestet werden. AlsPort ist hier 10000 gewählt worden.Alle Befehle bestehen aus nur einem Zeichen, einige besitzen noch einen Parameter. Eswird in jedem über den Port 10000 empfangenen Paket das jeweils erste Zeichen als Befehlinterpretiert und der Rest als Parameter.Im Folgenden erleutern wir die implementierten Befehle.

’A’ - ARP-Clear: Mit diesem Befehl wird die ARP-Tabelle geleert und ein neues ARP Paketgeneriert, um einen neuen Eintrag zu erzeugen.

’C’ - CAN-Status: Als Antwort erhält man die drei Fehlerregister des MCP2515: EFLG,TEC und REC. Diese enthalten z.B. Informationen über Übertragungsfehler. Die genaueBedeutung der einzelnen Bits kann im MCP2515 Datenblatt2 nachgelesen werden.

’E<MMMMMM>’ - EEPROM-MAC-Address: Bei diesem Befehl müssen sechs Zeichenals MAC-Adresse folgen. Diese werden in den EEPROM des Microcontrollers geschrie-ben. Die neue MAC-Adresse wird erst verwendet, sobald der Microcontroller neugestartetwird.

’I’ - Init-MCP2515: Dieser Befehl führt eine Reinitialisierung des MCP2515 durch. Dabeihandelt es sich jedoch nicht um einen Reset.

’M’ - MAC-Address: Mit ’M’ wird die MAC-Adresse aus dem EEPROM gelesen und zu-rückgeschickt. Diese muss nicht zwingend mit der Adresse übereinstimmen, die die Plati-ne verwendet, da sie erst nach einem Soft- oder Hardreset verwendet wird.

2http://www.ortodoxism.ro/datasheets2/0/0027dto5zhyf4i01qo7dqexxwhcy.pdf

21

3 Ergebnisse

’P’ - Ping: Dieses Zeichen wird lediglich incrementiert und somit als ’Q’ zurück gesendetund kann als eine Art Ping verwendet werden.

’R’ - Reset: Mit diesem Befehl kann ein Hardreset durchgeführen werden. Dazu wird derWatchdog Timer, der nach Ablauf den Mircocontroller neustartet, mit 15ms initialisiert undeine Endlosschleife gestartet. Der Watchdog setzt controllerintern das Resetflag, dies führtauch zu einem Reset aller Register. Zu Beachten ist, dass diese Resetfunktion 15 ms mehrZeit benötigt, als der Softreset.

’S’ - Softreset: Mit diesem Befehl wird ein Softreset durchgeführt, indem der Funktionszei-ger auf den Resetvektor des Microcontrollers gesetzt wird. Dabei bleiben die Registerwertejedoch erhalten.

’X’ - Wenn der Microcontroller neugestartet wird, sendet er ununterbrochen Meldungen,das er resettet worden ist über das Statusprotokoll. Mit ’X’ kann man den Erhalt der Init-meldung quittieren. In Folge dessen wird das Senden dieser Meldung eingestellt. DiesesFeature ist in der momentanen Fassungen des Quelltextes jedoch auskommentiert, da esim Moment nicht benötigt wird. Es kann jedoch wieder hereingenommen werden, solltedies notwendig sein.

22

4 Tests

4.1 Ping

Ein Ping zur Platine dauert durchschnittlich deutlich unter 1ms, er liegt bei etwa 800µs.Dies wurde über 10.000 Pings als arithmetischer Mittelwert festgestellt.

4.2 CAN

Den Versuchsaufbau zum Testen der Laufzeiten für CAN haben wir möglichst einfach ge-wählt. Hier für wird eine zweite Platine mit dem CAN-Echo-Programm1 geflasht, welchesjedes empfangene CAN-Packet sofort wieder zurück sendet. Die zu testende Platine wirdper Netzwerk mit einem Laptop und zu der anderen über den CAN-Bus verbunden. Nunverschickt man vom Laptop aus UDP-Pakete und misst die Antwortzeit. Die UDP-Paketewerden vom Laptop zur ersten Platine und anschließend über den CAN-Bus zur zweitengeschickt. Das Echoprogramm schickt das empfangene Paket zurück zur zu testenden Pla-tine, welche die Antwort an den Laptop weiterleitet.Bei einem Test mit 1000 Paketen wurde ein arithmetisches Mittel von 3384µs gemessen,wobei der Ping zur Platine bereits etwa 800µs benötigt.

4.3 UART

Um die UART zu testen, wird ein ähnlicher Versuchsaufbau verwendet. Um ein „Echo“über die UART zu erhalten, wird die Platine mit dem Motorcontroller des Roboters ver-bunden. Dieser antwortet auf ihm unbekannte Befehle mit „ERR“. Auch hier haben wir1000 Echo-Messungen durchgeführt, wobei sich eine Latenzzeit von 10351µs ergab. Beidiesem Ergebniss muss jedoch berücksichtigt werden, dass der Motorcontroller selbst eine

1Subversion: robocup/trunk/devices/eth2can/src/canEcho500kbps

23

4 Tests

Zykluszeit von 10ms besitzt. Entsprechend wird nur einmal alle 10ms eine Error-Antwortversendet. Unter Berücksichtigung dieser Tatsache ist der gemessene Wert als positiv zubewerten, da unsere Platine kaum Verzögerung verursacht.

24

5 Zusammenfassung und Ausblick

Das Ergebnis der Arbeit spiegelt die erfolgreiche Durchführung der Projektarbeit wieder,da die Platine die gesetzten Anforderungen vollständig erfüllen kann. Darüber hinaus hatsie mit etwa 1ms eine recht geringe Latenzzeit und wies, wie sich in den Tests zeigte, einehohe Stabilität auf, sodass sie gut in den Robotern eingesetzt werden kann.In Zukunft sollte ein neues Platinen-Layout erstellt werden, welches sich von den Ab-messungen her gut in die neuen Roboterrümpfe einbauen lässt. Zudem müssen dabei diebeschriebenen Designfehler behoben werden. Abschließend muss die Platine vervielfältigtund in die Roboter eingebaut werden.

25

6 Anhang

26

6 Anhang

RD

WR

RS

T

RTL8019AS

RTL8019AS

ISP

RS232

INT

PF

0(A

DC

0)61

PF

1(A

DC

1)60

PF

2(A

DC

2)59

PF

3(A

DC

3)58

PF

4(A

DC

4/T

CK

)57

PF

5(A

DC

5/T

MS

)56

PF

6(A

DC

6/T

DO

)55

PF

7(A

DC

7/T

DI)

54

(RX

D/P

DI)

PE

02

(TX

D/P

DO

)PE

13

(XC

K0/

AIN

0)P

E2

4(O

C3A

/AIN

1)P

E3

5(O

C3B

/INT

4)P

E4

6(O

C3C

/INT

5)P

E5

7(T

3/IN

T6)

PE

68

(IC

3/IN

T7)

PE

79

(T2)

PD

732

(T1)

PD

631

(XC

K1)

PD

530

(IC

1)P

D4

29

(TX

D1/

INT

3)P

D3

28

(RX

D1/

INT

2)P

D2

27

(SD

A/IN

T1)

PD

126

(SC

L/IN

T0)

PD

025

(A15

)PC

742

(A14

)PC

641

(A13

)PC

540

(A12

)PC

439

(A11

)PC

338

(A10

)PC

237

(A9)

PC

136

(A8)

PC

035

(OC

2/O

C1C

)PB

717

(OC

1B)P

B6

16

(OC

1A)P

B5

15

(OC

0)P

B4

14

(MIS

O)P

B3

13

(MO

SI)

PB

212

(SC

K)P

B1

11

(SS

)PB

010

(AD

6)P

A6

45(A

D7)

PA

744

(AD

5)P

A5

46

(AD

4)P

A4

47

(AD

3)P

A3

48

(AD

2)P

A2

49

(AD

1)P

A1

50

(AD

0)P

A0

51A

VC

C64

AG

ND

63

AR

EF

62

XT

AL1

24

XT

AL2

23 52

VC

C21 53

GN

D22

PG

3(T

OS

C2)

18

PG

4(T

OS

C1)

19

PG

0(W

R)

33P

G1(

RD

)34

PG

2(A

LE)

43

RE

SE

T20

PE

N1

IC2

C5 C6

R2 C7

C8 C9

Q1 R3

135

246

79

ISP

810

R4

R5

R6

PO

WE

R

R7

SCK,MOSI,MISO,RST,CS,CAN_INT

TXD,RXD,TXD1,RXD1

D[0..7]

A[0..10]

RST

RS

T

RS

T

SC

KM

OS

IM

ISO

TX

D1

RX

D1

TX

DR

XD

D0

D1

D2

D3

D4

D5

D6

D7

A7

A6

A5

A4

A3

A2

A1

A0

A10

CA

N_I

NT

CA

N_I

NT

ME

GA

128-

A

100n 100n

10k

GNDGND

GND

GND

100n

22p 22p

GND

16MHz

1k

4k7

4k7

4k7

GND

VC

C

VC

C

VC

C

VCC

VC

C

GN

Dgr

een

2k7

GN

D

Abbildung 6.1: Schaltplan: Seite 1 (ATmega128)

27

6 Anhang

+

+

VC

C

POWER OVER CAN

CA

N

RS

232

PA

Ds

RESET17CS16SO15SI14

SCK13

INT12

RX0BF11RX1BF10

TX0RTS4TX1RTS5TX2RTS6

VDD 18

TXCAN 1RXCAN 2

CLKOUT 3

OSC2 7

OSC1 8

VSS 9

IC4

TXD 1

RS 8

CANL6

CANH7

VREF 5

RXD 4

GND2

VCC3

IC5

D2

C10

C11

C12

C13

X2-

1

X2-

2

CA

N2

CA

N1

R15

R18

Q3

C28

C29

R20

H1

H2

H3

H4

KK

1

IC3

GN

D

INO

UT

F1

1234

CAN

C1+

1

C1-

3

C2+

4

C2-

5

T1I

N11

T2I

N10

R1O

UT

12

R2O

UT

9

V+

2

V-

6

T1O

UT

14

T2O

UT

7

R1I

N13

R2I

N8

IC6

1615

GN

DV

CC

IC6P

16

27

38

49

5

CO

M1

G1

G2

C19 C20

C21 C22

C23

C1+

1

C1-

3

C2+

4

C2-

5

T1I

N11

T2I

N10

R1O

UT

12

R2O

UT

9

V+

2

V-

6

T1O

UT

14

T2O

UT

7

R1I

N13

R2I

N8

IC7

1615

GN

DV

CC

IC7P

16

27

38

49

5

CO

M2

G1

G2

C35 C36

C37 C38

C39

SC

K,M

OS

I,MIS

O,R

ST

,CS

,CA

N_I

NT

TXD,RXD,TXD1,RXD1

RSTCSMISOMOSISCK

CAN_INT

TX

DT

XD

RX

DR

XD

RX

D1

RX

D1

TX

D1

TX

D1

MCP2515-E/SO

PCA82C250

GN

D

VCC

BY

550

220µ

F/2

5V10

µF/3

5V10

0n10

0n

GN

D

red

yello

w2k

7

2k7

VC

C

VC

C

GN

D

16M

Hz

22p

22p

GN

DG

ND

VCC

GN

D

VCC

4k7

GN

D

VCC

VC

C

MO

UN

T-P

AD

-RO

UN

D3.

0

MO

UN

T-P

AD

-RO

UN

D3.

0

MO

UN

T-P

AD

-RO

UN

D3.

0

MO

UN

T-P

AD

-RO

UN

D3.

0

GND

SK

104

FU

SE

SH

22,5

A

MA

X32

32C

SE

GN

D

100n 100n

100n 100n

GND

100n

VC

C

GN

D

MA

X32

32C

SE

GN

D

100n 100n

100n 100n

GND

100n

VC

C

GN

D

Abbildung 6.2: Schaltplan: Seite 2 (CAN, RS232, Stormversorgung)

28

6 Anhang

RT

L801

9AS

LPF LPF

WRRD

RST

INTgn

d tr

enne

n?

ET

H

AE

N34

AUI64

BA1474

BA1573

BA1672

BA1771

BA1869

BA1968

BA2067

BA2166

BCSB75

BD

085

BD

184

BD

282

BD

381

BD480

BD579

BD678

BD777

CD+54

CD-53

EECS76

GND 14

GND2 28

GN

D3

44

GND452

GN

D5

83

GN

D6

86INT0 4INT1 3INT2 2INT3 1

INT

410

0IN

T5

99IN

T6

98IN

T7

97IO

CH

RD

Y35

IOC

S16

B96

IORB 29

IOWB 30

JP65

LED061LED162LED263

LEDBNC60

RS

TD

RV

33

RX+56

RX-55

SA0 5

SA1 7

SA2 8

SA3 9

SA4 10

SA5 11

SA6 12

SA7 13

SA8 15

SA9 16

SA10 18

SA11 19

SA12 20

SA13 21

SA14 22

SA15 23

SA16 24

SA17 25

SA18 26

SA19 27

SD

036

SD

137

SD

238

SD

339

SD

440

SD

541

SD

642

SD

743

SD

895

SD

994

SD

1093

SD

1192

SD

1291

SD

1390

SD

1488

SD

1587

SM

EM

RB

31S

ME

MW

B32

TPIN+59

TPIN-58

TP

OU

T+

45T

PO

UT

-46

TX

+49

TX

-48

VDD 6

VDD2 17

VD

D3

47

VDD457

VDD570

VD

D6

89

X1

50

X251

RT

L

C15

C16

Q2

C17 C18

R13

1234567 8 9 10 11 12

U$2

R1

C1

C2C3

C4 C14

1-1

1-2

1-3

1-4

ET

H

1-5

1-6

1-7

1-8

LINK

R16

ACT

R17

C24

C25

C26

C27

D[0..7]

A[0

..10]

A0

A1A2A3A4

D7

D6

D5

D4

D3

D2

D1

D0

A7

A6A5

A10

GN

D

VCC100n

VCC

100n

20MHz

27p 27p

GNDGND

VCC

VCC

27k

GND

200

66p

10n10n

GND GND

10n 10n

GND GND

GN

D

2k7

VCC

2k7

VCC

100n

GND

VC

C

GND

GN

DGND

VC

C

100n

VCC

100n

GND

VCC

100n

GN

D

Abbildung 6.3: Schaltplan: Seite 3 (RTL8019AS)

29

6 Anhang

Abbildung 6.4: Platine im Roboter

30

6 Anhang

Abbildung 6.5: Platine im Roboter

31

Literaturverzeichnis

[1] Nardi, D. and Riedmiller and M., Sammut and C., Santos-Victor, J. - RoboCup 2004:Robot Soccer World Cup VIII (Jahr 2005)

[2] Ethernutprojekt http://www.ethernut.de/ , zugegriffen am 30. Januar 2008

[3] ISPF, Entwicklerhomepage des AVR-Ethernet-Boards http://www.ispf.de/

[4] Unser Robotersteuersoftware Framework: http://das-lab.net/ sowiehttps://trac.npw.net , zugegriffen am 30. Januar 2008

[5] AVR Tutorialseite http://www.mikrocontroller.net/ , zugegriffen am 30. Janu-ar 2008

[6] MCP2515 Tutorial http://www.kreatives-chaos.com/artikel/

ansteuerung-eines-mcp2515 , zugegriffen am 30. Januar 2008

[7] MCP2515 Datenblatt http://ww1.microchip.com/downloads/en/

DeviceDoc/21801e.pdf , zugegriffen am 6. Februar 2008

[8] Adam Dunkels uIP http://www.sics.se/~adam/uip/index.php/Main_Page ,zugegriffen am 30. Januar 2008

[9] Hardwaretreiber für RTL8019AS http://www.laskater.com/projects/

uipAVRdownload.htm , zugegriffen am 30. Januar 2008

[10] Eagle Software http://www.cadsoft.de/ , zugegriffen am 30. Januar 2008

[11] avr-gcc http://winavr.sourceforge.net/ , zugegriffen am 30. Januar 2008

[12] avr-libc http://www.nongnu.org/avr-libc/ , zugegriffen am 30. Januar 2008

[13] Avrdude http://download.savannah.gnu.org/releases/avrdude/ , zuge-griffen am 30. Januar 2008

[14] Schaltplan für MCP2515 http://www.kreatives-chaos.com/artikel/

can-testboard , zugegriffen am 30. Januar 2008

32

Literaturverzeichnis

[15] Ulrich Radigs AVR Webserver http://www.ulrichradig.de/home/index.

php/avr/webserver , zugegriffen am 30. Januar 2008

[16] Wikipedia SPI-Bus http://de.wikipedia.org/wiki/Serial_Peripheral_

Interface , zugegriffen am 30. Januar 2008

[17] Wikipedia CAN-Bus Erläuterunghttp://de.wikipedia.org/wiki/Controller_Area_Network, zugegriffen am 6. Februar 2008

33