Moin, Stolpere grade über was. Das HC-05 BT Modul kann zwar in Baud Rate, Parity und Stop Bits eingestellt werden. Scheinbar (in verschiedenen Datenblätter) gibt aber keine Möglichkeit von 8bit auf 7 bit Daten zu stellen. Sehe ich das richtig oder habe ich nur Tomaten auf den Augen ? Wundert mich doch ein wenig. Background: Ein altes Laufschritt Display wurde von mir mit einem HC-05 "Aufgerüstet" (+nen max3232 und ne nen 3,3 Volt Regler +Hühnerfutter einfach direkt an die RS232 Schnittstelle gelötet) Das Display selber kann 8n1 oder 7E2 bei 9600 soweit also kein Problem. Allerdings lässt sich mit 8n1 der Speicher nicht auslesen, weil das Display immer mit 7E1 sendet. Das kann mann leider auch nicht umstellen. Alternativen ? nen tiny auf den Sende Weg einschleifen der über soft USRAT und hardware USART ne 7E2 to 8N1 bridge basteln ? Anderes BT Modul (ich brauch quasi nur SPP/rfcomm 9600,7E2)
Arbeite mit 8n1. Was passiert, wenn ein Empfänger auf 8n1 gestellt ist, der Sender aber mit 7e1 sendet? Es gibt keinen Framing-Fehler, weil inklusive Start- und Stopbits ebenfalls 8 Bits übertragen werden. Es gibt keinen Paritätsfehler, weil bei "n" keine Parität ausgewertet wird. Und wo landet das "e"? Genau: Im obersten Datenbit, das bei 7 Bit nicht genutzt würde. Also nach Empfang einfach das Bit 7 ausmaskieren, fertig. Wenn die Anzahl der Stopbits sich unterscheidet (Du schreibst sowohl 7e1 als auch 7e2), musst Du beim Empfang mit 8n1 nichts berücksichtigen, beim Senden aber kann es sein, daß Du zwischen den einzelnen gesendeten Zeichen mehr Zeit lassen musst, da es sonst zu einem Framing-Fehler kommt. Die bekommst Du hin, wenn Du mit 8n2 sendest -- das zusätzliche Stopbit ist nichts weiter als eine 1-Bit-Sendepause. Probier's aus, entweder 8n1 oder 8n2.
Danke ich denke wird nicht klappen Das Display sendet immer in 7E2 (oben einmal falsch geschrieben) ich kann es mit 7E2 oder 8n1 beschicken. 8n2 mag das Display nicht.
Gast
#3264855
>8n2 mag das Display nicht.
Bedeutet das nicht, dass Dein Display ausschließlich auf
Dauer-Endlos-Datenemfang steht?
Normalerweise können hinter einem Datum tausende 0-en stehen, nur nicht
weniger als angegeben. Wecken ist erst beim Startbit angesagt.
amateur schrieb: >>8n2 mag das Display nicht. > > Bedeutet das nicht, dass Dein Display ausschließlich auf > Dauer-Endlos-Datenemfang steht? Mag sein das ich noch zu müde bin, aber ja natührlich steht das Display dauer empfang. > Normalerweise können hinter einem Datum tausende 0-en stehen, nur nicht > weniger als angegeben. Wecken ist erst beim Startbit angesagt. Ja hinter einem Datum, aber nicht nicht nach jedem Datum wenn viele Daten nacheinander bermittelt werden müssen. Eine Senden zum Diplay in mindestest 10 Byte lang. Das ist Grob aber nur das Protokol an sich und Steuerdaten. Würde dann noch die eigentlich Nutzlast dazukommen (also der text zum anzeigen)
Irgendwie macht das keinen Sinn für mich, was du da schreibst Marc! Wer benutzt denn noch 7bit Kommunikation? Du willst also dessen Speicher auslesen, der (implizit) intern 8bit organisiert ist. Das Modul sendet aber nur im 7bit Format und läßt sich auch nicht so umstellen, daß es 8bit in z.B. 2x 7bit sendet? Wenn das so ist, hat es eben einen Implementierungsfehler. Den kannste dann auch nicht beheben. Oder willst du was anderes?
Gast
#3264901
@Marc Dann scheint dein Display kein "echtes" asynchrones Protokoll zu verwenden. Es mag ja richtig sein, dass eine Anweisung aus mehreren "Bytes" besteht, und somit ein Befehl nicht ausgeführt werden kann, wenn er unvollständig ist. Aber außer, wenn es von "außen" aufgesetzt wurde, gibt es zwischen den Daten keine Zeitvorgabe. Natürlich sollte das Minimum (Stoppbits) nicht unterschritten werden, aber das ist ja selbstverständlich. Irgendwie habe ich das Gefühl, dass Dein Problem an anderer Stelle liegt. Schaffen beide Treiber die vorgeschriebenen Spannungen? Ist Deine Verbindung auch nicht zu lang?
Abdul K. schrieb: > Irgendwie macht das keinen Sinn für mich, was du da schreibst Marc! Wer > benutzt denn noch 7bit Kommunikation? Na heute Hoffentlich niemand mehr, aber vor 10 Jahren als das auch schon "veraltet" war war es nunmal so. > Du willst also dessen Speicher auslesen, der (implizit) intern 8bit > organisiert ist. Das Modul sendet aber nur im 7bit Format und läßt sich > auch nicht so umstellen, daß es 8bit in z.B. 2x 7bit sendet? Wenn das so > ist, hat es eben einen Implementierungsfehler. Den kannste dann auch Nein das Display sendet fest in 7E2, Nein keine Möglichkeit das Umszustellen. Nein kein Implementierungsfehler, 7 bit reichen da alle Befehle und Ascii Zeichen reinpassen. Der Fehler ist hier einzig das HC-05 BT Modul zu verwenden das scheinbar kein 7bit Mode hat (was auch meien frage war) Für die die es Interesiert http://www.alpha-american.com/p-alpha-4160r.html Das ding habe ich.
amateur schrieb: > Irgendwie habe ich das Gefühl, dass Dein Problem an anderer Stelle > liegt. Schaffen beide Treiber die vorgeschriebenen Spannungen? Ist Deine > Verbindung auch nicht zu lang? Leider ein falsches und trügerisches gefühl. Zu Lange Leituing über BlueThoot ja ? Aber um dich zu beruhigen... Mit nem eh Kabel ist ALLES Schick, denn die Hardware Schnitstell vom PC kann ich einstellen wie ich lustig bin. Das Display KANN 8n1 lesen, damit kann ich es auch über das HC-05 ansteuern geht auch. Nur wenn das Display was zu sagen hat schict dieses das nur mit 7e2 raus. Das mag schon der RX vom BT modul nicht und die Daten kommen als müll an.
7e2 meint bei dir 7 Datenbits, even-parity und dann noch 2 Stopbits? Das sollte jeder 8N1 UART empfangen können, denn das Parity-Bit wird einfach zum 8. Datenbit und wieviele Stopbits danach folgen, ist uninteressant. 1 Stopbit ist nur einfach ne Pause - die vom Nichtsenden von Daten nicht unterschieden wird und auch nicht kann. Einen Status "Leitung nicht belegt" gibt es nicht bei RS232. Früher gabs noch UART, die überprüften tatsächlich ob bei eingestellten 2 Stopbits diese auch wirklich (in Empfangsrichtung) stattfanden. Andernfalls gabs einen sogenannten Framing-Error. Und da davor, waren die Stopbits Platzhalter für den nicht sonderlich zeitsynchronen Wagenrücklauf.
Abdul K. schrieb: > 7e2 meint bei dir 7 Datenbits, even-parity und dann noch 2 Stopbits? Das > sollte jeder 8N1 UART empfangen können, denn das Parity-Bit wird einfach Ja meint es und nein klappt nicht, da kommt nur Müll an. Mus mir das ggf noch mal in HEX oder Binät ankucken aber das zweite Stop Bit wird scheinbar schon in das nächste byte geschoben. Das Prüf ich aber noch dieses Wochenende das BT Modul scheint das auch eher empfindlich zu sein. Die sauberste Lösung wäre ja nun wirklich nen BT Modul das 7 Bit kann. Das BTM222 kann aber auch keine 7 bin Übertragung wenn ich richtig lese. Gibt da noch andere im schmalen low cost BEreich Bleibt sonst noch noch nen Tiny dazwichen zu frimel der das für mich umsetzt aufder Display sende Richtung oder auf auslesen zu verzichten
Offensichtlich hat das Modul ein Problem mit der Länge des Stopbits. Kann man sich kaum vorstellen, da intern sicherlich ein Standard-UART arbeitet. Stimmt die Baudrate? Es dürfen auch keinerlei Transienten vorhanden sein, denn die triggern die Startbit-Erkennung. Da hatte ich schonmal ein Problem mit Cypress PSoC. Die haben keine gescheite Transientenunterdrückung. Was dann dazu führt, daß eine verrauschte Leitung an einem PSoC massive Störungen in den empfangenen Bytes erzeugt, während ein Standard-PC einwandfrei empfängt.
Gast
#3265033
Hallo, Als Besitzer 2er HC-05 wunder ich mich: das HC-05 hat zwar keinen 7-bit Mode, kann aber 8N2. Setzen mit AT+UART=<baudrate>,2,0 Beim Senden einfach mit 7E2 senden, und das Parity wandert transparent als 8. Datenbit durch das HC-05 Beim Empfangen dito bezüglich des HC-05. Standardmäßig ist der HC-05 auf 8N2, und damit gehts vermutlich per DEfinition schon mal nicht. Wo hab ich nun was falsch verstanden und liege deshalb völlig falsch ? Gruß, Michael
Gast
#3265039
Sorry, 2 Stopbits werden als 1 kodiert. Gruß, Michael
Abdul K. schrieb: Stimmt die Baudrate? Ja klar 9600 nicht schneller und nicht langsamer > Es dürfen auch keinerlei Transienten > vorhanden sein, denn die triggern die Startbit-Erkennung. Das ist doch ne nützliche Infomation. Das werde ich prüfen. Wobei ich fast davon ausgehe das das Signal Sauber ist. Die Schnitstelle ist ne Combi RS232 / RS432 schnitstelle. Da sind schon ordenlich Dioden und Block C verteilt. Sind so jedenfals Grundsolide & indutrieproof aus.
Mach mal 100pF parallel ;-)
Gast
#3265073
Hallo, das BT-Modul ist IMHO nicht zu empfindlich, sondern es macht mit 8N1 zwischen den Daten keine ausreichende Pause. Gruß, Michael
micha54 schrieb: > das BT-Modul ist IMHO nicht zu empfindlich, sondern es macht mit 8N1 > zwischen den Daten keine ausreichende Pause. Also sollte es auf 8n2 konfiguriert werden. Ein Problem gibt es dann nur, wenn das Display beim Senden mit 7e2 zwischen den Daten unzureichende Pausen macht ...
Machen wir es kurz und schmerzlos: Gelöst danke Rufus, denn er hatte gleich den richtigen tipp. Hab mir die Daten grade noch mal genau angeschaut. Das BT Modul steht weiterhin auf 8N1 auf der URAT Seite, Senden tu ich aber mit 8N2 über den BT Link. Das Funktioniert ohne das irgendwas am timing drehen müsste. Perfekt, denn ein gestecktes Ziel war das ich ggf. auch mit einem 08/15 Terminal texte zum anzeigen bringen kann. Beim Auslesen kommen die Daten die natürlich schief an, und genau da hat Rufus den richtigen einfach gehabt. 7 Bit ausmaskieren und aus den RAW Daten werden Nutzdaten. danke Nachwort: Seltsam finde ich aber immer noch das der URAT von BT Modul auf 8n1 stehen Mus, mit 8N2 bekomme ich keine Validen Daten ins Display (und kann damit natürlich auch kein Senden veranlassen). Fiese kleine Timing Geschichten.... @Abdul hab mir dennoch grade mal die Signale auf meinen Scope angeschaut. Sehe nicht einmal typische Überschwinger bei der steigenden Flanke (bei 200Mhz bei 2Gb/s)
Du läßt mich an meinem UART-Verständnis zweifeln. Bislang dachte ich die Teile komplett im Griff zu haben. Oder du kannst dich einfach nicht sauber ausdrücken? Sei es drum. Wenns jetzt geht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.