Hallo, zu erst einmal vielen Dank das in diesem Forum so vielen Usern konstruktiv geholfen wird! -> Mir auch, durch lesen der vielen Beiträge. Hut ab vor all denen die Ihr Wissen dementspechend zur Verfügung stellen. DANKE! Mein Problem - die viel diskutiere Geschichte "Atmega -> Ethernet"! Ich möchte meiner AVR-Net-IO beibringen, eigene Software läuft (1-wire/RS232), mir meine Informationen nicht über die RS232 sondern über Ethernet(ENC28J60) mitzuteilen. Nach Recherche bereits vorhandener Software ( siehe Google und auf dieser Seite ) bin ich bei den Sourcen von Ulrich Radig gelandet. Habe mir diesen Code ins AVRStudio geladen und versucht die "wichtigen" Zusammenhänge zu verstehen. -> Problem !!! :-) Geständnis: Mich erschlagen diese vielen Codezeilen! :-( Ich möchte keinen Server auf dem Atmega implementieren, ich möchte das der Atmega mir meine gewünschten Daten (String oder Bytes) per Ethernet zu meinem Server schickt (per tcp an IP -> Port). Der Server ist momentan noch eine Windowskiste mit einem Dienst der diese Daten empfängt und sie in einer Datenbank ablegt (Datum, Temperaturen, Status der Ausgänge usw.). Geplant ist eine Linuxmaschine, Router/Firewall/Mail-Server, die ja sowieso den ganzen läuft und diese Daten mit organisieren kann. Also eine Alternative zur Funktion "uart-put" oder "Debug" usw. Ablauf: 1. Temperaturen einlesen 2. Ausgänge setzten 3. Temperaturen, I/O-Status an Server senden Wäre dankbar für Denkanstösse auf Basis des Source Code von Ulrich Radig. (newStack1_2_5) Vielen Dank!
Um ehrlich zu sein, wird die andere Richtung für dich einfacher sein! Gucke dir vll mal die http_get methode an- die baut auch auf tcp auf und verbindet sich zu einem Server. persönlich würde ich aber auf die Telnet-steuerstruktur zurückgreifen, das ist einfacher ;-) mfg
Danke für die schnelle Antwort! allg. Frage "Meckern Eure Frauen auch so viel wenn mann sich nichts anderes anschaut außer Neckermann oder Otto? :-) zurück zum Thema: Ich generiere meine Ideen auf Basis der großen "Internetbibliothek" und folgender Ansatz sollte doch möglich sein: (Jugendlicher Leichtsinn!) -> bin erst 33! :-) Im Galileo Openbook "C von A bis Z, Capter 25" ist ein solcher Server / Client gut beschrieben (für PC´s) läuft auch prima und den Code habe ich verstanden! Diese Clientfunktionalität müsste doch auch mit dem Stack von U. Radig machbar sein. Mir fehlt der Ansatz! Schlagt mich wenn ich gar falsch liege! Danke im Vorraus!
Hallo @RenJ ich habe die GLEICHE Fragestellung und bin leider auch noch nicht weitergekommen. ==> Beitrag "Minimal Webserver?" Hoffentlich kommt noch ein "kluger, einfacher" Hinweis, wie man das mit minimalem Aufwand für die Ethernetsache realisiert.... MfG Achim
ReneJ schrieb: > Ich möchte keinen Server auf dem Atmega implementieren, ich möchte das > der Atmega mir meine gewünschten Daten (String oder Bytes) per Ethernet > zu meinem Server schickt (per tcp an IP -> Port). Der Server ist Der minimale Aufwand wäre, UDP-Pakete zu schicken. UDP ist einfach, zustandslos, und das kannst Du leicht mit wenig Aufwand selbst implementieren, ohne einen kompletten IP-Stack verwenden zu müssen. Wenn Du magst, kannst Du noch icmp und arp implementieren, aber das muss nicht sein. fchk
Hallo @Sucher (Gast), schaun wir mal wie´s weiter geht! Hallo @Frank K., Danke für die Antwort! generelle Frage: So wie ich das verstanden habe weiß ich bei tcp ob meine Information angekommen ist oder nicht und bei UDP eben weiß ich das nicht. Meine Entscheidung fällt, im Endausbau, auf tcp! Mir ist es momentan eigenlich egal ob ich tcp oder udp für die Datenübertragung benutze. Das Prinzip ist entscheident. Kannst Du mir einen Denkanstoss bezüglich "Daten senden" geben. (Auf Basis U. Radig!) ICMP wäre natürlich für die Entwicklungsphase auch toll, eigentlich der erste Schritt, aber wir reden erstmal über "Daten senden!". Ich denke wenn ich das "Senden" verstanden habe sollte es mit "PING" keine Probleme geben, ist ja auch schon implementiert - die entsprechenden Sektions suche ich mir dann raus. Vielen Dank!
ReneJ schrieb: > generelle Frage: So wie ich das verstanden habe weiß ich bei tcp ob > meine Information angekommen ist oder nicht und bei UDP eben weiß ich > das nicht. Bei tcp kümmert sich der Stack darum, bei udp musst Du Dich selber drum kümmern, wenn Du das brauchst. tcp ist in der Implementation so komplex, weil es sich um alle möglichen Eventualitäten wie Paketverluste, Fragmentierung, falsche Reihenfolge von empfangenen Paketen etc etc kümmern muss. Wenn Du diese Eventualitäten nicht brauchst, weil Du nur im lokalen Ethernet unterwegs bist, wo die MTU garantiert bei 1500 ist und nichts fragmentiert und wo Du nicht routen musst etc, dann kannst Du mit einem einfachen UDP-Protokoll einiges an Platz im Flash und im RAM sparen. Beispielsweise: 1. Server schickt UDP-Paket mit Anfrage. 2. Client wertet Anfrage im UDP-Paket aus und schreibt die Antwort in den UDP-Datenbereich. 3. Client vertauscht Sende- und Empfangsadresse im Ethernet- und im IP-Header, setzt die Länge passend und berechnet die IP-Checksumme und optional die UDP-Checksumme neu 4. Client sendet Antwortpaket 5. Wenn der Server das Antwortpaket innerhalb einer Sekunde nicht hat -> 1. Für das ganze brauchst Du genau 1514 Bytes Platz, und das UDP/IP-Protokoll beschränkt sich auf ganz wenige Dinge. Damit das ganze funktioniert, muss Deine Kiste nur noch ARP-Requests beantworten (damit der Server die Ethernet-Adresse zu Deine IP bekommt), aber auch das ist primitiv und auf einer halben Bildschirmseite abgehandelt. fchk
Hallo @Frank K. wie immer DANKE! für Dein Interesse und DANKE! für Deine Antwort! Beschränken wir uns für´s erste auf das lokal Netz: zu 1. Server = AVR-Net-IO -> richtig? / UDP-Pakete WIE? -> U.Radig Code zu 2. Client = mein Server (Linux oder Windows!) -> da kann ich drauf reagieren! zu 3. - 5. bekomme ich hin! ZwischenFrage: das Buch " C von A bis Z, Chapter 25" ist Dir bekannt? (nicht böse gemeint!) -> auf diese Basis ziehlt meine Frage hinaus! Bzgl. der Geschichte öffentliche Netze Frage ich später! :-) >@Frank K. >Damit das ganze funktioniert, muss Deine Kiste nur noch ARP-Requests >beantworten (damit der Server die Ethernet-Adresse zu Deine IP bekommt), >aber auch das ist primitiv und auf einer halben Bildschirmseite >abgehandelt. Wie meinst Du das, ich dachte wir sind lokal (ich lerne!)? Bei mir: -> Client = AVR-Net-IO = feste IP, meinServer = feste IP. Sollte die Antwort in den ARP-Requests beheimatet sein, bitte keine Schläge, ich informiere mich umgehend! Vielen Dank!
Hier mal ein Beispiel:
Die Daten im xpl_hartbeat_string werden im UDP Telegramm zum Port 43903
gesendet. Ziel-IP ist eine Broadcast Adresse. Die Daten stehen in
eth_buffer.
const char xpl_hartbeat_string[] PROGMEM =
"xpl-stat\n{\nhop=1\nsource=heizung.hbeat\ntarget=*\n}\nhbeat.basic\n{\n
interval=60\n}\n\0";
void xpl_hartbeat ()
{
unsigned int byte_count = 0;
while (pgm_read_byte(&xpl_hartbeat_string[byte_count]) !=
0)
{
eth_buffer[UDP_DATA_START + byte_count] =
pgm_read_byte(&xpl_hartbeat_string[byte_count]);
byte_count++;
}
create_new_udp_packet(byte_count,43903,XPL_PORT,(*(unsigned
long*)&xpl_bcast_ip[0]));
return;
}
Gruss
Axel
Nachtrag zum letzten Post: (@Franke K. v. 25.10.2010 22:13) Auszug aus: "http://de.wikipedia.org/wiki/Address_Resolution_Protocol"; ..Bevor ein Rechner in einem Ethernet an einen Rechner im selben Subnetz ein IP-Paket sendet, muss er die Information in einen Ethernetframe verpacken. Dazu muss er die MAC-Adresse des Zielrechners kennen und im entsprechenden Feld des Ethernetframes einfügen. Ist ihm diese nicht bekannt, kann er das IP-Paket nicht zustellen. Stattdessen ermittelt er dann mit Hilfe des ARP zunächst die MAC-Adresse des Zielrechners.... habe ich grundsätzlich verstanden! Vielen Dank!
ReneJ schrieb: > Hallo @Frank K. > > wie immer DANKE! für Dein Interesse und DANKE! für Deine Antwort! > > Beschränken wir uns für´s erste auf das lokal Netz: > > zu 1. Server = AVR-Net-IO -> richtig? / UDP-Pakete WIE? -> U.Radig Code > zu 2. Client = mein Server (Linux oder Windows!) -> da kann ich drauf > reagieren! Sorry, war wohl doof geschrieben, ich meine das umgekehrt, der AVR bekommt Fragepakete und sendet Antwortpakete. > ZwischenFrage: das Buch " C von A bis Z, Chapter 25" ist Dir bekannt? > (nicht böse gemeint!) -> auf diese Basis ziehlt meine Frage hinaus! nein kenne ich nicht, und auch den Code von U.Radig kenne ich nicht, bräuchtest Du hier auch nicht. Das einzige, was Du brauchst, sind die Routinen für den Ethernet-Chip. >>@Frank K. >>Damit das ganze funktioniert, muss Deine Kiste nur noch ARP-Requests >>beantworten (damit der Server die Ethernet-Adresse zu Deine IP bekommt), >>aber auch das ist primitiv und auf einer halben Bildschirmseite >>abgehandelt. > > Wie meinst Du das, ich dachte wir sind lokal (ich lerne!)? > Bei mir: -> Client = AVR-Net-IO = feste IP, meinServer = feste IP. Auf IP-Ebene ja. Darunter sitzt die Ethernet-Ebene. Jedes Ethernet-Gerät hat eine eigene, weltweit einzigartige 48-Bit Ethernet-Adresse. Die Verknüpfung zwischen IP-Adresse und Ethernet-Adresse macht das ARP-Protokoll. Ein UDP-Paket sieht also so aus_ 14 Bytes 20 Bytes 8 Bytes [Ether Header[IP Header[UDP Header[Daten]]]] Wenn Du das alles selber programmierst (das meiste ist nur Ausfüllen von Headern), dann weißt Du anschließend genau, was bei Dir im Netz alles so abgeht. fchk
Hallo @Axel, wie immer vielen Dan.....K! Sie verwirren mich jetzt ganz. Kompletten Code durchsucht und nicht über [xpl_hartbeat_string] gefunden! Was mache ich falsch? Hallo @Frank K. wie immer vielen Dan......K! Ich glaube wir reden aneinander vorbei. (auch nicht böse gemeint!) Anforderung: AVR stellt eine Verbindung zu einem Server her: Verbindung herstellen -> Daten senden -> Rückantwort abwarten -> Verbindung schliessen -> Irgendwann auf ein neues! U. Radig Code lassen wir jetzt mal aussen vor. Wenn ich das richtig Vestanden habe benötige ich "nur die Treiber für den ENC28J60?" Auf dieser Basis könnte man alles selbst implementieren! Ehrlich gesagt -> will ich nicht! (mal wieder nicht böse gemeint!) Findige Leute haben, behaupte ich mal, Ihre Familie/Kinder/Job vernachlässigt um die Entwicklungen, u.a. auf dieser Seite, voran zutreiben. Es muss doch eine Möglichkeit geben vorhandenen Code zu nutzen. @Frank K. - ich hoffe wir können weiter diskutieren/schreiben! Bzgl. ARB-Request muss ich weiter lernen! -> mach ich auch! Vielen Dank!
Hallo Rene, warum so kompliziert? Der Code von Ulrich ist doch fast schon perfekt. Dein AVR-Net-IO muss doch lediglich Informationen liefern. Das tut er mit dieser Software bereits. Du mußt doch nur die Informationen abrufen. Wenn du sowieso eine Linuxkiste am Laufen hast, dann richte einen CRON-Job ein, der in regelmäßigen Abständen die Temperatur, oder was du messen willst, abruft. Diese Information leitest du dann an deine Datenbank weiter. Mein AVR-Net-IO-Projekt findest du hier: Beitrag "Re: Heizungsschnittstelle 7-8-9" Gruß Guido
Das Beispiel von mir sollte zeigen, wie es geht, ist ein Beispiel aus einem meiner Projekte. Daran kann man sehen, wie man ein UDP Paket schickt, alles mit ARP etc. macht Ullis Code dann selbst. Gruss Axel
Hallo @Axel, Dein Tip hat mich auf die richtige Spur gebracht! Vielen Dank! Habe in meinem Projekt erstmal alles ausgedünnt um die Zusammenhänge zu verstehen. (klappt sogar!) Übergeblieben sind: timer, enc28j60 und stack (jeweils .c, .h), Desweiteren eine Funktion ähnlich @Axel und siehe da meine Firewall (PC) meldet sich und ich erlaube dem MC mir Daten zu schicken! Den Serverdienst (noch Windows) habe ich analog des weiter oben genannten Buches aufbaut (copy -> paste, :-),). Werde mich jetzt noch tcp widmen und dann einen kurzen Erfahrungsbereich, wenn gewünscht, oder weitere Fragen hier präsentieren! Ziel ist es (1) von dem Controller Daten geliefert zu bekommen und (2) er soll mich fragen was ich neues an Informationen für ihn habe und das dann in seine Config übernehmen! (1) funktioniert mit udp, tcp ist im Anlauf (Dank Eurer Hinweise) (2) komme ich später zu Tut mir Leid wenn ich mich nicht regelmäßig melde aber ich werde diesen Tread weiter pflegen! Wer den ersten Schritt ebenfalls umsetzten möchte (Senden von einem String per UDP) meldet sich. Vielen Dank! mfg rene
schade - würde mich ja melden aber das ist doch alles schon fertig und im Forum von Ulrich Radig beschrieben ;-) Oder Du schaust dir mal die ETH-M32-EX_AVR-NET-IO Software an. Dort ist alles schon für das AVR-NET-IO von Pollin umgeschrieben. Die Software findest Du unter http://son.ffdf-clan.de/include.php?path=forumscategory&catid=22. Dort drin nimmst du entweder den Code zum Senden von Mails (TCP) oder die UDP-Kopplung und setzt statt dem 2. Board eben einen UDP-Socketserver (einige Zeilen PERL reichen) ein. Den enthaltenen Webserver kannst Du abschalten.
Hallo hat schon mal jemdand hier im Forum diesen Stack ==> http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml auf einem AVR_NET_IO Borad ausprobiert und kann hier seine Erfahrung darüber kund tun. Es geht darum, die Originalsoftware von Pollin mit einer möglich "schlanken" Firmware zu ersetzen. Oder gibt es zwischenzeitlich einen Pollin-Firmware Clone? Ich meine nicht die "mächtigen" Webserver-Implementierungen die hier ausführlich diskutiert wurden. Mir reicht eine sinngemäße RS-232 Anbindung übers Netz. Die Netzanbindung soll als "kleine,stabile Nebensache" auf dem Board laufen, damit mehr Resourcen für Erfassung und Regelung übrig bleibt. MfG Achim
Hallo @all, passend zum Thema suche auch ich ein Stück Code für mein AVR-NET, dass einfach einen String per UDP an einen Server zu senden soll. Ich will ein paar Werte einlesen (Temperatur etc.) und diese dann in einem String zum Server senden. Ohne Anfrage vom Server einfach jede Stunde einmal Senden und fertig. Hat da jemand schon ein Stück Code? Bernd
BerndS schrieb: > Hat da jemand schon ein Stück Code? Ja bitte schön. Stammt von Dietmar Misch und wurde von ihm im Forum von Ulrich Radig als UDP-Kopplung von zwei ETH_M32_EX Boards vorgestellt.
1 | //Senden der aktuellen Daten zu einen UDP Server
|
2 | void udp_send (unsigned long UDP_IP_SEND) |
3 | {
|
4 | //oeffnet eine Verbindung zu einem UDP Server
|
5 | unsigned int byte_count,var=0; |
6 | |
7 | //ARP Request senden
|
8 | if (arp_request(UDP_IP_SEND) == 1) |
9 | {
|
10 | for (byte_count = 0;byte_count<(MAX_VAR_ARRAY*2);byte_count=byte_count+2) |
11 | {
|
12 | eth_buffer[UDP_DATA_START + byte_count] = (unsigned char)var_array[var]; |
13 | eth_buffer[UDP_DATA_START + byte_count+1] = (unsigned char)((var_array[var]) >> 8); |
14 | var++; |
15 | }
|
16 | create_new_udp_packet(byte_count,UDPSEND_RPORT,UDPSEND_SPORT,UDP_IP_SEND); |
17 | return; |
18 | }
|
19 | return; |
20 | }
|
UDP_IP_SEND ist die IP-Adresse des Servers MAX_VAR_ARRAY definiert die Größe von var_array var_array enthält die Werte
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.