Forum: Mikrocontroller und Digitale Elektronik Daten hin- und herschieben zwischen A und B


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 Anfänger (Gast)


Lesenswert?

Hallo, ich habe zwei Geräte - einen Raspberry Pi und einen 
Mikrocontroller, zwsichen denen ich Daten hin- und herschaufeln möchte. 
Später sollen es mehrere Mikrocontroller sein.

Der Raspberry Pi hat an seinen 26 Pins 3 Schnittstellen
- SPI
- UART (seriell)
- I2C

I2C scheidet aus, weil der BCM2835-Baustein auf dem Raspberry Pi einen 
Bug hat und das I2C nicht richtig umsetzt (Clock-Stretching-Problem).

SPI funktioniert zwar, aber ich benötige pro Bus-Slave eine CS-Leitung. 
Wenn ich z.B. 6 Slaves adressieren möchte, gehen mir 6 IO-Pins verloren. 
Deshalb wäre die Lösung mit I2C schöner gewesen, aber ich bekomme keine 
einwandfreie Kommunikation mit I2C hin wegen dem 
Clock-Stretching-Problem (Beitrag "Raspberry PI i2c-clock-stretching bug").

Ob der UART eine Lösung ist, weis ich noch nicht so genau, aber der hat 
ja max. 115200 baud.

Könntet ihr mir ein paar Tipps geben, ob es noch andere Ansätze für eine 
Kommunikation geben könnte (CAN-Bus scheidet auch aus).

Meine Idee wäre es jetzt, auf low-level-Ebene (dort können die Pins bis 
etwa 20MHz angesteuert werden) selber eine Software-I2C-Schnittstelle zu 
programmieren, aber irgendwie gefällt mir diese Lösung auch nicht.

Ich hab auch schon gegoogelt, und es gibt z.B. I2C-Slave to 
SPI-Master-Bridgebausteine - haltet ihr das evtl. für eine Lösung, um 
den Bug im Raspberry Pi zu umgehen?

von eagle user (Gast)


Lesenswert?

Anfänger schrieb:

> SPI funktioniert zwar, aber ich benötige pro Bus-Slave eine CS-Leitung.
> Wenn ich z.B. 6 Slaves adressieren möchte, gehen mir 6 IO-Pins verloren.

mit einem Hardware-Dekoder, z.B. 74HC138, kannst du mit 4 Pins bis zu 8 
Slaves ansprechen und mit 5 Pins bis zu 16.

> Ob der UART eine Lösung ist, weis ich noch nicht so genau, aber der hat
> ja max. 115200 baud.

ob da nicht mehr geht solltest du nochmal genauer untersuchen, der Pi 
ist schliesslich kein PC. Und soo viel schneller wird normgerechtes I2C 
auch nicht, 400kHz sind ja netto keine 400,000 Bits/s. Zum Ausgleich ist 
UART einfacher zu programmieren.

von Noch einer (Gast)


Lesenswert?

Mit 3 Pins 7 Slaves würde in diesem Fall besser passen.

von Noch einer (Gast)


Lesenswert?

I2C musst du sehr zuverlässig aufbauen. Nach einer verloren gegangenen 
Flanke ist der Reset so umständlich - praktisch hilft da nur 
Versorgungsspannung ausschalten. Bei SPI ist CS gleichzeitig Reset.

UART ist nur für Punkt zu Punkt Verbindungen konzipiert. Sollen mehrere 
Geräte auf dem selben Kabel senden, musst du einige Verrenkungen machen.

von Anfänger (Gast)


Lesenswert?

eagle user schrieb:
> mit einem Hardware-Dekoder, z.B. 74HC138, kannst du mit 4 Pins bis zu 8
> Slaves ansprechen und mit 5 Pins bis zu 16.

