Ich habe den UR-webserver für ARM angepasst. Es läuft auf einem LPC1768 DK2, müsste mit anderem Lowlevel-Teil aber auch auf anderen 32bittern laufen. Der Lowlevel-Teil stellt drei Funktionen zur Verfügung, auf die der Stack zugreift: init, send und receive. Dann braucht der Stack nur noch einen Timer. Der UR-Webserver ist gegenüber lwip und uip besser dokumentiert und leichter nachvollziehbar und daher für mich besser geeignet. Bislang funktioniert UDP und ICMP. TCP habe ich noch nicht ausprobiert.
Schönes Ding, aber stack.c in stack.h umzuwandeln ist nun wirklich KEINE gute Idee. Das ist grottiger Stil und gibt nur Ärger.
Na ja Schon witzig was es hier gibt. Erst bei U.Radig abkupfern und den eigenen winzigen Beitrag unter eigenes Copyright stellen. Da fehlen mir die Worte.
allianz schrieb: > winzigen Beitrag Diese Beurteilung setzt voraus, dass du den avr-code mit dem arm-code verglichen hast. Das glaube ich dir nicht. Wenn es im Vergleich zu U.Radigs Original wirklich nur ein winziger Beitrag ist, eröffnet er doch den Umsteigern auf Arm die Möglichkeit, auf bekanntem Terrain weiterzumachen. Schau dir mal die vielen Fragen im Forum zu Webservern, UDP, etc. - einschließlich meiner eigenen - an. Mehr als ein vorhandenes uip oder lwp-Beispiel zum laufen zu bekommen, ist nicht ganz so einfach. Die von mir zur Verfügung gestellte winzige Hilfe beruht auf einigen Wochen mit vergeblichen Versuchen, eine lauffähige UDP-Verbindung für Arm einzurichten. Ich halte daher die Darstellung der zugegeben einfachen Lösung dieses Leidensweges in diesem Forum für gerechtfertigt. Ich habe an einigen Stellen im Code deutlich gemacht, wo ich Änderungen vorgenommen habe. Das dient dem Überblick für mich und andere, damit bei der weiteren Programmierung nachvollzogen werden kann, wo Änderungen vorgenommen worden sind. Es ist nach wie vor der U.Radig-stack. Ein eigenes copyright daran wäre dämlich und wird von mir nicht in Anspruch genommen. Wie kommst du darauf?
nach weiteren winzigen Änderungen läuft jetzt auch der webserver, telnet und ntp. Wenn jemand Interesse am code hat, bitte melden
ich habe zum verstehen den ARM-webradio code genommen danach dann nach und nach alle funktionen angepasst und "veruniversellisiert" anstelle von warteschleifen beim ARP/DNS ... gibt es callbackfunktionen mit definierten abbruckkriterien( + rückmeldungen ) auch anpassungen an den Cortex mit DMA gibts wobei man sich den RX buffer sparen kann... der wäre sonst nur doppelt im system. TX buffer ist sogesehen ganz ok .. dadurch kann man sich die 3 DMA buffer aber schenken und mehr RX buffer einplanen. der Webradio code ist zwar nicht super dokumentiert .. ist aber auch so extrem gut gemacht um abläufe und die theorie dahinter zu verstehen zudem funzt der sehr gut und ist auch sehr performant auch der http kram wurde mit SD karte erweitert... anstelle der scripte( was dennoch möglich ist) gibts nun REST-API ( JSON ) insgesammt wird es langsam vom basiscode ist wirklich nur der kern grob erkennbar der rest wurde umgebaut und erweitert aber dank des basiscodes hab ich das handling dahinter auch halbwegs gut verstanden
karl k. schrieb: > nach weiteren winzigen Änderungen läuft jetzt auch der webserver, telnet > und ntp. Wenn jemand Interesse am code hat, bitte melden Bitte poste den Code hier im Forum.
Der komplette Code in GrottenC - eine Main-Funktion, von der aus alle Unterprogramme streng hierachisch aufgerufen und abgearbeitet werden. Das hat für Anfänger Vorteile, weil das Include je Datei nur einmal erfolgt und hierachisch frühere Funktionen in späteren Funktionen nutzbar sind. Wenn alles fertig ist, kann man es in richtiges C ändern. Es geht jetzt auch DNS. Nächste Schritte sind Webcam und DS1820, vielleicht noch Webradio? huhuuu schrieb: > ich habe zum verstehen den ARM-webradio code genommen gibt es da eine Art Modul, welches in den Radig-Code eingebunden werden könnte?
karl k. schrieb: > gibt es da eine Art Modul, welches in den Radig-Code eingebunden werden > könnte? denke nicht 100%ig den code fand ich aber einfach zum verstehen und universell genug um mehr mit machen zu können ich habe den mitlerweile recht gut erweitert ( ARP-cache , multiple ARP und DNS anfragen , HTTP von SD Karte , POP/SMTP , RSS reader , Sockets .... )
Ich habe mir den Watterott-Code auch angeschaut. Direkt verwendbar war er für mich nicht, weil er aufgrund der Komplexität meiner Ansicht nach allenfalls auf einem pingleichen Board hätte eingesetzt werden können. Da der Adam Dunkel Code - Lwip und uip - aufgrund der Protothreads zu schwierig zu verstehen ist und die Protothreads nach meinem Verständnis nur dann eine Berechtigung haben, wenn man den Code minimieren muss, habe ich mich letztendlich für die Anpassung des Radig-Codes entschieden. Mit diesem Code habe ich - wie viele andere auch- zu AVR- Zeiten das Polin NetIO zum laufen gebracht. Der Code ist noch verständlich, ausgereift und im Bereich AVR zumindest in Deutschland Mainstream. Da dieser Code von vielen genutzt wird, sind hier auch am ehesten Verbesserungen und Ergänzungen zu erwarten. Das ist wie mit der Modelleisenbahn. Es mag bessere Systeme als Märklin geben. Wenn man in der Schule mitreden will, hat man ohne Märklin aber schlechte Karten. Ich sehe zur Zeit auch keine Vorteile darin, statt des ausgereiften Radig Codes etwas anderes zu benutzen. Der Watterott-Code wird wohl auch nicht mehr gepflegt, zumindest wird das Webradion bei Watterott nicht mehr angeboten.
leluno schrieb: > Ich sehe zur Zeit auch keine Vorteile darin, statt des ausgereiften > Radig Codes etwas anderes zu benutzen. Ich habe auch mal mit dem Pollin-NetIo angefangen mit Ethernet zu spielen. Ist aber schon einige Jahre her. Der Stack von U.Radig war mir nicht robust genug. Der blieb bei mit immer hängen wenn ich ihn mit Pings bombardiert habe. Statt dessen war der uip-Stack mit sowas nicht zu beeindrucken. Woran das lag habe ich damals nicht weiter untersucht. UIP verwende ich auch auf den Cortexen. Die pthreads sind ja keine Pflicht bei uip. Lwip ist zwar sicherlich besser aber eben auch deutlich fetter. Den Watterott Code habe ich mir auch mal angesehen. Der ist zumindestens ziemlich kompackt. Einen Versuch wäre es mal wert...
old man schrieb: > Den Watterott Code habe ich mir auch mal angesehen. Der ist zumindestens > ziemlich kompackt. Einen Versuch wäre es mal wert... ich habe dazu auch erstmal aufräumen müssen den Radig code kannt ich nicht wirklich .. bzw habe mich mit damit nicht auseinandergesetzt den Watterrotcode hatte ich recht einfach verstanden .. zudem lief der stack inkl DHCP , ARP und DNS auf anhieb auf meinem LPC1768 ich habe den fast soweit das der auch IPv6 kann(parallel zu IPv4) es fehlen nur noch kleinigkeiten. ich hätte sicher einen anderen fetrigen nehmen können aber ich wollte den ablauf verstehen lernen bei dem µIP und dem LwIP war mir das ganze extrem verwirrend ... es ist am ende überall das gleiche prinzip aber bei dem waterrott und radig doch eher durchschaubarer
old man schrieb: > Der blieb bei mit immer hängen Bei mr läuft der Radig-code sowohl auf avr wie auch auf arm sehr stabil. Ich habe per batch auch viele Pings versucht- keine Probleme. Fehler würde ich am ehesten beim low-level-Teil/interrupt erwaten. Der ist beim LPC von CodeRed und anscheinend ausgereift. huhuuu schrieb: > es ist am ende überall das gleiche prinzip > aber bei dem waterrott und radig doch eher durchschaubarer Da sind wir völlig einer Meinung. Wichtig ist, dass man den Low-level-Teil zum laufen bekommt, dann den Stack, der Rest geht dann schon irgendwie...
Einige Fehlerkorrekturen und eine Ergänzung des Radig-Codes/httpd.c um eine Schnittstelle zum Auslesen von Textstrings. In einem Input-Feld können im Browser jetzt Textstrings bzw. cmd-Befehle eingegeben werden, die der lpc dann abarbeitet. Das Schalten und Anzeigen von Leds auf dem LPC funktioniert jetzt auch.
1 | //Einzelne Postpacket (z.B. bei firefox)
|
2 | if(http_entry[index].http_auth && http_entry[index].post == 1) |
3 | {
|
4 | for(a = TCP_DATA_START_VAR;a<(TCP_DATA_END_VAR);a++) |
5 | {
|
6 | //Schaltanweisung finden!
|
7 | |
8 | if(eth_buffer[a]=='V'){//kk+ |
9 | if(eth_buffer[a+1]=='A'){ |
10 | if(eth_buffer[a+2]=='R'){ |
11 | if(eth_buffer[a+4]=='S'){ |
12 | if(eth_buffer[a+5]=='T'){ |
13 | //+++++++++++++++ VARxSTR gefunden +++++++++++++++++
|
14 | u32 zl=0; |
15 | while((eth_buffer[zl+a+8])!='&'){ |
16 | resultVar[zl] =eth_buffer[zl+a+8]; |
17 | zl++; |
18 | }
|
19 | resultVar[zl]='\0'; |
20 | timer_Anzeige=15;set_f(fANZEIGE); |
21 | lgw(2,1,checkVar);lw(": ");lw(resultVar); |
22 | //++++++++ cmd ++++++++++++
|
23 | if(eth_buffer[a+8]=='c'){ |
24 | if(eth_buffer[a+8+1]=='m'){ |
25 | if(eth_buffer[a+8+2]=='d'){ |
26 | if(eth_buffer[a+8+3]=='_'){ |
27 | lw(" COMMAND"); |
28 | }}}}
|
29 | //-------- cmd ------------
|
30 | |
31 | //--------------- VARxSTR gefunden -----------------
|
32 | }}}}}//kk- |
Der Webserver schreibt jetzt DS1820-Messwerte auf eine sd-karte/fat chan. Auf Dateien der sd-karte kann über den Webserver zugegriffen werden. Code des Datenloggers:
1 | //++++++++++++++++ 50sec ++++++++++++++
|
2 | if(SEC==50)ds1820_start_meas(); |
3 | if(SEC==55){ |
4 | ds1820_auslesen_to_global_TR(); |
5 | var_array[0]=CelsiusTemp; |
6 | DatenArray[0]=CelsiusTemp>>8; |
7 | DatenArray[1]=CelsiusTemp; |
8 | }
|
9 | //---------------- 55sec --------------
|
10 | |
11 | //++++++++++++ min ++++++++++++++++++
|
12 | if((SEC==0|| gbi(bool_menu, mn_programmstart)==0)){lcd_goto(1,1);lcd_int2(hou);lw(":");lcd_int2(min);lw(":"); |
13 | //------------ min ------------------
|
14 | |
15 | //+++++++++ neuer Tag
|
16 | if((HOUR==0&&min==0)||gbi(bool_menu, mn_programmstart)==0){// |
17 | timestamp_d=DOY+(YEAR-2014)*365+(YEAR-2013)/4; |
18 | Dateiname[7]=(timestamp_d%10)+48; |
19 | Dateiname[6]=48+((timestamp_d%100)/10); |
20 | Dateiname[5]=48+((timestamp_d%1000)/100); |
21 | Dateiname[4]=48+(timestamp_d/1000); |
22 | res = f_open( &fsrc , Dateiname , FA_CREATE_NEW | FA_WRITE); |
23 | f_close(&fsrc); |
24 | }//-------- neuer Tag |
25 | //++++++++ alle 15 Minuten auf sd speichern +++++++++++++
|
26 | |
27 | if ((min%15==0) |
28 | //||(gbi(bool_menu, mn_programmstart)==0)
|
29 | ){
|
30 | timestamp_15m=(hou*4)+(min/15); |
31 | resultVar[0]=timestamp_15m; |
32 | resultVar[1]=CelsiusTemp>>8; |
33 | resultVar[2]=CelsiusTemp; |
34 | resultVar[18]='\r'; |
35 | resultVar[19]='\n'; |
36 | |
37 | //++ sd appand
|
38 | res = f_open( &fsrc , Dateiname , FA_READ | FA_WRITE); |
39 | /* Move to end of the file to append data */
|
40 | res = f_lseek(&fsrc, f_size(&fsrc)); |
41 | if( res == FR_OK ){ |
42 | res = f_write(&fsrc, resultVar, sizeof(resultVar), &br); |
43 | f_close(&fsrc); |
44 | }//-- sd appand |
45 | |
46 | //++++++++++++ timestamp +++++++++++++
|
Die Kommunikation zwischen Webserver und PC findet über ein VB-Programm statt. Das VB-Programm liest Daten vom Webserver, speichert diese auf dem PC und wertet sie aus. Das Programm sendet Schaltanweisungen an den Webserver und stellt Zustände des Webservers fest.
Anpassung des lowlevel-Teils für den Stm32F429, NTP und Webserver klappt auf Anhieb.
Bitte 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.