Dieser ArtikelBenutzerSuche |
Avr Webserver mit Wiznet WIZ810MJ
[bearbeiten] Hardware
Alle unbelegten Pins sind auf Stiftleisten geführt und können für freie Anwendungen verwendet werden, z.B. für ein LCD Display. [bearbeiten] Platine Die Platinen wurden bei Leiton gefertigt. Eagle Files: WiznetWebserverPCB Schaltplan im PDF Format: Schaltplan als PDF Bestückungsplan: Bestückungsplan als PDF Hier ein Bild eines fertig aufgebauten Webservers: [bearbeiten] ProgrammiermöglichkeitenAuf der Platine ist eine 6-polige Stiftleiste zum Programmieren vorhanden. Weiters wurde ein Bootloader geschreiben, durch den es möglich ist, den Avr mittels RS232 oder über USB zu programmieren. Der Bootloader ist STK500 kompatibel, wodurch man einfach mit dem AVR Studio oder mit Avrdude programmieren kann. [bearbeiten] AufbauBeachtung gilt der DC Buchse. Es gibt mehrere Versionen dieser Buchse. Die Buchse besitzt 3 Anschlüsse. Besitzt der seitliche Anschluss kontakt zum hinteren Anschluss, muss dieser abgschnitten werden. Ansonsten kommt es zu einem Kurzschluss der Eingangsspannung. Da sich unter dem Quarz für den Atmega128 mehrere Durchkontaktierungen befinden, muss der Quartz isoliert werden. Es gibt dafür spezielle Quarzisolierscheibchen. Ansonsten tut es auch ein Stück Kunststofffolie (zB ein Heftumschlag). [bearbeiten] Software[bearbeiten] SpeichertestprogrammUm den externen SRAM testen zu können wurde ein Speichertestprogramm geschrieben. Es beschreibt den kompletten RAM in einer Schleife. Danach wird er wieder ausgelesen und die Differenz zum geschriebenen Wert berechnet. Ist das Ergebnis 0, wurde die Speicherzelle richtig beschrieben und ausglesen. Ist das Ergbnis ungleich Null, trat während des Vorganges ein Fehler auf, wird die Led1 (PG4) wird eingeschalten. Nach beenden der Speicherprüfung wird die Led2 (PG3) geschalten. Leuchtet nur eine der beiden Leds, ist das Ergebnis des Speichertests OK. Leuchten beide Leds, ergab sich während des Auslesens ein Fehler. In diesem Fall sollte man die Lötstellen des SRAMs, Latches und AVR kontrollieren. Zusätzlich werden die Informationen auch über die serielle Schnittstelle ausgegeben. Baudrate ist 115200 bps eingestellt. Memtest Programm: Memtest
[bearbeiten] BootloaderDer Bootloader ist STK500 kompatibel, wodurch der ATmega128 direkt aus dem AVR Studio geflasht werden kann. Bootloaderroutinen mit Applikationsbeispiel zum Testen: Bootloaderroutinen mit Applikationsbeispiel Mit dem Define 'COMM_MODE' in der Header-Datei communication.h kann festgelegt werden, ob der Bootloader für RS232 oder USB ist. Diese Header befindet sich im Ordner Webserver_STK500_Bootloader. [bearbeiten] VoreinstellungenDamit der Bootlaoder funktioniert, muss zuerst die hex Datein Webserver_STK500_Bootloader.hex im Ordner Webserver_STK500_Bootloader\defaultmit einem externen Programmiergerät über die 6-polige Stiftleiste geflasht werden. Weiters müssen die Fusebits richtig eingestellt werden. Folgendes muss eingestellt werden:
Die Werte für die Fuses, die die obrigen Einstellungen beinhalten, sind 0xFF (low Fuse) und 0xDC (high Fuse). Will man den Bootloader für USB verwenden, muss man einerseits das Define 'COMM_MODE' in der Header-Datei communication.h für USB einstllen (Standardmäßig ist USB gewählt), andererseits muss der COM Port Treiber für den FT245 installiert werden. Diesen findet man hier http://www.ftdichip.com/Drivers/VCP.htm. Genauere Informationen zur Installation können auf der FTDI Homepage nachgelsen werden. [bearbeiten] Informationen zur NutzungDer Bootloader wurde mit dem AVR-Studio sowohl über USB als auch RS232 getestet. Probleme können auftreten, wenn der Bootlaoder für USB eingestellt ist und man USB - während man im AVR-Studio vebunden ist - absteckt. Sollte man dies doch tun, muss man zuerst den Connect-Dialog schließen, anschließend USB neu anstecken und erneut verbinden. In einer anderen Reihenfolge kann sein, dass man keine neue Verbindung aufbauen kann. Über RS232 treten diese Probleme nicht auf. Die Probleme über USB liegen möglicherweise am COM-Port Treiber von FTDI, da die Software am µC für die Auswertung der STK500 Kommandos für RS232 und USB gleich ist. [bearbeiten] Applikationen flashenIm Ordner vom Bootlaoder ist auch ein Applikationsbeispiel. Dieses Projekt kann verwendet werden, um hier seine eigenen Applikationen zu schreiben. Um eine Hex-Datei zu flashen, kann einfach über RS232 oder den USB-COM-Port im AVR-Studio eine Verbindung zum Webserver aufgebaut werden und die hex geflasht werden. Wichtig ist noch, dass in einer selbst erstellten Applikation die USB-Routinen/RS232-Routinen mitkopiliert und sowohl USB als auch RS232 wie im mitgelieferten Beispiel initialisiert werden, damit der Bootlaoder funktioniert und jederzeit eine neue Applikation geflasht werden kann. Ansonsten muss der Bootloader immer wieder neu geflasht werden.
[bearbeiten] InterfaceAlle Routinen für die vorhanden Interfaces des Webservers sind bereits im Applikationsbeispiel enthalten, siehe Applikationsbeispiel mit Bootloaderroutinen). [bearbeiten] External Memory InterfaceDa sich am Webserver mehrere Devices am XMEM-Interface befinden, musste eine Logik entwickelt werden, mit der je nach selektierter Adresse immer nur das jeweilig angesprochene Device aktiv ist. Am XMEM Inteface befinden sich folgende Devices:
Die gesamte Logikschaltung mit ausführlicher Dokumentierung kann hier heruntergeladen werden: Adresslogik für Webserver.pdf [bearbeiten] USBDer Webserver hat eine USB Schnittstelle und verwendet den FT245 von FTDI Chip als USB Chip. Der FT245 ist am XMEM Interface des Webservers angeschlossen und kann in einem fix vorgegebenem Adressbereich liegen (siehe External Memory Interface). Für den Webserver wird der COM-Port Treiber von FTDI verwendet, der zuvor installiert werden muss (siehe auch Bootloader Voreinstellungen). [bearbeiten] ÜbertragungsprotokollDas Übertragungsprotokoll war nötig und an den STK500 Bootloader gebunden, damit es auch möglich ist, von der Applikation in den Bootlaoder zu springen. Die Übertragung ist folgendermaßen aufgebaut:
Wird als START Byte ein 0x1B erkannt, dann wird die Funktion collectCompleteMessage() aus der Header Datei BootlaoderApplication.h aufgerufen, die nichts anderes macht, als zu warten, bis eine vollständige Message empfangen wurde, diese anschließend in der .noinit section speichert und daraufhin einen Reset mit dem Watchdog generiert, damit der Webserver in den Bootlaoder springt. Dort wird dann erkannt, dass ein Watchdog Reset ausgelöst wurde und neue Daten in der .noinit section für den Bootloader sind. Diese werden daraufhin ausgelesen und verarbeitet. [bearbeiten] Probleme an FT245 Pins TXE und RXFBeim Testen der Platine und des FT245 hat sich herausgestellt, dass nach dem Anstekcen der Stromversorgung oder nach dem Anstecken von USB am PC einige high-low Pulse an TXE und RXF auftreten. Diese waren insofern ein Problem als die Datenauswertung in der Hauptapplikation (nicht im Bootlaoder) interrupgesteuert erfolgt und ein Übertragungsprotokoll (für STK500 Bootloader nötig) verwendet wird. Diese Pulse wurden nun per Software kompensiert, dafür war jedoch der Timer0 notwendig. Der Timer0 kann somit nur mehr bedingt für eigene Anwendungen verwendet werden, empfohlen wird jedoch, diesen Timer nicht zu verwenden. [bearbeiten] UART RS232Auf der Webserver Platine befindet sich ein MAX3232 für die Pegelwandlung. Für RS232 wurden die Routinen aus der AVRlib verwendet (sowohl uart.h/uart.c als auch rprintf.h/rprintf.c). Damit man den Bootloader für RS232 verwenden kann, war es jedoch notwendig, die Receive Interruptroutine in der uart.c für den Webserver anzupassen. Für RS232 wird nun dasselbe Übertragungsprotokoll wie für USB verwendet. Siehe USB Übertragungsprotokoll [bearbeiten] CAN
[bearbeiten] SD-Karte Diese beiden Leiterbahnen müssen aufgetrennt werden
Leider hat sich ein Fehler im Schaltplan eingeschlichen. Zwei Netze haben den gleichen Namen und haben somit eine Verbindung untereinander. Dieser Fehler wurde aber beim Routen nicht erkannt und somit gibt es hier eine Verbindung. Nach neun Stunden Debugging wurde der Fehler gefunden. Damit die Ansteuerung der SD-Karte aber funktioniert, müssen zwei Leiterbahnen aufgetrennt werden. Im Bild links sind die notwendigen Schnitte orange und gelb eingezeichnet. Für das Verhalten der Schaltung hat diese Leitung (Datenausgang der SD-Karte) keinen Einfluss. Da die SD-Karte intern Pullup-Widerstände besitzt, hat SD-Karte auch bei offenem CS-Signal einen definierten Pegel. Für die FAT-Implementation wird eine vorgefertigte Bibliothek von Holger Klabunde verwendet. Es wurde ein einfacher Schreib- und Lesetest für den Webserver implementiert. Das Programm liest eine Datei ein und gibt sie über die serielle Schnittstelle aus. Weiters schreibt das Programm im Root-Verzeichnis der SD-Karte eine Datei. Danach wird ein neues Verzeichnis angelegt und darin eine weitere Datei geschrieben. Die Debug-Ausgaben erfolgen über die serielle Schnittstelle mit einer Bitrate von 115000bps. SD-Karten-Beispiel: Schreib- und Lesetest [bearbeiten] Software SPIDa Hardware SPI des ATmega128 bereits für CAN und SD Karte verwendet wurden, wurde am Webserver auch ein softwaremäßiges SPI Interface eingebunden. Für die Software SPI Pins ist eine eigene 6-polige Stiftleiste auf der Platine vorgesehen. Die Routinen sind in Assembler geschrieben und erzeugen einen SCK Takt von F_CPU/32. Die Assemblerfunktionen steuern nur SSMISO, SSMOSI und SSCK. Die Chipselect Leitung muss vom User vor Funktionsaufruf gesteuert bzw. initialisert werden. [bearbeiten] EthernetKategorien: Projekte | AVR | Ethernet |