Vernetzung von Mikrocontroller-Geräten mit Ethernet oder anders?

Ethernet ist schon in Ordnung, wenn man an das Firmennetz ran kann und 
darf und die eigenen Pakete tatsächlich durchgeroutet werden (bei 
intelligenten Switches nicht immer sicher). Allerdings ist der Overhead 
beachtlich. Bei einer selbst verlegten Verkabelung und geringem 
Datenvolumen tut es vielleicht auch RS485.

Statt einen Arduino mit dem teuren Ethernet Shield zu verwenden, gefällt 
Dir vielleicht die kompaktere Lösung besser. Die kannst du dann selber 
bauen oder fertig kaufen. Ist alles Open-Source, sogar die Schaltpläne.

http://stefanfrings.de/avr_io/index.html

Allerdings möchte ich mich dem Sebastian anschließen: Überlege, ob 
RS-485 ausreicht, das ist nämlich viel leichter zu handhaben.

Rs485. Sonst ist der sind 80% der Bauteile nur dafür da, das ganze ins 
LAN zu bringen.

485 Kann man ja auch ins LAN bringen, per Device Server.

Rs485 schrieb:

> Rs485. Sonst ist der sind 80% der Bauteile nur dafür da, das ganze ins
> LAN zu bringen.

Huch? Also ich brauch zu meinen Atmels bloß noch einen NIC-IC und eine 
MagJack-Buchse. Das sind nur 66,7%.

Und wenn ich den Atmel per RS485 anbinden wollte, bräuchte ich auch 
mindestens einen entsprechenden Wandler LL<->RS485 und ein Klemmbrett 
für die doofen Strippen und obendrein noch eine extra Stromversorgung 
für den Wandler, während ich den NIC-IC einfach aus derselben Spannung 
versorgen kann, mit der auch mein Atmel läuft. Ja ich kann sie sogar mit 
fertig kaufbaren Komponenten beide aus dem LAN versorgen. PoE macht's 
möglich.

Außerdem ist LAN auch noch sehr viel flexibler als RS485. Ich kann mit 
jedem verschissenen Notebook an die nächste freie Netzwerkbuchse im LAN 
gehen und gezielt mit meinem Controller reden, ihm notfalls sogar eine 
Firmware-Update von dort aus verpassen. Und ich kann den 
Datenbank-Server notfalls in Timbuktu oder Shenzen aufstellen und mein 
kleiner AVR kann trotzdem noch mit ihm reden (wenn ich und der Admin des 
LAN das so wollen). Ohne jeden zusätzlichen Hardware-Aufwand.

Also nö, wenn eine hinreichend dichte LAN-Infrastruktur bereits besteht, 
ist die Benutzung von RS485 im Allgemeinen ein Schildbürgerstreich 
allerübelster Sorte. Ausnahmen bestätigen natürlich wie immer die Regel. 
Allerdings kann ich mir solche Ausnahmen nur durch Sicherheitsbedenken 
begründet vorstellen. Sicherheitsaspekte wurden durch den TO aber 
ausdrücklich aus den Betrachtungen ausgeschlossen.

Wolfgang schrieb:
> Ich mache mir etwas konzeptionelle Gedanken,....
> Bastelnderweise würde ich für solche Stationen einen Arduino-Clone und
> ein Ethernetmodul nehmen

Zum ersten an den TO: Was du "bastelnderweise" als Basteln ansiehst, 
wird von anderen ganz anders gesehen - auf der einen Seite das 
Zusammenstecken von irgendwelchen fertigen Moduln und auf der anderen 
Seite das echte Entwerfen von Schaltungen, Leiterplatten usw.

OK, jeder hat so seine Art zu basteln, aber wenn man deinen Ansatz bis 
zum Ende weiterdenkt, kommt ein Haufen vernetzter Raspberries dabei 
heraus. Sowas geht zwar, aber es ist m.E. überhaupt nicht 
praxistauglich. Allein schon das ellenlange Booten, dann die für die 
Anwendung viel zu übertriebene Netzwerkverbindung und so weiter. 
Andererseits sind die Dinger fertig und für hardwareabgewandte Leute 
bereits mit fertiger Software-Infrastruktur versehen.