Hmm, das ist klar mit den Hardware-Dekodern, nur muss ich ja dann auch 
z.B. 8 Leitungen für 8 Slaves auf dem Bus mit verlegen. Ich kann dann 
z.B. nicht einfach in einem Stecksystem zwei Einschübe vertauschen, es 
steht dann ganz klar fest, zu welchem Einschub der entsprechende Slave 
gehört. Man könnte dann vlt. eine Anfangsroutine ablaufen lassen, mit 
der dann alle Slaves eindeutig identifiziert werden und dann 
softwaremässig die CS-Leitungen zuordnen. Wäre eine Lösung. Aber ich 
muss dann halt 8 CS-Leitungen durch mein System schleusen :-(

von Noch einer (Gast)


Lesenswert?

Wenn du so etwas zum ersten Mal machst, dürfte die übersichtlichste 
Lösung die beste sein. Das zentrale Problem: Du weißt nicht, ob der 
Fehler in der Hardware, in deiner Software oder im Linux steckt.

Bei SPI kann dein Programm beliebig langsam direkt die Port-Pins 
ansprechen. Mit einem einfachen Multimeter kannst du kontrollieren, ob 
alle Signale korrekt ankommen. Schon alleine weil die Fehlersuche 
einfacher ist, würde ich für das erste Projekt mit einzelnen CS 
Leitungen machen.

von Frank (Gast)


Lesenswert?

Wieso kein FTDI?
Gibt es auch fertige Kabel mit RS485 Treiber davon.
Evtl geht da etwas mehr was Datenrate und Reichweite angeht.

von Noch einer (Gast)


Lesenswert?

Etwas überraschende Frage.

Wieso Umweg über USB? Der Pi hat ja Pins die man direkt mit einen 3,3V 
MC verbinden kann. Zusätzliche Chips kosten Geld. FTDI gibt es nicht für 
Lochraster. Der Raspi-Prozessor ist zu langsam für zusätzlichen 
Overhead. Und USB-Kabel brauchen mehr Platz als eine Backplane.

Welche Argumente sprechen dafür?

von Anfänger (Gast)


Lesenswert?

Noch einer schrieb:
> Welche Argumente sprechen dafür?

Was auch noch dagegen spricht, ist die "Zuordnungsbarkeit" der 
USB-Ports. Pro USB-Schnittstelle bekomme ich im /dev-Verzeichnis eine 
neue Datei /dev/ttyUSB0... an dem Raspi hängen auch schon USB-Geräte wie 
Maus, Tastatur etc. Man müsste dann auch wieder nach jedem Start alle 
USB-Ports softwaremässig durchgehen und prüfen, an welchem USB-Port das 
entsprechende Gerät hängt. Wahrscheinlich ginge das auch, aber irgendwie 
umständlich.

von Amateur (Gast)


Lesenswert?

Vielleicht könntest Du ja mal durchscheinen lassen um welche 
Datenvolumina es geht und um welche Entfernungen.

Wir können aber auch raten...

Ein Wort zur Umgebung könnte auch nicht schaden. Es besteht immerhin ein 
winziger Unterschied zwischen einer stark gestörten Industrieanwendung 
und einem spielerischem Hobbyaufbau.

Auch wie sicher die Übertragung sein soll, ist manch einen Gedanken 
wert.

Muss aber nicht sein.

von Werner P. (Gast)


Lesenswert?

So ein ähnliches Problem hatte ich auch mal.

Meine Lösung:

Bussystem mit 8 SPI Devices welche über eine 2 Draht Leitung selektiert 
werden (Data und Clock). Auf jeder Platine habe ich einen kleinen Attiny 
verbaut welcher für die Decodierung zuständig ist.

Beispiel:

Master sendet 0010 als Bitfolge (Data und Clock). Attiny welcher diese 
Adresse hat setzt CS für das SPI Device auf Low. Alle anderen Attiny 
setzen CS auf High.

Sendet der Master 0000 gehen alle CS auf High.

Funktioniert bisher ohne Probleme.

Nachteil: für jedes CS Device ist ein Attiny notwendig.

von Noch einer (Gast)


Lesenswert?

> /dev/ttyUSB0...

Du bekommst zusätzlich unter /dev/serial/by-id/ einen Eintrag mit den 
Namen, den das Device liefert.

von Douglas Adams (Gast)


Lesenswert?


von eagle user (Gast)


Lesenswert?

Noch einer schrieb:

> UART ist nur für Punkt zu Punkt Verbindungen konzipiert. Sollen mehrere
> Geräte auf dem selben Kabel senden, musst du einige Verrenkungen machen.

UART an sich ist ja kein Problem, es kommt auf die Treiber an. Mit RS232 
geht's ganz schlecht. Mit RS485 kostet es zusätzlich ein Driver Enable 
Signal, das nicht ganz trivial ist. Mit einer Stromschleife geht's 
einfach, kostet aber viele kleine Bauteile. Wenn man Potentialtrennung 
braucht, lohnt sich der Aufwand evt. trotzdem.

Für diese Anwendung (mit genau einem Master) würde ich CAN-Treiber 
vorschlagen. Die werden genau wie MAX232 ans UART angeschlossen, aber 
man darf die Ausgänge der Treiber alle parallel schalten. Da vom Prinzip 
her immer nur ein Gerät zur Zeit sendet, ist UART+CAN 
selbstfunktionierend. Man kann auch je einen Treiberbaustein für Sendung 
und Empfang spendieren und so ggf. den Durchsatz erhöhen. Nachteilig ist 
der hohe Stromverbrauch, besonders, wenn man tatsächlich 2x120 Ohm 
spendiert. Bei kurzen Kabeln geht's aber auch hochohmiger.

von Frank (Gast)


Lesenswert?

Noch einer schrieb:
> Etwas überraschende Frage.
> Wieso Umweg über USB? Der Pi hat ja Pins die man direkt mit einen 3,3V
> MC verbinden kann.
Ja, scheinbar kann der UART ja aber nur 115,2kBaud.
Die Überlegung war, ob man trotz des Overhead von USB eine höhere 
Datenrate hin bekommt.

>Zusätzliche Chips kosten Geld.
Ist das ein Massenprodukt wo es auf das bisschen ankommt? Was kostet 
deine Zeit? Mit der Kabelvariante wo ich geschrieben habe steckst du es 
an und legst los. Keine Platine designen/bestellen/löten/in betrieb 
nehmen/Fehler suchen...

>FTDI gibt es nicht für Lochraster.
Wo steht die Anforderung?

>Der Raspi-Prozessor ist zu langsam für zusätzlichen
> Overhead.
Das weis ich nicht. Ich hätte es mal ausprobiert.

>Und USB-Kabel brauchen mehr Platz als eine Backplane.
Wo steht die Anforderung?

> Welche Argumente sprechen dafür?
Schnell ausprobiert, noch erschwingliche kosten, mit RS485 ein 
vernünftiger Treiber dahinter damit es auch ein paar Meter mehr sein 
dürfen.

von Jobst M. (jobstens-de)


Lesenswert?

Also:
- Schnittstelle am RPi vorhanden
- Schneller als 115kBd
- Mehrere Teilnehmer
- Eindeutige Zuordnung der Teilnehmer

-> Ethernet


Gruß

Jobst

von Anfänger (Gast)


Lesenswert?

Vielen Dank für Eure vielen Tipps - mal eine Frage zu dem CAN-Bus.

Folgendes Szenario - ein Slave nimmt Messwerte auf - 1000 16bit-Werte 
pro Sekunde. Diese Werte will ich an den RPi senden, man könnte das 
Datenholen z.B. 10mal pro Sekunde machen.

Meine Erinnerung an den CAN-Bus ist, dass ich nur ein Kommando senden 
kann und vorher den Slave adressieren muss.

I2C wäre für mich ideal, dort kann ich einfach machen:

<Slave_Adress>-<Command>-<Data>-<Data>...<Data>

Aber wegen dem Clock-Stretching klappt das nicht. Beim CAN-Bus hab ich 
ja

<Slave_Adress>-<Command>-<Data> - ich kann immer nur einen Wert abholen 
und muss dann immer wieder die Adresse mitsenden, umd das nächste 
Datenpaket zu bekommen.

Mit SPI hab ich halt meine Probleme wegen der vielen CS-Leitungen. Das 
Problem ist noch, wenn ich SPI auf dem RPi verwende und selbst mit einem 
Portexpander arbeite, so sind doch die beiden CS-Pins blockiert.

Werner P. schrieb:
> Sendet der Master 0000 gehen alle CS auf High.
>
> Funktioniert bisher ohne Probleme.
>
> Nachteil: für jedes CS Device ist ein Attiny notwendig.

Das gefällt mir ganz gut, da muss ich mal drüber nachdenken.

Kennt ihr vlt. eine bessere Alternative als einen RPi, der auch Linux 
drauf hat und kein Clock-Stretching-Problem?

von S. R. (svenska)


Lesenswert?

Du hast immernoch nicht beschrieben, was du eigentlich tun willst (oder 
ich habe es beim Überfliegen überlesen). Ethernet ist gut. USB ist gut. 
Wenn nicht, musst du mehr Informationen bringen.

Wenn ein I2C-Slave kein Clock-Stretching benutzt, kann es dir 
schnurzpiepegal sein, ob der RPi das unterstützt oder nicht. Es gibt 
genug Bausteine, die an einem RPi ganz wunderbar funktionieren. SPI 
braucht pro Slave einen CS-Pin. Aber den kannst du auch nachrüsten, z.B. 
mit einem PCF8574/A (oder was modernerem) am I2C des RPi.

Die klassische serielle Schnittstelle am PC schafft maximal 115,2 
kBit/s, moderne USB-Seriell-Wandler schaffen deutlich mehr; je nach 
Chipsatz bis zu 2 MBit/s.

Aber solange du nicht sagst, was du eigentlich möchtest, bleibt 
eigentlich nur Ethernet.

von häh (Gast)


Lesenswert?

Brauchste jetzt einen Standard oder isses egal ?
Wenn egal nimm einfach zwei Pins und einer ist mit #0 verbunden und #999 
ist mit #0 verbunden.
Der Rest ist für Dich.
Onewire gibt's dann noch mit zwei Leitungen oder Du funkst dazwischen 
...
Achja RSXYZ geht auch mit extra Chips oder per Software ...

von Anfänger (Gast)


Lesenswert?

S. R. schrieb:
> Du hast immernoch nicht beschrieben, was du eigentlich tun willst (oder
> ich habe es beim Überfliegen überlesen)

Hier steht es:

Anfänger schrieb:
> Folgendes Szenario - ein Slave nimmt Messwerte auf - 1000 16bit-Werte
> pro Sekunde. Diese Werte will ich an den RPi senden, man könnte das
> Datenholen z.B. 10mal pro Sekunde machen.

von S. R. (svenska)


Lesenswert?

Ne, das steht da nicht.
Da steht nicht:
- wieviele Slaves es gibt,
- wie weit voneinander die entfernt sind,
- wie kompliziert sie sein duerfen,
- wie wichtig die Daten sind,
- usw.

Also nimm Ethernet. Fertig.

von Anfänger (Gast)


Lesenswert?

S. R. schrieb:
> - wieviele Slaves es gibt,

ca. 10 Slaves

> - wie weit voneinander die entfernt sind,

max. 30cm

> - wie kompliziert sie sein duerfen,

so einfach wie möglich

> - wie wichtig die Daten sind,

Die Daten sind wichtig.


> - usw.

S. R. schrieb:
> Also nimm Ethernet. Fertig.

Das ist eine gute Idee, verwendet ihr bei den Mikrocontrollern dann z.B. 
Bauteil:

http://www.reichelt.de/?ARTICLE=109722&PROVID=2788&wt_mc=amc141526782519998&&gclid=CObglaP2zsgCFYTnGwodi3cEQQ 
?

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

Anfänger schrieb:

> I2C wäre für mich ideal, dort kann ich einfach machen:
>
> <Slave_Adress>-<Command>-<Data>-<Data>...<Data>
>
> Aber wegen dem Clock-Stretching klappt das nicht.

Wieso soll das nicht klappen?
Weisst du überhaupt, was CLock-Stretching ist oder ist das wieder so 
eine 'Ich hab mal gelesen, dass es da ein Problem gibt' Sache?


> Beim CAN-Bus hab ich
> ja
>
> <Slave_Adress>-<Command>-<Data>

Beim CAN Bus hast du in erster Linie erst mal überhaupt keine 
adressierbaren Slaves. DIe Idee hinter dem CAN Bus ist eine komplett 
andere. Weg vom klassischen Master-Slave Prinzip und hin zu: jeder 
plärrt auf dem Bus raus, welche Daten er anzubieten hat und wen auch 
immer diese Daten interessieren, der kriegt sie. Auf einem CAN Bus 
verkündet zb der Aussentemperatur Sensor alle paar Millisekunden, dass 
es jetzt gerade draussen +8°C hat. Ob sich die Heizungssteuerung diesen 
Wert holt oder die Rollosteuerung ist dem Temperatursensor egal, er 
verkündet was er gemessen hat.
Das ist die Grundidee. Nicht die Adresse des Senders oder Empfängers ist 
wichtig, sondern welche 'Datenfracht' ein CAN-Paket transportiert.
Das man damit wieder eine Master-Slave Kommunikation aufbauen kann ist 
ein Nebenprodukt. Die eigentliche Idee bei CAN ist aber eine ganz 
andere.


> Kennt ihr vlt. eine bessere Alternative als einen RPi, der auch Linux
> drauf hat und kein Clock-Stretching-Problem?

Falsche Frage.
Hast du denn überhaupt einen I2C Teilnehmer, der Clock Stretching 
betreibt? Die Mehrzahl wird dieses Feature nämlich gar nicht benutzen.

: Bearbeitet durch Moderator
von holger (Gast)


Lesenswert?

>ich habe zwei Geräte - einen Raspberry Pi und einen
>Mikrocontroller, zwsichen denen ich Daten hin- und herschaufeln möchte.
>Später sollen es mehrere Mikrocontroller sein.

>Hast du denn überhaupt einen I2C Teilnehmer, der Clock Stretching
>betreibt.

Er hat mindestens einen;)

