Ich wundere mich gerade. Ich würde gerne mehrere Raspberrys über ein Bussystem via GPIO miteinander kommunizieren lassen. Problem hierbei: Der Raspberry kann weder I2C im Slave Mode noch SPI im Slave Mode. Sehe ich das richtig? Gibt es weitere Möglichkeiten z.b. 5 Raspberrys über einen GPIO Bus miteinander kommunizieren zu lassen ohne einen speziellen HAT dafür zu benutzen? Wie sieht es mit serieller UART aus? Das ist ja ausschließlich eine Ende zu Ende Verbindung, richtig?
Rene K. schrieb: > Der Raspberry kann weder I2C im Slave Mode noch SPI im > Slave Mode. Sehe ich das richtig? bei i2c mag sein, sonst hat er MISO und MOSI, auch ein Ring aus Tx und Rx wäre denkbar. PIa an PIb usw. jeder PI der angesprochen wird gibt die Nachricht weiter bis sie wieder am richtigen Empfänger ankommt.
Da brauche ich ja auch jeweils zwei Schnittstellen. Das Ringformat mit Adresse ist aber eine gute Idee. Da nicht allzuviel Daten gesendet werden, werde ich wohl über Bit-Banging und zwei Pins ein eigenes Protokoll implementieren.
Joachim B. schrieb: > Rene K. schrieb: >> werde ich wohl über Bit-Banging > > wieso, sind doch Rx und Tx vorhanden Ja die UART ist ja eine Ende-zu-Ende Verbindung. Wenn an den gleichen zwei Leitungen aber 5 Raspberrys hängen, dann kommen sie sich doch aber in die Quere.
was verstehst du an Ring nicht?
1 | ---> PIa--->PIb--> |
2 | | | |
3 | <---PId<---PIc<--- |
Rene K. schrieb: > Wenn an den gleichen > zwei Leitungen aber 5 Raspberrys hängen, dann kommen sie sich doch aber > in die Quere. wie oft quasseln die denn und wie lange?
:
Bearbeitet durch User
Rene K. schrieb: > Ja die UART ist ja eine Ende-zu-Ende Verbindung. Wenn an den gleichen > zwei Leitungen aber 5 Raspberrys hängen, dann kommen sie sich doch aber > in die Quere. Du sollst die ja auch als Ring verschalten und nicht parallel! Also: Pi1_Tx -> Pi2_Rx, Pi2Tx -> Pi3_Rx, .... PiN_Tx -> Pi1_Rx
Ahh ja jetzt schlummerts :-D Quasi so wie im Bild oben. Und der Ablauf wäre dann folgender... Server sendet Nachricht mit Slave Adresse - Nachricht läuft solange durch bis Slave erreicht - Nachricht wird verarbeitet und schickt sie im Ring mit der Adresse des Servers weiter - Server sieht seine Adresse und verarbeitet die Nachricht.... Das klingt super. Für RS458 bräuchte ich ja wieder einen extra Umsetzer. Das möchte ich ja nicht. Somit ist der Ring genau das was ich suche. Die Daten sind sehr überschaubar. Im Grunde nur jede Minute ca. 10Bytes - nacheinander an jeden Slave dann.
Murkser schrieb: > Warum nicht gleich den Ethernet Port nutzen? Weil das in diesem Fall nicht möglich ist, das wäre gewiss die einfachste Möglichkeit.
Rene K. schrieb: > Das klingt super. Ja, pro Client 2 potentielle Fehlerstellen für den gesammten Ring. Funktioniert theoretisch aber schön ist was anderes.
>> Problem hierbei: Der Raspberry kann weder I2C im Slave Mode noch SPI im >> Slave Mode. Sehe ich das richtig? Nein. Tipp: Du solltest dieses neue Dings Internet mal versuchen. Dort gibt es sogenannte Suchmaschinen. Z. B. https://duckduckgo.com/
Wie lang werden eigentlich die Kabel und wie schaut die Stromversorgung aus? Evt. braucht man alleine deshalb RS485-Treiber.
Male schrieb: > Nein. Tipp: Du solltest dieses neue Dings Internet mal versuchen. Dort > gibt es sogenannte Suchmaschinen. Z. B. https://duckduckgo.com/ Ich weiß zwar nicht was du mir damit sagen willst. Aber gerade dieses "neue Ding Internet" und deren Gehilfen in Form von Suchdingern (in meinem Fall der Herr Google) hat mich ja gerade darauf gebracht das der Raspberry weder im I2C noch im SPI im Slave Mode laufen sondern ausschließlich als Master. Ich bin fest davon ausgegangen das eben gerade dies (Slave Mode) beim Raspberry möglich ist. Ist es aber nicht. Nun denn, solltest du dich natürlich besser mit diesem modernen Thema Internet auskennen und eine Möglichkeit in diesen neumodischen Suchdingern finden die erklären wie ich die Hardwarebeschränkung bei I2C oder SPI ohne Software Bit-Banging (ohne Auslöten des EEPROM!) umgehen kann... Dann nur her damit, ich bin gespannt. ?
Bauform B. schrieb: > Wie lang werden eigentlich die Kabel und wie schaut die Stromversorgung > aus? Evt. braucht man alleine deshalb RS485-Treiber. Es ist nur in-Circuit und maximal (bei Ring) 30cm Leitungslänge. Zwischen den PIs sind es ca. 3cm Leitungslänge. Als Strom stehen 12V, 5V sowie 3V3 zur Verfügung (die 3V3 vom Raspberry bereitgestellt) .
:
Bearbeitet durch User
Rene K. schrieb: > Weil das in diesem Fall nicht möglich ist Und warum nicht? Ist die Leiterzahl begrenzt? Ethernet ist etabliert, Kabel, Switche und zugehörige Software sind billig und gut verfügbar, das ganze ist stabil und zuverlässig. Man kann es auf Wunsch leicht ans Internet anbinden, über beliebige andere Netze umleiten und es gibt Unmengen an Software zur Übertragung aller möglichen Daten, und es ist einfach, eigene Software damit zu entwickeln. Nebenher kann man die PI's darüber auch fernwarten (SSH). Wenn man schon Ethernet-Transceiver zur Verfügung hat, braucht man einen schon sehr guten Grund, die nicht zu nutzen... Wenn es aus irgendwelchen Gründen dann doch RS485/seriell wird, kannst du ja PPP darüber nutzen, damit du wenigstens einen Teil der genannten Vorteile hast (IP-Kommunikation und vorhandene Software).
Rene K. schrieb: > Es ist nur in-Circuit und maximal (bei Ring) 30cm Leitungslänge. > Zwischen den PIs sind es ca. 3cm Leitungslänge. Im Ernst? Dann nimm doch einen Switch und eine Hand voll 5cm-Kabel. Das ist mit Abstand am Billigsten, Einfachsten und leistungsfähigsten. Das Zubehör bekommst du sogar im Mediamarkt, und du musst nix selber basteln.
Programmierer schrieb: > Rene K. schrieb: > Es ist nur in-Circuit und maximal (bei Ring) 30cm Leitungslänge. > Zwischen den PIs sind es ca. 3cm Leitungslänge. > > Im Ernst? Dann nimm doch einen Switch und eine Hand voll 5cm-Kabel. Das > ist mit Abstand am Billigsten, Einfachsten und leistungsfähigsten. Das > Zubehör bekommst du sogar im Mediamarkt, und du musst nix selber > basteln. Programmierer schrieb: > Und warum nicht? Ist die Leiterzahl begrenzt? Ethernet ist etabliert, > Kabel, Switche und zugehörige Software sind billig und gut verfügbar, > das ganze ist stabil und zuverlässig. Man kann es auf Wunsch leicht ans > Internet anbinden, über beliebige andere Netze umleiten und es gibt > Unmengen an Software zur Übertragung aller möglichen Daten, und es ist > einfach, eigene Software damit zu entwickeln. Nebenher kann man die PI's > darüber auch fernwarten (SSH). Wenn man schon Ethernet-Transceiver zur > Verfügung hat, braucht man einen schon sehr guten Grund, die nicht zu > nutzen... > > Wenn es aus irgendwelchen Gründen dann doch RS485/seriell wird, kannst > du ja PPP darüber nutzen, damit du wenigstens einen Teil der genannten > Vorteile hast (IP-Kommunikation und vorhandene Software). Ich kann deine Einwände, wie oben bereits gesagt, voll und ganz verstehen und stehe damit völlig konform mit dir. Aaaaaber: Der RaspberryPi Zero hat keinen Nic! Deswegen ja explizit die Frage nach Bus über GPIO.
Rene K. schrieb: > Der RaspberryPi Zero hat keinen Nic! Deswegen ja explizit die Frage nach > Bus über GPIO. Ach, gut zu wissen dass es um den Zero geht. Dann definiere einen der PI's, oder einen externen PC als Host, stecke einen USB-Hub ein, und schließe die (anderen) PI's da an. Dann aktivierst du auf den PI's das USB-CDC-Modul für Ethernet-über-USB und vernetzt die darüber. Dann noch etwas Routing-Konfiguration und du hast ein Netz über USB aufgebaut. Braucht ebenfalls nur Mediamarkt-Zubehör. Alternativ konfigurierst du die PI's als "echte" USB-Geräte (USB Gadget Treiber oder configfs) und schreibst eine eigene USB-Host-Anwendung z.B. via libusb. Ist etwas schöner, aber auch komplizierter.
Rene K. schrieb: > Murkser schrieb: >> Warum nicht gleich den Ethernet Port nutzen? > > Weil das in diesem Fall nicht möglich ist, das wäre gewiss die > einfachste Möglichkeit. Dann würde ich die entsprechenden Änderungen vornehmen damit dafür noch Platz ist. Wie willst Du die sonst überhaupt in irgendeiner vernünftigen Weise installieren/warten/updaten/debuggen/überwachen/etc. ohne Netzwerk? Man muß es sich doch nicht ohne Not noch extra schwer machen (außer vielleicht im Sport). Ist es ein Sport?
Bernd K. schrieb: > Rene K. schrieb: >> Murkser schrieb: >>> Warum nicht gleich den Ethernet Port nutzen? >> >> Weil das in diesem Fall nicht möglich ist, das wäre gewiss die >> einfachste Möglichkeit. > > Dann würde ich die entsprechenden Änderungen vornehmen damit dafür noch > Platz ist. Programmierer schrieb: > und schreibst eine eigene USB-Host-Anwendung z.B. via libusb. > Ist etwas schöner, aber auch komplizierter. sagt mal, geht's noch? Gibt es einen Preis für die komplizierteste Lösung? Für 50 Byte pro Minute über ein paar Zentimeter? Der UART-Ring braucht außer den Kabeln kein einziges Bauteil und schon garkein extra Gerät. Und die Software ist etwas überschaubarer...
Rene K. schrieb: > Für RS458 bräuchte ich ja wieder einen extra Umsetzer. Das möchte ich ja > nicht. Somit ist der Ring genau das was ich suche. Nicht unbedingt. Du kannst auch die Leitung an einer Stelle mit Pullup auf High setzen und der Sender wackelt dann entsprechend an der Leitung. Der Commodore Bus war so aufgebaut. Der hatte aber noch ein paar mehr Leitungen zur Flusskontrolle.
Bauform B. schrieb: > Und die Software ist etwas überschaubarer... Die Software mit UART wird wahrscheinlich umständlicher als einfach nen Netzwerksocket oder 0MQ oder sowas zu benutzen. > Gibt es einen Preis für die komplizierteste Lösung? Die Entwicklung und die Wartung wird 100 mal umständlicher wenn man nicht mehr an das laufende System rankommt weil man versehentlich das Netzwerk ersatzlos weg-"rationalisiert" hat. Insofern muß ich diese Frage also postwendend zurückgeben.
Bernd K. schrieb: > Die Entwicklung und die Wartung wird 100 mal umständlicher wenn man > nicht mehr an das laufende System rankommt weil man versehentlich das > Netzwerk ersatzlos weg-"rationalisiert" hat. na ja auch wenn die SD Karte aufgibt, mir schon zu oft passiert, schliesslich liegt die SWAP auf der SD. Aber PI mit NIC hilft da auch nicht ausser PI3 mit Netzwerkboot.
Bernd K. schrieb: > Die Entwicklung und die Wartung wird 100 mal umständlicher wenn man > nicht mehr an das laufende System rankommt weil man versehentlich das > Netzwerk ersatzlos weg-"rationalisiert" hat. Ganz genau! "Bauform" hat hier die typische Ingenieurs-brille auf: Es gibt zwar schon eine etablierte, stabile Schnittstelle (USB) auf dem Board, aber weil die nicht direkt sofort das tut was man braucht, bastelt man lieber eine ganz neue Hardware dazu... Bauform B. schrieb: > Gibt es einen Preis für die komplizierteste Lösung? Die Lösung ist extrem einfach. Man steckt fertige, vorhandene Komponenten zusammen und nutzt sie mithilfe fertiger, vorhandener, stabiler, flexibler Software. Sogar der Bauteilaufwand ist minimal - es wird nur der USB-Hub-IC gebraucht. Indem man einen Hub mit fest angebrachten Kabeln nutzt, das Gehäuse und Stecker entfernt und das dann verlötet wird es auch sehr kompakt, aber weniger flexibel. Die ganze Frickelei mit Paketierung der Daten, Prüfsummen, Fehlerkorrektur, Adressierung, Weiterleitung im Ring usw. spart man sich komplett - das macht alles Linux schon selbst. Man kann direkt komfortable High Level Protokolle nutzen und muss nicht das millionste Rad neu erfinden. Ganz nebenher kann man die PI's dann auch per SSH fernwarten, Daten übertragen usw. ohne irgendwas umstecken zu müssen.
Bauform B. schrieb: > Der UART-Ring braucht außer den Kabeln kein einziges Bauteil und schon > garkein extra Gerät. Und die Software ist etwas überschaubarer... Bauform B. schrieb: > sagt mal, geht's noch? Gibt es einen Preis für die komplizierteste > Lösung? Für 50 Byte pro Minute über ein paar Zentimeter? deswegen würde ich ja den PI3 vorschlagen und Netzwerkboot
Joachim B. schrieb: > deswegen würde ich ja den PI3 vorschlagen und Netzwerkboot Ich würde einen einzelnen SBC vorschlagen der die Aufgaben der mehreren PI Zero auf einmal erledigen kann, sodass sich das Problem in Luft auflöst. Es gibt SBC mit sehr viel IO, und wenn es um Rechenleistung geht - auf einen Server auslagern. Der PI ist nicht das Zentrum der Welt, und nicht jedes Problem, das ein PI nicht lösen kann, sollte durch die Verwendung von mehr PI's gelöst werden.
Programmierer schrieb: > Der PI ist nicht das Zentrum der Welt sehe ich auch so Programmierer schrieb: > stabile Schnittstelle (USB) auf dem > Board, aber weil die nicht direkt sofort das tut was man braucht, > bastelt man lieber eine ganz neue Hardware dazu... man könnte ja USB RS232 Adapter verkabeln oder USB NIC anstecken und bräuchte dann noch einen switch wer Ironie findet ....
Rene K. schrieb: > Male schrieb: >> Nein. Tipp: Du solltest dieses neue Dings Internet mal versuchen. Dort >> gibt es sogenannte Suchmaschinen. Z. B. https://duckduckgo.com/ > > Ich weiß zwar nicht was du mir damit sagen willst. Es tut mit wirklich leid, dass du nicht in der Lage bist etwas so einfaches zu recherchieren. Der Raspberry Pi (Slave) wird bei mir von einem ATMega328p (Master) angesprochen.
Rene K. schrieb: > 5 Raspberrys Rene K. schrieb: > Es ist nur in-Circuit und maximal (bei Ring) 30cm Leitungslänge. > Zwischen den PIs sind es ca. 3cm Leitungslänge. was machen 5 PI so nah beieinander was nicht einer erledigen kann? Wenn es nicht einer erledigen kann würde ich zum NUC greifen.
Programmierer schrieb: > Der PI ist nicht das Zentrum der Welt, und nicht jedes Problem, das ein > PI nicht lösen kann, sollte durch die Verwendung von mehr PI's gelöst > werden.
1 | Ist das einzige Werkzeug, was man kennt, ein Knüppel, |
2 | sehen alle Probleme aus wie Robbenbabys. |
novalix, debianforum.de, 2014-01-12
Rene K. schrieb: > Der RaspberryPi Zero hat keinen Nic! Deswegen ja explizit die Frage nach > Bus über GPIO. Das Zero W aber inform einer WLAN-Schnittstelle.
STK500-Besitzer schrieb: > Das Zero W aber inform einer WLAN-Schnittstelle. vermutlich dort kein wlan oder gar in einer schwer erreichbaren Kiste kein Empfang :)
Joachim B. schrieb: > vermutlich dort kein wlan oder gar in einer schwer erreichbaren Kiste > kein Empfang :) ja, vermutölich in einer Salami versteckt. Man könnte den Zeros doch feste IP-Adrressen geben, dann sollten sie sich untereinander unterhalten können.
STK500-Besitzer schrieb: > Man könnte den Zeros doch feste IP-Adrressen geben, dann sollten sie > sich untereinander unterhalten können. warum sollen sich denn 5 Raspis unterhalten? Was können 5 Raspis beieinander was einer nicht alleine schafft?
Joachim B. schrieb: > warum sollen sich denn 5 Raspis unterhalten? > Was können 5 Raspis beieinander was einer nicht alleine schafft? Bei meinem Projekt spricht ein Arduino per Bluetooth mit einem Raspberry Pi Zero W... Das Zero W streamt dann auch noch ein Videobild und bekommt aus dem Intranet auch noch Befehle. Das Raspberry Pi (an einem Fräskopf montiert) bewegt sich... Bzgl. der gewünschten Kabel-Lösung fällt mir auch kein sinnvoller Grund ein.
Soo... Erstmal vielen Dank an die User die mir mit sinnvoller Hilfe zur Seite standen und mir die richtigen Tipps und Denkanstöße gegeben haben. Ich habe es nun über UART im Ring gelöst. Es läuft genau so wie ich mir das erhofft habe. Vielen Dank euch. Auch wäre RS485 eine gute Idee gewesen. Just my 2cents - zu den anderen. Sagt mal Leute, jetzt ehrlich? Ist das wirklich euer Ernst? Ich habe fünf Zero W, alle fünf stecken auf einer Rasterplatine mit Pfostenstecker, von dieser Platine bekommen sie auch ihren Strom. An den fünf RP Stöpsel ich externe Datenträger an, von diesen Datenträgern werden Daten gelesen, berechnet und diese Werte werden je Minute abgefragt. Es sind zehn Byte.... 10 Byte (!!!!) Ich habe sechs dämliche Kabel gelötet bei drei Pins die Adresse des jeweiligen Slot hart gelötet. Es war ganze zehn Minuten Arbeit. Das Script dazu ist ein Python Zwanzigzeiler. Herrgott, die Frage war ganz simpel. Eine Antwort auf Netzwerk habe ich mit Begründung abgelehnt. Wieso um Gottes Willen soll ich mir da eine Nic dranbastelln, ein Switch aufstellen, fünf NW Kabel ziehen um 50 Bytes Nutzdaten zu transportieren? Und nein: ich möchte auch kein WLAN AP aufziehen. Auch muss ich auf den RP nichts aktualisieren? Warum auch??? Die Dinger laufen, und laufen gut, genauso wie ich das möchte. Und die würden auch in zwanzig Jahren noch genauso, mit der gleichen Software laufen. Sie sind nicht am Netz, daher auch kein Bedarf an Sicherheitspatches. Kann das ganze ein anderer SoC, PC oder SuperCluster nicht besser, schneller und Stromeffiezienter?!? Ja NATÜRLICH können die das! Ohne Frage! Aber die habe ich nunmal nicht, und werde ich mir zu diesem Zweck auch nicht anschaffen. Warum auch? Die RP liegen hier rum und reichen für den Zweck allemal! Zum Thema SD Card. Hey, ich weiß nicht was ihr für SD Karten habt, ich habe SanDisk 8GB Karten. Ich habe zwei RPs 2B seit nun fünf (5!!) Jahren in meinem Schrank hängen, an 4 Spax-Schrauben. Auf dem einen läuft ein Git Server und Opencloud. Auf dem anderen ein Web und SQL Server... Beide laufen seit fünf Jahren 24/7 durch... Mit Ihrer ersten SD Karte! Wisst ihr, ich glaube das ist auch einer der Gründe warum Deutschland in der Forschung mittlerweile so weit hinterher hinkt. Wenn völlig an der Realität und am Ziel vorbei entwickelt wird. Ich hoffe... nein ich bete darum... Das nicht alle Ingenieure so fern der Realität sind wie so manche hier. Das ist erschreckend und beängstigend zugleich. Was macht ihr wenn von euch verlangt wird ein 1 Meter Strich zu zeichnen? Empfehlt ihr dann erstmal drei Satelliten ins All zu schießen um die Linie zu triangulieren? Zum Thema Google und an den User Male... Sagmal wie machst du das mit deiner Frau zu Hause? Wenn sie fragt: "Kannst du mir mal helfen und den Verschluss aufmachen?“ antwortest du dann: " Natürlich kann ich, hab ich schon gemacht, aber frag doch Google wie das geht! "?? Im Grunde, ist dies nur belangloses Geschwätz ohne Substanz und kein Hinweis auf eine Lösung des Problems. Denn dies bist du schuldig geblieben und daher steht noch immer, so wie es auch bei Raspberry Foundation zu lesen ist: Es ist nicht möglich den I2C und SPI im Slave Mode zu betreiben. Von Sozialkompetenz einiger User hier möchte ich garnicht erst anfangen... Da lobe ich mir, ganz ehrlich solch User wie C-Hater. Er jedenfalls trägt in der ersten Hälfte seiner Postings sehr solide, mit viel Kompetenz und zielführend zu Lösung des Problemes bei um sich dann im zweiten Teil seiner Posts seiner niedrigen Instinkte hinzugeben. Das kann man noch unter "Digitalem-Tourette" verbuchen. Aber Mancher hier wird ohne Grund und Sinn beleidigend und diffamierent ohne auch nur eine Silbe zum Thema beizutragen. Erschreckend sowas. my2cents Ende! Ich hoffe ein Moderator schließt dieses Thema!
:
Bearbeitet durch User
Joachim B. schrieb: > auch ein Ring aus Tx und > Rx wäre denkbar. war die erste und meine Antwort! Es dauerte lange bis du es verstanden hattest Rene K. schrieb: > Da lobe ich mir, ganz ehrlich solch User wie C-Hater. Er > jedenfalls trägt in der ersten Hälfte seiner Postings sehr solide und damit verprellst du alle Anderen, aber nun gut auch das ist man ja gewohnt hier!
Rene K. schrieb: > Es war ganze zehn Minuten Arbeit. Das Script dazu ist ein Python > Zwanzigzeiler. Ach, was für ein Protokoll nutzt du? Was machst du, wenn einzelne Bits gekippt sind? Wenn ein Byte fehlt, und der Paket-Anfang/Ende durcheinander geraten? Komisch, dass in anderen Protokoll Implementationen Millionen Zeilen Code und Mannjahrhunderte Arbeit stecken, wenn das auch in Python in 20 Zeilen geht. Rene K. schrieb: > Wisst ihr, ich glaube das ist auch einer der Gründe warum Deutschland in > der Forschung mittlerweile so weit hinterher hinkt. Ja, weil die Leute die allererstbeste "Lösung" nutzen und nicht darüber nachdenken, was im Fehlerfall passiert, oder wenn neue Anforderungen dazu kommen. Und natürlich auch, wenn Anforderungen nur scheibchenweise dazu kommen: Rene K. schrieb: > Die RP liegen hier rum und reichen für den Zweck allemal! Rene K. schrieb: > Wieso um Gottes Willen soll ich mir da eine Nic dranbastelln, ein Switch > aufstellen, fünf NW Kabel ziehen um 50 Bytes Nutzdaten zu > transportieren? Es wurden noch andere Alternativen genannt. Da hätte man gar nichts löten müssen. PC-Mäuse übertragen auch nur einzige Datenmengen, aber sind auch nicht mehr per UART angebunden. Rene K. schrieb: > Beide laufen seit fünf Jahren 24/7 durch... Mit Ihrer ersten SD Karte! Dann warte mal auf den ersten Stromausfall.
Programmierer schrieb: > Ach, was für ein Protokoll nutzt du? Was machst du, wenn einzelne Bits > gekippt sind? Wenn ein Byte fehlt, und der Paket-Anfang/Ende > durcheinander geraten? Bei nur 3cm Leitungslänge kippen keine Bits, und es gehen erst recht keine ganzen Bytes verloren. Falls dies auf Grund extrem verseuchter Umgebung oder Versorgungsspannung dennoch passieren sollte, ist auch mit Fehlern bei RAM-Zugriffen zu rechnen, für die auf dem Raspberry ebenfalls kein fehlerbehandelndes Protokoll verwendet wird. Da alle Raspberries an einer gemeinsamen Stromversorgung hängen, muss auch nicht viel synchronisiert werden. Um unterschiedlich lange Boot-Dauern der einzelnen Raspberries auszugleichen, genügt es, wenn einer der Knoten wiederholt eine Testnachricht an sich selber schickt und nach dem erstmaligen Empfang derselben eine weitere Nachricht, die den anderen Knoten mitteilt, dass der Ring komplett ist und genutzt werden kann. > Komisch, dass in anderen Protokoll Implementationen Millionen Zeilen > Code und Mannjahrhunderte Arbeit stecken, wenn das auch in Python in > 20 Zeilen geht. Diese Protokolle sind für ganz andere Anforderungen konzipiert, Der UART-Ring dürfte hardwareseitig an Einfachheit (5 Stückchen Draht) nicht zu unterbieten sein, und ist auch protokollmäßig einfacher als bspw. ein RS485-Bus, da prinzipbedingt keine Buskollisionen auftreten können. Insofern sind Dinge wie USB und Ethernet erst recht mit Kanonen auf Spatzen geschossen.
Programmierer schrieb: > Rene K. schrieb: >> Es war ganze zehn Minuten Arbeit. Das Script dazu ist ein Python >> Zwanzigzeiler. > > Ach, was für ein Protokoll nutzt du? Was machst du, wenn einzelne Bits > gekippt sind? Wenn ein Byte fehlt, und der Paket-Anfang/Ende > durcheinander geraten? Komisch, dass in anderen Protokoll > Implementationen Millionen Zeilen Code und Mannjahrhunderte Arbeit > stecken Da kommen dann so Sachen wie UDP raus, wo es völlig akzeptabel ist, wenn ganze Pakete spurlos verschwinden... Oder die auf ein ping hin das ganze System abstürzen lassen... Programmierer schrieb: > Rene K. schrieb: >> Wisst ihr, ich glaube das ist auch einer der Gründe warum Deutschland in >> der Forschung mittlerweile so weit hinterher hinkt. > > Ja, weil die Leute die allererstbeste "Lösung" nutzen und nicht darüber > nachdenken, was im Fehlerfall passiert, oder wenn neue Anforderungen > dazu kommen. Möglicherweise liegt es auch daran, dass Mannjahrhunderte lang an der Eier legenden Wollmilchsau geforscht wird -- die dann vor lauter zukunftsträchtigen Features nicht mehr laufen kann.
Yalu X. schrieb: > Bei nur 3cm Leitungslänge kippen keine Bits, und es gehen erst recht > keine ganzen Bytes verloren Ach, gut zu wissen, dann hab ich mir das wohl eingebildet. Yalu X. schrieb: > Diese Protokolle sind für ganz andere Anforderungen konzipiert, Erfüllen die Anforderungen aber. Und sind fertig. Bauform B. schrieb: > Da kommen dann so Sachen wie UDP raus, wo es völlig akzeptabel ist, wenn > ganze Pakete spurlos verschwinden... Defekte Pakete werden aber erkannt. Und die Verantwortung wird hier lediglich auf die Anwendung verschoben. Yalu X. schrieb: > Der UART-Ring dürfte hardwareseitig an Einfachheit (5 Stückchen Draht) > nicht zu unterbieten sein, Stimmt, USB hat 10 Stückchen Draht und ein IC. Die man alle nachgeworfen bekommt. Wo man noch nichtmal irgendwas löten müsste. Wo man sich um die Hochfahr-Phase, verlorene Pakete usw. überhaupt nicht zu kümmern braucht. Wie gesagt, typisch Ingenieur: Anstatt die etablierte Lösung zusammen zu setzen basteln wir selbst schnell was hin, und für die Software-Probleme sind die Programmierer zuständig. Dass die Programmierer lieber fertige Software-Pakete (z.B. Protokollstacks) verwenden würden, was aber einen entsprechenden Physical Layer voraussetzt, ist denen egal. Naja, der TO ist ja beides in Persionalunion und muss seine Schnellschuss-Lösung dann selbst ausbaden. Prinzipiell nicht mein Problem, aber für sinnvolle Lösungsvorschläge beleidigen lassen muss ich mich nicht.
Programmier schrieb: > Wie gesagt, typisch Ingenieur: Anstatt die etablierte Lösung zusammen zu > setzen basteln wir selbst schnell was hin Was ist an einem seriellen Ring nicht etabliert? Das wurde früher häufig so gemacht und hat bestens funktioniert. Für das was der TO vor hatte ist das die einfachste Lösung mit dem minimalsten Aufwand. Über das Protokoll muß er sich eigentlich auch wenig Gedanken machen, da er sehr wahrscheinlich die UART-Schnittstelle des RasPi benützt. Für die UART-Schnittstelle gibt es in Python definitiv passende Klassen, um die Daten seriell zu senden. Er muß dann nur noch die empfangenen Daten anschauen und prüfen ob sie für den jeweiligen Raspi bestimmt sind oder nicht. Im ersten Fall werden die Daten verarbeitet im zweiten einfach weiter gerreicht. Um dies zu realisieren braucht's wirklich nicht mehr als 20 Zeilen. Du gehörst ganz offensichtlich zu den Leuten die mit Kanonen auf Spatzen schießen - scheint aber heutzutage normal zu sein. Sieht man leider an viel zu vielen Stellen.
Programmier schrieb: > Stimmt, USB hat 10 Stückchen Draht und ein IC. Die man alle nachgeworfen > bekommt. Wo man noch nichtmal irgendwas löten müsste. Wo man sich um die > Hochfahr-Phase, verlorene Pakete usw. überhaupt nicht zu kümmern > braucht. Huch? Also wenn mich meine Erinnerung nicht trügt, muss man sich bei USB sehr wohl um die "Hochfahr-Phase" kümmern und auch um verlorene Pakete (weil Device mittlerweile absent). Selbst auf Anwendungsebene. All die Implikationen von Plug'n'Play halt... > Wie gesagt, typisch Ingenieur: Anstatt die etablierte Lösung zusammen zu > setzen Das tut er. UART-Ringstrukturen sind schon eine etablierte Lösung gewesen, da hat Intel an USB noch nichtmal gedacht... Ich wünschte oft, sie wären auch nie auf diese blödsinnige Idee gekommen, denn USB war von Anfang an eher ein Hack denn eine saubere Lösung, ist aber über die Jahrzehnte wohl zur maximalverbasteltsten Sammlung von Standards geworden, die dieser Planet jemals gesehen hat... Der einzige Vorteil von USB ist: das ganze Elend ist für jeden zumindest einsehbar (wenn man auch nur für viel Geld wirklich mitspielen darf)...
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.