Aber um nen Chipkartenleser oder nen Kontakt am Dachfenster irgendwohin 
zu melden, ist das alles viel zu übertrieben. Da wäre ein ganz kleines 
Board mit nem mittelprächtigen µC deutlich besser angebracht, aber dort 
den gewaltigen Schwulst an Ethernet und TCP/IP unterzubringen, wäre 
herzlich daneben - und den riesigen Durchsatz brauchst du ja auch nicht. 
Da ist ne simple serielle Verbindung deutlich eher angesagt - und wenn 
mal so ein µC abstürzt, ist er per Watchdog binnen einer Sekunde wieder 
am Leben.

Also geh erstmal in dich, welche Sorte von Basteln du anvisieren willst. 
Die Version, ein übliches CATxyz Kabel zu verwenden, ist gut, 
schließlich kann man damit die peripheren Gerätchen mit Strom versorgen 
(24 Volt und dann vor Ort auf 5 oder 3.3 gebracht) und zugleich die 
Daten leiten, egal was man für ne Übertragung nimmt.


c-hater schrieb:
> Huch? Also ich brauch zu meinen Atmels bloß noch einen NIC-IC und eine
> MagJack-Buchse. Das sind nur 66,7%.

Ebenfalls huch. Mit nem passenden LPC braucht man nur noch ne Buchse mit 
eingebautem Trafo, das wäre noch weniger - aber der Aufwand liegt nicht 
in der Anzahl der Chips, sondern in der Komplexität des Systems. Und für 
ne Meldung über offenes Dachfenster oder Klingelknopf oder Kontakt am 
Wassertank braucht man nr ganz geringe Datenraten. Da würde wohl sogar 
V24 mit 1200 Bd vermutlich schon ausreichen.

W.S.

c-hater schrieb:

> Und wenn ich den Atmel per RS485 anbinden wollte, bräuchte ich auch
> mindestens einen entsprechenden Wandler LL<->RS485 und ein Klemmbrett
> für die doofen Strippen und obendrein noch eine extra Stromversorgung
> für den Wandler, während ich den NIC-IC einfach aus derselben Spannung
> versorgen kann, mit der auch mein Atmel läuft.

So dachte ich mir das im Vorhinein schon, ob man mit Alternativen nicht 
den Teufel mit dem Beelzebub austreibt. Das Einzige, was mir als ohne 
zusätzliche Komponenten machbar einfällt, wären wohl RS-232, aber dann 
auf UART-Pegel, oder I2C/SPI und ähnliches. Alles nichts, was über 
größere Entfernung funktioniert. Mit dem Nachteil, daß ich Datenfehler 
noch per selbstgeschriebenem Protokoll ausmerzen muß. Und sobald ich 
irgendein Chinamodul brauche, kann es gleich Ethernet sein. Mag bei 
selbstgeplanten Platinen und Stückzahlen ab 100 wieder anders aussehen.

W.S. schrieb:

> Zum ersten an den TO: Was du "bastelnderweise" als Basteln ansiehst,
> wird von anderen ganz anders gesehen - auf der einen Seite das
> Zusammenstecken von irgendwelchen fertigen Moduln und auf der anderen
> Seite das echte Entwerfen von Schaltungen, Leiterplatten usw.

Ich würde vermutlich in der Mitte landen, beim Zusammenlöten von Modulen 
auf Leiterplatten. :)

> OK, jeder hat so seine Art zu basteln, aber wenn man deinen Ansatz bis
> zum Ende weiterdenkt, kommt ein Haufen vernetzter Raspberries dabei
> heraus. Sowas geht zwar, aber es ist m.E. überhaupt nicht
> praxistauglich. Allein schon das ellenlange Booten, dann die für die
> Anwendung viel zu übertriebene Netzwerkverbindung und so weiter.
[...]
> Aber um nen Chipkartenleser oder nen Kontakt am Dachfenster irgendwohin
> zu melden, ist das alles viel zu übertrieben. Da wäre ein ganz kleines
> Board mit nem mittelprächtigen µC deutlich besser angebracht, aber dort

