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.
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).
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
