Guten Morgen! Frage: Projekte mit dem Ethernetmodul ENC28J60 sind ja zu genüge vorhanden. Aber was für eine Kommunikation findet zwischem diesem und einem daran angeschlossenen AVR statt? Gelegentlich lese ich "ich will eine HP auf dem AVR speichern" - ist das nur Geblubber? Ich wüsste nicht in welchen Ordner auf meinem Atmega ich das tun sollte! :) Ausserdem ist ja die Rede von Ports. Die interessieren mich. Da die Komm zwischen AVR und ENC über SPI stattfindet dürfte ja nur ein Port zur Zeit verwendet werden oder? Aber welcher und warum gerade der? Kann man sich das aussuchen? Also meine Vorstellung: links ein AVR mit ENC28J60, rechts ein AVR mit ENC28J60, verbunden mit Netzwerkkabel. Jede Seite hat seine eigene IP. Links soll an Rechts ein Byte schicken. Was passiert dabei? Schoenen Gruß- Stephan
Stephan schrieb: > Guten Morgen! > > Frage: Projekte mit dem Ethernetmodul ENC28J60 sind ja zu genüge > vorhanden. > Aber was für eine Kommunikation findet zwischem diesem und einem daran > angeschlossenen AVR statt? Das wird in jedem Projekt anders sein. Beispiel: Eine Webseite kann von einem AVR erzeugt werden, in der aktuelle Meßwerte oder Schalterstellungen angezeigt werden, und villeicht etwas zum Draufklicken in der Webseite hat, was wiederum beim Klicken im Browser über den AVR einen Schalter betätigt. > > Gelegentlich lese ich "ich will eine HP auf dem AVR speichern" - ist das > nur Geblubber? Ich wüsste nicht in welchen Ordner auf meinem Atmega ich > das tun sollte! :) Wer sagt, daß die in einem Dateisystem stehen muß? Wenn eine Anfrage per http kommt, muß der Server HTML liefern. Wie er das macht, ist seine Sache - er könnte sie aus einem Dateisystem lesen, wenn er eines hat, er kann sie aber genausogut aus dem Stand neu erzeugen (ähnlich wie CGI-Skripte auf einem normalen Server). Nichtsdestototz ist es auch vorstellbar, daß wirklich eine Seite aus einem Dateisystem gelesen wird, z.B. von einer SD-Karte. Das geht aber mit einem anderen Rechner einfacher. > > Ausserdem ist ja die Rede von Ports. Die interessieren mich. Da die Komm > zwischen AVR und ENC über SPI stattfindet dürfte ja nur ein Port zur > Zeit verwendet werden oder? Aber welcher und warum gerade der? Kann man > sich das aussuchen? Nein. Die Ports in TCP/IP haben nichts mit den IO-Ports eines Controllers zu tun. > > Also meine Vorstellung: links ein AVR mit ENC28J60, rechts ein AVR mit > ENC28J60, verbunden mit Netzwerkkabel. Jede Seite hat seine eigene IP. > Links soll an Rechts ein Byte schicken. Was passiert dabei? Kommt auf das Protokoll an (TCP, UDP, ...). Musst du dich mal mit TCP/IP schlau machen. Letztlich wird einer der beiden einen Service anbieten (also z.B. einen TCP- oder einen UDP-Port anbieten), und der andere eine Verbindung dazu aufbauen bzw. etwas dahin senden und vielleicht eine Antwort bekommen. Wenn man ein begrenztes Szenario hat und den Aufwand einschränken will, kann man auch direkt (z.B. auf Ethernetebene) Pakete senden und damit jedes selbstausgedachte Protokoll realisieren, TCP/IP ist nicht nötig, solange man alles selbst strickt. Neben TCP/IP gibt es ja auch noch andere Protokolle, die auf Ethernet aufgesetzt werden können. Der Vorteil von TCP/IP wäre halt, daß vieles schon fertig ist und die Kommunikation mit grundsätzlich anderen Systemen (PCs etc.) wesentlich einfacher wird. Z.B. setzt http (und damit ein Webserver) auf TCP auf.
Vielen Dank! UDP hoert sich schon mal interessant an. Werde mal eintauchen...
Angehängte Dateien:
-
hz2.gif
8,4 KB
Stephan schrieb: > Aber was für eine Kommunikation findet zwischem diesem und einem daran > angeschlossenen AVR statt? In diesem Fall I2C. Ein AVR steuert die Heizung, einer zweiter mit ENC dran kriegt die Zustandsinfo per I2C und liefert Statusanzeige und Protokoll ins Internet. Im Winterurlaub ist es ganz praktisch, wenn man sehen kann ob alles ok ist. Das 0,5MB grosse Langzeitprotokoll (Wochen-Monate) kann man sich per UDP (LAN) oder TCP abholen, und anderswo im Web macht ein PC-Server daraus Grafiken zu den gezeigten Werten.
Zum Einen kann man sich das Ethernet und das TCP/IP sparen. Zum Anderen das Filesystem. Man kann ein serielles Interface verwenden und die HTTP Kommunikation darueber machen. Ein kleiner Treiber auf dem PC macht die Umsetzung. Webserver bedeutet ein paar Seiten auf Anfrage zu liefern. Diese Seiten koennen auch im Flash stehen. Der Sinn davon? Man kann einem Geraet eine Weboberflaeche verpassen, ohne auf einen 32bitter gehen zu muessen, wenn der sonst Overkill waere.
Angehängte Dateien:
-
pruefadapter_1.jpg
98 KB -
pruefadapter_2.jpg
72 KB
Es müssen nicht immer Webseiten sein. Auf den Bildern ist ein Prüfadapter für Platinenprüfung zu sehen, dieser bekommt seine Befehle über Ethernet von einem anderen Rechner. Alles mit einem eigenen Protokoll auf TCP/IP gesteuert.
Hallo, ich glaube, hier liegt ein grundsätzliches Missverständnis vor, was die Aufgabe des ENC bei solchen Projekten ist: Der ENC ist der Low-Level Ethernet MAC und PHY, der die einzelnen Ethernet-Frames sendet oder empfängt. Diese werden in einem internen Speicher abgelegt. Der Mikrocontroller kann nun über die serielle Schnittstelle mit dem ENC kommunizieren und z.B. die Eigenschaften des ENC einstellen, einen Frame in den ENC-internen Speicher übertragen oder aus dem ENC-internen Speicher auslesen sowie das Senden des Frames auslösen bzw. den Enpfangsstatus auslesen. Alles danach muss vom Mikrocontroller durchgeführt werden, d.h. die höheren Ebenen 3-7 des OSI-Modells werden vom Mikrocontroller realisiert. Um nun z.B. einen Webserver zu implementieren muss also zuerst ein IP-Stack implementiert werden, der die IP-Paketverwaltung der zu sendenden oder empfangenen Frames übernimmt (also den Inhalt der Frames ausliest bzw. generiert). Darüber schließt sich z.B. das TCP-Protokoll an, welches sicherstellt, dass kein IP-Paket verlorengeht. In diesem Teil werden auch die einzelnen TCP/IP-Ports verwaltet (die im übrigen rein virtuell sind, dem Datenpaket wird nur um eine Nummer erweitert, mit deren Hilfe das TCP-Protokoll die empfangende Applikation bestimmt). UDP ist ein weiteres Protokoll, hat allerdings den Nachteil, dass verlorengegangene Pakete nicht automatisch noch einmal gesendet werden. Als Kür muss dann noch die Anwendung implementiert werden, die die eigentlich gewünschte Funktionalität bereitstellt (also z.B. eine HTML-Antwort auf einen http-Request zu senden). Für die einfache Verbindung zweier (oder auch mehrerer) Mikrocontroller gibt es wesentlich bessere Bus-Systeme als Ethernet (z.B. CAN oder RS485). Wenn aber Informationen auch mit dem PC verarbeitet werden sollen, so lohnt sich der Aufwand, da TCP/IP hier nun einmal der Stand der Dinge ist (alternativ könnte man auch einem MC den USB beibringen). Für all diese Aufgaben gibt es aber gerade auch für Atmel-Prozessoren im Netz etliche freie Bibliotheken, so dass hier niemand das Rad noch einmal erfinden muss. Man sollte allerdings schon eine gewisse Grundkenntnis der verwendeten Elemente (Bus-System, MC,...) mitbringen, da funktionierende Multi-Master-Busse schon die höheren Weihen der Mikrocontroller-Programmierung darstellen. Schöne Grüße, Martin
Wer andererseits Ethernet als Trägermedium für Verbindung von Mikrocontroller untereinander und mit PCs verwenden will, für den könnten auch die Wiznet-Chips oder -Module interessant sein. Die enthalten bereits den kompletten TCP/IP Stack onchip. Deren Interface (SPI oder parallel) zum µC bildet ungefähr die übliche Socket-Schnittstelle ab.
maveric00 schrieb: > Für die einfache Verbindung zweier (oder auch mehrerer) Mikrocontroller > gibt es wesentlich bessere Bus-Systeme als Ethernet (z.B. CAN oder > RS485). Wenn aber Informationen auch mit dem PC verarbeitet werden > sollen, so lohnt sich der Aufwand, da TCP/IP hier nun einmal der Stand > der Dinge ist (alternativ könnte man auch einem MC den USB beibringen). Wenn sich beide Mikrocontroller im selben Gehäuse oder sogar auf der selben Platine befinden ist Ethernet sicher das allerletze was man wählt. Im selben Raum/Etage ist CAN, RS485, usw. sicher die einfachere Alternative. Am flexibelsten ist aber sicherlich Ethernet, zumindest wenn man bereits eine bestehende Verkabelung hat. Einfach aus der Netzwerkdose ziehen und in die Netzwerkdose zwei Räume weiter stecken, fertig! Bei den meisten anderen Alternativen darfste erst einmal neue Leitungen ziehen. Selbst wenn gearde mal keine Netzwerdose im Raum ist gibt es immer noch PowerLAN(dLAN)-Adapter.
hier sind mal ein paar nützliche Links dazu: http://www.mikrocontroller.net/articles/Miniwebserver http://wiki.neo-guerillaz.de/mediawiki/index.php/Hauptseite http://wiki.neo-guerillaz.de/mediawiki/index.php/Microwebserver Das OpenMCP Projekt ist ein gutes Beispiel wieviel man so alles in einen 8-Bitter reinstecken kann (oder auch das EtherSex Projekt). Aber da die 32-Bitter mittlerweile auch recht günstig geworden sind die auch eine interessante Alternative, je nach Anwendung halt. Z.B. LPCXpresso <30€, SimpleCortex 49$. Die haben reichlich Flash intern um darin ganze Romane auf Webseiten legen zu können.
Sobald man Ethernet an Board hat braucht man eine Menge mehr an Strom. Wenn es also nur um gelegentlich Konfiguration und Bedienung geht, hat man besser nur eine serielle Verbindung und macht das Umsetzen auf einen Socket im PC. Man kann ueber die serielle Schnittstelle ja auch HTTP laufen lassen.
Wobei vieles wo man sinnvollerweise den Mikrocontroller per Ethernet anbinden möchte schon einiges an Flash (>16kByte) im Controller vorausetzt. Zumindest für Privat ist da z.B. ein Atmega32 schnell teurer als ein vergleichbarer STM32. Und der STM32 bringt dann gleich noch eine ganze Menge weiterer praktischer Dinge (z.B. DMA, mehr SRAM, USB, ...) mit. Und von der Hardware her sind die kleineren STM32 auch nicht sooo kompliziert. Spannung mit Stützkondi, ganze 4 Pins für die SWD Programmierung und das war es auch beinahe schon. Im Gegensatz zum AVR kann man sich auch nicht so leicht aus den Dingern beim Flashen ausversehen aussperren. Einzig beim Löten wird es ein (kleines) bisschen schwieriger, TQFP48 oder TQFP64 muss man schon einplanen...
M. K. schrieb: > Auf den Bildern ist ein Prüfadapter für Platinenprüfung zu sehen, dieser > bekommt seine Befehle über Ethernet von einem anderen Rechner. Sieht ja nett aus - aber wozu braucht man sowas? Deine Box ist quasi das Prüfsystem und wird von einem PC gesteuert, richtig? Warum stellt man nicht einfach einen Rechner daneben und wählt einen anderen/einfacheren Bus zum "Prüfsystem"? Bei solchen Selbstbau-Lösungen hätte ich als Kunde immer Bedenken wegen Wartung, Nachbaufähigkeit und Ersatzteilbeschaffung (vor allem auf lange Sicht gesehen...). Außerdem ist ein billiger Rechner mit Messkarten oder ähnliches oftmals günstiger.
In vielen Faellen hat der PC keinen Dampf im IO Bereich. Der PC kann kein Timing einhalten. Wenn man nun etwas mit hoher Bandbreite messen muss, sollte man sich nicht auf irgendwelche National Instruments Boards verlassen, sondern besser auf eine Standalone Loesung gehen. Wir haben uns auch mal so eine high Bandwidth Parallel Karte von NI zugelegt. Die Karte hatte Duzende von Modi, deren Konfiguration auch nicht ganz trivial war. Schliesslich nach 3 Wochen probieren ging's dann leider doch nicht. Die Karte haette gemaess Datenblatt 20MByte machen sollen, wir waeren mit 2MByte zufieden gewesen. Die erreichbare Bandbreite hing vom mode ab. Der tiefste Mode, der dann schlisslich lief brachte nur 20kByte oder so. Ein selbstgebautes PCI board, wie ein anderer Beitrag heute zu bauen versucht, ist leider auch nichts. Denn schlisslich braucht man eine Windows Hardware Treiber dazu. Da kann man Monate verbraten bis man die Details raus hat. Ein externes board, das mit Ethernet angeschlossen ist, ist eine vernuenftige Loesung. Weshalb nicht USB ? USB kann hoechstens 5m. Die FTDI Losungen enden bei 3MByte. Und ein richtiger USB Treiber ist auch nicht trivial. Da sind auch schnell ein paar Monate weg.
Lupin schrieb: > Sieht ja nett aus - aber wozu braucht man sowas? Wir bekommen unsere bestückten Platinen von externen Lieferanten, dort passieren die tollsten Dinge. Mit diesen Prüfadaptern werden die Platinen vor Einbau in die Geräte überprüft, teilweise initialisiert und justiert. Lupin schrieb: > Deine Box ist quasi das Prüfsystem und wird von einem PC gesteuert, > richtig? Warum stellt man nicht einfach einen Rechner daneben und wählt > einen anderen/einfacheren Bus zum "Prüfsystem"? Das was du beschreibst hatten wir bisher, 8 Prüfsysteme mit universaler Schnittstelle und 3 Messplätze mit PCs, dazu noch diverse Labornetzteile und Multimeter. So langsam geht aber der Platz aus, die PCs Monitoren etc. wollen auch irgendwo stehen. Die Verdrahtung des ganzes war auch nicht immer einfach. Für einige ungelernte/lern-unwillige ein Problem. Das neue System kann an jedem Arbeitsplatz verwendet werden, ist einfach zu verkabeln. Nur 3 Verbindungen Netzstecker, Netzwerkstecker und Tastatur. Eventuell kommt noch ein Labornetzteil dazu, welches dann seriell über die Box gesteuert wird. Die Befehle für das Netzteil kommen dann auch vom PC und werden von der Box nur durch gereicht. Lupin schrieb: > Bei solchen Selbstbau-Lösungen hätte ich als Kunde immer Bedenken wegen > Wartung, Nachbaufähigkeit und Ersatzteilbeschaffung (vor allem auf lange > Sicht gesehen...). Außerdem ist ein billiger Rechner mit Messkarten oder > ähnliches oftmals günstiger. Das ganze wird nicht verkauft sondern wird nur Firmenintern genutzt. Die reinen Bauteilkosten liegen unter dem Preis eines Einzelplatz-PCs der mit ca. 350€ bis 500€ veranschlagt werden kann. Das neue Prüfsystem benötigt zwar auch einen PC dieser kann dann aber mehr als ein Prüfsystem steuern. Momentan arbeite ich daran diesen 'PC' auch noch überflüssig zu machen indem dieser in eine virtuelle Maschine wandert.
M. K. schrieb: > Wir bekommen unsere bestückten Platinen von externen Lieferanten, dort > passieren die tollsten Dinge. Mit diesen Prüfadaptern werden die > Platinen vor Einbau in die Geräte überprüft, teilweise initialisiert und > justiert. Das war mir klar, ich mach so 'nen Spass jeden Tag... Wir bauen ICT/FKT Programme für diverse Testsysteme bzw. eigene Systeme und die entsprechenden Adapter. Deshalb fand ich deinen Adapter auch ganz interessant :) M. K. schrieb: > Das ganze wird nicht verkauft sondern wird nur Firmenintern genutzt. Die > reinen Bauteilkosten liegen unter dem Preis eines Einzelplatz-PCs der > mit ca. 350€ bis 500€ veranschlagt werden kann. Von den Bauteilkosten redet ja keiner. Entwicklung und Fertigung der Systeme sind ein bischen interessanter. Scheint eine gute Lösung für euch zu sein - ich find's nur sehr aufwendig. Wenn's erstmal entwickelt ist und für entsprechend viele Baugruppen/Adapter genutzt werden kann könnte es sich wohl wieder rechnen.
Thread beobachten
Seitenaufteilung abschalten
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.