Ich halte einen Raspberry auch für übertrieben, auch wenn er billiger 
oder gleichteuer wie Pollins NET-AVR zu haben ist. Ein PC mit 
Betriebssystem ist zu aufgebläht, außerdem kann der keine Echtzeit, wenn 
er lokal andere Schnittstellen usw. abfragen muß.

> den gewaltigen Schwulst an Ethernet und TCP/IP unterzubringen, wäre
> herzlich daneben - und den riesigen Durchsatz brauchst du ja auch nicht.
> Da ist ne simple serielle Verbindung deutlich eher angesagt - und wenn
> mal so ein µC abstürzt, ist er per Watchdog binnen einer Sekunde wieder
> am Leben.

Das bleibt aber gleich, ob ich einen MAX232 oder einen ENC28J60 (bzw. 
diesen 5100/5200 von Dingsbums) an den µC dranhänge. Für seriell 
(welcher Art auch immer) brauche ich dann eine skalierbare Gegenstelle 
mit Software, die die Verteilung nach TCP/IP übernimmt. Gut, gibt 
fertige Device-Server, dann verlagere ich die serielle Ansprache in 
meine "Zentralsoftware", denn auf dem Rechner dort kommen dann 10, 20, 
100 virtuelle COM-Ports an.

Dafür soll Hardware-Ethernet wiederum Probleme machen können, weil so 
ein Chip mal spinnen kann, womöglich das ganze Netzwerk zumüllt und es 
keine Updates dafür gibt (andererseits, wie oft habe ich an meinem 
Windows2000-Rechner in den letzten 10 Jahren irgendwelche Treiber 
aktualisiert...?)

W.S. schrieb:

> der Aufwand liegt nicht
> in der Anzahl der Chips, sondern in der Komplexität des Systems.

Da ist was dran. Der Punkt ist nur: das einzig Komplexe ist der 
Netzwerk-Stack und den brauch' ich nur einmal halbwegs fehlerfrei zu 
implementieren. Dann ist dieser Teil der Komplexität Geschichte, mutiert 
zur Blackbox, um die man sich keine Sorgen mehr machen muß. Jedenfalls, 
was die Endgerät betrifft.

Und der Rest... Jo mei, entweder man beherrscht die Konfiguration eines 
IP-Netzwerks oder man beherrscht sie nicht. Es ist absolut scheißegal, 
ob der Endpunkt ein PC, ein Smart-TV, ein WLAN-Radio oder ein 
ATtiny-basiertes Gadget zur schnöden Überwachung einer Dachklappe ist. 
Es ist immer dasselbe Wissen, was man haben muß, um die Sachen dazu zu 
bringen, miteinander Reden zu können...

Das ist echte Synergy und echte Verringerung der Komplexität. Nur einmal 
etwas mehr lernen müssen, das aber immer wieder auf völlig 
unterschiedlichen Gebieten anwenden zu können.

Und es gibt auch sehr mächtige Hilfsmittel dafür für lau: Wireshark kann 
man auf jeden hergelaufenen PC oder Notebook mit drei Klicks 
installieren. Mit einer zweiten NIC (notfalls als USB-Stick für 5..10€) 
kann man PC/Notebook als Interceptor-Bridge in jede einzelne 
Netzwerkverbindung einschleifen. Wirklich nötig ist das aber nur sehr 
selten...

> Zuverlässigkeit im Sinne von Störunempfindlichkeit

An sich ist Cat6 empfindlicher als RS485. TCP macht die Sache 
zuverlässig. Er erkennt und wiederholt fehlerhafte Pakete.

Theoretisch wäre ja TCP über RS485 zuverlässiger als TCP über Ethernet. 
Nur macht so etwas niemand.