von Anfänger (Gast)


Lesenswert?

Karl H. schrieb:
> Wieso soll das nicht klappen?
> Weisst du überhaupt, was CLock-Stretching ist oder ist das wieder so
> eine 'Ich hab mal gelesen, dass es da ein Problem gibt' Sache?

Ich habe einen Logikanalyzer an den I2C-Bus gehängt und dann gesehen, 
dass das Clock-Signal vom Slave entsprechend gehalten wird, wenn er noch 
nicht fertig ist und dann kommt der RPi durcheinander.

von Jobst M. (jobstens-de)


Lesenswert?

Anfänger schrieb:
> Ich habe einen Logikanalyzer an den I2C-Bus gehängt und dann gesehen,
> dass das Clock-Signal vom Slave entsprechend gehalten wird, wenn er noch
> nicht fertig ist und dann kommt der RPi durcheinander.

Und!? Magst Du uns vielleicht auch noch den Chip mitteilen!?


Anfänger schrieb:
> ich habe zwei Geräte - einen Raspberry Pi und einen
> Mikrocontroller

... und welchen?
Ist das der Chip, welcher das SCK hält? Wäre eine Alternative keine 
Möglichkeit?

Und: Woher kommen die Daten? Welche Chips sind noch involviert? ...

Es ist echt nervig, alle Informationen häppchenweise auf Nachfrage zu 
erhalten und solange um Dein Problem herum zu rätseln.



