Hallo,
Kannst du nicht einfach beide Bytes nacheinander rausschicken und dies dann bei deinem Programm im PC berücksichtigen?
Martin
Hallo,
da ich beim letztensmal soviel erstklassige und schnelle Hilfe bekommen habe, habe ich mich nun richtig registriert.
Mein neues Problem ist, das ich eine Zeit mit dem 2313 messen möchte und diese am PC zu weiterverarbeitung benötige. Bisher mit dem 8Bit Timer war es kein Problem da hab ich das Byte einfach rausgeschickt und alles klappte. Aber nun soll es der 16Bit Timer sein. Wie mache ich den das jetzt am besten, damit ich das 1. und 2. Byte auseinander halten kann? oder muss ich hier ganz anders vorgehen?
Hallo,
Kannst du nicht einfach beide Bytes nacheinander rausschicken und dies dann bei deinem Programm im PC berücksichtigen?
Martin
Linus Torvalds, Entwickler von LinuxIch will Microsoft wirklich nicht zerstören. Das wird nur ein gänzlich unbeabsichtigter Nebeneffekt sein.
Würde ich nur sehr ungern tun. Wenn ich dann am PC mal ein Byte verpasse oder der Controller schon was gesendet hat bevor das Programm läuft. Würde ja ziemlicher Müll rauskommen, wenn die beiden Byte falschrum eingelesen werden.
Sende doch 4 Bytes. (Richtungserkennung).
00000001 daten1 00000010 daten2 oder sowas
Linus Torvalds, Entwickler von LinuxIch will Microsoft wirklich nicht zerstören. Das wird nur ein gänzlich unbeabsichtigter Nebeneffekt sein.
Du kannst im Register UCR einstellen(das bit heisst, meine ich CHR9), dass das UART 9-Bit lange "Bytes" sendet. Das zusätzliche Bit kannst du dann benutzen um die beiden Bytes als "erstes" oder "zweites" zu markieren.
Wie das mit deinem Empfangsprogramm harmoniert, weis ich natürlich nicht.
Ansonsten würde sich ein "Startbyte" anbieten, das jeder Übertragung vorrausgeht. Da dieser Wert aber dann in den anderen beiden Bytes nicht vorkommen darf, kriegst du keine vollen 16 bit mehr übertragen.
Oder du beschränkst das Ganze gleich auf 14bit und nimmst das MSB zum Unterscheiden der beiden Bytes.
Oder du nimmst ein Start- und 3 Datenbytes.
it works best if you plug it (aus leidvoller Erfahrung)
Das Problem mit dem Startbyte was x-ryder ja auch vorschlug, ist ja aber wie schon erwähnt. Das das Byte das so aussieht wie ein Startbyte auch ein Datenwert sein könnte. ein 9Bit Byte werd ich mir mal angucken. Wäre es aufwendig dirket klartext über die serielle zu sende? also statt das byte 0xff zB 255 und dann ein zeilenumbruch?
Ich würde ein Startbyte senden, dann die zwei Datenbytes und ein Prüfbyte, dass sollte reichen.
Ja, aber damit ist doch nicht das Problem gelöst das es möglich wäre das das Byte was ich lesen möchte genauso aussieht wie das Startbyte. Es gibt ja numal nur diese 256 Byte möglichkeiten und alle davon ergeben einen Sinnvollen Messwert. Wie soll man also sicherstellen, das gerade das Startbyte kam und kein Messwert ohne auf die 16Bit Auflösung zu verzichten?
Das einzige was ich mir vorstellen könnte wäre eine Klartext ausgabe. Das nicht das Byte geschickt wird sondern "Messwert: 65511" als Beispiel danach ein Zeilenumbruch. Vorteil wäre noch man könnte einfach ein Terminal Programm ranhängen und könnte ohne spezielle Software sehen was da so gemessen wird.
So ein Problem hatte ich auch mal, allerdings mit noch mehr bytes.
Ich hab es mit nibbles gelöst.
Beispiel: Du möchtest zwei Bytes schicken: 0xFE und 0x78.
Dann übertrage 4 Bytes so:
0x0F
0x1E
0x27
0x38
oberes Nibble als Index und unteres Nibble als Nutzdaten.
Das mit dem Klartext bietet sich an, wenn man in einer Hochsprache schreibt. Die haben meistens fertigen Methoden dafür(heissen meistens print oder so). In Assembler ist das recht aufwändig(schließlich musst du die Konvertierung der Zahlen in ASCI-Zeichen selbst einbauen.). Vielleicht findest du aber Routinen, die du nurnoch anpassen musst.
it works best if you plug it (aus leidvoller Erfahrung)
Lesezeichen