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.
>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.
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.
tom schrieb: > Also 10 uC die ununterbrochen oder erst auf anfrage 32Byte große daten > senden Und wie schnell?
wäre es eigentlich verkehrt SPI zu nehmen? das ist doch die schnellste zur verfügung stehende Schnittstelle oder? seht ihr da hindernisse?
32byte alle 2ms, machen 16kByte/s, oder 160kBit. Wenn man die alle Synchronisieren koennte, mit einem geminsamen Trigger, denn synchron zu messen und zu senden waere etwas effizienter wie asynchron.
tom schrieb: > wäre es eigentlich verkehrt SPI zu nehmen? Ja. SPI ist so ziemlich das schlechteste, da viele MCs kein gepuffertes SPI haben. Die Gefahr eines Datenverlustes ist also sehr hoch. Außerdem kostet es einen hohen Verdrahtungsaufwand (jeder Slave benötigt sein eigenes /SS). Nimm I2C oder CAN. Peter
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.
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
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
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.
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?
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.