Allgemeine Fragen zum Thema UART-Übertragung zwischen 2 Controllern
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.
Hinweis kann nach Kenntnisnahme deaktiviert werden!
-
-
Hast du es auch schon mal so probiert?
BASCOM-Quellcode
- Autostart_abfrage:
- Incr Q
- If Q = 6 And Programm = 4 Then
- Q = 0
- Toggle F
- Else
- If Q = 50 Then
- Q = 0
- Toggle F
- End If
- End If
- If F = 1 Then
- If Programm = 4 Or Programm = 3 Then
- Lcdat 4 , 91 , La2
- Else
- Lcdat 4 , 91 , La
- End If
- Else
- Lcdat 4 , 91 , " " , 0
- End If
- Daten(3) = La
- Daten_byte = La 'Daten(3)
- Gosub Senden
- Return
Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem. -
hat sich wohl überschnitten. Ja das hatte ich die ganze Zeit. Geht nicht.
-
nochmal HAAALT!
Also jetzt wirds ganz verrückt:
Jetzt wir in dem FB-Oled Oben rechts satt der "64" eine "250" angezeigt. Das ist ja wol das Startbyte...
Unten rechts bei "Tempo" flackert die Anzeige hin und her zwischen dem eingestellten Encoder-Wert und der Zahl "64".
Ich schliesse daraus: Die Übertragung findet wohl statt, aber nicht richtig (von mir) adressiert. Oder die Auswertung in der FB ist nicht richtig. -
hier ist das Video dazu:
Man sieht, daß der eingestellte Encoder Wert vom rechten OLED "97" auch auf dem linken dargestellt wird, aber
durch die Variable LA (64) ständig überschrieben wird
-
Wie schon gesagt, deine Übertragung ballert alles raus und dein Empfänger kommt nicht hinterher. Mit der Reduzierung der Geschwindigkeit bist du jetzt auch in die richtige Richtun gegangen.
Du benutzt inkey im URXC Interrupt, was dort nicht nötig ist. Hol doch einfach das Byte aus dem UDR, du bist doch schon da?
Was passiert, wenn die Zahl 250 nicht im Datenstrom kommt, also verschluckt wird?
Dein Speicherbereich läuft über in andere Daten, die nicht verändert werden dürfen.
Was passiert, wenn deine Daten, also das 2. oder 3. Byte, den Wert 250 enthalten?
Es würden 2 Abfragen im Interrupt wahr.
Die rohen Daten per Printbin zu übertragen, finde ich nicht elegant, dafür ist Ascii mit seinen Steuerbytes viel besser geeignet. Du hast ja keine Not mit der Zeit, dass du gleich an die Grenze gehen musst.
Ausserdem ist es sicher recht mühsam und frustrierend, wenn es nicht klappt. -
Hohe Datenübertragungsgeschwindigkeiten ohne Datenflusskontrolle (was aber zwei weitere Ports am µC erfordern würde, der MAX232 kann ja vier Leitungen händeln) finde ich ohnehin sehr mutig.
An Leitungen mangelt es dir ja nicht da du zur Verbindung ohnehin ein Kat-5-Kabel verwenden möchtest. -
die anderen 6 Leitungen vom cat5 sind alle belegt. Habe jetzt die Baudrate auf 9600 runter: Keine Verbesserung.
Die Übertragung mit 2 Variablen (Tempo und Menüauswahl) funktioniert ja schon- zwar etwas verzögert, aber damit kann ich leben.
Ich vermute da stimmt etwas im Code nicht. Hab übrigens auch schon von inkey() auf UDR umgestellt.
Umstellen auf ASCII wäre dann noch die Option.
Nur zu meinem Verständnis: Bei der senden-Sub ist doch das "daten_byte" ein Transportmittel, daß sich mit daten(1) bis daten(10) befüllen läßt und dann
zum Empfänger rübergeschickt wird? Jedenfalls klappt das mit daten(1) und daten(2) problemlos -
"Ich dachte, ich kann im Hauptprogramm die Variable LA als DATEN(3) bezeichnen, versenden und im FB Programm wieder weiterverarbeiten?!"
Klar, zwischen Zeile 2401 und 2402 Printbin Daten(3) sollte gehen. Deiner Empfangsroutine ist egal wieviele Bytes kommen - ab dem 10. schreddert sie die anderen Variablen und schreibt bis zu 255 Bytes ins Ram bevor sie wieder bei Daten(1) auskommt solange bis sie ein Stop (251) erkennt. Dann beginnt sie wieder bei Daten(1).
In der FB wird auch dann La beschrieben wenn keine Daten(3) gesand wurden. Muß kein Problem sein nur nicht wundern wenn Blödsinn drinn steht falls nie eins gesannt wurde, sonnst nimmt er immer den letzten bekommenen Wert
Irgendwie hänge ich jetzt mehr als 5 Stunden hinterher. Es geht nicht daten_byte = Daten(3) damit würde nur ein Datenbyte gesendet das dann in Daten(2) landet. Es müssen mehrere gesand werden.
Egal wie ob mit anderem Variablennamen oder einer Schleife liegt ganz an Dir
Nur zu meinem Verständnis: Bei der senden-Sub ist doch das "daten_byte" ein Transportmittel, daß sich mit daten(1) bis daten(10) befüllen läßt
daten_byte ist ein willkürloch genannter Variablenname eines Bytes da passt auch nur ein Byte rein.
Jedenfalls klappt das mit daten(1) und daten(2) problemlos
Ja weil Daten(1) kommt von Printbin Befehl_byte uns Daten(2) von Printbin Daten_byte die Daten(3) müssen auch ein Printbin andere_variable haben.Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()
-
Pluto, erstmal vielen Dank! Das war sehr anschaulich erklärt. ich habe die Senden-Sub mit dem printbin ergänzt.
Senden:
Printbin Daten(3)
Printbin 250 'Start-Byte
Printbin Befehl_byte
Printbin Daten_byte
Printbin 251 'Ende-Byte
Return
Es scheint wichtig zu sein, daß der printbin daten(3) Befehl NICHT zwischen 250 und 251 steckt. Wenn ich es nämlich tue, wird daten(1) falsch übertragen.
So kommt erstmal eine stabile "0" statt der 64 an (siehe Foto Anhang)
Leider kann ich Daten(3) alias LA immer noch nicht auf das OLED der FB übertragen und ich verstehs nicht. Ich tüftel weiter...Wenn noch jemand eine Idee hat, wäre sie sehr willkommen! -
Nachtrag: Das Problem muss auf der Senderseite liegen. Wenn ich in der URXC des Empängers ein freches
LA=64 definiere, wird die 64 auch im OLED angezeigt.
Uart0:
'inputbin daten(3)
Dat = Udr 'empfangenes Byte einlesen
If Dat = 251 Then 'Ende-Byte erkennen
Flag = 0
Neue_daten = 1
End If
If Flag = 1 Then 'Byte's in Empfangstabelle schreiben
Daten(z) = Dat
Z = Z + 1
End If
La = 64
If Dat = 250 Then 'Start-Byte erkennen
Flag = 1
Z = 1
End If
Return -
Eigendlich muß es dazwischen. Vor dem Start ist das Flag 0 womit nichts gespeichert wird. Erst nachdem ein Start erkannt wurde werden die darauffolgenden Bytes gespeichtert in der Reihenfolge in dem sie ankommen. Befehl_byte wird Daten(1) da z eins ist Datenbyte wird zu Daten(2) u.s.w. bis ein Stop empfangen wird. Vielleicht mal versuchsweise z ausgeben ( und daten1-4). Es sollte um eins höher sein als die Anzahl der empfangenen Bytes. Oder einen Terminal dazuklemmen um zu sehen was das schiefläuft.
Überschneidung - Zeigt er auch 64 wenn dort Daten(3)=64 stehen würde?Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pluto25 ()
-
Pluto25 schrieb:
Zeigt er auch 64 wenn dort Daten(3)=64 stehen würde?
Es gibt dann ja nur 2 Möglichkeiten:
Die URXC der FB filtert Daten(3) nicht korrekt heraus oder daten(3) wird nicht von der Senderseite aus übermittelt. -
Um das zu erkennen wäre ein PC mit serieller Schnittstelle gut. Einfach anschließen und Putty besser Hterm (das kann hex darstellen) starten und schaun was übertragen wird.
-
Pluto25 schrieb:
Eigendlich muß es dazwischen.
-
Pluto25 schrieb:
Um das zu erkennen wäre ein PC mit serieller Schnittstelle gut.
Nein, das muss auch so gehen. Irgendetwas (kleines) stimmt hier nicht im code. Überhaupt kein Vorwurf an Dich- im Gegenteil!
Es muss gelingen, neben dieser 250-251 routine ein weiteres Datenbyte zu übermitteln. DAs ist völlig inakzeptabel, dass das nicht geht.
Das MUSS gehen. Datenmenge und Geschwindigkeit sollten für die Übertragung ein Witz sein. Im Moment reden wir darüber, daß 2x pro Sekunde eine 64 übertragen werden soll. -
Was mir gerade auffällt, Die Hauptroutine des Fb knallt mit max speed rund. Versuchsweise mal ein Waitms 200 vor Zeile 85. Möglicherweise "verschluckt" der sich.
Wird das LCD nicht wahnsinnig wenn es 10000 mal pro sekunde das gleiche gesagt kriegt? -
moment...mach ich mal...
-
Pluto25 schrieb:
Wird das LCD nicht wahnsinnig wenn es 10000 mal pro sekunde das gleiche gesagt kriegt?
-
nein. Bremsen in der main der FB bringen gar nichts. La wird weiterhin als Null im FB Oled angezeigt