Ich mache mir etwas konzeptionelle Gedanken, wie und womit man mikrocontrollergesteuerte Einzelgeräte (Eigenbau oder sonst weitgehend veränderbar) in geschäftlicher Umgebung (also Bürogebäude, Halle, Gelände, aber in eher kleinem Maßstab) sinnvoll vernetzt. Konkret denke ich dabei an Authentifizierungstationen, also z.B. Codeeingaben, Kartenleser, aber das betrifft eigentlich auch alle anderen denkbaren Anwendungsmöglichkeiten wie Sensoren (Hallentor offen, Tankfüllstand etc.) Das Ganze wird dann z.B. auf einem Server zentral oder sonstwie verwaltet. RFID-Leser fragt in der Datenbank, ob Karte 4711 die Kaffeemaschine freischalten darf, oder wenn das Kühlhaus nachts auftaut, gibts eine Email an den Chef. Sicherheitsaspekte seien für die Betrachtungen mal weitgehend außen vor. Es wird kein Atomreaktor und keine Brandmeldeanlage im Chemiewerk betrieben. Sonst entfällt Eigenbau ohnehin. Bastelnderweise würde ich für solche Stationen einen Arduino-Clone und ein Ethernetmodul nehmen, jeweils an "das" Netzwerk oder in ein eigenes hängen. Das Ganze dann von einem wie auch immer gearteten Server (Prozeß auf dem "richtigen" Server oder ein Raspberry oder sonstwas kleines) gesteuert. Wobei manche Stationen sinnvollerweise autonom agierende Clients wären (Chipkarte wird vorgehalten, Abfrage beim Server ob berechtigt, dann Türöffner betätigen), andere wie Temperatursensoren oder wenn es in Richtung Hausautomation geht (Dachluke bei Regen zufahren) auch Befehle empfangen können müssen. Mit TCP/IP über Ethernet geht das sicherlich alles. Es erscheint vorteilhaft, daß man bestehende Netzwerkinfrastruktur mitnutzen kann. In der Praxis hat man aber doch weitgehend sternförmige Verkabelung auf einen Punkt hin, nämlich den Serverraum. Bei auseinanderliegenden Objekten vielleicht einige wenige solcher Punkte. Und dann kann ich das Cat6-Kabel, das an meinem Mikrocontroller ankommt, doch auch am fernen Ende für beliebig anderes als Ethernet nutzen. Also statt in einen Switch stecke ich alle Stationen in ein X-Dings, spare mir die Ethernetmodule an den µCs und den Verwaltungsoverhead für TCP/IP. Das X-Dings hat nach außen eine TCP/IP-Schnittstelle zu meinem Serverprogramm und mit den µCs spricht es was auch immer. Zuverlässigkeit im Sinne von Störunempfindlichkeit ist gefragt, eine Stromversorgung ähnlich PoE wäre wünschenswert und hardwaremäßig soll keine Sonderverkabelung nötig werden und am µC möglichst wenig Aufwand entstehen. Genau da setzt meine Frage an: Was ist praktikabel?
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.
Falls es auf LAN hinaus läuft, so gibt es von WIZNET die Module WIZ107SR, die auf einer Seite TCP-IP und auf der anderen Seite eine serielle Schnittstelle haben. Für Mikrocontroller schön einfach. Konfiguration per Tool über's Netzwerk. Beim eventuellen Kauf darauf achten, dass es die TTL-Version und nicht die V.24 ist (sonst wird ein Extra-Pegelwandler gebraucht).
Wolfgang schrieb: > Zuverlässigkeit im Sinne von Störunempfindlichkeit ist gefragt, eine > Stromversorgung ähnlich PoE wäre wünschenswert und hardwaremäßig soll > keine Sonderverkabelung nötig werden und am µC möglichst wenig Aufwand > entstehen. > > Genau da setzt meine Frage an: Was ist praktikabel? Die mit Abstand einfachste, kleinste und billigste Möglichkeit, einen Ethernetknoten zu realisieren, ist ein PIC18F67J60. Dieser Chip enthält alles: Prozessor, RAM, Flash, IO, Ethernet MAC, Ethernet PHY. Du brauchst nur noch ein paar passive Bauelemente und einen 3.3V Spannungsregler. Weniger geht nicht. Und zum Fernwirken reicht diese Lösung allemal. Beitrag "Re: LED-Panel per Ethernet anbinden" Beitrag "Re: Günstigstes Web I/O" Da Du noch POE willst, käme hier noch ein passender Schaltregler dazu. Eine der günstigsten Lösungen ist der NCP1080. Das teure hier ist der Transformator, der Chip ist billig. http://www.onsemi.com/PowerSolutions/product.do?id=NCP1080 Hier pinnst Du einfach den Schaltplan ab. Damit hast Du alles zusammen. fchk
Felix Adam schrieb: > Falls es auf LAN hinaus läuft, so gibt es von WIZNET die Module > WIZ107SR, die auf einer Seite TCP-IP und auf der anderen Seite eine > serielle Schnittstelle haben. Für Mikrocontroller schön einfach. > Konfiguration per Tool über's Netzwerk. Ich habe bereits mit einem WizFi 630 gearbeitet. Für schnelle Bastellösungen ganz nett, aber nicht für den produktiven einsatz geeignet. Zu Stromhungrig, zu sensibel mit der Spannungsversorgung. Die UART schnittstelle macht zwar das einrichten einer kommunikation einfach, jedoch verlierst du die kontrolle darüber, mit wem der chip kommuniziert. Frank K. schrieb: > Die mit Abstand einfachste, kleinste und billigste Möglichkeit, einen > Ethernetknoten zu realisieren, ist ein PIC18F67J60. Dieser Chip enthält > alles: Prozessor, RAM, Flash, IO, Ethernet MAC, Ethernet PHY. Sehe ich ebenso. Das ist der kleinste prozessor, den ich kenne, der ALLES mit an board hat. Dazu einen abgespeckten TCP/IP Stack mit etwa 4kByte Codegröße, entspricht der umgangssprachlichen Eierlegenden Wollmilchsau für vernetzte mini-gadgets
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
der ESP8266 ist aber WLAN! Für große Entfernungen also ungeeignet
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.
Micha schrieb: > 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. Der von mir erwähnte PIC hat 8k RAM. Reicht. Die Rechenleistung liegt im Bereich eines normalen AVR. Das widerlegt Deine Behauptung. Wobei: Bei einem AVR-System liegt zwischen AVR und Ethernet immer ein SPI, während die Ethernet-PICs direkt ohne Umwege per Hauptspeicherzuriff arbeiten können. Im direkten Vergleich mit SPI und einem ENC28J60 (etwas ähnliches ist auch im PIC eingebaut) ergibt sich etwa eine 40-80% höhere Datenrate. fchk
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.
Stefan Us schrieb: > Die Kommunikation zwischen AVR und Ethernet Controller kann auch > parallel erfolgen, zum Beispiel beim CP2200 und CP2201. Sicher. Aber wer will das schon, wenn man alles in einem Chip haben kann, dazu noch billiger, und der 25 MHz-Quarz taktet dann auch den Prozessor, was dann nochmals Platz- und Geldersparnis bringt? Der CP2200 alleine kostet über 5$, und beim PIC18F67J60 hast für 3.50$ alles drin und dran. fchk
Am einfachsten für den Schaltungsentwickler ist - wenn es denn Ethernet sein soll - allemal ein XPORT oder entsprecheder Clone. Abmessungen: Ethernet-Buchse, Funktion: Ethernet-zu-seriell-Wandler, Alles drin, Alles dran. http://www.lantronix.com/device-networking/embedded-device-servers/xport-pro-lx6.html
:
Bearbeitet durch User
> 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: >> 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? Es gab die Luminary Micro Serie LM3S..., die von TI samt Firma gekauft wurde. Das Zeugs war aber so grottig (ich habe ich ausprobiert), dass es nach kurzer Zeit wieder eingestampft wurde. Ob die LM4* einen PHY im Package haben, weiß ich nicht. Das ist dann aber mit Sicherheit ein Multi-Die Package, also teuer. Der PIC ist noch so einfach, dass Prozessor, MAC und PHY auf einem Siliziumplättchen gemeinsam produziert werden können. Bei den höher integrierten Prozessoren geht das nicht mehr. Das ist das gleiche wie mit den CAN-Transceivern. Die brauchen auch einen völlig anderen Halbleiterprozess und sind deswegen immer separate Chips, auch wenn NXP Prozessor und Transceiver in ein Package packt. fchk
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.
Was sagt der der Fragesteller zu der ganzen Sache? fchk
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...
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.