Avr Webserver mit Wiznet WIZ810MJ
Hardware
- Atmega128
- 32kB SRAM
- WIZ810MJ Ethernetmodul
- FT245R
- CAN galvanisch getrennt
- SD Karte
- RS232
- Software SPI
Alle unbelegten Pins sind auf Stiftleisten geführt und können für freie Anwendungen verwendet werden, z. B. für ein LC Display.
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:
Programmiermöglichkeiten
Auf 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.
Aufbau
Beachtung 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).
Software
Speichertestprogramm
Um 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 ausgelesen. Ist das Ergbnis ungleich Null, trat während des Vorganges ein Fehler auf und 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
Bootloader
Der 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.
Voreinstellungen
Damit 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:
- ATmega103 Kompatiblitätsmodus deaktivieren
- JTAG und On-Chip-Debugging deaktivieren
- Externen Quarz aktivieren
- Bootresetvektor aktivieren
- Bootsize = 1024 words
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.
Informationen zur Nutzung
Der 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.
Applikationen flashen
Im 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.
Interface
Alle Routinen für die vorhanden Interfaces des Webservers sind bereits im Applikationsbeispiel enthalten, siehe Applikationsbeispiel mit Bootloaderroutinen).
External Memory Interface
Da 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:
- 32kB SRAM: Adresse 0x0000-0x7FFF
- Wiznet Modul WIZ810MJ: Adresse 0x8000-0xFFFF
- USB FT245: beliebige Adresse zwischen 0xA000-0xAFFF (nicht genutzer Bereich des Wiznet Moduls)
Die gesamte Logikschaltung mit ausführlicher Dokumentierung kann hier heruntergeladen werden: Adresslogik für Webserver.pdf
USB
Der 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).
Übertragungsprotokoll
Das Ü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:
- START
- 0x1B reserviert für Daten aus AVR Studio
- anderes 8 bit Startbyte, das ungleich 0x1B ist, kann für USER Daten verwendet werden
- Sequence Number
- 8 bit breit
- Message Size 1
- MSB der Message Size (Anazhl der Datenbytes)
- Message Size 2
- LSB der Message Size (Anzahl der Datenbytes)
- Datenblock
- Messagesize (16bit) Datenbytes zu je 8bit
- Checksumme
- XOR aus allen Bytes einer Message (START, SeqNum, MsgSize1, MsgSize2, DATA)
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.
Probleme an FT245 Pins TXE und RXF
Beim Testen der Platine und des FT245 hat sich herausgestellt, dass nach dem Anstecken 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 Bootloader) interruptgesteuert 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.
UART RS232
Auf 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
CAN
- Hardware SPI
- MCP2515
- CAN Transceiver
- Galvanische Trennung mit DC-DC Wandler und Optokoppler
- Latch, für SD nötig
SD-Karte
- Hardware-SPI
- Latch, damit CS auf low bleibt
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
Software SPI
Da 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.