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.
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.
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.
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.
