... und ist fit in der C programmierung? ich bin leider freak der assembler-programmierung und in der schule hat man es entgegen unseren wünschen vorgezogen, uns turbopis@@ äh.. turbo pascal anstatt C beizubringen. :-( zu deutsch ich kann kein C und bräuchte diesen webserver am liebsten so, daß der dort eingesetzte controller die steuerung des ethernet/web einschließlich der puffer übernimmt und die empfangenen daten aus dem web vom HTTP header befreit über z.b. I2C an einen zweiten controller weiterreicht. dieser gibt dann über den I2C daten zurück, die der web-controller dann mit HTTP header versehen und an den client zurückschicken soll. wie aufwendig ist das, bekommt das jemand in nicht allzu langer zeit hin zu programmieren bzw. kann einem c-anfänger dabei helfen?
Hallo > ... und ist fit in der C programmierung? nö - aber ich habe den Webserver nach Ulis C Vorlage auf ASM umgesetzt > ich bin leider freak der assembler-programmierung und in der schule hat > man es entgegen unseren wünschen vorgezogen, uns turbopis@@ äh.. turbo > pascal anstatt C beizubringen. :-( ja, ja > zu deutsch ich kann kein C und bräuchte diesen webserver am liebsten so, > daß der dort eingesetzte controller die steuerung des ethernet/web > einschließlich der puffer übernimmt und die empfangenen daten aus dem > web vom HTTP header befreit über z.b. I2C an einen zweiten controller > weiterreicht. dieser gibt dann über den I2C daten zurück, die der > web-controller dann mit HTTP header versehen und an den client > zurückschicken soll. willst du das mit I2C und 2. Controller jetzt nur machen weil du den Webserver in dein Projekt/Controller nicht einbinden kannst? Was willst du genau machen? > wie aufwendig ist das, bekommt das jemand in nicht allzu langer zeit hin > zu programmieren bzw. kann einem c-anfänger dabei helfen? dabei kann ich dann keine Hilfe leisten Sascha
ich würde den webserver gerne vom eigenen projekt entkoppeln. es macht sich beim eigenen projekt meiner meinung nach einfacher wenn man sich nicht um den webserver zu kümmern braucht, nicht mit seinen speicherbereichen im RAM oder registerinhalten kollidieren kann und dieser einem verschiedene aufgaben wie die HTTP header oder diese ganzen ack-geschichten abnehmen kann. vor allem die 4kb ram im 644 finde ich recht wenig für einen webserver und zusätzlich ein eigenes projekt. da merkt man eben, daß die dinger nicht wirklich für die anwendung als webserver geschaffen wurden. ;) wenn sich jemand auch schon in den originalen C quellcode eingearbeitet hat ist für ihn vielleicht so eine erweiterung kein wirkliches problem. ich finde z.b. diese C-übliche verteilung des quellcodes über hunderte dateien mit einbindungen über 20 ebenen einigermaßen lästig wenn man nicht weiß was wo drin steht. hast du von deinem ASM-webserver noch den quellcode? wie alt ist die C-version des webservers auf dem sie basiert?
naja der Speicherplatz - ich hab auch allerhand reingepackt ohne das er überläuft Beitrag "Re: Zeigt her Eure Kunstwerke !" , mit ASM geht da schon einiges. Währe die Frage von wem die HTTP Kommunikation ausgeht? Fall A: externer Cient fragt an deinem Server eine Seite an ... - du schickst die angefragte Adresse über I2C an deine APP - die APP liefert die Daten über I2C zurück an den Webserver und der schnürt ein entspechenden Packet Fall B: deine APP will Daten von einem externen Webserver abrufen - deine APP schickt die URL an den Webserver, der macht die Anfrage - und liefert die Daten per I2C an deine APP zurück Die I2C würde auf jeden Fall Multimaster-I2C erfordern, sonst pollst du dich kaputt. Für B braucht du einen HTTP Client und diese Funktion ist im Stack noch nicht ganz funktionsfähig siehe Beitrag "Wie können Web-Sites mit dem ETH_M32_EX aufrufen?" Ich würde aber denken, das die Kommunikation über I2C zu langsam wird um ordentlich zu arbeiten, und für die Kommunikation brauch'ts zusätzlich ordentlich Pufferspeicher. ___ mein ASM-Code basiert weitestgehend auf dem aktuellen Stack Sascha
I2C sollte sich in hardware realisieren lassen, der 644 hat das ja drin dann kann man es auch nutzen. damit wird das auch ausreichend schnell und man kann die interrupts nutzen. ich möchte auch keine großen dateien oder bunte bilder übertragen. der "betriebsmodus" soll nach deinem fall A ablaufen, ein client richtet anfragen an den server. server<->server kommunikation wäre höchstens an einen zeitserver sinnvoll. genutzt werden soll das für steuerungsaufgaben/fernüberwachung z.b. einer heizungsanlage. der server muß also eine komplette HTML-seite senden können, in die er messwerte und schaltzustände einfügt. außerdem muß er auf anfragen reagieren, im genannten beispiel einen neuen sollwert übernehmen oder schaltzustände ändern. eine rudimentäre benutzerverwaltung ist auch sinnvoll. eigentlich kann der webserver von herrn radig das im wesentlichen so wie er ist, aber ich weiß nicht wie weit ich ihn zusätzlich mit den MSR aufgaben belasten kann. zumal der controller in besagtem beispiel auch selbständig pumpen oder regelventile schalten müßte. deswegen würde ich das gerne voneinander trennen, daß ich einen µC zur freien vollen verfügung bekomme ohne drauf achten zu müssen, daß genug resourcen für das web-interface übrigbleiben.
na dann wirds doch schon wieder einfacher, der Stack kann ja schon aktuelle Portdaten in die Website einbetten und Schaltbefehle entgegennehmen. Anstelle das die Daten von den Ports des Contollers kommen bzw. dort hingeschrieben werden verwendest du einfach einen Puffer im RAM. Den befüllst du per I2C mit den aktuellen Werten, die der Webserver dann in die Seiten einbaut. Umgekeht legt der Server die Schaltbefehle im RAM ab und du kannst sie per I2C abholen. Damit reduziert sich der Datenverkehr auf dem Bus auch drastisch. So hab ich das bei meinem 1. Webserver auch per RS485 gemacht. Einzigste s Problem dieses Lösungsansatzes - wenn du auf Eingaben über die Weboberfläche einigermaßen schnell eine Rückmeldung über selbige benötigst sind dem recht schnell Grenzen gesetzt. Deshalb habe ich bei mir auch den Webserver in mein anderes System integriert. Bei einer ordentlichen Interrupsteuerung bleibt ausser dem Webserver noch genug Rechenleistung für andere Aufgaben übrig. Sascha
interessanter ansatz, aber damit biege ich den webserver auf diesen einen spezialfall zurecht. so wie ichs beschrieben habe (die komplette HTML seite geht über den I2C) wäre es universell einsetzbar ohne jedesmal den webserver zu "verbasteln". geschwindigkeit sollte der I2C dafür genug bieten, wie gesagt es geht mir nicht um die übertragung von bildern. im extremfall kann ich einzelne dateien wie buttons oder so immer noch direkt ins flash des webservers packen und diese somit vom I2C-bus kriegen, denke aber nicht daß das nötig sein wird.
kann den beitrag nicht mehr bearbeiten würd aber trotzdem gerne noch was nachtragen, also sorry für das doppelposting. @sascha kriegst du es hin in deinem assembler-code eine entsprechende änderung für so ein hardware-I2C interface zu basteln?
> interessanter ansatz, aber damit biege ich den webserver auf diesen > einen spezialfall zurecht. so wie ichs beschrieben habe (die komplette > HTML seite geht über den I2C) wäre es universell einsetzbar ohne > jedesmal den webserver zu "verbasteln". sicher ist das dann recht genau angepasst, aber eine Universallösung wie du sie dir vorstellst belegt dann auf alle Fälle zusätzliche Resourcen. Mein Vorschlag nur die veränderlichen Daten über I2C oder was auch immer auszutauschen ist so unflexsibel nun auch wieder nicht, was nicht geht sind Strings, aber da kann man ja auch den Browser noch ein wenig einspannen um die Daten aufzubereiten. > @sascha > kriegst du es hin in deinem assembler-code eine entsprechende änderung > für so ein hardware-I2C interface zu basteln? basteln kann man -fast- alles - ist nur eine Frage der Zeit, und sowas wird recht aufwendig! Überlege mal wie der Datentransfer geregelt und gepuffert werden soll: 1. zum Webserver wird eine TCP-Verbindung aufgebaut, der HTML Request wird empfangen 2. die angefragte URL wird per I2C übermittelt 3. der Webserver muss mit der Beantwortung warten bis er über I2C die Meldung bekommt ob die Seite verfügbar ist 4. deine APP sendet die Daten der HTML Seite (nach belieben), der Webserver sammelt die ert mal und wenn genügend Daten im Puffer sind werden sie über die TCP-Verbindung gesendet so - nun kann ein Client ja auch mehere Seiten anfordern, oder es greifen mehrere Clients zu - damit müssten für jede Verbindung entsprechende Puffer reserviert werden! Sascha
naja, wieviele gleichzeitig offene TCP-verbindungen kann der server denn in seiner jetzigen version? allzu viel kann man ja auch nicht durch den I2C hinterlegen weil dafür wieder der speicher knapp ist, genau wie für irgendwelche puffer. da wäre es wohl leichter C zu lernen und die komplette MSR-aufabe vom webserver erledigen zu lassen. evtl. bräuchte ich mal deinen sourcecode mit ein paar vermerken wo ich sowas wie MSR noch einfügen kann und was ich von der µC hardware noch verwenden kann (also was nicht vom webserver benutzt ist, sowas wie timer usw)... der µC muß ja in irgendeiner endlosschleife laufen und eine zeitbasis hat der webserver auch. vielleicht geht ja sowas, daß er die MSR-aufgabe etwa einmal pro sekunde aufruft und während dessen abarbeitung weiterhin auf anfragen aus dem ethernet reagiert, stelle ich mir aber schon recht schwer vor. brauche da bestimmt noch einiges an hilfe von dir. :-//
Ben _ schrieb: > naja, wieviele gleichzeitig offene TCP-verbindungen kann der server denn > in seiner jetzigen version? ist natürlich wieder vom Speicher abhängig bei mir läuft er momentan mit 14, RAM-Verbrauch pro Verbindung liegt bei 35Byte. > allzu viel kann man ja auch nicht durch den I2C hinterlegen weil dafür > wieder der speicher knapp ist, genau wie für irgendwelche puffer. da > wäre es wohl leichter C zu lernen und die komplette MSR-aufabe vom > webserver erledigen zu lassen. von wievielen Messwerten reden wir denn? > evtl. bräuchte ich mal deinen sourcecode mit ein paar vermerken wo ich > sowas wie MSR noch einfügen kann und was ich von der µC hardware noch > verwenden kann (also was nicht vom webserver benutzt ist, sowas wie > timer usw)... der µC muß ja in irgendeiner endlosschleife laufen und > eine zeitbasis hat der webserver auch. vielleicht geht ja sowas, daß er > die MSR-aufgabe etwa einmal pro sekunde aufruft und während dessen > abarbeitung weiterhin auf anfragen aus dem ethernet reagiert, stelle ich > mir aber schon recht schwer vor. also an Hardware braucht der Webserver eigentlich nur SPI und einen externen Interrupt. Desweiteren einen (Sekunden)takt um einige Zeitabläufe wie Timeout's zu realisieren. Bei mir werden ALLE Funktionen nur aus einer Mainloop aufgerufen, damit behindert sich nichts und läuft recht gut parallel. wo willst du eigentlich die HTML-Dateien speichern? In mein Stack hab ich die Funktionen zum laden der Dateien aus dem Flash 'weitestgehend ausgebaut' da alles von SD-Karte kommt. Uli's Authentifizierung hab ich nicht mit übernommen, und in meinem aktuellen Projekt (siehe oben) durch eine aufwendigere Technik mit Cookies ersetzt (funkioniert aber nur im Zusammenhang mit der SD-Karte). Die Übergabe von Eingabewerten geht nur über die URL (GET), und nicht wie in den neueren ETH_M32-Stack's per POST. Meine vorherige Version des Stack's die ich auf einem Standalone Webserver laufen hatte belegt incl. FAT16 Unterstützung und Update per SD-Karte (aber ohne Authentifizierung) ca. 14,5kByte, die könnte man 'relativ' problemlos um einige zusätzliche MSR Aufgaben erweitern. > brauche da bestimmt noch einiges an hilfe von dir. :-// schauen wir mal ... Sascha
was mich auch noch interessieren würde - wenn der AVR gerade eine web-anfrage beantwortet und bevor das abgeschlossen ist kommt eine neue, evtl. von einem anderen benutzer oder so. lehnt der die ab oder kann er beide anfragen nacheinander abfertigen? andere möglichkeit wäre ein nachbau der hardware und eine völlig eigene programmierung der ethernet/web-dienste um es vollständig zu verstehen. allerdings ist da ja ein ziemlich aufwendiges projekt und im grunde ist alles schon fertig erhältlich - man könnte es sich also ersparen. ist ja auch nicht nur das beantworten von http-anfragen, sondern das initialisieren des ethernet-interfaces, netzwerkverbindung usw. kommt ja auch noch dazu... das alles lernen bin ich ne ganze weile beschäftigt.
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.