Aus eigner Erfahrung kann ich dir sagen, es ist viel Arbeit! Meine Idee 
wäre, STM32F407 in Form von Clients und Raspi als Server ins Netz zu 
hängen. So hast du eine stromsparende und stabile (kommt natürlich auf 
die Umsetzung an) Lösung. Ich habe einen 125KHz RFID Reader entwickelt 
und STM32F407 mit Lan. Wollte eigentlich auch so etwas ähnliches machen, 
habe es aber dann gelassen. Alleine mit so einem Produkt auf den Markt 
zu gehen erfordert hohe Investitionskosten.

Die billigste, einfachste und kleinste Lösung, eine Verbindung ins 
eigene Netzwerk zu erreichen, ist IMHO ein ESP8266 Modul. Die Module 
sind kleiner und billiger (im 10ner Pack) als ein MagJack, 
Protokollstack etc ist fertig, ein paar Prints und man ist im Netz.

MfG Klaus

c-hater schrieb:
> Da ist was dran. Der Punkt ist nur: das einzig Komplexe ist der
> Netzwerk-Stack und den brauch' ich nur einmal halbwegs fehlerfrei zu
> implementieren. Dann ist dieser Teil der Komplexität Geschichte, mutiert
> zur Blackbox, um die man sich keine Sorgen mehr machen muß. Jedenfalls,
> was die Endgerät betrifft.

Bis du das in Assembler geschrieben hast, kann sich keiner mehr dran 
erinnern seit wieviel Jahren die RS485 Lösung schon fehlerfrei seinen 
Dienst tut. Oder interpretiere ich "c-hater" falsch?

Naja, der µIP Stack ist in C geschrieben und ziemlich leicht portierbar 
und kleiner als 8kB. Man muss das Rad ja nicht gleich neu erfinden.

Komplexer als eine einfache serielle Verbindung bleibt's natürlich immer 
noch, denn man muss die IP Parameter irgendwie konfigurierbar machen.

Wenn du auch kleine uCs mit einbinden willst, ist sicher RS485 eine gute 
Wahl, da praktisch jeder Controller einen UART hat. Für Ethernet 
brauchst du schon MAC+Phy+Mag und mehr Speicher und Performance. Wenn 
dich die zusätzlich Hardware aber nicht abschreckt, kannst du ja auch 
noch über CAN nachdenken (je nach Datenvolumen und -geschwindigkeit). 
Ich mag daran nach wie vor, dass man sich kein Protokoll ausdenken, 
sondern nur die IDs sinnvoll vergeben muss.

Die Kommunikation zwischen AVR und Ethernet Controller kann auch 
parallel erfolgen, zum Beispiel beim CP2200 und CP2201. Da ist angeblich 
auch etwas schneller, als per SPI.
Allerdings ist spitzen-Performance nicht überall nötig.

> Aber wer will das schon, wenn man alles in einem Chip haben
> kann, dazu noch billiger

Ja, der PIC Controller ist durchaus interessant.

Gibt es eigentlich ARM Controller mit Ethernet und integriertem PHY?

Stefan Us schrieb:
> Gibt es eigentlich ARM Controller mit Ethernet und integriertem PHY?
Ja, gibt es: einige TM4C129x von TI. Einen angepassten lwIP-Stack gibt 
es und die ganze Geschichte ist recht einfach zum Laufen zu bringen. Die 
Chips kosten allerdings ein paar € mehr als die PICs.

Bei 485 kann man recht einfach z.B. 30 Geräte auf einen Bus zusammen 
fassen. Bei Ethernet brauche ich da schon einen recht großen Switch für 
der auch schon einiges an Strom verheizt.

Micha schrieb:
> Stefan Us schrieb:
> Gibt es eigentlich ARM Controller mit Ethernet und integriertem PHY?
>
> Ja, gibt es: einige TM4C129x von TI. Einen angepassten lwIP-Stack gibt
> es und die ganze Geschichte ist recht einfach zum Laufen zu bringen. Die
> Chips kosten allerdings ein paar € mehr als die PICs.
Ach ja: die TM4C haben 100MBit/s. Also wer's braucht...