Bascom UART Input - Versionsgeschichte

Krulli_alt: typos

2007-02-26T01:05:31Z

typos

PicNick: /* OVERLAY */

2006-01-26T08:30:13Z

‎OVERLAY

PicNick: /* Siehe auch */

2006-01-22T15:56:33Z

‎Siehe auch

PicNick: /* Byte-Stuffing */

2006-01-21T17:17:30Z

‎Byte-Stuffing

PicNick: /* Byte-Stuffing */

2006-01-20T15:20:46Z

‎Byte-Stuffing

PicNick am 20. Januar 2006 um 15:17 Uhr

2006-01-20T15:17:13Z

PicNick am 20. Januar 2006 um 12:35 Uhr

2006-01-20T12:35:49Z

Neue Seite

==Bascom UART Input==

==Autor==
* [[Benutzer:PicNick|PicNick]]

==Siehe auch==
* [[Avr]]
* [[Bascom]]

[[Kategorie:Robotikeinstieg]]
[[Kategorie:Microcontroller]]
[[Kategorie:Software]]
[[Kategorie:Quellcode Bascom]]

@@ Zeile 15: / Zeile 15: @@
 ===OVERLAY===
-Ein sehr häufige Anwendung von OVERLAY ist das Redefinieren von mehrbytigen Feld-Typen wie WORD, LONG, SINGLE, etc. für seriele Input/Output-Zwecke
+Ein sehr häufige Anwendung von OVERLAY ist das Redefinieren von mehrbytigen Feld-Typen wie WORD, LONG, SINGLE, etc. für serielle Input/Output-Zwecke
 <pre>
 DIM Redef_word  AS WORD
@@ Zeile 34: / Zeile 34: @@
-Ein weiter Möglichkeit ist es, einen Speicherbereich, den 5 Felder insgesamt einnehmen, einfach ein zweitesmal zu definieren, diesmal aber als einfaches Byte-Array.
+Ein weiter Möglichkeit ist es, einen Speicherbereich, den 5 Felder insgesamt einnehmen, einfach ein zweites mal zu definieren, diesmal aber als einfaches Byte-Array.
 <pre>
 DIM Msgbyte1 as Byte
@@ Zeile 150: / Zeile 150: @@
 Recht geschickt ist es aber auch, im ersten Byte der Message gleich die Länge der Message zu senden, dann können auch variabel lange Nachrichten richtig transportiert werden. Das letzte Byte wiederum könnte die Check-Sum beinhalten.
-'''Anmerkung:''': Diese Beispiele mit Text-Messages dienen nur der Demonstation. Das Verfahren ist aber voll-transparent, kann also alle Bytewerte von 0 - 255 beinhalten.
+'''Anmerkung:''': Diese Beispiele mit Text-Messages dienen nur der Demonstration. Das Verfahren ist aber voll-transparent, kann also alle Bytewerte von 0 - 255 beinhalten.
 Statt des (willkürlich) gewählten Zeichens "A" nimmt man in der Praxis besser eines, das statistisch selten vorkommt, wenn sich das überhaupt ermitteln läßt.

@@ Zeile 15: / Zeile 15: @@
 ===OVERLAY===
-Ein Möglichkeit ist es, den Speicherbereich, den diese 5 Felder insgesamt einnehmen, einfach ein zweitesmal zu definieren, diesmal aber als einfaches Byte-Array.
+Ein sehr häufige Anwendung von OVERLAY ist das Redefinieren von mehrbytigen Feld-Typen wie WORD, LONG, SINGLE, etc. für seriele Input/Output-Zwecke
 <pre>
 DIM Msgbyte1 as Byte
