Hallo zusammen, ich habe folgende Sache irgendwie zu lösen. Ich habe eine Main Unit (ATmega 644), welche die Auswertung sämtlicher Signale und Zustände übernimmt. Nun habe ich auf einem Modul eine kleinere CPU (ATmega16 oder 32) welche mit dem internen RC Oszillator betrieben wird. Dieser Salve überwacht 8 analoge Spannungen, wenn eine aus dem zulässigen Bereich kommt, wollte ich mit einer Leitung der Master CPU einen Interrupt zuführen und die soll dann die Möglichkeit haben, alle Spannungen aus dem Slave abzufragen. Es kommen unter Umständen noch 2 der gleichen Slaves dazu, die machen auch wieder das gleiche... jeweils 8 analoge Spannungen kontrollieren und bei Grenzüber- bzw. -unterschreitung dies mitteilen. Gut soweit zur Theorie... mir bekannte Busse sind UART, SPI, TWI... habe mit allen bereits gearbeitet, SPI und TWI leider nur TxD -> fire and forget... :-( UART fällt aus, wegen interner Takterzeugung beim SLAVE. Bleibt TWI oder SPI... oder was ganz was anderes? Welcher dieser Beiden ist geeignet zuverlässig Daten zu übertragen so das Übertragungsfehler definitiv ausgeschlossen werden können? Die Baugruppen sind gut 40cm voneinander getrennt. Grüße AVRli...
TWI und SPI sind beide geeignet um Daten zu übertragen. Da Du den Terminus "zuverlässig" und die Beschreibung "das Übertragungsfehler definitiv ausgeschlossen werden können" benutzt, muss man Dir leider sagen das diese Kriterien nicht absolut sind sondern graduell. Anders ausgedrückt: Es gibt keine absolut zuverlässige Übertragung oder die Möglichkeit Übertragungsfehler definitiv auszuschliessen. Das sind Parameter die mit statistischen Methoden beschrieben werden. Es gibt eine Reihe von Möglichkeiten die Wahrscheinlichkeit der korrekten Übertragung zu erhöhen. Das Internet sagt mehr dazu. Um dennoch mal so einen Anhaltspunkt zu geben, kann man pragmatisch sagen das die beiden Verfahren innerhalb ihrer Grenzen "recht zuverlässig" sind. Es muss schon recht viel passieren, damit da was schiefgeht. Die wesentlichen Einflussfaktoren sind die Entfernung und die elektromagnetische Umgebung. Dazu müsstest Du Informationen liefern.
Hmm schrieb: > Die wesentlichen Einflussfaktoren sind die Entfernung und die > elektromagnetische Umgebung. Dazu müsstest Du Informationen liefern. Ja wie geschrieben, die Module sind ca. 40cm von der Main Unit entfernt. In der Umgebung ist etwas HF in der Luft. Es handelt sich um eine Steuerung von einem Fonie Sprach Relais. Am gleichen Standort sind aber noch andere Netzbetreiber mit etwas mehr Leistung aktiv. Also muss das ganze gegen HF Störungen unanfällig sein. Die einzelnen Pakete kann man ja noch mit CRC versehen. Nur darf sich die Verbindung nicht aufhängen... :-( Grüße AVRli...
Ich wuerd das UART bevorzugen und wenn die Module als Subleiterplatten montiert sind, auch gleich den Controllerclock weitergeben, sodass alle synchron laufen. Denn TWI & SPI haben keinen Buffer, beide sind toll als Master aber beschissen als Slave. Denn der Slave muss hinreichend schnell Antworten, sonst ist das Byte schon ueberschrieben.
Wenn du keinen Quarz am uC hast scheidet USART aus. Ich würde auch keinen "gemeinsamen" Clock quer über die Leiterplatte routen. SPI scheidet aus, weil der Atmel beim SPI Slave keinen Puffer eingebaut hat. d.h. Nach der letzten Takt-Flanke des Bytes hast du einen halben Takt Zeit die Daten aus dem eingehenden Puffer zu lesen. Danach wird es vom neuen reinkommenden Daten überschrieben! Beim XMega könntest du die Daten vielleicht noch per DMA o.ä. schnell wegspeichern. Bleibt TWI. Das sit eigentlich keine schlechte Wahl. Mache ich auch. Der Slave bestimmt das Tempo durch freigeben der Clock-Leitung. Benutzt du die Hardwareeinheit, musst du so ziehmlich viele Fälle abfangen. Der Lohn ist eine schnelle und sichere Übertragung. schnell: 400kBit, sicher: der Master weiss zumindest, dass die Daten angekommen sind Nachteil: der Master muss auf die Freigaben des Slaves warten und kann nicht einfach so drauf los senden (wie bei USART, SPI) Also Master auf alle Fälle im ISR implementieren. Viel Erfolg. Adib. --
Elf von Dreizehn schrieb: > Denn TWI & SPI haben keinen Buffer, beide sind toll als > Master aber beschissen als Slave. Denn der Slave muss hinreichend > schnell Antworten, sonst ist das Byte schon ueberschrieben. Das stimmt so nicht. Bei TWI hat der Slave die Möglichkeit, die Taktleitung Low zu halten, um die Übertragung zu bremsen. Ich würde TWI nehmen, da es mit zwei Leitungen auskommt und schon mehr Protokoll eingebaut hat. Vor allem wenn immer die gleichen Daten als Antwort kommen und der Master außer der Device-Addresse nicht selektieren muss, ist das recht einfach.
Hi >Wenn du keinen Quarz am uC hast scheidet USART aus. Stimmt nicht. AVRs können auch synchrone UART. MfG Spess
Das ungepufferte SPI des AVR scheidet aus, damit läßt sich nicht zuverlässig ein Slave implementieren. Du kriegst graue Haare, ehe sowas läuft. Auch läßt es sich schwer als Bus implementieren, da jeder ein separates Slave-Select braucht. Das I2C ist geeignet, allerding unterstützt das HW-I2C keine Fehlererkennung und kann sich verklemmen. Man muß also zusätzliche Timeouts aufsetzen, wenn SCL oder SDA auf Low klemmen bleiben oder der Master nicht erkennt, daß der Bus frei ist. Die Software wird also etwas haarig. Ich würde die UART empfehlen (als RS-485 verbunden), das ist am einfachsten und sichersten. Wieviel Millionen Stück willst Du denn pro Jahr verkaufen, daß der dafür notwendige Quarz Dir zu teuer ist? Du kannst auch eine 3. Leitung nehme, wo der Master z.B. einen Sekundentakt verteilt und damit die Slave sich nachjustieren. Oder der Mater sendet vor jedem Paket ein Break mit definierter Länge zum Nachjustieren. Es geht also auch ohne Quarz. Peter
AVRli schrieb: > In der Umgebung ist etwas HF in der Luft. Schon wieder so ein Gummibegriff. Am einfachsten ist, wenn du Übertragungsfehler auf der physikalischen Ebene der Übertragung tolerierst und durch entsprechende Absicherung im Datenübertragungsprotokoll (CRC) dafür sorgst, das sie ausreichend sicher erkannt werden. Durch geeignete Kodierung kann man auch erreichen, dass auf der Empfängerseite sogar Fehler teilweise korrigieren werden können (Stichwort Hammingabstand, FEC).
Spess53 schrieb: > Stimmt nicht. AVRs können auch synchrone UART. Dann aber ATmega16 oder 32 -> ATmega164 oder 324. Peter
Adib schrieb: > SPI scheidet aus, weil der Atmel beim SPI Slave keinen Puffer eingebaut > hat. d.h. Nach der letzten Takt-Flanke des Bytes hast du einen halben > Takt Zeit die Daten aus dem eingehenden Puffer zu lesen. Danach wird es > vom neuen reinkommenden Daten überschrieben! Naja einen halben SPI Takt hat man da Zeit. Wie lange das dauert hat man da durchaus selbst unter Kontrolle. 2 Möglichkeiten. 1. Man betreibt die SPI als 5 wire Spi. Clock Mosi Miso Chipselct Busy 2. Der Master fügt eine Pause von x µsec/msec zwischen den einzelnen Bytes ein um dem Slave die Zeit zu geben. Und eine CRC würde ich grundsätzlich bei einer Kommunikation verwenden. Dadurch kann man ja gerade erst erkennen ob die empfangenen Daten Korrekt sind, oder eben nicht. ==> Wiederholung der Übertragung im Fehlerfall Treten CRC Fehler dann häufiger auf, ist es an der Zeit nach der Ursache zu suchen. zb EMV,Leitungsanpassung,Dämpfung ....
Peter Dannegger schrieb: > Wieviel Millionen Stück willst Du denn pro Jahr verkaufen, daß der dafür > notwendige Quarz Dir zu teuer ist? Ja genau das ist es ja... es ist ein Einzelstück, es muss funktionieren, es darf auch was kosten, es muss nicht gespart werden... ;-) Peter Dannegger schrieb: > Ich würde die UART empfehlen (als RS-485 verbunden), das ist am > einfachsten und sichersten. Ok, dann brauche ich als "Master" CPU eine größere, die dann mit 2 UART's HW seitig ausgestattet ist. Der eine dann für die BUS Kommunikation. Die zweite brauche ich für eine PC Anbindung. Oberste Priorität bei dem Projekt ist die sichere Funktion. Danke für Eure Diskussion, ich habe mit solch einer Bus Anbindung einfach wenig Erfahrung, von daher erspare ich mir durch Eure Tipps unter Umständen ewiges gefrimel. Grüße AVRli...
AVRli schrieb: > Ok, dann brauche ich als "Master" CPU eine größere, die dann mit 2 > UART's HW seitig ausgestattet ist. Geht auch gleich groß, heißt dann 644P. Der 644 war schonmal abgekündigt, aber komischer Weise gibts den wieder. Peter
Peter Dannegger schrieb: > Geht auch gleich groß, heißt dann 644P. :-O Schau an, der hat 2 UART's ??? Ich muss mir da mal das datenblatt besorgen. Ich muss gestehen das ich hinter dem P nun nicht gerade solch einen Funktionszuwachs erwartet hätte. Grüße AVRli...
kommt halt drauf an was die µC noch so zu machen haben, ob da ggf. nicht mit Software-UART schon was gerissen werden kann. Hab die Software-RX meist auf nem normalen INT-Eingang, dann entfällt die Lauscherei auf dem Pin.
Ja nun HW wäre mir in dem Fall lieber. Nun stehe ich vor einem weiteren Problem, ich brauche nun noch 10x ADC... :-( So langsam wird es eng... Danke aber für die Überlegungen und die Diskussion, nach allen Recherchen zu RS-485 ist das für mich die beste Lösung. Grüße AVRli...
AVRli schrieb: > Ja nun HW wäre mir in dem Fall lieber. Nun stehe ich vor einem weiteren > Problem, ich brauche nun noch 10x ADC... :-( TLC1541/42/43 fchk
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.