Eine einfache Frage. Ich möchte von einem Mikrocontroller Daten per Kabel zu einem Bluetoothmodul übertragen.(UART) Das Bluetoothmodul sitzt aber auf einem seperaten Board deshalb das Kabel. Jetzt meine Frage wie würdet ihr das Kabel belegen? Ich dachte an RX/GND/TX. Meint ihr das reicht oder sollte ich lieber mehrere GND-Leitungen mitführen? Abstand sind ca 10 cm. Danke
Willst du wirklich Software Handshake? Sonst noch RTS/CTS dazu.
Marcus schrieb: > Willst du wirklich Software Handshake? Sonst noch RTS/CTS dazu. Würde ich auch wärmstens empfehlen wenn man nicht grade Baudraten <=9600 Baud verwendet. Das Bluetooth Modul wird die Daten mitunter nicht rechtzeitig los, insbesondere wenn in urbaner Umgebung das 2,4GHz Band dicht ist.
Marcus schrieb: > Willst du wirklich Software Handshake? Sonst noch RTS/CTS dazu. Hab ich mir noch gar keine Gedanken drüber gemacht, dass das Probleme machen könnte. Klang immer überall so schön kompfortabel. TX/RX an Mikrocontroller anschließen und los gehts. Ich habe einen Atmega168 und ein RN41 Bluetoothmodul. Weiß gar nicht ob das überhaupt des HW-Handshakes mächtig ist. Außerdem habe ich soetwas noch nie implementiert weil ich es nie gebraucht habe. Ist das aufwendig in C zu implementieren? Kennt jemand gute Quellen wo man sich informieren könnte?
Die HW-Handshake Leitungen sind simple Logik Pegel. Diese sin Software auszuwerten ist vom Aufwand her einfach, als Taster abzufragen, da die Handshake Signale nicht prellen.
Tolle Doku vom Teil: Ganz vorne: Flow control:None In 3.3.0.2 WHICH HARD SIGNALS SHOULD I CONNECT? You should connect power, ground, RX, and TX. CTS should be low or you can connect or tie it to RTS. (Also doch Fake-HW Flowcontrol) Spätestens im HCI Modus brauchst du sie dann: 3.4.1 HCI over UART In this mode, the hardware interface between the host processor and the Bluetooth module is the UART. You must interface the flow control signals between the host processor and the Bluetooth module for the HCI interface to work. Failure to do so can cause the host processor and the Bluetooth module to become out of sync and break the Bluetooth link
Marcus schrieb: > Tolle Doku vom Teil: > > Ganz vorne: > > Flow control:None > > In > 3.3.0.2 > WHICH HARD SIGNALS SHOULD I CONNECT? > You should connect power, ground, RX, and TX. CTS should be low or you > can connect or tie it to RTS. > > (Also doch Fake-HW Flowcontrol) > > Spätestens im HCI Modus brauchst du sie dann: > > 3.4.1 > HCI over UART > In this mode, the hardware interface between the host processor and the > Bluetooth module is the UART. You must interface the flow control > signals between the host processor and the Bluetooth module for the HCI > interface to work. Failure to do so can cause the host processor and the > Bluetooth module to become out of sync and break the Bluetooth link Im Punkt 1.1 MCU Interface lese ich aber: "Connecting the hardware flow control lines CTS and RTS is highly recommended for applications that transmits a continuous stream of data." Nichts von Fake... (Ich habe hier das Datenblatt vom RN41 direkt von Microchip) Was hast du für ein Datenblatt gelesen? Das, was du als >(Also doch Fake-HW Flowcontrol) bezeichnest, sehe ich als Möglichkeit der Beschaltung, wenn man kein Hardwarecontrol braucht.
Da habe ich mich wohl vertippt. Ich habe ein RN42 nicht RN41. Aber was ich auf die schnelle gelesen habe sollten die ziemlich gleich sein bis auf die Sendeleistung. Die Angaben in der Doku sind tatsächlich merkwürdig. Aber mal angenommen es gibt Hardware-Flusssteuernuzg im RN42 dann müsste ich theoretisch den RTS Pin vom RN42 auf einen Interrupt am Mikrocontroller legen. Der RTS Pin geht auf high wenn der MC aufhören soll zu senden und auf low wenn er weitersenden kann. Heißt also ich müsste steigende und fallende Flanken mit dem Interrupt abfangen und das Senden dementsprechend unterbrechen oder fortsetzen. Richtig? Angenommen für den Fall dass das BT-Modul nur senden soll und nicht empfangen.
Bzw. müsste ja auch gar kein Interrupt sein. Könnte ja auch einen stinknormalen GPIO nehmen und jedesmal vorm Senden den Pin anfragen und wenn er high ist eben nicht senden und die Daten in einen FIFO-Puffer schreiben.
Okay hab jetzt nochmal in diversen Datenblättern/Dokus zu dem RN42 gelesen. Steht überall was anderes drin aber scheint doch so als könnte das Teil HW-Flow-Control. Ich kann aber keinerlei SPP-Befehl oder ähnliches finden wie man es ein- / bzw. ausschaltet. Anscheinend soll man CTS und RTS kurzschließen wenn man sie nicht nutzen will. Da ihr bei dem Thema ja Probleme gesehen habt (wahrscheinlich berechtigt) will ich es jetzt RTS vom RN42 auch mit über das Kabel verbinden. Reicht dass dann wenn ich am Mikrocontroller die RTS Leitung auf einen Pin lege und den vor dem Senden abfrage, oder wie würdet ihr das machen? Mein Kabel würde dann 4 Adern haben. | TX/GND/RX/RTS |
Nimm CTS. Mit CTS signalisiert das "Modem", dass es bereit ist, Daten zu senden.
Stefan U. schrieb: > Nimm CTS. Mit CTS signalisiert das "Modem", dass es bereit ist, Daten zu > senden. Okay. Aber der CTS Pin am RN42 ist doch ein Input. Wie soll der dem Mikrocontroller signalisieren, dass er aufhören soll Daten an das Modul zu senden?
> Aber der CTS Pin am RN42 ist doch ein Input.
Hmm, das ist komisch. Vielleicht haben die das Reverse beschriftet. Ist
TxD auch ein Input? Das würde dann passen, dann musst du doch RTS
nehmen.
Angehängte Dateien:
-
RN42_Pins.PNG
8,4 KB
Stefan U. schrieb: > Hmm, das ist komisch. Vielleicht haben die das Reverse beschriftet. Ist > TxD auch ein Input? Das würde dann passen, dann musst du doch RTS > nehmen. Nein TX ist ein Output. Siehe Anhang.
Komisch, für mich siehst das so aus, als hätten die entweder DI und DO vertauscht, oder RTS und CTS. Weisst du was: Häng Leuchtdioden dran um festzustellen, welcher der beiden Pins wirklich der Ausgang ist.
Stefan U. schrieb: > Weisst du was: Häng Leuchtdioden dran um festzustellen, welcher der > beiden Pins wirklich der Ausgang ist. Ich bin noch in der Layoutphase. Das wird also schwierig da was dran zu hängen das leuchtet. Und da das BT-Modul nur senden soll muss auch die Flusskontrolle nur in eine Richtung stattfinden. Ich würde auch gerne aus Platzgründen nur den einen Pin verbauen.
Hab gerade nochmal bei anderen Modulen geschaut RN41 , einige BTMxxx, etc. auch dort ist der RTS Pin immer als Output geführt. Vom Namen her "Request to send" macht es ja auch Sinn dass es ein Output ist nur ob das dann für meine Zwecke der richtige Pin ist, das ist die Frage. Ich möchte ja nur dass der Mikrocontroller aufhört zu senden wenn das BT-Modul nicht hinterherkommt. Aber aus dieser Beschreibung : "UART RTS, goes high to disable host transmitter" würde ich rauslesen, dass der Pin auf High geht wenn es nicht hinterherkommt. Der Host ja in dem Fall der Mikrocontroller der dann eben "disabled" werden würde. Disable wäre in dem Fall einfach. Höre auf zu senden. So ganz versteh ich diese Flow Control Sache noch nicht.
> würde ich rauslesen, dass Ich auch, aber das ist einfach falsch! "Will der Rechner (DTE) Daten senden, so wird das über RTS signalisiert. Hat das Modem (DCE) sich mit dem entfernten Modem synchronisiert, dann wird dies über CTS signalisiert." https://de.wikipedia.org/wiki/RS-232#RTS.2C_CTS_und_RTR Ich bin mit dieser Technik aufgewachsen. Wir sind uns doch einig dass der µC der "Rechner" DTE ist und das Funkmodul das "Modem" DCE ist, richtig?
Beitrag #5236554 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Das Bild habe ich von http://www.bb-elec.com/Learning-Center/All-White-Papers/Serial/FAQ-RS-232-Connections-That-Work.aspx geklaut. Diese Seite beschreibt das ganze schlüssig, so wie ich es jahrelang genutzt habe.
Hmmm Tx sollte modemseitig auch ein Eingang sein. Da geht doch immer was durcheinander.
batman schrieb: > Hmmm Tx sollte modemseitig auch ein Eingang sein. Da geht doch > immer was durcheinander. Da geht doch ein roter Pfeil vom Computer zum Modem. Stimmt doch!
Ich glaube, die tun einfach so, als sei das Funkmodul ein DTE. Allerdings passt das dann wiederum nicht: "UART RTS, goes high to disable host transmitter" RTS heisst nämlich "Request to send" (ich möchte was senden). Bei diesem Modul bedeutet es aber so viel wie "ich bin nicht bereit". Über die Negation können wir mal hinweg sehen, dann ist es immernoch ein großer Unterschied, ob ich sage "Ich möchte etwas senden" oder "ich bin nicht bereit (etwas zu senden)". Das eine wäre ein Eingangssignal, das andere ein Ausgangssignal. Schöne Verwirrung. Man könnte meinen, diese Schnittstelle wurde gerade erst von Buschmännern erfunden und ihre Bedeutung noch nicht übersetzt.
batman schrieb: > Alfredo schrieb: >> Nein TX ist ein Output. Siehe Anhang. UART_TX ist der Ausgang der UART und nicht des Modems! Und es ist doch logisch, daß der Ausgang der UART auf den Eingang des Modems führt, oder nicht? Was bringst du denn hier alles durcheinander?
> Was bringst du denn hier alles durcheinander?
Damit hat der Hersteller des Moduls angefangen. Der würfelt alles wild
durcheinander.
Lindemann schrieb: > UART_TX ist der Ausgang der UART und nicht des Modems! Das Modem ist auch UART oder was glaubst du, was es ist.
Oh man... in dieser Doku hier steht auf Seite 3 etwas "Interessantes". Dort ist der RTS Pin des RN42 nicht als "Request to send" sondern als "Ready to send" beschrieben... http://www.mouser.com/ds/2/321/30086-RN-42-Bluetooth-Module-Guide-v1.0-709309.pdf
Tscha das ist halt die normale Schlamperei heutzutage. Keiner weiß mehr so genau, was er tut. Im Endeffekt bleibt nur Testen, obs geht. Ansonsten auf die I/O-Angaben setzen.
Alfredo schrieb: > Oh man... > > in dieser Doku hier steht auf Seite 3 etwas "Interessantes". Dort ist > der RTS Pin des RN42 nicht als "Request to send" sondern als "Ready to > send" beschrieben... > > http://www.mouser.com/ds/2/321/30086-RN-42-Bluetoo... Könnte was damit zu tun haben: https://de.wikipedia.org/wiki/Datenflusssteuerung#Datenflusssteuerung_durch_RFR.2FCTS_.28oft_f.C3.A4lschlich_als_RTS.2FCTS_bezeichnet.29
Jetzt kann man sich nicht mal mehr auf die Datenblätter der Hersteller verlassen. Also ihr würdet jetzt eher danach gehen das RTS als Output aufgeführt ist und den über das Kabel zum Mikrocontroller führen?
Naja wenn ich nur unidirektional vom Mikrocontroller zum Bluetoothmodul sende dann schon oder? Es wird nur TX (µC) mit RX (BT) verbunden. Dem Bluetoothmodul ist also relativ egal was der µC tut so lange es nicht mit Daten "verstopft" wird.
> Jetzt kann man sich nicht mal mehr auf die Datenblätter > der Hersteller verlassen Bei chinesischen Produkten ist das leider der Regelfall.
Stefan U. schrieb: > Bei chinesischen Produkten ist das leider der Regelfall. ... Nochmal eine generelle Frage. Die beiden Platinen werden aus der selben Spannungsquelle gespeist liegen aber natürlich räumlich getrennt. Sonst bräuchte ich das Kabel nicht. Macht es dann überhaupt Sinn die Masse mit über die Leitung zu schieben. Genereiert das nicht eine Massseschleife?
> Macht es dann überhaupt Sinn die Masse mit über die Leitung zu schieben. Das ist sogar unbedingt notwendig, weil sich die Signale der UART Schnittstelle auf GND beziehen. > Genereiert das nicht eine Massseschleife? Ein Draht ist noch keine Schleife. Wenn aber beide Geräte mit einem geerdeten (nicht potentialfreien) Netzteil oder per USB mit einem PC verbunden sind, dann hast du indirekt über die Erdung der Steckdose eine zweite Masse-Verbindung. Und das bildet dann zusammen mit deiner GND Leitung eine Schleife. Dennoch brauchst du die GND Leitung, denn eine geringe Potentialverschiebung auf der Steckdosen-Erdung von nur 0,5V würde schon zu einem Totalausfall der Kommunikation führen. Um dieses Dilemma zu lösen, wurde RS485 erfunden. Oder noch einen Schritt weiter: Ethernet. Da werden die beiden Seiten durch magnetische Übertrager getrennt und dort kann man dann deswegen tatsächlich auf die GND Leitung verzichten. Meine ganze Wohnung ist mit ungeschirmten Netzwerkkabeln ausgestattet, weil in meinem Altbau keine anständige Erdung (stattdessen Nullung) installiert ist. Bei mir hat jede Steckdose eine andere Spannung auf der Erdung. Wenn ich empfindliche Geräte miteinander verbinde, muss ich immer daran denken, sie zusammen in eine gemeinsame Steckdosenleiste zu stecken.
Stefan U. schrieb: > Ein Draht ist noch keine Schleife. Wenn aber beide Geräte mit einem > geerdeten (nicht potentialfreien) Netzteil oder per USB mit einem PC > verbunden sind, Die Schaltungen werden mit Batterien betrieben. Aber trotzdem ist wohl nicht davon auszugehen, dass auf beiden Platinen exakt das selbe Potential vorliegt. Danke
Exakt gleich sind 2 Potentiale nie aber darauf kommts auch nie an. :)
> Aber trotzdem ist wohl nicht davon auszugehen, dass auf beiden > Platinen exakt das selbe Potential vorliegt. Wenn ihre GND Potentiale miteinander verbunden sind und keine unerwarteten Ausgleichsströme fließen (wo sollten die her kommen?), dann werden sie mit Sicherheit exakt das selbe Potential haben. (ein paar µV Spannungsabfall zählen nicht)
Naja außer dem gemeinsamen Plus-/Minuspol der Batterie und der Kabelverbindung des USARTs haben die beiden Platinen nichts miteinander am Hut. Hohe Ausgleichströme sollten also nicht auftreten. Und auf den Platinen selbst sind auch nur Komponenten deren Stromaufnahme im mA-Bereich liegt. Nunja ich werde die GND-Leitungen im Kabel einfach einplanen und falls sie Probleme macht kann man sie immer noch kappen.
> falls sie Probleme macht kann man sie immer noch kappen.
Du wirst Probleme bekommen, wenn du sie kappst.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.