@@ Zeile 42: / Zeile 61: @@
     End If
 </pre>
 Es '''muß''' vor Inkey() sichergestellt sein, daß auch tatsächlich ein Zeichen eingelangt ist, denn Inkey() würde, wenn nichts da ist, 0x00 zurückgeben. Dieses 0x00 können wir aber von einem "echten" 0x00, das ja möglich wäre, nicht unterscheiden. Daher vorher "IsCharWaiting()". In einer Receive-ISR ist das natürlich nicht erforderlich, denn da ist immer ein gültiges Zeichen da.
 ===Message-Header und Trailer===

@@ Zeile 84: / Zeile 84: @@
 </pre>
-{{Baustelle|PicNick}}
+Der Empfänger
 ==Autor==

@@ Zeile 68: / Zeile 68: @@
 '''Beispielscode:'''
 Vielleicht klingt das kompliziert, ist es aber nicht
@@ Zeile 83: / Zeile 84: @@
 </pre>
+{{Baustelle|PicNick}}
-−
-−
 ==Autor==

← Nächstältere Version		Version vom 20. Januar 2006, 15:17 Uhr
Zeile 1:		Zeile 1:
	==Bascom UART Input==		==Bascom UART Input==
		+	An sich hat Bascom eine ganze Reihe von recht praktischen Befehle für die Daten Ein- u. Ausgabe über den UART. Solange sich Sender und Empfänger immer darüber einig sind, ob gerade ein Byte oder ein Single transferiert wird, ist man hier gut bedient.
		+
		+	Wenn man aber wegen anderer Beschäftigungen des Kontrollers den Empfang asynchron gestalten will, zeigen sich ein paar Widrigkeiten. Denn der Uart empfängt seine Daten immer als eine Reihe von einzelnen Bytes und es müssen daraus erst wieder die richtigen Felder zusammengesetzt werden. Verschärft wird das, wenn auch noch mehrere, womöglich verschiedenartige Felder zu empfangen sind, die erst zusammen einen Sinn ergeben, also zum Beispiel strukturierte "Messages"
		+	===Mehrere Felder (Message)===
		+	Das ist gewissermaßen die Aufgabenstellung:[[Bild:Bascinput1.png]]
		+	<pre>
		+	DIM Msgbyte1 as Byte
		+	DIM Msgword as Word
		+	DIM Msgbyte2 as Byte
		+	DIM Msglong as Long
		+	DIM Msgbyte3 as Byte
		+	</pre>
		+	All diese Felder sollen hintereinander empfangen werden. Die Reihenfolge wäre nicht so schlimm, aber wie macht man z.B. aus 4 einzelnen Bytes ein "Long" ?
		+
		+	===OVERLAY===
		+	Ein Möglichkeit ist es, den Speicherbereich, den diese 5 Felder insgesamt einnehmen, einfach ein zweitesmal zu definieren, diesmal aber als einfaches Byte-Array.
		+	<pre>
		+	DIM Msgbyte1 as Byte
		+	DIM Msgword as Word
		+	DIM Msgbyte2 as Byte
		+	DIM Msglong as Long
		+	DIM Msgbyte3 as Byte
		+
		+	DIM Buffer(9) as Byte AT Msgbyte1 OVERLAY
		+	</pre>
		+	Dadurch entsteht:
		+	[[Bild:Bascinput2.png]]
		+	Zu dem Buffer-Array wird natürlich auch ein Index mit dem Anfangswert 1 benötigt
		+	DIM Bufferindex as Byte
		+	Bufferindex = 1
		+
		+	Wenn nun zu einem x-beliebigen Zeitpunkt ein Byte empfangen wird, wird es in den Buffer geschrieben
		+	<pre>
		+	IF IsCharWaiting() <> 0 then
		+	Buffer(Bufferindex) = INKEY()
		+	incr Bufferindex
		+	IF Bufferindex > 9 then
		+	'------------- Alle Datenfelder komplett, jetzt verarbeiten oder signalisieren ----------------
		+	Bufferindex = 1 ' Index zurücksetzen
		+	End If
		+	End If
		+	</pre>
		+	Es '''muß''' vor Inkey() sichergestellt sein, daß auch tatsächlich ein Zeichen eingelangt ist, denn Inkey() würde, wenn nichts da ist, 0x00 zurückgeben. Dieses 0x00 können wir aber von einem "echten" 0x00, das ja möglich wäre, nicht unterscheiden. Daher vorher "IsCharWaiting()". In einer Receive-ISR ist das natürlich nicht erforderlich, denn da ist immer ein gültiges Zeichen da.
		+
		+	===Message-Header und Trailer===
		+	Das gezeigte Prinzip hat natürlich für eine praktische Anwendung einen gravierenden Nachteil: Wenn wegen Überlastung oder sonstigen Gründen der Empfänger auch nur ein Byte versäumt, kommt er eigentlich nie oder nur zufällig wieder zu den richtigen Daten.
		+	*Bei ASCII-Daten kann natürlich ein Steuerzeichen (<CR>) als Kennzeichen verwendet werden, daß als nächstes wieder eine neue Message beginnt.
		+	*Haben wir es aber mit "transparenten" Daten zu tun, also Bytes mit 0-255, haben wir keine solchen reservierbare Kennzeichen.
		+
		+	====Checksum====
		+	Als erste Sicherung ist es mal gut, solche verstümmelten Messages als solche zu erkennen. Das löst zwar nocht nicht das genannte Problem, aber wenigstens ist die Gefahr falscher Daten abgewendet. Da gibt es viele Varianten, CRC, BCC und andere. Das sind Prüfziffern, die man hinten an die Message anhängt. Der Sender erstellt sie, der Empfänger prüft.
		+
		+	====Byte-Stuffing====
		+	Das ist das Verfahren, doch irgendein Zeichen als Steuerzeichen verwenden zu können, indem der Sender gezielt Bytes in den Byte-Stream "reinstopft" (stuffing), die nur zur Kennzeichnung dienen, ob ein Byte "echt" ist oder Teil der Daten ist. Der Empfänger entfernt sie dann wieder.
		+	Dabei gilt folgende Regel: Folgt diesem Steuerzeichen ein beliebiges anderes Zeichen, ist es
		+	auch wirklich ein Steuerzeichen. Wenn nicht, gehört dieses Folgebyte zu den Daten
		+
		+	Da jedes Zeichen recht ist, hier ein Beispiel mit dem Zeichen "A", das einfach zum Message-Beginn-Steuerzeichen erklärt worden ist.
		+	Die Zeichenfolge "Hello, World" ist zu übertragen. Der Sender schickt also einfach
		+	"AHello, World" über die Leitung (A=Header, das andere eben irgendeine Nachricht)
		+	Das war nun offensichtlich kein Problem, es ist kein Mißverständnis möglich<br>
		+	Aber nun:
		+	"Guten Abend" Losgeschickt wird nun
		+	"AGuten AAbend"
		+	Das erste "A" wird von einem "G" gefolgt, also gilt es auch als Header
		+	Dem zweiten "A" folgt aber ein weiteres "A", also fällt es weg und es bleibt nurmehr "Abend" übrig
		+
		+	'''Beispielscode:'''
		+	Vielleicht klingt das kompliziert, ist es aber nicht
		+
		+	Der Sender
		+	<pre>
		+	DIM Buffer(9) as Byte
		+	DIM BufIdx as Byte
		+	PRINT chr("A"); ' der Header wird gesendet
		+	for Bufidx = 1 to 9
		+	if Buffer(BufIdx) = "A" then
		+	PRINT chr("A"); ' ein "A" wird "reingestopft"
		+	End If
		+	PRINT Buffer(BufIdx);
		+	next
		+	</pre>
		+
		+

@@ Zeile 146: / Zeile 146: @@
 [[Kategorie:Microcontroller]]
 [[Kategorie:Software]]
 [[Kategorie:Quellcode Bascom]]