Hallo! Ich bin zur Zeit auf der suche nach einem geeigneten Bus, mit dem ich zwischen 2 Microcontroller (AVR, oder AT91SAM) bidirektional kommunizieren kann. Dabei ist es aber wichtig, dass sich der Bus möglichst einfach (mit möglichst wenig zusäzlichen Bauteilen) galvanisch trennen lässt. Die beiden Controller sitzen dabei auf der gleichen Leiterplatte, der abstand sollte also die 20cm im Normalfall nicht übersteigen. Welche möglichkeiten fallen euch da so ein? danke euch schom mal! mfg AiM
Gast
#951411
UART? Dazu dann dann entweder Optokoppler oder digitale Isolations ICs (ADUMXXXX von Analog oder ISOxxxx von TI). Ein einfacher DC7DC Wandler erzeugt dann die galvanisch getrennte Spannungsversorgung für die Sekundärseite.
Hallo! Danke für die Antworten. Das Problem ist allerdings, dass ich am verwendeten AT91 die beiden vorhandenen Hardware UARTs bereits belegt habe, wodurch diese Lösung vermutlich ausscheidet? Oder übersehe ich da was?? mdf AiM
Soft-UART
Gast
#951442
Ja, du übersiehst etwas: Den Software-UART! MfG Bauteiltöter
Gast
#951446
Es gibt auch den SPI Bus.
Gast
#951451
Ja dann würde ich auch den SPI bevorzugen.
Du kannst TOSLINK benutzen (halb duplex). Ist billig und kann hohe Datenraten. Als Verbindung nimmst Du bis zu 10m Kunstofflichtleiter. Eine bessere galvanische Trennung erreichst Du nie ;-)
Kann das dann so funtioniern, den SPI zu trennen??
Angehängte Dateien:
-
galv_Trennung_spi.png
(4,9 KB)
Mit LEDs ohne Widerständen grillst du nur die Koppler und Controller. Beim CS vom Slave macht sich GND besser. Aber sonst passt es, wenngleich traditioneller gestimmte Leute wohl aus alter TTL-Gewohnheit nicht gegen VCC mit Pulldown sondern gegen GND mit Pullup schalten würden (die LEDs auch). Der Haken liegt im SPI der AVRs, die sich eher wenig für Slave-Betrieb eignen.
> Der Haken liegt im SPI der AVRs, die sich eher wenig für Slave-Betrieb > eignen. In wie fern kann das ein Problem sein?? Bzw. wie kann sich dieser "Haken" äußern??
@ Michael A. (aim) >In wie fern kann das ein Problem sein?? Bzw. wie kann sich dieser >"Haken" äußern?? Es wird langsamer. Du musst nach dem Auswählen des Slave per CS ne ganze Weile warten, um sicher zu gehen, dass der AVR per Interrupt die Daten ins SPI register geschrieben hat. Grössenordungsmässig ein paar Mikrosekunden. MFg Falk
Es ist bei AVRs und vielen anderen ungepufferten SPI-Implementierungen ein bischen schwierig, genau den Zeitpunkt zu treffen zu dem man auf das Transferregister zugreifen darf. Mittendrin im Transfer geht ja nicht. Und danach herrscht etwas Zeitdruck, weil man das getan haben muss bevor der Master mit dem nächsten Byte loslegt. Muss man also entweder das Zeitverhalten sehr sauber konstruieren, ggf. mit Wartezeiten seitens des Masters, oder der Slave quittiert jedes Byte mit einem Interrupt (zusätzliche Leitung).
Man kann auch den Master nach dem Absetzen des Bytes die Clock weiterlaufen lassen, bis er ein Byte jenseits von $FF (oder meinetwegen $00) zu lesen bekommt. Dann weiß der Master, daß der Slave die Daten abgeholt hat.
>Optokoppler Diese Beispielschaltung (von Michael A.) funktioniert nur bei schneckenlangsamen SPI-Bussen, weil die Standard-OK so langsam sind. 10us tr und tf sind da keine Seltenheit. Das ergibt eine Grenze bei gerade mal 50kHz. SPI kann da mehr. Aber die Rettung ist nahe und bereits angesprochen: >ADUMXXXX von Analog Devices oder ISOxxxx von TI oder ISOLoop ILxxx von NVE ADUM und ISOLoops gibts auch pinkompatibel... Und wenns unbedingt optisch sein soll: Hier ist der gute alte 6N137 angesagt.