Anfänger schrieb:
>> Also nimm Ethernet. Fertig.
>
> Das ist eine gute Idee,

Stand 5 Beiträge weiter oben auch schon ...

> verwendet ihr bei den Mikrocontrollern dann z.B.
> Bauteil:
>
> http://www.reichelt.de/?ARTICLE=109722 ?

Ja, z.B.



Alternativ: SPI-Daisy-Chain. Sofern von den Bausteinen unterstützt. 
(welche auch immer das dann sein mögen)


Und: Soll das ganze auf eine Platine oder wird das eine 
Freiluftverdrahtung?



Gruß

Jobst

von S. R. (svenska)


Lesenswert?

Ich gebe auf. Er will nicht verraten, was er tun will, also ist es mir 
nicht wichtig, wie er es tun will. Salamitaktik.

von Anfänger (Gast)


Lesenswert?

Jobst M. schrieb:
> Ist das der Chip, welcher das SCK hält?

Ja genau, das ist ein ARM STM32

von Anfänger (Gast)


Lesenswert?

Jobst M. schrieb:
> Und: Soll das ganze auf eine Platine oder wird das eine
> Freiluftverdrahtung?

Jetzt eine "Freiluftverdrahtung", später soll das dann, wenn es 
funktioniert, auch festgelötet werden, damit sich die Kabel dann nicht 
mehr ablösen.

von Anfänger (Gast)


Lesenswert?

Kann man vielleicht das Clock-Stretching abschalten, wenn man es nicht 
haben will?

von Jobst M. (jobstens-de)


Lesenswert?

Anfänger schrieb:
> Ja genau, das ist ein ARM STM32

Warum muss es diese Rakete sein?
Kann es evtl. am Programm liegen, dass der den SCK festklemmt?

Jobst M. schrieb:
> Wäre eine Alternative keine Möglichkeit?
>
> Und: Woher kommen die Daten? Welche Chips sind noch involviert? ...

???????


> Es ist echt nervig, alle Informationen häppchenweise auf Nachfrage zu
> erhalten und solange um Dein Problem herum zu rätseln.

...!


Anfänger schrieb:
> Jetzt eine "Freiluftverdrahtung", später soll das dann, wenn es
> funktioniert, auch festgelötet werden, damit sich die Kabel dann nicht
> mehr ablösen.

Also Freiluftverdrahtung ...


> Gruß
>
> Jobst

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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