UART zwischen zwei Boards übertragen / Kabelbelegung

Willst du wirklich Software Handshake? Sonst noch RTS/CTS dazu.

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.

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?

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!

Alfredo schrieb:
> Nein TX ist ein Output. Siehe Anhang.

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?

Ein einseitiges Handshake? Macht das Sinn?

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.