mikrocontroller.net

Forum: PC Hard- und Software RaspberryPi: GPIO Kommunikation


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Rene K. schrieb:
> werde ich wohl über Bit-Banging

wieso, sind doch Rx und Tx vorhanden

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
was verstehst du an Ring nicht?
---> PIa--->PIb-->
|                 |
<---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
von Dirk B. (dirkb2)


Bewertung
1 lesenswert
nicht lesenswert
Was ist mit RS485?

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Dirk B. schrieb:
> Was ist mit RS485?

auch gut

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bauform B. (bauformb)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Parallel geht auch ohne RS485

von Rene K. (xdraconix)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

von Murkser (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Warum nicht gleich den Ethernet Port nutzen?

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Horst (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Male (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>> 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/

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Wie lang werden eigentlich die Kabel und wie schaut die Stromversorgung 
aus?  Evt. braucht man alleine deshalb RS485-Treiber.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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. 😉

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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
von Programmierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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).

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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 ....

von Male (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
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.
Ist das einzige Werkzeug, was man kennt, ein Knüppel,
sehen alle Probleme aus wie Robbenbabys.
novalix, debianforum.de, 2014-01-12

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> Das Zero W aber inform einer WLAN-Schnittstelle.

vermutlich dort kein wlan oder gar in einer schwer erreichbaren Kiste 
kein Empfang :)

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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?

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Programmier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Zeno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.