Hallo Feunde der Nullen und Einsen Ich habe mal eine Verständnissfrage : zur Zeit spiele ich mit Bascom AVR und Mbed herum.... nun will demnächst Daten via Netzwerk (Ethernet) austauschen [zustände; messwerte; {eventuell audio signale} ]. Nach viel herrumgesuche ist jetzt noch eine Frage offen: Kann ich beim Datenaustausch noch das C bzw. Bascom nutzen aus dem Congtroller nutzen oder muss ich dann auf Java umsteigen und eine Art webserver einrichten? Wichtig bei der Idee ist das alle Controller eigenständig auch bei Netzwerkausfall weiter arbeiten und ihr Grundprogramm weiter ausführen. Besten Dank im voraus Euer Dirk
Wenn du SENDEN willst, dann spielt dein MC "Client", d.h. er teilt einem Webserver per GET oder POST Informationen mit (z.B. Sensorwerte als TEXT, Internet funktioniert primär mit Texten). Dieser Informationsaustausch ist auf Wunsch bidirektional, d.h. der empfangende Webserver kann eine Antwort mit Informationen senden, muss aber nicht bzw. der MC kann die auch ignorieren. Die Eröffnung der Kommunikation geht aber immer vom Clienten aus, beendet wird die TCP-Verbindung wahlweise vom Server oder vom Clienten (steht im GET- bzw. POST-Statement). Wenn du primär EMPFANGEN willst, dann muss dein MC den Webserver geben, also auf einem TCP-Port lauschen, ob da einer connected und 'was mitteilen will .... "Richtige" Webserver machen dann sofort einen neuen Socket auf (sog. "Serversockets"), falls da zur gleichen Zeit noch jemand was will, während die vorherige Verbindung noch steht ... das ist für die meisten MCs aber etwas "oversized".
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.
Hallo Danke für eure Antworten, Bei mir hat es gerade "klick" gemacht... MODBUS TCP um meine eigenen Controller ins Netzwerk zu bringen. Oder spricht da was dagegen?
Dirk S. schrieb: > Oder spricht da was dagegen? Das ist schon ein recht hoch angesetztes Protokoll, kannst du aber machen. Damit ist aber die Frage der Hardware noch offen. Evtl. ist das AVR Net-IO dafür das richtige: https://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin http://son.ffdf-clan.de/
Danke Matthias 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.
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.
Hallo Danke erstmal für die weiteren Antworten, Zeitkritisch ist keine meiner geplanten Projekte. Also mit dem gedanken an des Raspberry Pi habe ich auch schon gespielt, ab welcher Version sollte ich mir eins zulegen? Das Thema Audio kann ich ja damit auch erschlagen oder...
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.
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.