entwicklung eines ethernet-auf-can-adapters auf basis des...
TRANSCRIPT
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
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
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
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