Hallo zusammen. Arbeite schon lange mit Assembler und habe jetzt ein Problem zu lösen, wo mir leider keine Lösung einfällt. Deshalb frage ich hier mal, wie ihr solche Dinge löst? Habe eine Webseite im ATmega 640 die ich mit folgendem Programmcode über UART und einem WIZNET TCP/IP Modul über das Netzwerk bei Anfrage sende. Webseite_senden: ldi ZL, LOW(2*webseite) ldi ZH, HIGH(2*webseite) html_text_senden: lpm temp, Z+ cpi temp, 0 breq html_text_ende call UART_0_senden rjmp html_text_senden html_text_ende: ret webseite: .db "<html><body>......usw. ...</Body></html>",0 ;Null dient als Endeerkennung Also einen ganz normalen Assembler Code um Daten die unter .db abgelegt sind über die UART zu übertragen. Jetzt ist es ja so, das die Webseite nicht nur konstante Daten beinhaltet, sondern sich spezielle Werte in der Webseite ändern, die man schließlich darstellen möchte. Das beste wäre natürlich wenn man das .db so gestalten könnte: Webseite: .db ""<html><body><p>ANALOGWERT 1 = ",zahl1,zahl2,zahl3,"</p><p>ANALOGWERT 2 = ",zahl1,zahl2,zahl3,"</p>... usw. ...</Body></html>",0 zahl1, zahl2, zahl3 wären jeweils eine SRAM Variable die den darzustellenden ASCII Wert (in diesem Falle nur 3-stellig) beinhalten würde. Also z.B. soll die 214 eingefügt und dargestellt werden und in der SRAM Variable zahl1 wäre die 2 als ASCII Wert in zahl2 wäre die 1 als ASCII Wert und in zahl3 wäre die 4 als ASCII Wert. LEIDER! geht das aber so nicht zu machen, das man SRAM Variablen in .db oder auch .dw so einfach einbauen kann. In der Vergangheit habe ich es so gelöst, das ich immer an der Stelle, wo ein Wert eingetragen wurde, den HTML Programmcode unterbrochen habe, den Wert als ASCII mit einem anderen Unterprogramm übertragen habe und danach den HTML Code wieder weiter abgearbeitet habe. Das funktioniert zwar, ist aber sehr umfangreich und sehr unübersichtlich, da jedes mal ein Teil des HTML Codes wieder mit ldi ZH, ldi ZL, LPM usw. aufgerufen werden muß, was letztendlich eine Menge an HTML Schnipselcode ergibt und man schnell die Übersicht verliert. Wie macht ihr das denn in Assembler, wenn ihr in einen HTML Code oder anderes, dynamische Werte z.B. aus dem SRAM einbringen bzw. dazwischen schieben wollt? Danke für eure Hilfe. Gruß Tom
Na ja, für sowas nimmt man eigentlich was anderes als Assembler. Eine Möglichkeit das relativ einfach zu realisieren ist es, ein beliebiges Zeichen, das sonst nicht im Text vorkommt, pro auszugebender Zahl in den HTML-Text zu schreiben, und dann im Programm vor dem 'call UART_0_senden' auf dieses Zeichen zu testen und gegebenfalls eine Wert-Ausgaberoutine anstelle des 'call UART_0_senden' aufzurufen.
Thomas W. schrieb: > Wie macht ihr das denn in Assembler, wenn ihr in einen HTML Code ... Du könntest Dich nach einer Library mit Stringverarbeitungsfunktionen umsehen und diese verwenden. Ansonsten wird es vielleicht auch Gründe dafür geben, warum das Erzeugen von mehr oder weniger aufwendigen Texten nicht allgemein etwas ist, was in Assembler programmiert wird.
Die Idee von Heiko hat mich auf eine Lösung gebracht, die ich mal so ausprobieren werde. Den HTML Text ganz normal mit dem Registerpaar Z und dem LPM Befehl laden und senden und immer an der Stelle wo eine ASCII Zahl bzw. Wert eingefügt werden muß ein Zeichen z.B. 0x01 sollte in HTML als ASCII Zeichen soweit ich weis nicht vorkommen, einfügen. Die einzuschiebenden Werte vorab in richtiger Reichenfolge in das SRAM ablegen und dann mit dem Registerpaar Y immer ein Datenbyte aus dem SRAM holen und den Wert des Registerpaares Y inkrementieren, wenn die 0x01 auftritt. Somit hätte ich sogar mit dem 0x01 einen Platzhalter und die Content Lenght, welche ich für HTTP Benötige würde auch einfach zu bestimmen sein. Danke Heiko für deine tolle Idee.
Ich denke eine Library mit Stringverarbeitungsfunktionen wird es nur für C geben. Diese kann ich mir mal gerne ansehen, um zu verstehen wie man das einfügen von SRAM- Werten macht. Eventuell finde ich da auch noch eine andere Idee wie man so etwas lösen kann. Auch wie Heiko schon verlauten lies, C wäre besser, aber ich sage immer... Wenn der Compiler von C einen Programmcode erzeugen kann, den der ATmega versteht und auch das macht was er soll, dann muß es auch in Assembler möglich sein. Denn das Ausgangsprodukt (HEX File), was letztendlich in den Flash des ATmega geschrieben wird ist im Grunde genommen das selbe. Es kommt halt in Assembler nur darauf an zu wissen wie man auf ein ähnliches Ergebnis kommt wie es aus dem C-Compiler gespuckt wird. Das ist leider manchmal sehr mühsam, das gebe ich gerne zu. Ist aber auf anderer Seite auch eine Herausforderung, die man gerne bewältigen möchte. Danke für eure Hilfe, das bringt mich doch schon viel, viel weiter. :-)
Hallo Heiko. Habe gerade mal das so ausprobiert wie ich es beschrieben hatte. So mit den beiden Registerpaaren Z und Y. Funktioniert hervorragend!!! Nochmals besten Dank für deinen Vorschlag. Damit auch andere Assembler Freunde eine Webseite aus dem ATmega heraus "basteln" können, habe ich den Grundsätzlichen Code mal als PDF Datei angehangen. Danke nochmals für deine Idee.
Man kann sogar Variablen in die Seite einbauen, so dass man sich im Assemblercode gar nicht mehr darum kümmern muss, welche Zahl ausgegeben werden soll:
1 | .db "<html><body> Dies ist Aufruf ",1,Aufrufe," dieser Seite</body></html>",0 |
1 ist die Einleitung, dass nun eine Adresse im RAM folgt, ab der ein Text liegt. Bei 0 endet der String. Ausgabe aus ROM mit Z, Ausgabe aus RAM mit Y - wie schon von Dir gemacht. Weitere Möglichkeiten wären: 2 - Zahl als Byte im RAM (0-255) 3 - Zahl als signed Byte im RAM (-128 - +127) 4 - Zahl als Word im RAM (0-65535) 5 - Zahl als signed Word im RAM (-32768 - +32767) 6 - Float Gruß Jobst
Hallo Jobst. Dein Vorschlag würde die ganze Sache natürlich noch gestalterisch einfacher machen. Allerdings muß ich zugeben das ich es noch nicht ganz verstanden habe und möchte deshalb nochmal nachfragen. Wenn ich unter .db wie dein Beispiel folgendes habe: .db "<html><body> Dies ist Aufruf ",1,Aufrufe," dieser Seite</body></html>",0 dann ist es klar, das die "1" die Erkennung dafür ist, das jetzt ein Byte aus dem SRAM folgt. Aber was ich noch nicht richtig verstehe ist der Eintrag "...,Aufrufe,...". Aufrufe würde doch der Name bzw. die Adresse einer Variable sein, die die Anzahl der Aufrufe gespeichert hätte und die unter .dseg im SRAM definiert wurde? Oder sehe ich das falsch? Soll das ganze dann vielleicht so ablaufen:? "1" wird erkannt, das bedeutet die nächsten 2 einzulesenden Bytes sind kein String, sondern eine 16 Bit Adresse der Variable die das entsprechende anzuzeigende Byte enthält. Also wird der mit Z eingelesene Wert nicht als ASCII Wert über die UART gesendet, sondern das 1-er Erkennungsprogramm nimmt diesen Adresswert, liest aus dem SRAM den Wert aus und gibt diesen über die UART aus. Danach geht es ganz normal im String weiter.... Hast du es so gemeint? Habe ich das so richtig verstanden? Wenn ja, dann gibt es aber ein kleines Problem. Denn es werden ja immer 2 Bytes aus dem String gelsen und man müßte sicherstellen das nicht die "1" und das HIGH-Byte der Adresse sondern immer das HIGH-Byte und das LOW-Byte der Adresse zusammen gelesen werden. Danke für deine Hilfe. Gruß Tom
Thomas W. schrieb: > Hallo Jobst. > Dein Vorschlag würde die ganze Sache natürlich noch gestalterisch > einfacher machen. Allerdings muß ich zugeben das ich es noch nicht ganz > verstanden habe und möchte deshalb nochmal nachfragen. > Wenn ich unter .db wie dein Beispiel folgendes habe: > > .db "<html><body> Dies ist Aufruf ",1,Aufrufe," dieser > Seite</body></html>",0 > > dann ist es klar, das die "1" die Erkennung dafür ist, das jetzt ein > Byte aus dem SRAM folgt. > Aber was ich noch nicht richtig verstehe ist der Eintrag > "...,Aufrufe,...". Aufrufe würde doch der Name bzw. die Adresse einer > Variable sein, die die Anzahl der Aufrufe gespeichert hätte und die > unter .dseg im SRAM definiert wurde? Oder sehe ich das falsch? > Soll das ganze dann vielleicht so ablaufen:? > "1" wird erkannt, das bedeutet die nächsten 2 einzulesenden Bytes sind > kein String, sondern eine 16 Bit Adresse der Variable die das > entsprechende anzuzeigende Byte enthält. Also wird der mit Z eingelesene > Wert nicht als ASCII Wert über die UART gesendet, sondern das 1-er > Erkennungsprogramm nimmt diesen Adresswert, liest aus dem SRAM den Wert > aus und gibt diesen über die UART aus. Danach geht es ganz normal im > String weiter.... Hast du es so gemeint? Habe ich das so richtig > verstanden? genau so hat er es gemeint, hab ich auch schon auf diese Weise gmacht > Wenn ja, dann gibt es aber ein kleines Problem. Denn es > werden ja immer 2 Bytes aus dem String gelsen Wieso? Es wird immer ein Byte gelesen. > und man müßte > sicherstellen das nicht die "1" und das HIGH-Byte der Adresse sondern > immer das HIGH-Byte und das LOW-Byte der Adresse zusammen gelesen > werden. die ausgelesene "1" oder nennen wir es mal Token, verwirfst du und liest noch zwei Byte nach z.B. YL & YH. Eine Vorabbestimmung der Contentlength geht natürlich nur indem du ein Blinddurchlauf ohne Ausgabe machst. Gerade bei Dezimalausgabe von Werten hast du ja nie fixe Längen. Sascha
Thomas W. schrieb: > Hast du es so gemeint? Habe ich das so richtig > verstanden? Jopp > Wenn ja, dann gibt es aber ein kleines Problem. Denn es > werden ja immer 2 Bytes aus dem String gelsen und man müßte > sicherstellen das nicht die "1" und das HIGH-Byte der Adresse sondern > immer das HIGH-Byte und das LOW-Byte der Adresse zusammen gelesen > werden. Nein, es wird immer nur ein Byte gelesen (LPM kann nur Bytes). Ein anderes Problem könnte aber bei der Assemblierung entstehen, da die Adresse ein Wort ist und so nicht mit .db verarbeitet werden könnte. Dann muss man sich mit ..., 1, high(Aufrufe), low(Aufrufe), ... behelfen. Dann ergibt sich folgender Ablauf:
1 | (Z ist mit Startadresse vom String gesetzt) |
2 | |
3 | ROMloop: |
4 | LPM tmp, Z+ |
5 | wenn tmp = 0 dann ret |
6 | wenn tmp = 1 dann jmp RAMausgabe |
7 | tmp ausgeben |
8 | jmp ROMloop |
9 | |
10 | RAMausgabe: |
11 | LPM YH, Z+ |
12 | LPM YL, Z+ |
13 | RAMloop: |
14 | LPM tmp, Y+ |
15 | wenn tmp = 0 dann jmp ROMloop |
16 | tmp ausgeben |
17 | jmp RAMloop |
Gruß Jobst
Thomas W. schrieb: > Damit auch andere Assembler Freunde eine Webseite aus dem ATmega heraus > "basteln" können, habe ich den Grundsätzlichen Code mal als PDF Datei > angehangen. Ist das Ironie? Sicher, es gibt noch ungeeignetere Dateiformate dafür (JPG oder andere Bildformate), aber was spricht gegen eine stinknormale Textdatei?
Rufus Τ. F. schrieb: > Ist das Ironie? Sicher, es gibt noch ungeeignetere Dateiformate dafür > (JPG oder andere Bildformate), aber was spricht gegen eine stinknormale > Textdatei? Ich hab das mal gewandelt...
Moin, sry wenn ich mit einer blöden Frage dazwischen grätsche. Warum macht man so was eigentlich? Also, eine Webseite über seriell ausgeben. Sinnvoller wäre es doch die Daten in einem einfachen Protokoll auszugeben und die Visualisierung den Rechner machen zu lassen. Entweder bettet der das dann in eine Webseite ein oder du benutzt so was wie das ComVisu (Forumssuche) Da stellt sich mir eine Frage. Kann man unter Linux den Browser direkt vom device file lesen lassen? also so was wie "file:///dev/ttyUSB0
nicht"Gast" schrieb: > Warum macht man so was eigentlich? Also, eine Webseite über seriell > ausgeben. Du hast den Anfangsbeitrag wohl nur flüchtig gelesen: > Habe eine Webseite im ATmega 640 die ich mit folgendem > Programmcode über UART und einem WIZNET TCP/IP Modul > über das Netzwerk bei Anfrage sende. Die UART ist nur für die Kommunikation zwischen AVR und Netzwerkmodul nötig.
Rufus Τ. F. schrieb: > Du hast den Anfangsbeitrag wohl nur flüchtig gelesen: Lustig. Wird Zeit für ein Bier. Die Zeile mit dem Wiznet hab ich tatsächlich gelesen, aber das Wissen darüber hat sich beim Lesen der restlichen Beiträge wieder verflüchtigt :) Mein Fehler
Hallo Jobst und Sascha. Erst mal einen ganz großen Dank an Jobst für seine Idee der Umsetzung und vor allem für den tollen Beispielcode. Obwohl ich schon seit vielen Jahren programmiere, habe ich noch nie eine Adresse in .db gebracht bzw. von dort ausgelesen. Das sogar HIGH(Adressbyte) und LOW(Adressbyte) unter .db überhaupt geht, wusste ich bis heute noch nicht. Ist aber logisch, denn ldi r16, HIGH(wert) und ldi r17, LOW(wert) verwende ich ja schon immer... Auch das es möglich ist das Doppelregister Y mit LPM laden zu können hatte ich bis heute noch niemals benötigt. Also danke nochmals an Jobst für die tolle Unterstützung. Wie Sascha auch schon geschrieben hatte, kann es eigentlich kein Problem mit den beiden Adresswerten geben. Es werden zwar immer 2 Byte "eingelesen" bzw. in den Prozess aufgenommen aber mit dem Befehl LPM jeweils nur ein Byte übergeben. Habe das ganze schon mal ausprobiert und es funktioniert auch nur mit ...",Aufrufe,"... Letztendlich habe ich aber doch die erste Idee wie im geposteten Beispielcode verwendet. Nur aus dem Grund heraus, das die Anzahl der Bytes für die Content Lenght dann die gleiche ist, da für all die "1"-er dann auch nur ein Byte eingefügt wird. Wenn ich die "1" verwerfen müßte, wäre der Code für die Bestimmung der Content Lenght wesentlich aufwendiger!
Hallo Rufus Τ. Firefly. Tut mir leid, mit dem PDF Format. Aber ich dachte es liest sich halt besser wenn die Farben mit drin sind. Danke an Heinz für die Wandlung. Ok beim nächsten mal dann also TXT, versprochen. Für alle die WIZNET nicht kennen sollten, das ist eine Koreanische Firma die verschiedene Module herstellt, die die Kommunikation über TCP/IP vollkommen autark machen und am Ausgang (kann SPI, UART, RS232 oder parallel sein) kommt dann nur noch HTTP und HTML raus. Das ist für einen Mikrocontroller das beste, wenn der sich nicht um die Protokolle TCP und IP kümmern muß. Die Einstellungen (IP Nummer, Baudrate usw.) können über das Netzwerk, oder über die Schnittstelle gemacht werden. Solch ein Modul kostet auch nicht die Welt... Habe schon mehrere Projekte mit solch einem Modul (WIZ107SR) ausgerüstet und bis heute kein Problem damit gehabt. Kann ich nur empfehlen.
Thomas W. schrieb: > Obwohl ich schon seit vielen Jahren programmiere, habe ich noch nie eine > Adresse in .db gebracht bzw. von dort ausgelesen. Damit kann man sehr komplex verschachtelte/verknüpfte Daten ablegen! :-) Oder springen ... Beitrag "Re: Superprofi hat ein ASM Problem" Gruß Jobst
:
Bearbeitet durch User
Hallo Jobst. Du scheinst dich wirklich richtig professionell auszukennen. Ich ziehe den Hut. So etwas ähnliches mit der Verschachtelung oder Springen habe ich vor kurzem erst in einem Buch von Schwabel Schmidt gelesen. Hatte es zu diesem Zeitpunkt noch gar nicht verstanden wie er das meint. Aber jetzt kommt so allmählich Licht in das Dunkel... Gestern Abend habe ich den Code für den Mikrocontroller noch fertig programmiert und ausprobiert. Funktioniert mit der kompletten Webseite hervorragend! Nur ein kleines Problem tauchte auf, welches ich euch noch mitteilen möchte, da es eventuell dem ein oder anderen helfen könnte. Problem: Zur Erstellung des HTML Codes habe ich natürlich einen HTML Editor verwendet, der eine Vorschaufunktion hat, um auch zu sehen welchen "Blödsinn" man verzapft hat. Im Editor lief alles ohne Probleme. Aber die Webseite im Mikrocontroller wurde zwar im Browser (IE) angezeigt und auch das Favicon (318 Bytes) wurde angezeigt, aber das eingefügte kleine JPG LOGO-Bild (2965 Bytes) nicht. Vom Browser kam noch nicht einmal die HTTP Anfrage "GET /bild.jpg...". Woran lag es? Es lag eigentlich am Browser, der immer alles schnell, schnell haben möchte....! Grund: Der Textbasierte Teil der Webseite ist 6510 Bytes groß darin enthalten sind dann 178 Bytes die "eingeschoben" werden. Die Übertragung des Bildes mit <img scr="bild.jpg"... passiert ziemlich am Anfang. Die Datenübertragung von der UART zum WIZNET Modul war auf 57600 Baud eingestellt. Dadurch hat es halt ca. 2 bis 3 Sekunden gedauert, bis der Textbasierte Teil der Webseite zum Browser übertragen war. Aber da war die Zeit zu lang und der Browser hat dann auf das Bild nicht mehr gewartet und die Anfrage "GET /bild.jpg... nicht mehr gesendet. Lösung: Habe einfach die Baudrate auf 115200 gesetzt und jetzt ist es auch schnell genug für den Browser, so das der die Anfrage für das Bild nicht verwirft. Jetzt wird auch das kleine LOGO-Bild angezeigt.
Thomas W. schrieb: > Dadurch hat es halt ca. 2 bis 3 Sekunden gedauert, bis der > Textbasierte Teil der Webseite zum Browser übertragen war. Aber da war > die Zeit zu lang und der Browser hat dann auf das Bild nicht mehr > gewartet und die Anfrage "GET /bild.jpg... nicht mehr gesendet. Das klingt ... äußerst unwahrscheinlich. Ich vermute, dass der Browser das GET schon abgeschickt hat, als du noch mit dem Senden des Textes beschäftigt warst, und du hast deswegen davon nichts mitgekriegt (HTTP-Pipelining). Sowohl TCP als auch UART können fullduplex, aber du musst eben auch zuhören. Theoretisch kannst du beliebig langsam senden. Wenn alle 2 Sekunden ein Zeichen reinkommt, bekommst du normalerweise keinen Timeout vom Browser. Ein Proxy in der Leitung mag das anders sehen.
Hähh das sollte sich kaum auswirken das HTTP tcp basiert und jeder Teil vom Browser geladen wird. Das einzige was sein kann das der Timeout zuschlägt da es zu lange dauert bis der Tx Buffer voll ist und das Pakete gesendet wird. Das mit den Inhalten kann man auch mit CGI lösen was die dynamischen Inhalte nach lädt. So muss ja die ganze Seite neu angefordert werden.
Naja der Browser versucht weitere Tcp Verbindung zu öffnen und wenn nur 1 http Port offen ist wird die Verbindung abgewiesen. Drück mal F12 für die debug Console des Browsers.
:
Bearbeitet durch User
Marco H. schrieb: > Das einzige was sein kann das der Timeout zuschlägt da es zu lange > dauert bis der Tx Buffer voll ist und das Pakete gesendet wird. Es kann auch sein, dass der Browser HTTP-Pipelining betreibt, also "GET /\r\nGET /bild.jpg\r\n" mit zu kurzer Pause zwischen den Anfragen sendet und erwartet, dass beide beantwortet werden. Während ein Request bearbeitet wird, dürfen weiterhin reinkommende Requests nicht verworfen werden (Ausnahme: HTTP/1.0 oder close-after-request).
S. R. schrieb: > Ich vermute, dass der Browser das GET schon abgeschickt hat, als du noch > mit dem Senden des Textes beschäftigt warst, und du hast deswegen davon > nichts mitgekriegt (HTTP-Pipelining). Sowohl TCP als auch UART können > fullduplex, aber du musst eben auch zuhören. Das die Netzwerkleitung Duplex ist, weis ich. Aber ich war immer der Meinung, das der Browser doch erst einmal warten müsste bis die mit "GET / usw. angeforderte Startseite auch wirklich bis zum letzten Byte beim Browser angekommen ist. Hatte auch an der RX Leitung der Verbindung vom WIZNET Modul zum ATmega eine "Mithörleitung" zu einem Terminal Programm angeschlossen. Während des Sendens der Webseite zum Browser kam da nichts an. Erst als die Webseite vollständig übertragen war, kam die Anfrage zum Favicon, aber niemals die Anfrage zum Bild. Vielleicht muss ich eventuell mal meine Einstellungen im WIZNET Modul überprüfen. Eventuell lässt das ein Duplex nicht zu, oder Duplex ist abgeschaltet oder sowas... Naja, irgendwie bekommt man es doch immer wieder hin... :-) Hauptsache es funktioniert jetzt und das tut es auch.
Also wenn dort der selbe stack läuft wie der zum download angebotene sehe ich schwarz. Der hat ein dickes Bug und zwar wenn die Daten größer wie der Buffer ist. Dann bekommt der Browser den ersten Teil doppelt. Das war die Ursache des nicht wohl geformten Javascript. Beitrag "einfache und performante W5500 LIB"
:
Bearbeitet durch User
Thomas W. schrieb: > Aber ich war immer der Meinung, das der Browser doch erst > einmal warten müsste bis die mit "GET / usw. angeforderte > Startseite auch wirklich bis zum letzten Byte beim > Browser angekommen ist. Das gilt für HTTP/1.0 und für HTTP/1.1 mit "Connection: close" bzw. ohne "Content-Length" auch, da der Browser dann erst mit dem Verbindungsende weiß, wieviele Bytes kommen. Aber im Prinzip darf man auch mehrere Anfragen hintereinander schicken.
Hallo Marco. Ich verwende keine LIB W5500 und habe noch niemals eine LIB oder anderes Vorgefertigtes von anderen verwendet. Ich programmiere ausschließlich in Assembler und bisher habe ich immer meinen eigenen "Treibercode" für irgendwelche Hardware/Software geschrieben. Ich bin schon froh, wenn ich die Kommunikation über HTTP und HTML mit meinen Assembler Kenntnissen soweit hinbekomme das es funzt. Zu den ganz speziellen Eigenschaften von HTTP, HTML und Browser-Standards kann ich leider nicht viel Beitragen, da mir einfach das 100%´tige Wissen darüber fehlt. Deshalb Danke an dich, das du hier hilfreich mit unterstützt. Gruß Tom.
Das Problem ist das Browser und der Http Server nun mal zusammen arbeiten ;) Man muss schon die andere Seite verstehen, sonst wird es schwierig. Das HTTP Protokoll ist auch nicht so umfangreich. Das verhalten des Browser lässt sich mit deiner Seite beeinflussen. Hierzu gibt es Infos die der Http Server übermittelt. In der Regel richtet sich der Browser auch in diese. Was ich er meinte ist dein Wiznet Modul, da ist ja ein ARM drauf und auf dem läuft der Stack. Um zu verstehen was da passiert musste ich mich auch mit Http und Javascript beschäftigen. Deine Aufgabe ist ja im Prinzip sehr einfach. Die Statische Seite wird einmal geladen und das dynamische kommt per Javascript als JSON string. um die werte von 4 ADC Kanäle zu übertragen wird nur folgender String angefordert. Der Server liefert: ADCStatusCallback({"ain":[{"v":"1880"}, {"v":"2209"}, {"v":"4095"}, {"v":"3171"}], "aout":[{"v":"100"}, {"v":"200"}]}); Das Javascript auf der anderen Seite zeigt die Werte dann dynamisch in deiner Webseite an. Das ganze kann man ohne Problem 300ms oder weniger abfragen da der Umfang der Daten extrem gering ist. Deine Seite muss jedes mal neu geladen werden.
:
Bearbeitet durch User
Hallo Marco. Da ich nicht so firm mit dem HTTP bin stelle ich hier mal das ein, was von meinem "Server" im ATmega über die UART und das WIZNET Modul als HTTP zurück an den Browser gesendet wird. Ist nicht viel, aber eventuell hast du eine Idee und kannst mir mal bitte schreiben, was eventuell noch hinein muß, damit das HTTP Protokoll professionell gestaltet ist. Hier der Inhalt: HTTP/1.1 200 OK CR LF Content-Length: 6510 CR LF Content-Language: de CR LF Content-Type: text/html CR LF Refresh:60 CR LF CR LF Zuerst sende ich die Version 1.1 weil auch die Anfrage als 1.1 vom Browser gekommen war. Dann die 200 und OK als Zeichen das die Startseite vorhanden ist und alles OK zum senden ist. Dann die Anzahl der zu sendenden Bytes, dann die Sprache, dann den Typ der zu sendenden Textdatei (HTML), dann noch einen automatischen Refresh nach 60 Sekunden und zum Schluss 2x CR LF zum Beenden vom HTTP Protokoll. Dann beginnt das HTML .... Hast du da noch eine Idee was verändert oder hinzugefügt werden müsste?
Ja der Zeichensatz fehlt charset=utf-8 z.Bsp sonst hängt es davon ab was auf dem Rechner eingestellt ist. Cache-control: no-cache Connection: -> https://en.wikipedia.org/wiki/HTTP_persistent_connection
:
Bearbeitet durch User
Thomas W. schrieb: > Zuerst sende ich die Version 1.1 weil auch die Anfrage als 1.1 vom > Browser gekommen war. Du kannst auch mit HTTP/1.0 antworten, dann weiß der Browser wenigstens schon einiges, was du nicht kannst, z.B. mehrere Anfragen über eine Verbindung und Pipelining. :-)
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.