Hallo Forum, ich habe da so eine Idee, welche mich nicht losläßt.... Es existieren doch so schöne RS232 nach TCP/IP Konverter von Lantronix, DIGI, etc. Wenn nun an der RS232 Seite HTML-formatierte Strings von einem Mikrokontroller gesendet werden, könnte mann doch so wunderbar und sehr einfach und preiswert Meßwerte etc. direkt in/als Webseiten darstellen, wenn man mit einem beliebigen Browser darauf zugreift. Der Rückweg sollte mit entsprechenden GET/POST Methoden auch funktionieren; also Steuern via Webinterface. Könnte man das mit Eurem Know How einmal diskutieren und in die Tat umsetzen ? Ich experimentiere gerade eine wenig mit einem Lantronix XPORT/Atmega 8 und Bascom herum. Danke und liebe Grüße, Jasmin
Hallo Manos, ja, eigentlich ist es per Definition ein Webserver, aber nur ein ganz trivialer.... Reicht ja schon wenn er beim Abfragen einer Webseite diese auch anzeigt. Der HTML "Code" würde dann vom MC erzeugt. POST/GET würde doch schon ausreichen.. ?! Jasmin
Moin, beim Ursprungspost fielen mir spontal zwei Donge ein: - gibts schon .... nennt sich Webserver -> siehe Webserver mit Atmega32 - warum einfach wenn es auch kompliziert geht. Der XPORT hat einen eingebauten Webserver ...
Wirus ???!!! entschuldige, aber soooo gibt es das NICHT ! Natürlich existieren diverse MC basierende "Webserver" auf Basis von MC's, aber: Das ist alles recht überladen, wenn ich wie beschrieben einfach nur Meßwerte darstellen, resp. einlesen möchte. Der XPORT hat mich knapp 40 gekostet; Inbetriebnahme 10 Minuten. Unschlagbar, oder !? Der Webserver dient erst einmal auschließlich der Konfiguration des XPORT. Erst vermöge des SDK's (habe ich mich intensiv mit beschäftigt) und recht komplexer JAVA Programmierung könnte ich den entsprechnd anpassen. "Also warum einfach wenn's auch kompliziert geht ???????" Ich bin halte ein Mädchen mit pragmatischen Ansätzen ;-). Jasmin
Ich beschäftige mich gerade mit dem selben Problem, siehe hier: http://www.mikrocontroller.net/forum/read-1-350576.html#new Ein netter Benutzer dieses Forums und ich sind über diesen Thread gestolpert: http://www.mikrocontroller.net/forum/read-1-247578.html Gruss Thomas
Thomas, das scheint ja wohl leider im Sande verlaufen zu sein. Oder "D.S" hat die Lösung parat ? Jasmin
Naja, der Ansatz scheint zu funktionieren, ich konnte das "Hallo Welt" auf meinem Browser darstellen. :o) Ich weiss leider nicht, wer dieser D.S. ist. Ich denke, das sollte man schon zum laufen bringen, ist halt wieder etwas Fleissarbeit. Gruss Thomas
Aber Peter, die machen das doch eben genau NICHT so. Oder habe ich da was überlesen ? Peter, kannst Du uns bitte Deine Ergebnisse zur Verfügung stellen ? Also den Code für Deinen MC welcher die HTML-Seite generiert ? Funktioniert das mit jedem (IE, Firefox) Browser ? Jasmin,... geht jetzt zur Arbeit
Thomas Berger, (sorry nicht Peter) kannst Du uns bitte Deine Ergebnisse zur Verfügung stellen ? Also den Code für Deinen MC welcher die HTML-Seite generiert ? Funktioniert das mit jedem (IE, Firefox) Browser ? Wenn ich wieder zeitlich etwas Luft habe, werde ich auch etwas testen ! Jasmin,... geht jetzt zur Arbeit
Jasmin: Zur Zeit ist noch kein Code vorhanden, ich habe den XPort über Com1 an den Rechner angeschlossen und sende ganz einfach die Textdatei an die serielle Schnittstelle. Das war gestern erst ein Test.
In der neuen c't 11/2006 S. 67 ist ein RS232 zu Ethernet-Wandler "kurz vorgestellt" den www.elektronikladen.de vertreibt, mit einem ATMega64L und einem Ethernet-Chip auf 50*32mm (ohne RJ45-Buchse). Im Text noch ein Hinweis auf frühere Besprechungen ähnlicher Produkte. Preise um 40-70Euro. Hersteller Sollae Systems www.eztcp.com
Hallo, wieder online... Gibt es noch jemanden der etwas konstruktives zu dem Thema beitragen kann ? Ich wollte keine Diskussion über bestehende Lösungen eztp oder ähnlich beginnen. Das es einige Devices TCP nach RS232 und umgekehrt gibt, kann man sich schnell ergooglen..........;-(... Mich wundert es ein wenig, das keiner den pragmatischen und höchst nützlichen Ansatz sieht, um MC Schaltungen so WEB zu enablen wie hier angedacht. Jasmin
@Jasmin: Fehlt bei deiner Überlegung nicht noch das Hypertext-Transfer-Protocol, als Aufsatz auf das TCP/IP? Und wo gibst den Xport für 40Euro?
Hallo Jasmin, _"RS232 nach HTTP/HTML Konverter"_ das ist ein sehr interessantes Thema. Mir schwebt schon lange ein eigener WEB-SERVER vor. (Messdaten abfragen und Steuerbefehle senden) Traute mich nur noch nicht an dies Materie heran, da ich mich mit zwei Grundproblemen noch nicht auseinandersetzen konnte. 1. Problem: Die Harware, wie müssen die TCP/IP-Signale für den µC aufbereitet werden. 2. Problem: Wie müss das TCP/IP-Protokoll aufgebaut sein Einfach etwas nachbauen, ohne Grundlagen, in der Hoffnung, dass es auch funktioniert, ist nicht meine Lebenseinstellung. Bernhard Bernhard
Bernhard, den Zusatz der philosophischen Betrachtung im Sinne von "Einfach etwas nachbauen, ohne Grundlagen, in der Hoffnung, dass es auch funktioniert, ist nicht meine Lebenseinstellung" verstehe ich nicht. Ich kann Dich dennoch um Deine 2 Probleme erleichtern, denn um all das mußt Du Dich ja gar nicht mehr kümmern weil es der XPORT (oder ein ähnliches Gerät ;-( ) ja schon alles für Dich erledigt ! Der MC stellt eine simple HTML Seite als ASCII String an der RS232 Port des XPORT zur Verfügung. Der Text kann hier bereits Meßwerte des Controller's enthalten. Auf der anderen Seite verbindet sich ein Webbrowser mit der IP des XPORT vorzugsweise auf Port 80 (HTTP). Schwups sendet der MC seinen ASCII String und schon zeigt Dein Browser eine beliebig schick oder schlicht formatierte Webseite mit Meßdaten Deine Wahl ! Den XPORT habe ich übrigens über meine Firma (Arbeitgeber) und nicht als Privatperson für deutlich unter 50 erworben (sogar die SSL Variante). Der Rückweg (Steuerungsanforderungen an den MC) sollte mit enstprechenden HTML Methoden wie PUT etc. auch leicht zu implementieren sein. Jasmin
Darauf kann man aufbauen ! "mehr" muß nicht umgesetzt werden. HTTP request The Hypertext Transfer Protocol (HTTP) defines a request-response mechanism for obtaining documents from a web server. The web browser sends a request to the server in the form of a multi-line string, each line being terminated with Carriage Return and Line Feed (<CR> and <LF>) characters. The first line specifies an upper-case "method" (that is, command), followed by an argument string. The most common method is "GET," followed by a filename to be fetched, and a protocol version identifier. Subsequent lines contain additional information about the browser configuration: GET /index.htm HTTP/1.0 User-Agent: Mozilla/4.5 [en] (Win95; I) Pragma: no-cache Host: 10.1.1.11 Accept: image/gif, image/x- xbitmap, image/jpeg, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 If we're keen to keep memory usage to a minimum, the question must be asked: what use is the additional information? We don't care about the type of browser, our server hasn't got sufficient resources to maintain a cache or an access log, and if the file we're sending has an unacceptable character set, there's nothing that can be done about it. Even the HTTP version number on the first line isn't needed; we're planning to use the simplest HTTP interface anyway. It would seem that we can chop off the remainder of the command after the filename, without losing any functionality, but what is the maximum length of the filename? Surprisingly, this is largely under the control of the server, for the following reason: when the user wishes to access the server for the first time, an IP address is entered into a browser window, such as: http://172.16.1.2 The web client (browser) locates the given address, and submits the request to that server using a null filename: GET / HTTP/1.0 By convention, most web servers interpret this as a request for the default index file, which is INDEX.HTM or INDEX.HTML. This, in turn, contains pointers to other files on the server. While the user clicks on pages we've provided, they will only be requesting filenames we've defined, so if we keep these short, we won't have to handle any long filenames. A possible exception to this rule would occur if we included any HTML forms on our server. When a form is submitted, all the state-information is appended to the filename, making a much longer string. Various other difficulties are associated with forms-handling on a very small web server, so for the time being, we'll assume that forms aren't being used. HTTP response The response from the server to the client consists of an HTTP header, and, if the request succeeded, the document itself. The header consists of several text lines, each terminated with a <CR> <LF> delimiter. The header is separated from the document's contents by a single blank line. As a minimum, the header must identify the HTTP protocol version, the success or failure status, and the content-type of the document (plain text, HTML, GIF graphic). For example: HTTP/1.0 200 OK Content-type: text/html <html> <head>Test page</head> <body>This is a test page</body> </html> Unfortunately, it isn't possible to send out the same HTTP header for all files; it must be adapted to reflect the file's contents. A minimum list of file formats would be: text/plain text/html image/gif though it would be highly desirable to add other formats to the list. If the client's request fails, an appropriate HTTP error message must be sent out, and it is also desirable to send out a document explaining the problem, so that the browser has something to display. The simplest explanation could be in the form of a plain text document, which has no fancy formatting: HTTP/1.0 404 Not found Content-type: text/plain File 'abc.htm' not found
Bitte konkretisiere doch mal die angedachte Aufgabe. Wie hoch ist die Datenrate in beide Transferrichtungen, wie soll die Darstellung im Browser sein, Messkurven, Text, Tortendiagramme ? Wie oft muß der Browser aktualisieren, sind das Oszillogramme in quasi Echtzeit? Ich denke, erst dann kann man entscheiden, ob ATmega und XPORT die passende Lösung sind, oder ob es zwei Nummern kleiner oder größer sein muß. Der XPORT mit 48 MHz 80186 und 256kSRMA/512k Flash nur als Hilfsarbeiter für einen 8-Bitter ist ähnlich seltsam wie der "USBwiz", der einem 8-Bitter zu einer USB-Hostschnittstelle verhilft, mittels Philips-ARM-Prozessor. 73 Christoph
Christoph: Da ich den XPort und den ATMega schon hier habe, macht es für mich schon Sinn, diese zu verwenden. Das ganze kann später auch für andere Anwendungen verwendet werden, es wird ja nur der UART verwendet. Ob das so in euren Augen Sinn macht oder nicht, ist mir egal, es geht mir nur um das basteln. Wenn ich später noch Freude daran habe, kann ich immer noch einen Schritt weiter gehen und den TCP/IP-Stack implementieren und einen Realtek Chip oder WTW nehmen. Jasmin: Ich habe gestern mit einem kleinen Testprogramm begonnen, welches den HTTP-Server bilden wird. Das ganze wird in C geschrieben und im Moment verwende ich einen 90s8515, da ich für diesen noch ein Experimentiertboard hier liegen habe. Der Code kann aber leicht für einen Mega8 portiert werden. Leider bin ich diese Woche "leicht" im Stress, ich melde mich wieder bei neuen Ergebnissen. Gruss Thomas
Hallo Thomas Ja fürs Hobby spielen die Kosten und die Frage wie sinnvol das ist erstmal keine Rolle. Euer Projekt erinnert mich am ehesten an die Laserdrucker hier im Firmannetz, die melden sich alle im Browser. Ich kann den Papier- und Tonerstand abfragen und den Druckstatus, eine Statistik und so weiter. Wenn man "Hilfe" anklickt wird man ins Internet zum Hersteller verbunden
Mehr soll das Teil (am Anfang) auch nicht machen, nur die gemessenen Daten als Website mit Text und Zahlen darstellen.
Hallo zusammen, hallo Christoph Kessler , "Der XPORT mit 48 MHz 80186 und 256kSRMA/512k Flash nur als Hilfsarbeiter für einen 8-Bitter ist ähnlich seltsam wie der "USBwiz", der einem 8-Bitter zu einer USB-Hostschnittstelle verhilft, mittels Philips-ARM-Prozessor." " Der von Dir so despektierlich beschriebene Hilfsarbeiter erledigt hier den gesamten IP-Stack, mit SSL-Verschlüsselung, DHCP, NTP, TCP/UDP... ich habe bstimmt noch etwas vergessen.... Somit ist er ein absoluter High Tech Hilfsarbeiter dessen Fähigkeiten ich mich gern bediene. Unter http://www.hw-group.com/products/hw_vsp/index_en.html Mit einer Übertragungsrate von um die 900 kbit/s schaufelt der schon einiges an HTML formatierten ASCII-Daten über die Leitung ist also für die Übertragung von Meßdaten völligst ausreichend. Thomas, ich habe gerade auch etwas mit Bascom zusammengebaut, was schon grundsätzlich funktioniert ! (Es soll hier einige oberschlaue BASCOM-Hasser geben, bitte haltet Euch aus diesem Thread heraus ;-( .... ,es scheint schon schwierig genug transparent zu machen, welche potentiale hinter solch einer pragmatisch einfachen Lösung liegen und wie somit das "WEBENABLEN" von MC's kinderleicht und sehr preiswert wird ). Wenn ich etwas vorzeigbares habe, werde ich es hier umgehend zur Verfügung stellen. Unter http://www.hw-group.com/products/hw_vsp/index_en.html findet man übrigens eine Softwarelösung für einen virtuelle COM-Port nach TCP/IP Wandler. Damit kann jeder an der Lösung mitarbeiten auch wenn er keinen XPORT oder ähnlich besitzt ! jasmin
Ich bin nicht ein grosser Fan von Basic, daher nehme ich lieber C. ;o)
Hallo Jasmin Ich verfolge den selben Ansatz wie du. Ich habe einen TCP/IP Converter (Linkcom Xpress) den ich für einen einfachst Webserver einsetzen möchte. Ein AVR soll die HTML Daten interpretieren resp. generieren. Ich möchte nur die Temperatur und eine Schaltzustand im Web anzeigen. Ich bin am noch am suchen von Informationen und bin gespannt, was hier noch für Lösungen diskutiert werden.
@ Broadcast, Stunkfille ??? Na, ja ..vielleicht dann über's Wochenende, wenn das Wetter mies ist und mein Freund nervt !? Jasmin
Eine Beschreibung für einen einfachen Webserver hier: http://www.embedded.com/story/OEG20010312S0103
Hallo Jasmin, Ich habe dieses WE endlich Zeit gefunden um zu basteln.:o) Soweit habe ich nun einen rudimentären HTTP-Server, welcher auf Anfrage eine Webseite senden kann. Ich habe aber noch ein kleines Problem: Der Browser lädt "ewig" nach, ich habe im Moment noch keine Idee, wie ich die Verbindung als beendet erklären kann. Ich sende nach der html-Datei zusätzlich ein CR und LF, dann werden keine Daten mehr über den UART geschickt, der Browser scheint aber noch auf etwas zu warten. Der zweite Punkt ist, dass ich die Webseite nur explizit auf dem Port 10001 aufrufen kann. Ich denke aber, dass ich dies in den Einstellungen des XPort noch ändern kann. Gruss Thomas
Hallo Thomas,
ich kann mir das nicht so recht vorstellen was du beschreibst.
Was meinst du mit "er lädt ewig nach" ?
Ich habe das Wochenende damit verbracht den XPORT mit neuer Firmware,
neuen COB-Dateien und neuen Tools aufzupeppen.
(lohnt sich übrigens !!)
Du kannst den Port (Standard 10001) beliebig verschieben.
Ich habe ihn auf Port 80 gelegt und den für die Webverwaltung auf port
443.
Mache mal ein Telnet in folgender Syntax:
telnet pabu19.dyndns.org 80
Damit landest Du bei mir im Keller ;-)
Das ist ein Xport den ich ins Internet gehängt habe.
Am seriellen Port hängt ein STK 500 und ein Atmega 8 macht nichts
anderes als die eingegangenen Zeichen als Echo zurückzusenden.
Der Xport kann immer nur eine zeitgleiche Verbindung ab, könnte also
mal besetzt sein ......
Wenn Du magst, sende doch einmal den Code Deines HTML-Servers.
Den könnte ich dann einmal hier dranhängen !
Ich werde am Wochenende nicht daran arbeiten können, da ich auf einer
Sportfreizeit unterwegs bin (macht auch Spass !!).
Jasmin
Woher habt Ihr Eure Informationen zum XPORT? Lantronix hat da irgendwie nichts. >Ich werde am Wochenende nicht daran arbeiten können, da ich auf einer >Sportfreizeit unterwegs bin (macht auch Spass !!). Viel Spaß.
Hallo, Lantronix hält jegliche Informationen zum Download auf der Webseite vor; http://www.lantronix.com Welche Informationen suchen Sie denn ? Bart Henson
Wie bekomme ich den HTML-Server zum Laufen? Die Datenblätter etc. beschreiben immer nur die Konfiguration als RS232-Verlängerung.
hallo, entschuldige, aber du scheinst das gerät noch nicht so ganz zu verstehen ;-). lese dir die gute dokumentation durch... der html server läuft immer (default port 80, für die konfiguration). in diesem thread diskutieren wir aber andere dinge, oder was ist deine intention ? Jasmin
Gut, wieder eine Unklarheit beseitigt. Wie bekomme ich da dann eine HTML-Seite drauf? (In welchem Dokument findet man da was?) Auf der ct'-Seite werden zwar auch Probleme geschildert, aber Ergebnisse scheinen nicht präsentiert zu werden.
Hallo Jasmin, Der Fehler war so ähnlich, wie wenn die Webseite falsch ist, wenn z.B. das </html> Tag fehlt. Der Browser wartet auf Daten, es kommt aber nix mehr. Ich habe das Problem mit dem "laden" behoben. :o) ich habe die Angaben für die Grösse der html-Daten nicht korret angegeben, daher fehlten dem Browser noch ein paar Zeichen, welche nicht mehr gesendet wurden. nun funzt die Sache. Deinen "Telnet-Echo-Server" werde ich heute Abend noch testen. Gruss Thomas
Hi zusammen, hier mal mein senf ;) : System1 sendet über die 232 den Wert "www1234" Der 232 auf Ethernet converter sendet die daten weiter via Ethernet und den Port 4000 etwas an den RemoteServer mit der IP 192.168.1.100. Auf dem Remot-Server läuft ein Programm welches die Daten des Ports 4000 in eine Datei schreibt. Die index.php liest die daten aus und zeigt die messwerte an.... fertig :) habe ich alles richtig verstanden ?
Marek: Nö, in die andere Richtung. Ich gebe in meinem Browser die IP des Xport an und der AVR generiert mir die Webseite, welche ich im Browser sehe. Deine Variante wäre auch machbar, ist aber nicht das, was ich möchte. Gruss Thomas
@Rahul was Du da möchtest ist genau der Weg den wir eben nicht gehen wollen. Willst Du so an die Sache ran, dann besorge dir das SDK von Lantronix und programmiere in java (wie im C't-Projekt)..... Wie Thomas gerade Marek beschrieben hat soll es laufen. Ganz einfach; der MC sendet auf Browserrequest eine HTML-Seite an die serielle Schnittstelle und der Browser holt das ganze dann ab und stellt es dar. Hier bietet sich dannn die gesamte HTML Vielfalt inclusive der Möglichkeit auch java script einzusetzen.... aber das ist wieder nur für "schön". @Thomas Der Rückweg; also Steuerbefehle vom Browser an den Xport und somit an den MC zu senden muß auch funktionieren (HTML PUT oder ähnliche Methoden; siehe selfhtml). Dann kann man über den Browser auch "seine Heizung" fernsteuern. Ich habe übrigens den Xport 3, dann kann das ganze auch via SSL laufen und wird somit sicher ! In den MC könnte man sogar eine Passwortabfrage einbauen, oder mit SSL Clientzertifikaten arbeiten ;-) fein, fein .. Jasmin (von der Arbeit ..;-( )
Hallo Besucher, der Testlink "telnet pabu19.dyndns.org 80" ist wegen heftiger Lötarbeiten momentan offline. Ich hoffe bald mit echten Ergebnissen wieder "online" zu sein. @ Thomas, kannst Du mit dem Quelltext Deiner bisherigen Versuche etwas beisteuern ? info at key-it.de, oder hier im Forum.. Ich stelle meine "Ergüsse" auch zur Verfügung. Jasmin... fährt jetzt bis Montag in Urlaub......
Jasmin: Kann ich machen, aber erst am Sonntag. Ich bin gerade eine etwas interessantere Variante am basteln, welche auf dem atmega8 läuft und die ADC-Kanäle auslesen wird. Ist aber, wie bereits erwähnt alles in C. Gruss Thomas
Guten Abend, Ich habe nun die erste Version meines XPort Webservers fertig gestellt. :o) Die Quellen sind im angefügten Zip-File verfügbar. Es handelt sich dabei erst um eine sehr primitive Variante, die Einkommenden Daten des Browsers werden noch nicht überprüft. Es wird auf jede Anfrage direkt der HTTP-Header und die Webseite geschickt. Die Webseite selber ist in einem Array abgelegt.
1 | char Page[] = { |
2 | "<html><head><title>XPort Webserver 1.0beta</title>\
|
3 | </head>\n\ |
4 | <body bgcolor=\"#507EAE\">\ |
5 | <font size=\"5\" face=\"helvetica,arial\" |
6 | color=\"#FFFFFF\">\ |
7 | <b>XPort Webserver, 1.0beta</b><br><br>\
|
8 | Uptime: $UPTIME s<br><br>\
|
9 | ADC0: $ADC0<br>\
|
10 | ADC1: $ADC1<br>\
|
11 | ADC2: $ADC2<br>\
|
12 | ADC3: $ADC3<br>\
|
13 | ADC4: $ADC4<br>\
|
14 | ADC5: $ADC5<br>\
|
15 | </font>\
|
16 | </body></html>\n" |
17 | }
|
Variablen (Mit einem $ gekennzeichnet) werden beim senden der Seite dynamisch durch den Zahlenwert ersetzt. Ein grosses Problem ist dass die Variable "char Page[]" eine gewisse Grösse nicht überschreiten darf, ansonsten funzt das Programm nicht mehr richtig. Beim Kompilieren gibt es keine Fehlermeldung, das Programm läuft aber nicht mehr. nach etlichen Stunden suchen kam ich darauf, dass das Problem einen Zusammenhang mit den Char Array hat, ich weiss aber noch nicht wieso und bin somit für Tipps sehr dankbar. Ich werde diese Woche noch weiter daran basteln und die neuen Ergebnisse hier posten. Gruss Thomas
Dein char-Array wird nicht nur ins Flash-ROM geschrieben, sondern beim Start des Programmes aus selbigen ins RAM kopiert, damit mit den üblichen C-Funktionen darauf zugegriffen werden kann. Das RAM ist aber bei Deinem Prozessor (mega8 steht wohl im Makefile) nicht sonderlich groß ... Das dürfte Dein Größenproblem erklären.
Rufus: Danke, ich habe etwas gegoogelt: Mit dem Attribut "PROGMEM" werden die Daten dann direkt aus dem Flash gelesen. Das habe ich kurz Probiert, es erscheint aber nun eine Warnung, wenn ich das Array übergebe, das sollte ich vieleicht mit einer "const" Deklaration lösen können. Ich werde morgen weiter suchen. Gruss Thomas
Oha, das wird doch etwas komplexer, als nur das Attribut zu setzen... Um die Daten aus dem Flash zu lesen, muss man pgm_read_byte() verwenden. D.h. ich muss Funktionen wie "strcat" mit einer ersetzen, welche diese verwendet, sehe ich das richtig? Gruss Thomas
Wie macht ihr das mit der IP-Nummer des Webservers? Ich meine, man müsste einen DynDNS-Account einrichten. Das Progr. DynDNS-Updater dient zum Abgleich einer dynamischen IP Adresse mit einer festen Domain Adresse und läuft auf dem PC. Wie geht das mit einem Webserver wie hier diskutiert? Muss man eine feste IP-Nummer beim Provider beantragen? Das kostet!
Wenn Du Deinen Inet-Zugang ueber einen Router machst, kannst Du dort meist die Anmeldung beim DynDNS-Server durchführen lassen. Ansonsten hilft es wohl nichts und Du muisst diese Anmeldung auch ueber den uC machen...
Hallo Guido, ja dyndns oder ähnlich.... Aber für interne Zwecke ist das natürlich nicht nötig und wer es "kommerziell" einsetzen möchte wird wohl "etwas frei haben". Portforwarding würde ja auch schon genügen und keine IP Adresse belegen. Ich habe aber eine feste ip bei meiner Flatrate von VIA dazubekommen. War "umsonst", schau mal nach ob das Angebot noch steht (viadsl). Ich bekomme sogar interessante Rabatte, also wenn jemand soetwas benötigt könntet ihr mich anfragen. @thomas Mit Bascom ist das (Flash-Zugriffe) ganz einfach ;-)..... Wenn ich einen kompletten Überblick über Deine Implementierung bekommen möchte, soll ich dann alle *.c Dateien ausdrucken, oder wie bekomme ich den Zusammenhang hin ? Ich poste in den nächsten Tagen einmal meine "Codeschnipsel); nix aktuelles aber funktionierte schon vor einem halben Jahr.. Jasmin
Was meinst du mit Zusammenhang? Flash zugriffe sind in C auch einfach, man muss halt erst wissen wie. ;o)
@Thomas, ich meine damit einen "zusammenhängenden" Quellcode. Aber bemühe Dich nicht weiter. Das soll ja kein Nachilfethread für C-Programmierung sein ;-) Dennoch: Wann sendet denn Dein Controller die Webseite an den Xport ? Wodurch "fühlt" er sich angesprochen ? Vielleicht komme ich mit diesen Hinweisen weiter. Jasmin
Zitat von Jasmin: Ich poste in den nächsten Tagen einmal meine "Codeschnipsel); nix aktuelles aber funktionierte schon vor einem halben Jahr.. Gerne, würde mich auch interessieren. Was ich noch nicht wußte: eine Html-Seite wird durch eine extere Geschichte aktuallisiert? Wie und wie löst man das in Bascom? Bitte um die Codebeispiele. Danke im Vorraus MfG
@Bernd, Bascom, oder was auch immer, ist da erst mal aussen vor. Metatags (siehe Selfhtml) refreshen (fordern an) die Webseite automatisch in beliebigen Intervallen. Jasmin
Guten Abend Bernd: Für das Refresh muss im Header der Html-Seite <meta http-equiv="refresh" content="30;URL="> eingetragen werden. Somit wird die Seite alle 30Sek aktualisiert. Durch probieren habe ich herausgefunden, dass wenn ich keine Url angebe, die aktuelle Seite wieder geladen wird. Jasmin: In der Datei interrupts.c ist die Funktionen SIGNAL (SIG_UART_RECV). Nach dem das letzte Zeichen über den UART empfangen wurde wird nach 400ms in der Funkton SIGNAL (SIG_OUTPUT_COMPARE1A) die Funktion web_init() und anschliessend web_sendchar() auf gerufen. Dort wird ein Zeichen des HTTP-Headers oder der Webseite gesendet. nach dem das Zeichen gesendet wurde, wird SIGNAL (SIG_UART_TRANS) auf gerufen, welche dann wieder web_sendchar() aufruft, bis die komplette Seite gesendet wurde. Die SIGNAL-Funktionen sind für Interrupts. SIGNAL (SIG_OUTPUT_COMPARE1A) ist bei mir so eingestellt, dass alle 100us ein Interrupt ausgelöst wird, daraus kann ich dann eine Zeitinformation (z.B. den Uptime-Counter) ableiten. Das mit den Daten aus dem Flash funzt. Ich arbeite nun meine Todo-Liste ab, wobei diese ständig weiter am wachsen ist, weil mir immer neue Ideen einfallen. :o) Gruss Thomas
Thomas, wenn ich das richtig verstehe, kümmerst du dich eigentlich überhaupt nicht um die http konventionen. Du wartest also bis der browser sein letztes zeichen gesendet hat und antwortest dann nach 400 ms mit dem senden (d)einer html seite. Was passiert wenn der browser eigendeinen müll sendet, oder an einer anderen stelle etwas schief läuft. Mann könnte sich natürlich auf den transport-layer (tcp/ip) verlassen aber ...., kann natürlich noch auf der seriellen übertragung etwas passieren ???? Wäre es nicht besser das relativ einfache HTTP Protokoll zu berücksichtigen ? Ich habe einfach den string "GET / HTTP/1.0" resp. das GET am anfang und das HTTP/1.0 am ende herausgefiltert und als korrekte browseranfrage interpretiert. ALLE zeichen danach bis zu einem erneuten GET / HTTP/1.0 können dann ignoriert werden, allerdings fehlt eine wirkliche "ENDE-Meldung" der GET-methode..... Da scheint dein profanes 400 ms warten nicht schlecht. Ist aber eben nicht ganz schlüssig bezüglich des protokolls. ICH HABE ALLERDINGS AUCH KEINE BESSERE IDEE ! Jasmin
Thomas, hier die Lösung zu meiner Bemerkung: Browser sendet beispielsweise: GET /infotext.html HTTP/1.1 Sobald der Header mit einer Leerzeile abgeschlossen wird, sendet dann der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Also fängt der Anfang des Browserrquest immer mit "GET ......HTTP/X.X gefolgt von crlf an. Das Ende des Browserrequests wird definitiv über eine Leerzeile mit crlf (0XD,0XA)am Ende signalisiert. Dazwischen können beliebig viel Zeichen stehen. Jasmin Quelle: http://de.wikipedia.org/wiki/HTTP#Argument.C3.BCbertragung
Hallo, auf der Webseite http://web-sniffer.net/ kann man wunderbar den Protokollaufbau mit den steuerzeichen erkennen. Hier ein Aufruf einer Webseite: HTTP Request Header Connect to 194.231.228.187 on port 80 ... ok GET / HTTP/1.1[CRLF] Host: www.key-it.de[CRLF] Connection: close[CRLF] Accept-Encoding: gzip[CRLF] Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*[CRLF] Accept-Language: de[CRLF] User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Web-Sniffer/1.0.24[CRLF] Referer: http://web-sniffer.net/[CRLF] [CRLF] Hier kann man also wunderbar den Aufbau nebst Steuerzeichen erkennen. Jasmin
Jasmin: Wie gesagt, es ist erst eine primitive Version eines HTTP-Servers. ;o) Wie die Seite angefordert wird habe ich bereits an der seriellen Leitung einem Terminal Programm "ausgemessen" und im Internet gelesen, nur noch nicht implementiert. Das wird der nächste Schritt werden. Zum senden von Kommandos (Schalten von Ausgängen usw.) muss ich die eintreffenden Daten analysieren und Je nach Kommando reagieren. Der Trick mit der 400ms Verzögerung ist nur ein provisorium. Dies war in meinen Augen der einfachste Weg. Gruss Thomas
Thomas, wenn es nicht schon so spät wäre, würde ich in den Keller gehen und meinen PC anwerfen,,,,;-) Die sich ergebenden Möglichkeiten sind doch schon toll, oder ? Und das alles mit nem "billigen Xport o.ä.". Wundersam, das so wenige mitziehen. Ich hoffe mich auch bald wieder produktiver eingeben zu können; Die Arbeit frißt mich gerade etwas auf ........... Deine Vorgehensweise finde ich pragmatisch sympatisch. Ich pflege meist auch erst den einfacheren Weg zu gehen... Der Rest folg später. Jasmin
Tja, ich denke es ist halt einfacher, wenn ich eine Baustelle nach der anderen bearbeite als an mehreren Stellen zu beginnen. Ein weiterer Vorteil ist, dass ich nun relativ einfach Variablen auslesen kann: Einfach in den HTML-Code einbauen und ausgeben. Dies erleichtert sehr die Fehlersuche. Gruss Thomas
>Wundersam, das so wenige mitziehen.
Interessantes Thema, an dem ich mich auch beteiligen würde, wenn ich
nicht ein anderes Projekt hätte.
Zum Thema "preiswert" fällt mir immer wieder der Siteplayer von
Netmedia ein. Mit dem habe ich damals meine Diplomarbeit gemacht und
erweitere das Projekt jetzt um eine UDP-Steuerung...
Einen XPort habe ich auch noch irgendwo rumliegen...
Eigentlich müsste es doch gehen, die festen Bestandteile der Website im
Flash abzulegen byteweise zu senden, und die Sachen, die durch das "$"
markiert werden (netmedia benutzt dafür das "^") während dieser
Sendung an den XPort aus dem SRAM zu lesen. Damit würde man sich ein
paar SRAM-Zellen sparen...
Rahul: Mit einem Java-Applet kann man so etwas realisieren. Ich möchte aber eine Java freie Lösung. Falls du eine andere Lösung gefunden hast, wäre das schon interessant. Gruss Thomas
>Mit einem Java-Applet kann man so etwas realisieren.
Bäh! JAVA!
(war das verständlich?) ;-)
Rahul, Thomas, ich habe mich gerade einmal 10 Minuten mit dem Siteplayer beschäftigt. (Tochter macht noch heia...) Also das Prinzip ist hier genau das, was Thomas und ich ja gerade so mit dem Xport umsetzen. Die Doku zum Siteplayer ist klasse, geht sogar genau auf solche Probleme ein die ich mit der Umsetzung am Xport habe. Ein super Fundus zum Knowledgetransfer ! Danke Rahul... Wo habt Ihr den damals bezogen ? @JAVA: Möchten wir hier an dieser Stelle einfach vermeiden, weil gar nicht nötig ! Jasmin
Einziger Vertrieb in D scheint Lascar.com zu sein. Siteplayer für ca. 30 Euro + 8 Euro RJ45-Trafodose + Versandkosten... JAVA ist mir zu bunt...
Java geht nicht mit lynx. ;o) Ich werde das PDFin der Pause mal anschauen, danke!
Nein, Scherz beiseite, ich möchte etwas, das man mit jedem Browser bedienen kann, also etwas ohne Java-Zeugs. Und wenn das mit Lynx klappt, dann wohl mit jedem Browser.
Hallo, ich bevorzuge übrigens auch nur reine Text E-Mails. HTML Mails nehme ich erst gar nicht an..... Lynx ist klasse, ebenso eine bash oder ksh... Puristen gibt es überall ! Jasmin ;-)
Wenn man seine ersten PC-Erfahrungen auf DOS-Maschinen gemacht hat (Ende der 1980er), wird man auch gerne "Tastenkombinationsfuzzi" von den "Mäuseschubsern" genannt... (Hat jetzt nicht wirklich was mit dem Thread zu tun)
Jasmin: Ich habe gestern damit begonnen, das generieren der HTML-Seite zu verbessern. Im Moment ist die Grösse der Seite auf die Grösse des Ausgabebuffers beschränkt. Neu wird die Ausgabe in einzelne Blöcke unterteilt, dies schont die RAM-Resourcen erheblich (im Prinzip gibt es so kein Grössenlimit mehr, ausser die Grösse des Flash/EEprom). Auch kann man so in Zukunft grössere Bilder (z.B. eine generierte Messkurve) übertragen, oder Dokumente aus einem externen Speicher. Hast du dich schon tiefer mit den Anfragen des Browsers an den Server beschäftigt? Als nächster Schritt möchte ich gerne die Eintreffenden Kommandos interpretieren. Wenn man auf bei einem Formular einen Knopf drückt (z.B. "Submit" hier im Forum), was wird dann genau an den Server geschickt? Gruss Thomas
>Wenn man auf bei einem Formular einen Knopf drückt (z.B. "Submit" >hier im Forum), was wird dann genau an den Server geschickt? Man bekommt die Seitenanfrage geschickt. Daran angehängt sind die Parameter und Werte. (Zumindest ist das beim Siteplayer so...) z.B. www.blafasel.org/index.html?Name=Mueller&Vorname=Horst&submit=submit auf selfhtml.org wird das Thema "Formulare" (zu denen der Submit-button gehört) schön beschrieben.
Hallo Thomas, ich werde etwas zur HTTP Verwurstelung an diesem Wochenende zur Verfügungs stellen (BASCOM). Lies einmal im Siteplayer Manual nach: http://www.siteplayer.com/docs/web_enable.pdf Dort ist es sehr scön erklärt, wie man mit der HTML input type Methode per submit Daten vom Browser an den Xport sendet und wie diese dann auch aussehen. Im übrigen sei nochmal erwähnt, dass der Siteplayer konzeptionell genau unsere Idee umsetzt. Selfhtml lohnt sich imer zum nachschauen. Jasmin
Ach ja, zum Schnüffeln hattest Du doch den seriellen Port angezapft (die 2. RS232 am PC ist Gold Wert !!!). Unicom von http://www.shamrock.de/dostools.htm ist dazu immer noch unübertroffen !!! Jasmin
Hallo, hier ein bischen Programmgerüst. Das ist ziemlich durcheinander, habe da auch schon seit Monaten nicht mehr draufgeschaut. Also bevor jemand überschnell Fragen stellt, bitte selber ein bischen Hirnschmalz reinstecken. Ich erinnere mich, das es mit Firefox problemloser lief als mit dem IE; warum weiß ich nicht. Bitte auf die CRLF Auswertung im HTTP Stream achten, scheint das A un O zu sein ;-) Jasmin
N'abend, ich benötige eure Hilfe.............. Wenn ich eine Datei im JPEG Format über die serielle schnittstelle senden möchte verlassen mich meine Ideen. Ich möchte dazu kein Filsystem auf dem AVR hinterlegen. Nehmen wir einmal an ich hätte die Datei im Binärformat irgendwo im Flash abgelegt... Na ja, bis dahin alles kein Problem, aber wie sende ich nun die Datei auf Anfrage des Browsers ab ? Jede Anregung ist willkommen ! Jasmin /D.S
Jasmin (oder Dietmar?): Ich habe deinen Code kurz angeguckt, bist du der Dietmar Steiner (DS) aus dem oben angesprochenen Thread? http://www.mikrocontroller.net/forum/read-1-247578.html Eure Notation scheint auf jeden Fall die selbe zu sein und beim whois auf key-it.de ist als Admin auch Dietmar Steiner eingetragen. Ist aber ne schlaue Idee, ist mir auch schon aufgefallen, dass man mit "Tittenbonus" mehr Antworten erhält. ;o) Zu den technischen Details: Ich habe bis jetzt noch kein Formular in Html gebastelt, ist aber eine gute Idee, ich kann eines auf den AVR Laden und dann abhorchen, was der Browser an den XPort sendet. Die Übertragung von Bildern ist(denke ich mal) das selbe wie von HTML-Seiten. Der Header muss sicher angepasst werden, so dass der Browser weiss, dass und welches Bild er empfängt. Mit den Bildern warte ich noch bis der Rest zu 100% funzt. Der Siteplayer scheint das selbe zu machen, was ich bis jetzt gelesen habe. Aber wer will den schon eine fertige Lösung? :oP Gruss Thomas
@ Thomas, mein comimg out !!! War aber ursächlich so gar nicht meine Intention mit dem XXX-Bonus zu spekulieren. Aber so richtig angebaggert wurde ich allerdings auch nicht ;-(. Wie Du aufgrund Deiner fachmännischen Recherchen feststellen kannst, ist die MC-Fummelei reiner Zeitvertreib für die wenig verbleibenden Wochenendstunden. Ich nehme mittlerweile an, das die JPEG Übertragung reines "Bitbanging" sein wird. Daher bei Browseranfrage einfach Byte für Byte ein JPEG übertragen...... Im Moment bekomme ich den Hintern nicht hoch, sprich keine 10 Minuten freie Zeit. Habe mir in den letzten Tagen neue Fenster mit Rolladenmotoren einbauen lassen (24 Stück !!). Auch wieder so ein MC-Thema. In jedem Rolladenkasten liegt schon ein CAT 5 Kabel (BUS). Testschaltung und Software ist schon fertig; für die ulrimative Rolladensteuerung... (RS485 Bus mit kleinen Atmega im Rolladenkasten und Steuereinheit mit größerem ATMEL). Die kann ich ja dann mit unserer Idee WEB-Enablen !!!! Gruß, "Jasmin", alias D.S.
Dietmar:
Kein Problem, in vielen technischen Foren gibt es xxx-Bonus. Wenn ein
Mann etwas fragt, dann heisst es, RTFM, benutz doch Google, das hatten
wir schon 1000mal....
Bei einer Frau werden gleich die Lösungen präsentiert... Zufall? Ich
weiss nicht... ;o)
Für Bilder muss im Header sicher der Content-Type angepasst werden,
irgend etwas wie "Content-Type: image/jpeg" und anschliessend das
Bild in einzelnen Bytes übertragen, das sollte schon alles sein. Ich
finden den Link nur nicht mehr, bei dem ich das gelesen habe.
> Aus welchem Teil der Republik stammst Du ?
Aus der Schweiz. :o)
Gruss Thomas
Guten Abend, ich habe die neue Variante für die Generierung der HTML-Seiten fertig gestellt, scheint soweit zu funzen. Nun hat mich die Neugierde doch gepackt und ich habe versucht, ein Bild in die Webseite einzubinden. So wie ich das bis jetzt verstanden habe, sendet der Browser die Anfrage für die Seite, diese wird vom HTTP-Server an den Browser geschickt. Nun müsste der Browser aber noch nach dem Bild "fragen", das macht er aber nicht. Googeln brint nicht viel, alle Beispiele die ich bis jetzt gefunden haben beschreiben nur, wie man eine Seite sendet, wie das mit den weiteren Dokumenten ablaufen sollte, habe ich keine Ahnung. Kann mir jemand einen Tipp oder einen Link geben, wo das beschrieben ist, ein Beispiel oder so? Gruss Thomas
das ist ein Interresantes Thema. Hat man da Mehr Frei Leistung übrig als beim RTL oder Schluckt der Xport noch mehr?
ich meinte Eignetlich ob der "HTTP-Server" viel Rechnenleistung braucht oder ist das nur die byts über die UART raus schieben? Gruß marco
.... es benötig fast keine "Rechenleistung". Reines schieben von Bytes... der Hardware UART der Atmels macht das mit links ! Jasmin
macht nichts. Wenn du meine Handschrift lesen würdest währe das normal das man da was anders liest.
Angehängte Dateien:
-
XPort_2006-06-08.jpg
1,3 MB
Ich bin wieder einen Schritt weiter, das übertragen von Bildern klappt nun auch. Da der Flash-Speicher im atmega8 etwas beschränkt ist, reichte es nur für ein Smilie. :o) Als nächsten Schritt muss ich unbedingt die Anfrage des Browsers analysieren. Der Trick, mit der Zeitverzögerung nach dem Senden der Daten vom Browser, ist nun definitiv nicht mehr brauchbar, hat sich für die ersten Versuche aber gut bewährt. Gruss Thomas
Angehängte Dateien:
-
XPort_2006-06-08.jpg
47 KB
Sorry, das obere Bild ist ein bmp, kein jpg... hier das richtige. Gruss Thomas
Hallo Thomas, wie funktioniert das nun prinzipiell mit der Dateiübertragung (JPEG)? Ich gehe davon aus, das Du kein Filesystem implementiert hast sondern es anders in den Griff bekommen hast.. Gruß Jasmin / DS
Der Browser "fragt" nach dem Bild, dann sende ich den HTTP-Header für ein Gif und anschliessend die Rohdaten. Der "Zahlenfriedhof" als Char Array abgelegt, wie die Webseite oder der Header. Gruss Thomas
Hallo, ich hab mal eine kleine Demo in C für einen Atmega8 programmiert. Es wird dabei die angefragte Datei zurückgegeben. In dem angefügten Beispiel sind 4 Test-HTML-Dateien enthalten. Bei Änderungen an den HTML-Seiten ist es wichtig die Content-Lenght anzupassen. Evtl. sollte man dazu doch mal ein kleines Programm schreiben (ich hab das im GCC-Forum schonmal geftragt und das Ganze mit sed probiert, aber das ist ja sowas von kryptisch...) Den Xport sollte man auch noch so anpassen, dass der Puffer nicht nach jedem Byte geleert wird. Ich habe mir die Übertragung eben mal mit Ethereal angeschaut und gesehen, dass der Xport in Werkseinstellung jedes Byte einzeln überträgt. Da jedes Byte in einen komplettes TCP-Paket gepackt wird ist das natürlich ein ziemlicher Overhead.
Seh grad, in den html-Dateien fehlt noch ein \r vor dem \n. Seltsamerweise funktioniert es bei mir auch nur im Firefox, aber wieso?
Thomas, das Problem hatte ich ja auch, Firefox funktioniert und IE nicht. Ich hatte und habe keine Idee. Wieseo SED ? Ich kenne SED Implementierungen nur von Unix/Linux. Wie willst Du mit dem Atmega ein SED Kommando absetzen ? Die Größe einer Datei in C zu ermitteln sollte doch eine KLeinigkeit sein; selbst wenn sie irgendwo im Flash steht und kein Filesystem zugrunde liegt. Meines Erachtens konnte man die contenth length , zumindest bei reinen html ohne Dateidownload völlig Mißachten. Oder wie sind Deine Erkenntnisse ? D.S.
Mit sed habe ich mir das so gedacht, eine normale nicht angepasste html-Seite mit sed z.B. über das makefile so anzupassen, dass es direkt mit einkompiliert werden kann. Also Sonderzeichen escapen, Newlines durch \n ersetzen etc. Die Content-Length aus dem Flash zu ermitteln ist nicht schwer. Jedoch hab ich ja auch die Funktion drin, in der Seite Werte dynamisch anzeigen zu lassen. Folglich müsste ich zumindest Teile der Seite im RAM aufbauen um die Länge zu bestimmen. Davon hat der Atmega8 aber nicht so viel. Ohne Angabe der Länge bleibt beim Firefox immmer der Ladebalken bestehen. So sieht es auch aus, wenn ich eine zu kleine Content-Length angebe. Warum es bei mir beim IE generell nicht funktioniert ist mir ein Rätsel. Wenn man sich das mit Ethereal anschaut werden auch die kompletten Daten übertragen. Auf irgendwas scheint er dann aber noch zu warten. Wenn ich herausgefunden habe, woran es liegt melde ich mich nochmal.
Der Content-Length-Header ist nicht zwingend notwendig. Normalerweise beendet der Server dann einfach die TCP Connection. Ich vermute, dass das Problem hier ist, dass genau das nicht passiert. Dann läuft das Teil in einen TCP-Timeout, der üblicherweise im Bereich 1-2 Stunden liegt ;)
@ Daniel, Thomas, genau das habe ich so auch beobachtet, wenngleich die Timeouts nur ca. 10-15 Minuten dauerten. Ich meine auch gelesen zu haben, das dies von der Version des HTTP Protokolls abhängt. Neuere Versionen arbeiten "zustandslos", daher wird die TCP Verbindung sofort beendet. Vielleicht gibt es auch ein Metatag mit "Hangup-Funktion". Aber im Grunde bin ich ziemlich sicher, das der Header eben nicht erforderlich ist, also können evtl. Probleme nicht daher rühren. Generell kritisch sind immer die nötigen CR/LF und die Leerzeile mit CR/LF am Ende. Offenbar reagieren da die Browser etwas unterschiedlich. Kann das jemand so bestätigen ? Was Du mit dem SED vorhattest habe ich jetzt verstanden. Bei dynamischen Webseiten ist das natürlich keine Option. D.S.
http://www.faqs.org/rfcs/rfc1945.html Zitat: "Except for experimental applications, current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response." HTTP/1.1 führt Erweiterungen ein, die es ermöglichen die Verbindung offen zu lassen, aber auch dort entscheidet der CLIENT, ob er das will. Also auch bei HTTP/1.1 kommt man nicht um ein Schliessen der Verbindung herum.
Guten Abend, bei dem schönen Wetter hatte ich keine Lust zum basteln. :o) Thomas: Die HTML-Datei mit #include in den Code einzubauen ist eine sehr gute Idee, muss ich auch machen, danke. Die Content-Length ist nach meinen Erkenntnissen wichtig, wenn eine Seite aus mehreren Dokumenten besteht (html und Bilder), muss die Länge stimmen, sonst kann man lange warten bis die Bilder übertragen werden. Ich habe das so gelöst, dass ich die Seite generiere und so die Länge bestimme, dann wird die Content-Length in den Header eingesetzt, der Header gesendet und anschliessend die Webseite. Gruss Thomas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.