µC und das Ethernet

Client und Server sind dir aber schon n Begriff???

Dirk S. schrieb:
> nun will demnächst Daten via Netzwerk (Ethernet) austauschen
> [zustände; messwerte; {eventuell audio signale} ].

Mit WEM willst Du Daten austauschen?

Mit existierenden, evtl. fremden Systemen?
Dann muß Du schauen, welche Protokolle diese Systeme beherrschen, und ob 
Dein AVR/Bascom dafür taugt.

Nur eigene Systeme?
Dann mußt Du Art/Menge/geforderte Übertragungszeiten analysieren und 
anhand dieser Daten ein geeignetes Protokoll auswählen. Das KANN http 
sein, aber das ist weder für Zustände und Meßwerte noch für Audio 
wirklich das ideale.

Java hat damit GAR NICHTS zu tun, wenn Du kein Betriebswirt bist.

Frank E. schrieb:
> d.h. er teilt einem
> Webserver per GET oder POST Informationen mit (z.B. Sensorwerte als
> TEXT, Internet funktioniert primär mit Texten).
Ethernet ist nicht gleich TCP/IP, mit dem im Internet kommuniziert wird. 
Es gibt auch andere Protokolle über Ethernet.
Im Internet wird auch nicht primär in textform kommuniziert (ICMP, 
Video-Stream, binärer Transport über FTP, ...). Das Internet ist nicht 
das Web. Es ist lediglich das Transportmedium für das Web.
Um zwei oder mehrere µC über Ethernet kommunizieren zu lassen, braucht 
es nicht zwingend HTTP (das Protokoll des World Wide Web), also einen 
Webserver. Das geht kompakter auch binär mit einem eigenen, viel 
einfacherem Protokoll.

Dirk S. schrieb:
> Gibt's was einfaches für Anfänger

Hallo;
schau dir mal die Produkte von "wiznet" oder "netburner" an.
Gruß

Ich schmeiss mal etwas Senfkörner dazu:

- JSON für uCs (da gibts hier schon einige Diskussionen zu). Simpler 
Ansatz, Skalierbarkeit dafür weniger gut, und um Audio zu übertragen ev. 
nicht ganz das richtige
- MQTT: Speziell für Sensoren-Telegramme, schön leichtgewichtig
- netpp: Binäres, kompaktes binäres RPC-Protokoll im reinen 
Master/Slave-Betrieb, Eigenschaften werden in XML beschrieben, ähnlich 
Genicam, kann aber Video/Audio übertragen.

Modbus folgt nicht gerade dem Keep-it-Simple-Prinzip und ist 
technologisch etwas zum Dinosaurier geworden. Aber halt ein Standard. 
Wenn man auf den verzichten kann, würde ich am ehesten mit MQTT 
anfangen. Nur meine bescheidene Meinung, es gibt unzählige Standards, 
von denen leider die meisten "broken by design" sind.

Dirk S. schrieb:
> Gibt's was einfaches für Anfänger oder soll ich mich gleich an Modbus
> machen.
>  Komme ich im Modbus herum oder werde ich früher oder später wider in
> die Richtung gehen.

Modbus brauchst du zum rumspielen nicht.

Nimm einfach TCP/IP oder UDP und gut. Definier dir ein simples 
Protokoll, und schaue dass es erstmal läuft. Klassischerweise 
programmiert man sich einen Echoserver und einen Client, der Server 
sendet erstmal alles zurück an den Client, was dieser schickt.

Das ist schon genug Arbeit für den Anfang.

> Gibt's was einfaches für Anfänger

Ja, Embedded Systeme mit Betriebsystem, zum Beispiel den Raspberry Pi.

Anfängern würde ich nicht raten, Mikrocontroller in Kombination mit 
TCP/IP zu verwenden. Denn das ist einfach ein zu komplexes Thema.

Wenn du wenigstens bereits Erfahrung in der Internet Programmierung auf 
PC und Servern hättest, dann würde ich auch zu Wiznet Modulen raten, 
aber ohne diese Grundkenntnisse hast du einfach zu viele Unbekannte 
Sachen auf einen Schlag.

Falls du es dennoch wagen willst, hilft Dir eventuell mein Buch 
http://stefanfrings.de/mikrocontroller_buch/index.html

Stefan U. schrieb:
>> Gibt's was einfaches für Anfänger
>
> Ja, Embedded Systeme mit Betriebsystem, zum Beispiel den Raspberry Pi.
>
> Anfängern würde ich nicht raten, Mikrocontroller in Kombination mit
> TCP/IP zu verwenden. Denn das ist einfach ein zu komplexes Thema.

Und sobald es ans Anbinden eines Sensors oder Echtzeit geht, wird Linux 
ein furchtbar komplexes Thema und verletzt klar die "Keep it 
simple"-Prinzipien einer robusten Entwicklung. Vom Stromverbrauch mal 
ganz abgesehen.

Die nicht unerheblich gewachsene ESP8266-Community hat da eine Menge 
Lösungen parat, und einige Leute haben bereits fertige 
Kommunikationslösungen mit den oben genannten Protokollen auf Basis von 
LWIP implementiert. Ok, die "Stock"-Firmware hat so ihre Probleme, aber 
es gibt gute Alternativen wie der "Frankenstein"-Fork, etc.
Ähnliches sollte auch auf dem AVR gehen. Siehe z.B. auch "contiki" OS.

Volle Zustimmung, jedoch ist das alles nichts für Anfänger. Contiki 
schon gar nicht.

Wobei die Frage nach Echtzeitanforderungen wichtig ist.

@Dirk
Bauchst du ein System mit exakt definiertem Timing? Wenn ja, dann geht 
Linux natürlich eher nicht.

Dirk S. schrieb:
> Also mit dem gedanken an des Raspberry Pi habe ich auch schon gespielt,
> ab welcher Version sollte ich mir eins zulegen?

Kauf dir halt gleich den 2 B . Kost ja nicht wirklich viel mehr..

> Das Thema Audio kann ich ja damit auch erschlagen oder...

Der kann zumindest FullHD Filme mit AC3 Streamen. Wenn du audio streamen 
willst, kann das also gehen.. trivial ist das aber wohl eher nicht mehr.


Anyway, ich halte den einstieg in die Socketprogrammierung mit Linux für 
sehr sinnvoll. Das ist gut dokumentiert, es gibt ne Tonne von Tutorials, 
gerade auch für den PI gibts ja ne große Community.

Wenn du dann soweit bist, dass du zwischen Rechner und PI daten per 
ethernet echoen kannst, kannst du ja weiterschauen.. ;)

> ab welcher Version sollte ich mir eins zulegen?

Eine B Version, denn die A Versionen haben kein Ethernet.