multi slave realisierung

Gast #1935314
Lesenswert?

Hi Leute,
ich habe 10 uC-boards (Slaves) die Daten Senden sollen und ein uC-Board 
(Master) welches die daten sammeln und so schnell wie möglich uber rs232 
an den PC schicken soll.
Jetzt würde ich gerne wissen was eurer Meinung nach die sinnvollere 
Kommunikationsmethode zwischen dem Master und den Slaves wäre. SPI, CAN, 
USART, I2C, usw.
Gast #1935322
Lesenswert?

>Jetzt würde ich gerne wissen was eurer Meinung nach die sinnvollere
>Kommunikationsmethode zwischen dem Master und den Slaves wäre.

Jetzt würde ich von dir gerne wissen was du machen möchtest.
Sonst ist keine sinnvolle Antwort möglich.
Gast #1935342
Lesenswert?

Also 10 uC die ununterbrochen oder erst auf anfrage 32Byte große daten 
senden und 1 uC der diese Daten erfasst und an den PC weitergibt. habe 
noch nicht fesgelegt welchen uC ich verwende weil ich erst schauen muss 
wie ich das am besten realisiere.
Gast #1935724
Lesenswert?

Peter Dannegger schrieb:
> SPI ist so ziemlich das schlechteste, da viele MCs kein gepuffertes SPI
> haben. Die Gefahr eines Datenverlustes ist also sehr hoch.

Aber die Controller sind doch slave d.h. sie schicken nur auf 
anferderung Daten. ok man müsste denen einen Buffer verpassen damit nix 
verloren geht. I2C ist doch sehr langsam oder was passiert den im 
worstcase (alle uC haben zur fast gleichen Zeit daten die sie loswerden 
wollen).

A...aha Soooo. schrieb:
> Ne. Ich wuerd RS422 einsetzen. Im synchronen Betrieb. Dh nach einem
> gemeinsamen Trigger wandeln alle, und jeder weiss wann er senden darf,
> mit einem Timer vom Trigger her verzoegert. Und vor dem PC einen
> RS422-RS232 Converter.

aber ich will doch ersteinmal nur wissen welches die bessere möglichkeit 
zur kommunikation zwischen uC-Master und den uC-Slaves ist. Die 
verbindung zum PC dachte ich realisiere ich mit nem FTDI
#1935868
Lesenswert?

tom schrieb:
> Aber die Controller sind doch slave d.h. sie schicken nur auf
> anferderung Daten.

Und genau das ist der Pferdefuß.
Beim AVR hat der Slave genau einen halben SCK-Takt Zeit, das nächste 
Byte zu senden. Tut er das nicht, sendet der Master trotzdem seinen Takt 
und liest Mumpitz ein.
Der Master weiß das nicht und kann das auch nicht feststellen. Es gibt 
ja kein Handshake.

Angenommen der Slave läuft mit 8MHz und der Master sendet SCK mit 
500kHz, dann muß der Slave innerhalb 8 CPU-Zyklen ab dem SPI-Interrupt 
das Byte schreiben. Der Interrupteintritt alleine dauert aber schon 9 
Zyklen.

Ein gangbarer Ausweg wäre, ein SPI-Slave empfängt nur und sendet nie 
Daten. D.h. der Slave muß sich zum SPI-Master umschalten und dann gibt 
er den SCK aus.

Quasi wie eine Halb-Duplex RS-485.
Dann kann man aber auch gleich RS-485 nehmen.


Peter
#1935901
Lesenswert?

Was spricht den gegen I2C. Das ist doch wie dafür gemacht. 2 Leitungen 
und du hast alle Teilnehmer dran. Wenn die Abstände zwischen den ICs 
nicht zu groß sind, ist das (meiner Meinung nach) die beste Lösung.

Der Master muss halt die entsprechenden Slaves auffordern ihr Daten zu 
senden.
Gast #1937189
Lesenswert?

Wie müsste denn die RS485 schnittstelle zwischen den uCs aussehen? Ich 
brauch dafür doch zusätzliche rs485 treiber oder? Könntest du mir eine 
kleine skizze machen wie die beschaltung ausssehen müsste?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren