Theoretisch sollte die Antwort klar sein, aber hat zu folgendem jemand praktische Erfahrung? zwei ATMega sollen über ein einfaches paralleles 3-Bit-Wort kommunizieren. Aber: Der erste läuft auf 5V, = sein High-Level der zweite läuft auf 3.3V = sein High-Level. Da 3.3 ja beim 5V-betriebenen bereits als High gezählt werden, sollte das ja kein Problem geben - andersherum ist es aber wie? Ungut? Egal? Wenn ich an den 3.3V-Mega ein 5V signal an den High-Impedance Input lege - nimmt er das einfach als logisches High und das wars? Oder gibts probleme? In diesem Fall wären ja Spannungsteiler die einfachste Lösung. Also: Kann ich die beiden so zusammenschalten oder nicht?
Alex v. L. schrieb: > Wenn ich an den 3.3V-Mega ein 5V signal an den High-Impedance Input > lege - nimmt er das einfach als logisches High und das wars? > Oder gibts probleme? Du verletzt die Maximalwerte aus dem Datenblatt. Und dann beginnen die Schutzdioden zu leiten und du speist Strom aus dem 5V-Portpin in die 3,3V versorgung ein. Mit ein wenig "Glück" bekommst du die dann auf 4,5V hochgezogen... Abhilfe: mach einen Serienwiderstand oder einen Spannungsteiler zwischen den 5V Ausgang und den 3V Eingang. Mehr dazu im artikel Pegelwandler
Danke!
Habe den Artikel gelesen, so wie es mir außerdem scheint wäre es einfacher wenn ich die Pegel an einer anderen Schnittstelle zum µC wandle - aber: Diese Schnittstelle wäre dann die USART zu einem Bluetooth-Modul. Der µC läuft allerdings auf einem langsamen externen 32.768kHz Crystal. Sind Spannungsteiler da noch gut anwendbar? Oder sollte ich z.B. den MAX3378E nehmen?
>... so wie es mir außerdem scheint wäre es einfacher wenn ich die Pegel an >einer anderen Schnittstelle zum µC wandle - aber: Wieso wäre das einfacher? (Womit ich nicht sagen will, das es nicht einfacher wäre, nur das wir das nicht nachvollziehen können). Vielleicht zeigst Du mal einen Blockschaltplan mit den Versorgungsspannungen der jeweiligen Subsysteme. Ganz allgemein kann man, so denke ich, folgendes sagen: 1. Der Spannungsunterschied ist im wesentlichen unbedeutend. 2. Ob Bi- oder Uni-direktional macht einen Unterschied. 3. Wie die Flankensteilheit sein muss, macht einen Unterschied. 4. Wie die Geschwindigkeit sein muss, macht einen Unterschied. Das Beste wäre also, die Schnittstelle zur Pegelumsetzung zu wählen, die mit der geringsten Flankensteilheit, die geringste Geschwindigkeit erfordert. Desto billigere Transistoren/ICs und einfachere Schaltungen kannst Du verwenden. Spannungsteiler gehen natürlich nur unidirektional. (Das ist Dir wahrscheinlich klar, aber man kann ja nie wissen).
>Ach quark ist ja bidirektional also nichts mit Spannungsteilern - >MAX3378E dann mittel der Wahl? Oh. Da habe ich zu langsam geschrieben. Da gibt es noch mehr Möglichkeiten. Hängt, wie beschrieben von weiteren Parametern ab. Z.B. das hier: http://m.eet.com/media/1144208/193193f1.pdf Lies mal zur Einführung: http://www.mikrocontroller.net/articles/Pegelwandler
Alex v. L. schrieb: > Diese Schnittstelle wäre dann die USART zu einem Bluetooth-Modul. Der µC > läuft allerdings auf einem langsamen externen 32.768kHz Crystal. Mit welcher Takt ein uC läuft, das hat doch nichts mit der Schnittstelle zu tun, an der der Pegel angepasst werden soll. Also reicht es aus, wenn du nur die Schnittstelle im Auge behältst. Und wenn dort Datenraten mit 100kBit/s auftreten, dann reicht ein Pegelwandler, der nur 20us Flankensteilheit hinbekommt, nicht aus. Also wäre ein Skizze mit den beteiligten Bauteilen (und deren Typ) sowei der nötigen Datenrate recht hilfreich...
Lothar Miller schrieb: >Also wäre ein Skizze mit den beteiligten Bauteilen (und deren Typ) sowei >der nötigen Datenrate recht hilfreich... ConvertsQuestionsToAnswers schrieb: >Vielleicht zeigst Du mal einen Blockschaltplan mit den >Versorgungsspannungen der jeweiligen Subsysteme. Nun bist Du zweimal dazu aufgefordert worden. Da muss also was dran sein. :-)
Beliebt ist die Methode die hier beschrieben wird: http://www.nxp.com/documents/application_note/AN10441.pdf So beliebt, dass es fertige Module für 1,30-1,80 für das Brotbrett gibt, weil es beim Basteln öfter vorkommt: http://www.ebay.de/itm/New-5V-3V-IIC-UART-SPI-Four-Channel-Level-Converter-Adapter-Module-For-Arduino-/390610600469
Lothar Miller schrieb: > Mit welcher Takt ein uC läuft, das hat doch nichts mit der Schnittstelle > zu tun, an der der Pegel angepasst werden soll. irgendwie hatte ich den Zusammenhang so erstellt, dass ich ja an das Bluetoothmodul über USART nur mit der maximalen Taktrate des µC (hier 32.768kHz) übermitteln kann, was auch eine Aussage über meine benötigte Flankensteilheit macht? Falsch gedacht? ConvertsQuestionsToAnswers schrieb: > Lothar Miller schrieb: >>Also wäre ein Skizze mit den beteiligten Bauteilen (und deren Typ) sowei >>der nötigen Datenrate recht hilfreich... > > ConvertsQuestionsToAnswers schrieb: >>Vielleicht zeigst Du mal einen Blockschaltplan mit den >>Versorgungsspannungen der jeweiligen Subsysteme. > > Nun bist Du zweimal dazu aufgefordert worden. Da muss also was dran > sein. :-) Gerne! Nur ist der noch nicht fertig, ich bin gerade dran (deshalb ja auch die Frage nach dem Pegelwandler ;-)) - Wenn ich soweit durch bin (vll in 30-60 min.) stell ich ihn gerne hoch. Soweit nur erstmal: ConvertsQuestionsToAnswers schrieb: > Wieso wäre das einfacher? Weil der µC (ATMega644P) an vier weiteren ATMega164A hängt (mit drei-bit-wort-selfmade-Protokoll), an einem 16Bit ADC über SPI und dem Amber2300 Bluetoothmodul über USART. Nur das Bluetoothmodul braucht die 3.3V, alles andere läuft auf 5. Einfacher daher nur aufgrund der anzahl Verbindungen. Ich bin in beidem - U(S)ART und SPI noch völlig unerfahren auf dem µC, habe aber ein Beispielprojekt für die µC-Amber2300 Schnittstelle (auch C-Code) an dem ich mich langhangeln kann. bei dem SPI sieht es anders aus, daher auch der Beitrag Beitrag "Re: LTC2486 und AtMega" mit aber wohl ungünstigem Titel (bisher nicht allzu viel Feedback ;-) ) Soweit, ich mach mich an den Schaltplan.
> läuft allerdings auf einem langsamen externen 32.768kHz Crystal >> Und wenn dort Datenraten mit 100kBit/s auftreten Die Datenrate kann ja nicht höher als 32.768kHz sein bzw. eigentlich nur maximal die Hälfte (wg. Nyquist). Also 16.384kHz ...
>Gerne! Nur ist der noch nicht fertig, ich bin gerade dran (deshalb ja >auch die Frage nach dem Pegelwandler So ein Blockschaltplan kann man auch ruhig mal (und hier im Besonderen) vorher in verschiedenen Versionen machen. Da spricht nichts dagegen. Sowas verändert sich. Evolutionäres Design, sozusagen. Dabei fällt mir aber noch folgendes ein: Im allgemeinen hat ein Bluetooth Modul zwar eine Bidirektionale Schnittstelle aber keine bidirektionalen Einzelverbindungen (sprich Drähte). Dafür spricht, das Du von UART redest. Dann brauchst Du keinen Bidirektionalen Pegelwandler.
ConvertsQuestionsToAnswers schrieb: > Dafür spricht, das Du von UART redest. Dann brauchst Du keinen > Bidirektionalen Pegelwandler. Das klingt logisch, hätte ich auch selber drauf kommen können, RxD und TxD sind ja gerichtet!! Was ist mit den CTS/RTS flags? Ich habe den Schaltplan jetzt mal angehängt - gerade noch mit dem MAX3378E als Pegelwandler. Kurze Erklärung: Der Mega644 steuert vier Sensorboards, die auch von dieser PCB hier versorgt werden. Zurück kommt eine Analoglane pro Board. Alle vier Analogsignale werden vom LTC2468 aufgefasst und sollen vom Mega644 über SPI abgefragt werden, dann über USART an das BTModul, das die Daten an einen PC schickt. Fragen sind bei mir gerade folgende offen (begründet aus fehlender Protokollerfahrung meinerseits mit SPI und UART, die ich jetzt zu sammeln gedenke): - Ist die SPI Schnittstelle richtig angeschlossen, wenn der LTC2468 als Slave arbeitet? - unabhängig von der Pegelwandlung: Sind die RTS/CTS Flags bestimmten Pins der USART0 Schnittstelle des ATMega644 zugeordnet oder kann man die andocken wo man will und das Handling ist dann eigener Brei? - Anschließend an den letzten Kommentar von "ConvertQuestionsToAnswers": Ließe sich das ganze dann einfach auch durch vier Spannungsteiler lösen?
> Ich habe den Schaltplan jetzt mal angehängt
Hoppelt da jetzt gerade ein Kaninchen über die kalten Äcker, mit 'nem
Schaltplan am Püschel? :-)
Die Fragen nach CTS/RTS beantworten die Datenblätter des Prozessors und des Bluetooth-Moduls. Mich beschleicht da gerade das ungute Gefühl, das wir an Deiner Stelle die Schaltung entwickeln.
ConvertsQuestionsToAnswers schrieb: > Mich beschleicht da gerade das ungute Gefühl, das > wir an Deiner Stelle die Schaltung entwickeln. Bitte nicht! Tatsache ist aber: Erst mit funktionierendem "Evalboard" kann ich mir die Software/Protokolle sinnvoll antun. Ich versuche grade erstmal den Wald vor lauter Bäumen nicht aus den Augen zu verlieren! Fehlt denn so viel an der eigentlich schon fertigen Schaltung?
Du solltest jedenfalls in der Lage sein, die Frage nach RTS/CTS nach Lektüre der Datenblätter selbst zu beantworten.
ConvertsQuestionsToAnswers schrieb: > Du solltest jedenfalls in der Lage sein, die Frage nach RTS/CTS nach > Lektüre der Datenblätter selbst zu beantworten. Ja, die Richtung habe ich mir beantwortet - du hast recht. Die nach den Pins/ dem internen Handling im µC nicht (weil keine Erfahrung und im DB im USART Kapitel erstmal noch nichts finden können zu cts und rts)
>Ja, die Richtung habe ich mir beantwortet - du hast recht. Es ging um diese Fragen: >- unabhängig von der Pegelwandlung: Sind die RTS/CTS Flags bestimmten >Pins der USART0 Schnittstelle des ATMega644 zugeordnet oder kann man die >andocken wo man will und das Handling ist dann eigener Brei? Wenn man nun garkeine Ahnung hat, was ja legitim ist, dann liest man erstmal ein paar Grundlagenartikel im Netz. So. Und dann im Datenblatt. Und wenn man > ... im DB im USART Kapitel erstmal noch nichts finden ... dann liest man es nochmal bis man abschliessend nichts findet. So. Aber um das ein wenig abzukürzen: Der AVR-U(S)ART unterstützt keine Hardware-Handshaking. Sprich, er hat keine RTS/CTS-Leitung. Einerseits kann man das selbst mit zwei Portpins nachbilden. Andererseits lässt sich das (soweit ich weiss) in den Bluetooth-Modulen manchmal konfigurieren.
ConvertsQuestionsToAnswers schrieb: > Wenn man nun garkeine Ahnung hat, was ja legitim ist, dann liest man > erstmal ein paar Grundlagenartikel im Netz. > So. Und dann im Datenblatt. Ich denke du hast recht, teilweise auch mit deinem Ärger. Das Einlesen ist schon länger eingeplant und wird intensivst noch stattfinden (müssen). Auch wenn es an der Stelle vielleicht nicht direkt ersichtlich ist: Ich möchte nur gerne die Hardware fertig haben, damit ich hands-on lernen kann. Und da die Protokolle für mich bisher eine "reine code sache" waren und damit alles lediglich an ein paar wenigen verbindungen hängt, ob ich das eval-board soweit fertig machen kann, dass ich hands on lernen kann, kamen diese fragen recht unbelesen. Ich danke dir für deine Aussage, dass der AVR keinen hardware-handshake kann - das hat mir jetzt einiges einfacher gemacht! Wenn noch irgendjemand eine aussage zu den SPI-Pins (Beschaltung/Pulldown/up) machen könnte wäre das toll - wenn nicht muss ich halt mit dem board warten bis "nach dem lesen", was auch ok ist. Wobei ich dazu sagen möchte dass ich durchaus meine datenblätter durchschaue. Aber ich denke jeder kennt es: Man sieht insbesondere das, womit man bereits etwas verbindet. Ich verknüpfe noch, viele Verbindungen sind also noch nicht da ;-)
> wenn nicht muss ich halt mit dem board warten bis "nach dem lesen", was > auch ok ist. Das wird das Beste sein.
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.